It’s getting around that time when I’m spending more time working on the game as I realize how many little things need to be fixed, added, tweaked. I’ve recently given up most of my weekends now in an effort to get more hours in. I’m currently working 6 out of the 7 days a week on the game in some way. It’s mostly game programming, sometimes graphics, web development, emailing, phone calls, or getting business forms and other legal stuff squared away.

This week was a rather productive week on several fronts:

  • Got a lot of new art assets from Adam and implemented them
  • Feedback from testers started trickling in and the reaction has been positive along with tons of great suggestions/ideas
  • Fixed a lot of old bugs that were sitting in the queue
  • Improved some memory usage of textures

The week wasn’t without it’s headaches though. This completion date graph illustrates just how badly I estimated this week’s tasks:

Bad Estimates Ahoy!

The amount of tasks was unusually large for the past week, but the amount of tasks wasn’t as big an issue as some tasks taking 10 times longer than I wanted.

The biggest one was getting multi-threaded texture loading on the iPhone working. The hours I logged into getting it working is my own personal testament to how a seemingly simple task can blow up to ridiculous portions when you mention the word “multi-threading”. Had I known it’d take this long I would’ve opted for a more basic solution and leave it to a side project. The bright side is now I can load audio and graphics in parallel along with the main thread being able to continue any animations and such. It took about 20 hours to get it working and debugged, which is somewhat embarrassing haha!

Hair-pulling Threading Issues

It started with me wanting to off load the texture loading to another thread. Simple enough. I’ve done this before on other projects. It took a couple of hours to learn how to get OpenGL setup correctly to allow this. Then I discovered OpenGL wasn’t being the meanie, but a function call from core graphics wasn’t allowing me to call it from a background thread (sometimes…ugh). I researched it for a couple of days while finishing up other things, but wasn’t able to find anything conclusive. I then decided to take the leap and implement my own PNG loader using libpng as a base.  I mean really…how hard could it be? Hah…hah…ha…

Saying it was frustrating would be the understatement of the year, and last year. I usually try to avoid copy/pasting code as I like to read and understand the API I’m using so when it DOES break I’m not utterly clueless. Libpng’s interface is rather low-level and not exactly the cleanest. After reading documentation on it for what seemed forever I decided to start with an example program and modify it to fit my needs.

Let’s not forget that I’m an XCode/Unix newbie so getting libpng/zlib working as a static library in XCode was a nightmare for me. I ended up building from the source against the correct config’s and SDK’s for the iPhone to avoid the “invalid architecture” warnings. Next came actually implementing the loading. It looked pretty straight forward in all the examples I saw, except I wanted one feature I didn’t see in any of the sample code: be able to load non-power-of-2 textures onto the iPhone. All of the game’s assets are of various shapes and sizes, and several are non-power of 2. I haven’t taken the time to do proper texture atlasing and I wanted the ability to quickly drop any assets Adam sent me into the game’s folder and load it without fiddling with size alignments and the other mess.

This is where things started to get hairy because I was seeing issues crop up that weren’t necessarily from my code so I was lead astray a lot. The caveat is the iPhone has a rather special way of “compressing” PNGs. It took me a while to understand the implications of this because I could load the PNGs fine but holy shit were they rendering wrong in OpenGL! It finally dawned on me to change the blend function OpenGL was using. Much to my surprise I couldn’t find one that would give me the equivalent alpha blending that I got with premultiplied alpha’s. And I wasn’t about to go back and re-design all the assets. By this time I was pretty comfortable working with libpng and I decided to just write a custom transform function to premultiply the alpha when loading it to mimic the previous technique of loading:

Finally, you can write your own transformation function if none of the existing ones meets your needs. This is done by setting a callback with

png_set_read_user_transform_fn(png_ptr,
       read_transform_fn);

You must supply the function

void read_transform_fn(png_ptr ptr, row_info_ptr
       row_info, png_bytep data)

See pngtest.c for a working example. Your function will be called after all of the other transformations have been processed.

Alrighty, so now I can load things ~20 hours later. Talk about a huge step backwards. Doing the pre-multiplication at runtime is a trade off of convenience over speed. When it comes time to release the game I might consider doing this prior to compiling so the assets are “cooked”. But doing it at runtime adds about 1-1.5 seconds from my unscientific tests.

What’s amusing was once this was working it took 15 minutes to get multi-threading working. Now I decided to be adventurous and load the audio and graphics on separate threads from the main thread, for a total of 3. Speed tests show it’s on average no faster or slower than having both asset types be loaded in order on a single thread *Shrug*. Oh well, if the iPhone ever gets another core then I’ll be set ;). Ultimately, I now have the freedom to toss asset loading on a background thread while the game continues playing with minimal hit to the frames per second.

This  kind of thing is probably a bit advanced and overkill to do for such a simple and small game as Tilt To Live. If I have time (unlikely) over the next several weeks I’ll try to put together a complete code listing for those looking to have more control of their asset loading with libpng on the iPhone.

Tangible goals are key to any project. Without them I feel like I’m peddling up a steep hill just so I can peddle up some more. Scheduling and time logs showing time spent are great for statistical and historical purposes, but in the scheme of things can do little to save a project if you and your team lack that motivation needed to push the last mile. Countless indie games die from loss of interest. I’ve had several of my own projects fall by the wayside as other opportunities popped up that seemed more “fun”. As they say, the grass is greener on the other side :). But I would argue the overall motivation for those failed projects didn’t dropped per-say. It was just that a particular type of motivation wasn’t effective at getting that project done, and that the person failed to cultivate the right type of motivation to see it through…

Short Term Vs. Long Term Goals

When it comes to goal setting I tend to write my short-term, concrete goals down in some form. That list takes the form of a weekly schedule and to-do list. The longer term goals, such as “Finish game X” or even loftier ones such as “become a full-time independent developer” or even “Travel…somewhere…anywhere” kind of stay in my head constantly nagging away at me :). I find that when I’m not working directly on my game for a period of time the long term goals rear their head and eventually guide me back on course. But interestingly enough, the second I sit down in front of the computer to work my long term goals go out the window and short term goals kick in. This has had some pretty compelling implications on my work habits.

Some weeks I tend to faff about a good bit on YouTube, TED, RSS, IM, and other things throughout the work session. This happens even when I’m fully aware of the devil that is the internet. Now what happened between the time I was driving home from errands all hyped up about getting my game done and sitting down in front of my computer to make that dream a reality? I feel like my long term goals aren’t pushing me along anymore once I’m in a position to do actual work. What I’m finding is that I’m constantly looking at my to-do list and reminding myself how great it’ll be to finally have a a a good GUI system implemented this week to make the game hopefully look a little more…professional? I’m looking forward that following weekend to have a new build to push out to beta testers. I’m not looking forward to finishing game X on any given week, but finishing feature Y or bug Z. The important distinction here is that those short term goals have tangible results that are more easy to visualize while working.

Yes, I’m saying I have no idea how Tilt To Live will end up, I can only guess at that. I have a clearer image of how feature Y should work though. Maybe I should chalk this up to inexperience? It just seems so weird to me that there’s some sort of internal switch in my motivation based on the context of where I am at or doing at the moment that decides whether short term or long term goals will be the most effective. Realizing this will help push me more to create better weekly schedules so that my short-term goals are more tangible.

This seems obvious when you think about it, but I started thinking about how this applies to other things in life when I came across The Buried Life while listening to an Adam Corolla Podcast (doing laundry at the same time so not completely faffing about!). How many goals do people never see become a reality because they experienced my errand-to-computer dilemma? They got all hyped up about an idea, but when they were on that edge of opportunity they backed away not because they didn’t want to do it, but because they simply didn’t have any short term goals to push them over that edge? I’ll leave at that for now as it’s a bit heavier topic that I simply don’t have the time or qualifications to fully analyze at the moment. Back to my indie task at hand…

Gravity Well

Work in Progress Screenshot of "Tilt To Live"

As I’m approaching the final legs of production (and starting to get my shit together for promotion and marketing) tangible goals are harder to find and smaller. In the beginning, having a playable mock up was a huge step forward that could be completed in a single week. Nowadays it’s about getting X animation doing Y exactly correct so it’s timed with the audio to give the best feedback for the user. The amount of effort for both tasks is about the same, but the return on investment for me as a programmer is much smaller when doing these polishing tasks. But I know polish on a good game is what pushes it past “ok” to “good” and gets people talking about it.

In a large project, such as indie game, having long term goals are essential to getting you and/or your team to jump on the project. Without those short-term goals feeding your long term motivation, your motivation eventually starves and the project slowly dies.

This week’s partial tangible goal list:

tangibles

By Saturday that list will hopefully be empty, but it’s not the empty list I’m excited to see, but the fact that I’ll have a first pass of a tutorial system in the game by the end of the week :). Looking at this list I can tell my “scheduling skills” were a bit lacking and I know most if not all of the priority #2 cases will be moved to the following week because this week’s goal is to implement and polish a tutorial system. Hopefully, this won’t translate to another hour long fall through the rabbit hole they call the internet :|.

Oh, and in case anyone is wondering what task management system I’m using, it is called FogBugz. It’s been a treat to be able to use such a robust system, even if I’m a single developer.

colestanceI’m currently working on an editor for the next iteration of Gunstyle on the weekends. I find it’s a nice break from iPhone development and lets me start the week with renewed energy to work on Tilt To Live again. I’m using wxMax to develop the UI for the actual editor. It’s not much at the moment but it’s coming together slowly. The editor code architecture is taking a page from the Unreal engine mentality of having your engine and editor be pretty much one in the same. After a little re-jiggering the internals of my framework I can now run a blitzmax game using my framework in a normal graphics window or inside an editor. The code running the actual game logic doesn’t have to know which mode it is in unless it really wants to, so it’s pretty transparent from the viewpoint of game code.

As for the editor code, that’s another beast entirely and it really adds complexity to the code base. I haven’t decided yet how “integrated” I want the editor in the game framework I have. Currently, 99% of the editor code lies on the game code layer, above the framework, and the framework just has some functionality for handling the switching between OpenGL window and a wx Application. The reason it makes this difficult is there are a set of opposing goals I’m dealing with here:

  • If I want to be able to re-use this framework for future projects, I don’t want to pigeon hole myself into a position where the editor is only good at making 2D side-scrolling physics-based maps. This mentality leads to where I am right now with the editor living largely outside the framework and just hooking into it.
  • If I want my framework to have a fully functioning editor, this will undoubtedly turn into a “Gunstyle Engine”. As I will want to make tools to specifically aid in creating Gunstyle maps and objects. Is that a bad thing? From a time and goal perspective, no. From an idealistic point of view, I want the framework to be ‘general’.
  • A potential compromise between the two opposing points above is to create a ‘generic’ editor that exposes a lot of hooks and ability to code in new tools. While a good way to approach this, I’m only doing this for fun and the end goal is to have a fun game to play. As someone with a limited time and constrained resources I cannot take on this approach as it’s a whole project unto itself.

So as a result, I’m left with either:

  1. A one-off editor for Gunstyle. The code from this editor could potentially be re-used for future games but will be specifically designed to work with the Gunstyle game.
  2. An integrated editor in the framework. In my mind, this would graduate the code from “framework” to “engine” code-base as it would introduce not only a set of API’s but a basic content-pipeline for creating content for this code base.

cole2stance
The main reason the one-off editor approach caused me to pause is there have been situations where I want to include functionality in the core of the editor (in the framework layer) but it would require me to pull in a lot of game specific functionality into the core as well. So I’m sure this is leading to several less than optimal code design decisions because I’m trying to tackle a game specific editor while simultaneously trying to develop a bare-bones editor.

An example of this is I’ve added a line tool to the editor this weekend. The line tool creates a physics based line object into the map for Gunstyle. Now, I feel a basic line and box editing tool is something that could be added to the core of the framework. The problem? The framework has no physics functionality. Physics is all on the game-layer. Currently, the 2D rigid body physics engine is home-grown, but physics is one of those things where I would like to switch out from project to project (using Box2D, Chipmunk, or Farseer). As a result, I’ve yet to roll any physics engine into the core of the framework.

After getting all of that written out in front of me, I think I’ll be sticking to the one-off editor route for this project. If anything comes of Gunstyle and it’s editor I’ll probably be more willing to roll more of the game editor into the core and just go the ‘engine’ route in the future. But for now, I’m trying to focus on Getting This Thing Done. And coding a generic solution to a specific problem is not the best way to Get It Done.

Some days it takes a herculean effort to force myself to sit down and work on my game. Some weeks it can be destructive to my entire schedule, while others its a complete non-issue. Overtime I’ve found prioritizing my tasks wasn’t enough to really Get Things Done. I needed a way to organize my daily tasks in such a way that would maximize my motivation to actually work that day, particularly after coming home from my day job. By taking my top priority items and then sorting them from easiest/most fun to hardest/most boring I think has helped my overall productivity.

I’ve resisted the temptation to try to squeeze in and finish off any low hanging fruit when I’m finishing up for the day and leaving it for the next session. Why? It increases the chances that I start on time the next day and get ‘into the zone’ faster for when I need to really concentrate on the harder bugs and features later into the day. It’s much easier for me to come back to an easy fix or feature. Whenever I have a really hard bug I tend to dread working on it before I’ve even sat down at the computer. Sometimes this can’t be avoided as some bugs can take days of work to finally be fixed, especially if you’re on a very limited time schedule with a day job and other obligations. I haven’t met many people who look forward to debugging some crazy hard bug when they start their day’s work. Once over the ‘hump’ when you’ve settled into just doing the easy things you can quickly ramp up and tackle the hard problems on your to-do with little fuss.

But when the day (or in my case, the night) is winding down, I try to save away some of those easy or fun 5 minute tasks for the next day to really help motivate me into starting on time. As for other tips on game development project motivation and such, instead of going into other aspects of it I’ll just link you guys to a post by Jake Birkett, of Grey Alien Games, that sums it up very nicely for indies looking to get ‘serious’ about their game development business. In particular, this bit:

I’ve run out of motivation

Well perhaps game programming isn’t for you but some other aspect of game production is? But maybe you just need to re-motivate yourself! There’s plenty of stuff about this all over the Internet. Try doing something that inspired you to make games in the first place – perhaps you need to play some of your favourite games, or boot up an emulator and play some old classics, or read some stories about other people’s success, or make a little fun minigame, or listen to some Commodore 64 tunes or Euphoric Trance music. Whatever gets you back into that space where you really want to have fun making and selling a game! Be sure to REPEAT this process whenever you feel your motivation dip.

Having a plan really helps out as you can chart your progress and see clearly what you need to do next. Also if you feel unmotivated, just START something, anything on your project and 5-10 minutes later you’ll probably be really into it.

That last bit is very important and speaks to the issues I encounter most often. For me, that ‘something’ is usually a 5-15 minute fun/easy high priority task that needs to get done. Planning this ahead of time helps as staring at a list of tasks and ‘cherry-picking’ when I’m in a state of lousy motivation usually ends up with me picking things that don’t need to get done right away and leaving more important tasks to linger on the list. Game development isn’t all fun, but with a little forethought and planning you can really help minimize the mundane feeling parts of software development.

I’ve been using Subversion even as a single developer for several years now. It’s invaluable to me and millions of other developers. If you’re a developer working on any project that lasts more than a couple hours and you aren’t using version control then you are shooting yourself in the foot. As a developer, we’re comfortable with juggling several things in our heads at the same time, it’s a fundamental skill we use everyday when developing software. But when you start to do ‘internal’ version control in your head while developing you are only slowing yourself down and it will ultimately lead to lesser quality code.

Don’t think you’ll need this chunk of code, but you’re not absolutely sure? Did you just rewrite method X but you want to keep the previous iteration around as a reference? And more relevant to me: Are you making a bug fix but are mentally keeping in mind how to revert that fix in case it doesn’t work?

All of those questions are red flags that you aren’t using your version control system (if any) to a meaningful capacity. That last question came up earlier this week when I was wrapping up the first alpha build to start testing with a small group of testers for my iPhone game, Tilt To Live. I wanted to implement a new collision algorithm in the game so the higher difficulty levels would run much more smoothly. Wanting to get this right ‘the first time’ (hahah ya right, another lesson learned) I first mocked the algorithm up in Blitzmax, optimized there and debugged it there. Of course, any debugging done in a different language for a mock up is fixing purely conceptual bugs rather than implementation bugs.

The Wednesday night deadline was quickly approaching and I just finished implementing the new algorithm. I start play testing for 5 minutes. 10 minutes. 15 minutes. 20 minutes, wow the game is performing really well! 25 minutes, CRASH! WHAT?! How can this be?

So I quickly restart the game to see if I can figure out any clues as to why it is happening. 5 minutes in I crash again, but it’s still seemingly random. And the debugger isn’t spitting out any useful information to help pinpoint the bug. Knowing the only code I had introduced was replacing a call to the new algorithm I knew just replacing a single line of code would revert me back to the ‘previous version’ (this should have been red flag #1). I start debugging for hours to try to find the cause of the ‘BAD_ACCESS’ fault that is most likely coming from a null pointer somewhere in the new collision algorithm, that seems to still happen ‘randomly’.

Anyway, hours pass and then the next day I spend a few more hours on it to try to see if I can fix it before I start trying to compile an alpha build. Failure. I simply just need more time to get this fixed without releasing the alpha build with a critical bug (red flag #2).

In the end, I had to revert to the slower n-squared collision algorithm for the alpha build. Using SVN, it was trivial to revert back to the previous version, quickly test it, build, and release. Yet, there is a much better process to avoid this very time-sensitive issue of getting bug fixes into a build without compromising the stability of the build. It’s called branches.

Now, I’m no stranger to branches, as I use them to catalog releases, but to incorporate them into my daily development routine is new and is something I’m going to try to implement to avoid this issue in the future. Jeff Atwood, co-creator of StackOverflow.com,  has a rather good summary of different branching patterns for on-going development. As a single developer I’m going to try to adopt the ‘trunk is sacred’ (Branch per Task) method and try to merge features into it from development branches.

What’s the benefit? Always being able to release something that is relatively stable regardless if you’re in the middle of something or not. And you don’t have to worry about ‘auxiliary’ changes you made leading up the current fix that may also break the build. I’m finding that as I draw closer to a more complete game, I need to be able to release builds on a weekly or bi-weekly basis for testers to play test. Knowing that there is some glaring bug that is a showstopper is a head ache for you and your testers.

I’ve been researching different version control systems outside of SVN to see if there’s something that could make branching and merging more seamless and integrated into my work-flow. I’ve found that distributed control systems such as git, and Bazaar, supposedly make this fast and easy. Although,  I’m not ready to give up subversion yet; mainly because it is working. But I may test those systems out in the future for smaller projects. TortoiseSVN’s merging dialog can be a little more clearer, as it stands now it is rather confusing the first time you use it. I’m currently testing out Versions (Mac Only) since I’m developing mostly on the Mac for the iPhone game, and it seems to be a little more intuitive in branching, but can’t comment on merging yet as I’ve yet to look into it.

And now I’m off to enjoy the rest of my weekend :).

Update: Looks like Versions won’t suit my needs. Neither will Cornerstone. SyncroSVN Client seems to support basic things like switching, merging, and branching while the other more ‘fancy’ looking apps don’t do anything beyond committing/updating/branching. Except that SyncroSVN’s GUI isn’t any easier than the command line for merging/switching. Looks like I’m going to the command line or revert to using Tortoise SVN (on windows) for the time being while these Mac apps sort themselves out and mature a bit…