Last week was a busy week as I spent most of it implementing and tweaking the really basic tutorial system I had in mind for Tilt To Live. From my gameplay experiences I feel tutorials have gotten pretty good at being integrated into the game themselves and not being ridiculously wordy/boring. I’m not sure if it’s that I tend to grok how most genre game mechanics work from many years of playing, or understand the basic ‘standards’ across games in the same genre, or that the tutorials are really getting better. I tend to be optimistic about it though and hope we are progressing :). When I was designing the tutorial system for Tilt To Live (which isn’t anything special, but I did sit down and give it a bit of thought) I started thinking from a more general game design perspective on what to consider in such a system:

How complex is thy game?

I generally pay attention for first few minutes of tutorials to learn the essential controls then I barrel forward into the game hoping for the best. Some tutorials overstay their welcome. It really comes down to distilling the core gameplay experience and then getting the user to run through those motions quickly and keeping it engaging. Of course it’s really hard to get around that if you’re game is as complex as say…Commandos 2.

Commandos 2 may be the most ferociously complicated game released yet for Xbox. – 1UP


Sometimes there just isn’t getting around that boring part of the tutorial if your game really IS complex and there are a lot of rules required to know before you can  make your first move. For sufficiently complex games, tutorials are a huge part of the game design problem. When I played commandos I pretty much lost interest after 15 minutes futzing around in the training missions. Another tale of a lost player due to a lengthy and uninteresting tutorial :(. And this was even with a friend of mine who was a huge fan of the game pretty much holding my hand through the first couple of missions. It just didn’t click with me, but I like to think that the ‘fun’ of the game was lost on me.

Yet, lengthy tutorials are common in non-video game settings. Take contract bridge for instance. I learned to play it with several co-workers and if you gave me a manual and several self-paced tutorials I probably would have never figured it out (particularly the bidding system). Call me dumb, but I like to think I’m just lazy ;).


The difference in me learning how to play bridge vs taking the time to play commandos 2 was that the “tutorial” was integrated into the very game itself in a way. I wasn’t playing “Tutorial: Bridge” like I was playing “Tutorial: Commandos 2”. I was playing full non-handicapped bridge and learning at the same time. It was a constant learning process. It was a fun process of discovery, which for some odd reason didn’t come across to me in Commandos 2. The rules of the game don’t spoon-feed you tactics and how to ‘win’ at bridge. Also the ‘engaging’ part was from talking to the other players in the game to learn more. Not many tutorial systems beat social interaction. I’m certainly not the only one that enjoys learning how to play a game through other enthusiasts. Juuso, of recently had similar thoughts:

I like how Zombie Panic has no tutorial, nor much hints at all. Instead, players ask each other “how you rotate the board”. In Zombie Master (for some reason I’m getting zombie game examples here) it’s cool how players ask each other “what to do next?” – sometimes the reply is “n000b!” but often time other people tell what to do. I think that’s tutorials in its greatest form: community interaction where everybody helps each other. People can enjoy the game in many different levels.

In essence, the more complex your game rules are you may be more justified to put in a longer tutorial. But you need to ask yourself, particularly if you’re an indie focusing on smaller games, is your tutorial system teaching the player the game rules (Bridge) or is the tutorial holding their hand while they play a bunch of throw away levels (Commandos 2 and a lot of single player games)?

Who art THOU?

These days, no amount of tutorials will get a player who is casually interested in your game but doesn’t grok the necessary control schemes to talk in that game’s “language”. By language, I mean FPS, RTS, or RPG relevant control schemes. Each genre of games kind of have set standards on how to play that particular game. I’ve pretty much concluded that my mother, at her current age and interest level, will never be able to pick up Halo 3 and learn to play it competently. Not because I don’t believe she doesn’t have the ability (lol), but simply because she doesn’t care enough about it to invest the time and energy to become familiar with that system. Give her bejeweled 2 on the other hand and omg…we’ve lost contact…for hours. On the other hand, any hardcore gamer can take any FPS shooter, run through a brief tutorial on what is different about this shooter than others and proceed to play.

Casual games have picked up on that sensibility (for the most part), and keep tutorials pretty minimal but make very few assumptions about the player from what I recall. The good iPhone games tend to be doing a decent job at conveying play mechanics quickly and efficiently, because the audience is mobile. Some opt for a simply ‘how to play’ button but offer no in-game advice, while others do the opposite.

I chuckled to myself when I realized the brilliance of Doodle Jump’s aesthetic, intentional or not. They were able to literally pencil in the tutorial in the background as you play and not break the “mis-en-scene” (hah, how’s that for artsy?) of the game.


In Practice

So, when it came to implementing a tutorial system for Tilt To Live I had the answers to the above two questions along with some other notes:

  1. How Complex is the game? Mechanically, it’s dead simple. Actual difficulty of getting a reasonably high score? Currently, results may vary. The resulting tutorial system should be either a)extremely minimal b) non-existent.
  2. Who are YOU? While the game has obvious influences from more hardcore 360 shooters, I wanted to tone down the difficulty, give a more approachable aesthetic, and try to reach a less hardcore audience. The resulting tutorial system shouldn’t assume too much of the player’s previous gaming knowledge. This influences the terminology you use in tutorials and other text.
  3. Appealing to the Core Ideas of the game: One of the core ideas of Tilt To Live is to keep it as minimal and simple as possible. Right down to the title, which serves almost as a tutorial in itself.

Adam and I kind of went back and forth on whether a game as simple as Tilt To Live really needed any explanation. I mean the title pretty much says it all for goodness sake. I persisted and decided even a brief explanation of at least one of the game rules (collecting pick ups to attack enemies) should get an explanation. We eventually came up with this (a work in progress video):

So the player on the first launch of the game is informed of the general rules of the game but control is never taken away from them as they can freely play the game. This gives the first time casual player some time to get acclimated to the game’s controls and then proceed as normal.

We’re still up in the air about a “How To Play” option that would give more detail on the power ups and mechanics. I figured no one would give a damn about the option, especially after seeing a few other iPhone games. It all points back to the complexity of the game. It doesn’t necessitate the explanation of all the power ups. Plus discovering what each one does is part of the fun :). Additionally, I will cut anything from the main menu as long as it doesn’t make  it more difficult to get to information you want in order to keep in line with point #3 above. So I’m leaning towards removing it all together, but I’m not completely done iterating on it so it may change….

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:


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.

Tilt To LiveWhen it comes to gui coding I don’t typically find it the most glamorous things to do. Particularly when dealing with games. You are left with writing a lot of boiler plate GUI code that is tightly integrated with your rendering pipeline. And even when I do find gui libraries for games they tend to try to emulate the OS in look and feel. When you want something lightweight and very interactive/animated you typically have to write it and integrate it yourself. If someone knows of a library for games that allows for versatile GUI development please leave a link in the comments :). When left unchecked, GUI code can end up being:

  1. messy and hard to maintain
  2. difficult to change
  3. rigid (basically just “functional” with very minimal style)

The GUI is one of the few remaining “big” items left on Tilt To Live’s to-do list. When imagining the GUI I had all sorts of crazy ideas for animations, transitions, interactions. Despite it being a relatively minor part of the game’s experience I still felt it important to really make it as polished as possible. Why? The GUI is the first thing a new user sees when launching a game (unless you’re Jonathon Blow’s Braid). It’s important to grab the user’s attention as soon as you can to make sure they give your game a fair shake.

Attention! Over Here! Look at Me!

In the mobile market you are fighting for pretty small attention spans. One of the design goals for Tilt To Live is to make it quick to play. Currently it takes one tap to start playing the game. I’m still working on reducing the initial load time. I even contemplated removing the requirement of ‘one tap’ to play, and to just drop the player into the game. When someone selects ‘Tilt To Live’ on the iPhone there’s a large chance they are simply wanting to play a quick game of Tilt To Live. In fact, other games like Spider: The Secret of Bryce Manor do just that and it’s actually quiet welcome. My only reservation is Tilt To Live may expand in the future to multiple game types so the ‘play from launch’ approach isn’t ideal if the desired game mode isn’t known with great certainty.

Either way, trying to get that good first impression on the user is very important. In addition to that, reducing the friction required to play your mobile game could possibly raise the game up beyond “I have nothing better to do” status and overtake other forms of gaming.


So back to GUI animations. Throughout the game I’ve used a hacked-together curve editing tool I wrote in Blitzmax to produce animations for items spawning, enemies popping up, etc. It works “well enough”, but the barrier to creating a new ‘curve’ was still high and it added to the total filesize of the game and was another asset to add to the app. So I revisited easing functions. I use some throughout the GUI system, but they aren’t very interesting. I started looking into alternatives and ended up with a rather nice solution.

Below is a work in progess video of the new easing functions in action on Tilt To Live’s menu UI:

A couple of years ago, Shawn Hargreaves had a really nice article explaining curve functions and how to use them in the context of GUI transitions using the XNA framework. It was a really nice primer to getting your hands wet with polynomial functions. Fast forward to today, I still have the basic “exponential” and “sigmoid” functions, but they were pretty boring in the scheme of things. Tilt To Live’s aesthetic is kind of cartoony so those functions weren’t very lively.

Having worked with Flash many years ago I knew it’s easing animation capabilities were very sophisticated, but I wanted to have some subset of that flexibility in my code as well, so off to Google I went. The best resource I found was Timothée Groleau’s Easing Function Generator. Not only did it have a nice set of preset easing functions, it generated the code to produce those exact curves! Wow, this was a huge time saver! For anyone that wishes to use these functions as well, the variables used in the function probably require a quick explanation:

  • t – the floating point time value from 0 to 1 (inclusive). If you want the position on the curve half way through the transition then you pass ‘0.5’ through t.
  • b – the starting position. In a one dimensional setting this is the value you would get if t = 0.
  • c – the ‘change’ in position. So if you want to transition from 34 to 56 then c = (56-34) = 13. (more on this later)
  • d – duration of the transition. If you want the transition to last, for example, 2 seconds then d= 2.

With that actionscript function generator it’s pretty trivial to implement it in any other language (as in my case, C). Although my GUI transitions aren’t based off of changes in position, but off of start and end positions. So my typical transition function signature looks like Transition(startPosition, endPosition, delta). Below is an example implementation in C:

float EaseOutElastic(float startVal, float endVal, float blend)
float diff = endVal – startVal;
float tsquared = blend * blend;
float tcubed = tsquared * blend;
return startVal + diff*(33*tcubed*tsquared – 106*tsquared*tsquared + 126*tcubed – 67*tsquared + 15*blend);

The result:

  • Much more interesting GUI transitions
  • No extra assets as curves are procedural
  • Can re-use curves in different types of animations (position, scaling, rotation, etc)

When I’m doing a polish phase on the GUI of a game or animations, sounds, etc I’m often reminded of the tidbit from Kyle Gabler’s  Gamasutra article about prototyping: Make it Juicy. Using easing functions to add a bit of bounciness, juiciness, and overall personality to a game can really help make the game feel more alive…feel more…juicy.

Tilt To Live


I had planned to put up more of a tutorial post on rendering adaptive 2D grids for things like editors and such, since it was something I recently implemented. I got it working in my editor but then when I tried to conjure up a more “simplified” version in Blitzmax without any of the abstractions of a scenegraph, camera, and other numerous things I found I was tripping up over Blitzmax’s own graphics commands O_o. Being impatient I took the route of “at least it works in my system” and I’m just going to point you to a code listing that helped me generally implement it. Moving along now…

Since working on my weekend “Gunstyle 2” project I’ve had to develop a map editor that allows a mapper to save map files and load them into the game. In the first iteration of the game we had written the map files as binary files with all the assets needed in a single map file. On the 2nd iteration for the XNA Dream.Build.Play competition we used TorqueX as our engine of choice and it used XML files to serialize assets. After developing in both and developing the “next” version of Gunstyle in Blitzmax, I’ve had to tackle the decision of which type of serializing the framework and game would use.


I opted for XML in the end. The reasons were:

  • Portability – Something we wanted to do with the newest version of the game was pull over some of our levels from the original and the XNA/TorqueX version so we could quickly test gameplay on fully-developed maps. Massaging a binary file to be compatible with another binary format is a headache to say the least. The maps in the original Gunstyle were binary, so I took the route of exporting the maps to an XML format. the Binary-> XML conversion wasn’t easy either, but once in XML updating the schema as the framework evolved was A LOT less painful. Extracting the geometry of levels from our XNA version (which was actually a custom XML file outside of TorqueX) proved to be trivial also.
  • Readability – This is a difficult one to prove that is useful. If a binary file is valid, why do you need to read it? During development of the file format, being able to read the file output helps with debugging.
  • Flexibility – With XML, you can treat the map file almost like a database. Using XPath or some other way of querying the data, you aren’t restricted to the exact order things are in the file.
  • Ease of editing – With XML I can now leverage text editors to do simple edits in a map file rather than writing some custom tool to do what amounts to a basic  ‘search/replace’ for a map if, for example, an asset name is changed.

While using XML did give me some benefits, there were some trade offs I had to deal with:

  • Non-Encapsulation – Now a map file no longer was a single monolithic file. Which to me seems ‘cleaner’ and is much easier to distribute. Maps consisted of an XML file that essentially described the geometry, scenegraph layout, and where to find the textures and audio.
  • More Verbose Code – Writing a binary file in Blitzmax is less lines of code than writing an XML file (I’m using a binding to libxml by the way).

On the topic of encapsulation, I really liked having maps be a single file you can send to someone and be able to play. This also greatly simplified the auto-download feature of our previous game where we simply looked for the missing map file. I suspect to get this type of simplicity for users I would have to implement a virtual file system for the game and have assets and XML files be wrapped up in zip files or something. I’m fine with dealing with more verbose code as the benefits outweigh the downsides in my opinion.


There’s definitely more down-sides to using XML over binary than I listed above, but I can’t think of any at the moment. I attribute this to my hunger. I am now going to proceed to feed my face, play some games, and start doing some networking work :).  Just as a note, I will be traveling for the next week-ish, so don’t be surprised if I don’t get a new (hopefully more insightful/useful post than this one) post up next weekend. Happy Labor Day Holiday!

One thing I’ve learned from working on games along side a day job is it takes a very strong commitment otherwise it will grind to a halt shortly after starting. You have to plan for the long haul as any game worth playing, or better yet paying for, requires much more time than you think. Especially if it’s your first ‘commercial’ endeavor. Planning is paramount if you wish to have any chance in succeeding. I have more thoughts on planning that I want to explore in future posts, but for now I just wanted to share some data for anyone else also pondering how to best fit indie game development into their already busy schedules.

The 10 hour work day

So for the past couple of months I’ve been working 10-hour days for 4 days a week at my normal day job. This means I never work Fridays. My original thinking was that having a whole day off to just work on my game would prove to be very helpful as it could be treated as a whole uninterrupted 8-hour work day. The drawback was my Monday-Thursdays were extremely busy. I knew doing this schedule would require some serious discipline to pull off and still keep physically active as to not adversely affect my health. As a result, my daily routine was rather strict and had pretty close to zero room for any hiccups or delays. Got stuck in traffic? Just lost an hour of coding. Had to run to grocery store mid-week? Just lost another hour of coding. Parents/family/friends call to chit-chat? That night of coding is probably gone. It was a constant battle to try to keep on schedule.

Ultimately, I mitigated the delays, but at the expense of sleep. What’s interesting is it wasn’t a completely conscious decision. As I kept struggling to catch up on trying to fit a few hours of coding time a night I slipped a little later into the night as the weeks went by. Eventually I was down to 5.5-6 hours of sleep a night. Some people can function with that, while others (like me) can’t sustain that sleep schedule for long. In fact, I could only last til Wednesdays on that schedule before I started noticing it was affecting me during the day.

Regardless, I pressed on for another month on this routine. It wasn’t until I started noticing I had stopped losing weight and was actually beginning to pack on weight that I decided I needed to reevaluate my plan. I have a daily routine of jogging and working out after work and it’s something I try very hard to maintain so that the long hours I put in sitting at a desk at work and at home working on my games doesn’t ruin my health. This wasn’t the only red flag that told me to reevaluate though. There were others:

  • Even with Friday off I still couldn’t achieve the ‘8 hours’ of indie work on Fridays. With Monday-Thursday being so busy I had to put off an errands, shopping, routine weekly tasks to Friday if the services weren’t available on the weekends. This typically ate up half of my day.
  • To further hurt my productivity on Fridays, I was so tired by that time that I typically could only muster anywhere from 2-4 hours of actual work on Fridays. This wasn’t much more than my typical nights on Monday-Thursday.
  • With no wiggle room during the week my relationships with family/friends were extremely hard to maintain. Any time spent keeping in touch was directly any time I had ‘lost’ for the day to work on my game. Having general ‘social’ time throughout the week is important. But you knew that already :).

Ok, so those were all reasons for leaving a 10 hour schedule behind. But what do my timelogs say?

8-hour vs 10-hour. Fight!


The above is just a small summary of timelog data I’ve kept track in Excel over the last 3 months working 10-hour work days for the most part. It’s far from perfect, but it serves its purpose. The interesting number there is ‘Totals’. At 14 hours and 44 minutes I was working a rather crazy schedule. And as mentioned earlier, my Fridays ended up being no different than any other day of the week. My Mondays interestingly had a consistently lower time (case of the Mondays perphaps?).

Data is wonderful. It allows you to make predictions based off realistic performances. I had this fantasy of working ‘8 hours’ on Fridays, and it ultimately proved to be fictitious. So was my original thinking that 8-hour work days wouldn’t allow me a large enough chunk of hours during the week to get anything worthwhile done? After some number crunching I found two very compelling facts:

  • Working 8-hours a day Mon-Friday at a day job and working on the game just Monday through Thursday would give me AT LEAST the same amount of hours I would get working 10’s, and in the best case scenario I could gain 3-4 more hours a week.
  • I would be able to get 7-8 hours of sleep a night consistently.

Any experiment was in order. So I decided to work 8 hour days the last week and the results are in:


Hah, Success! So after coming home from “work” two hours earlier I was able to work on my game for only 4 of the days of the week and STILL get about the same amount of hours in with the 10-hour/day schedule. And you know what the best part is?

  • I could have some semblance of a life now. I could hang out with friends, talk to family, any time inside the week and not fear that I was losing time
  • I could get some decent amount of sleep
  • Overall quality of life was higher
The End Is Nigh

Looking back on the data and my memories of the past couple of months, it seems obvious that an 8-hour work schedule for my day job would’ve been the better bet. But I seem to have been caught up on the idea of having a whole day to my game seeming like a great way to make progress on it in large chunks. In reality, I couldn’t ignore the other things that needed to be done that week and Friday became ‘catch up on errands’ day rather than ‘Tilt To Live Development’ day. Now, the 10-hour work week I still believe is completely workable if you wanted to work into the weekend and simply did not work on anything after work during the week. This approach is good I think for the ‘weekend warrior’, but I tend to want to reserve my weekends for relaxing, hanging with friends, and playing games :).

So anyone who is in my position of deciding what type of work schedule to run at their day job while trying to finish their own indie game hopefully will find some of this data useful. I know some companies offer 9-hour work schedules with either half-day Fridays or every other Friday off, but I think I would still decide to go with the 8s. I’ve found that spreading the hours across the week helps me keep up a higher level of productivity and motivation than trying to cram it into the end of the week or weekend. You have to treat the development of your game like a jog, not a sprint. My major flaw was thinking that working for long concentrated hours (ie on Fridays) was better than short sustained sessions across the week. When it comes to coding it’s hard to start and stop constantly, but it’s something I have to get use to. I’ve noticed as time goes on I’ve become better at breaking up seemingly monolithic tasks into workable chunks.

In the end, the most important thing to find is balance. I believe I may have found mine for the time being…


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.

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 had this issue in past 2D games all the time. The ability to interpolate 2D rotations for basic animations for anyone that doesn’t understand quaternions becomes a rather laborious task. I’ve done messy if-then statements to try to catch all the cases where rotation hits the ‘360 to 0’ boundary and it’s always ugly and seemed like there had to be a more mathematically correct way to interpolate a circular value.

Well for anyone that sticks with it long enough, they undoubtedly run into quaternions. What are quaternions? I’m not about to explain it in detail, but I like to think of them as a way to express a 3D rotations and not having that annoying gimbal lock problem.

So how do quaternions help our 2D rotation needs? Well if you’re in a situation where you need to interpolate between the shortest path between 2 angles then Quaternions can help. You have a few choices to solve this problem:

  1. Use if-then clauses to try to catch all the cases when you hit a rotational boundary if you are rotating from, for example, 300 degrees to 2 degrees. You would want to rotate all the way through 360 instead of going backwards.
  2. Use quaternions, which are more applicable to 3D rotations, to interpolate between to angles using spherical interpolation (slerp for short).
  3. Use spinors, which are a very similar concept to quaternions, except they are more catered to 2D rotations.

You’ll eventually see that using quaternions is somewhat overdoing it as 2 axises are never used in any calculation in 2D. If you eliminate these 2 axises from the quaternion you end up with a spinor! Thanks to Frank, of Chaotic Box, who helped lead me down that direction for my own iPhone game.

To help test out the concept and make sure it’s working I ended up writing a Blitzmax quickie app using what little I know about quaternions. I’m certainly a bit iffy when it comes to dealing with complex numbers, as I don’t fully grok them as I do normal vector math, but I make do. So if anyone reads this post and sees some sort of logical error in my code, by all means leave a comment and I’ll improve the listing.

So to get started I needed a way to represent a 2D rotation as a spinor. So I created a spinor type with some basic math functions (all of them analogous to how quaternions work):

Type Spinor
Field real:Float
Field complex:Float

Function CreateWithAngle:Spinor(angle:Float)
Local s:Spinor = New Spinor
s.real = Cos(angle)
s.complex = Sin(angle)
Return s
End Function

Function Create:Spinor(realPart:Float, complexpart:Float)
Local s:Spinor = New Spinor
s.complex = complexPart
s.real = realPart
Return s
End Function

Method GetScale:Spinor(t:Float)
Return Spinor.Create(real * t, complex * t)
End Method

Method GetInvert:Spinor()
Local s:Spinor = Spinor.Create(real, -complex)
Return s.GetScale(s.GetLengthSquared())
End Method

Method GetAdd:Spinor(other:Spinor)
Return Spinor.Create(real + other.real, complex + other.complex)
End Method

Method GetLength:Float()
Return Sqr(real * real + complex * complex)
End Method

Method GetLengthSquared:Float()
Return (real * real + complex * complex)
End Method

Method GetMultiply:Spinor(other:Spinor)
Return Spinor.Create(real * other.real – complex * other.complex, real * other.complex + complex * other.real)
End Method

Method GetNormalized:Spinor()
Local length:Float = GetLength()
Return Spinor.Create(real / length, complex / length)
End Method

Method GetAngle:Float()
Return ATan2(complex, real) * 2
End Method

Function Lerp:Spinor(startVal:Spinor, endVal:Spinor, t:Float)
Return startVal.GetScale(1 – t).GetAdd(endVal.GetScale(t)).GetNormalized()
End Function

Function Slerp:Spinor(from:Spinor, dest:Spinor, t:Float)
Local tr:Float
Local tc:Float
Local omega:Float, cosom:Float, sinom:Float, scale0:Float, scale1:Float

‘calc cosine
cosom = from.real * dest.real + from.complex * dest.complex

‘adjust signs
If (cosom < 0) Then cosom = -cosom tc = -dest.complex tr = -dest.real Else tc = dest.complex tr = dest.real End If ' coefficients If (1 - cosom) > 0.001 Then ‘threshold, use linear interp if too close
omega = ACos(cosom)
sinom = Sin(omega)
scale0 = Sin((1 – t) * omega) / sinom
scale1 = Sin(t * omega) / sinom
scale0 = 1 – t
scale1 = t
End If

‘ calc final
Local res:Spinor = Spinor.Create(0, 0)
res.complex = scale0 * from.complex + scale1 * tc
res.real = scale0 * from.real + scale1 * tr
Return res
End Function

End Type

One caveat in the above code is that any angle from 0-360 is mapped to 0-180 in the Spinor. What does this mean? it means if I want to represent the angle 270 I need to divide it by 2, creating the spinor with the angle 135. Now when I call GetAngle() it will return 270. This allows us to smoothly rotate the whole 360 degrees correctly. This is explained here in more detail.

So now I want to spherically interpolate (slerp) between 2 2D angles. Well, if I call Slerp() on the spinor type it’ll do just that, giving me another spinor that sits in between the 2 angles. I’ve read a couple of articles in the past on slerp and how to implement it, but in order to get things done I just used a publically listed code snippet and ported it to blitzmax. That whole article is worth the read and recommended, even if you’re just using 2D.

Now that the concept of spinors is encapsulated in the Spinor type I wanted just a basic convenience function that I can feed 2 angles and get another angle out:

Function Slerp2D:Float(fromAngle:Float, toAngle:Float, t:Float)
Local from:Spinor = Spinor.Create(Cos(fromangle / 2), Sin(fromangle / 2))
Local toSpinor:Spinor = Spinor.Create(Cos(toAngle / 2), Sin(toAngle / 2))
Return Spinor.Slerp(from, toSpinor, t).GetAngle()
End Function
the ‘t’ variable is the time variable from 0 to 1 that determines how far to interpolate between the 2 angles. Giving it a value of 1 means you will get toAngle out, and a value of 0 is equal to fromAngle and anything in-between is just that…in-between.

Now I can call Slerp2D(300, 10, 0.5) And get the correct angle without worrying if I’m interpolating in the right direction :).

Also, I want to point out that the above code was just used in a quick proof of concept app. It’s somewhat sloppy and to be honest, I’m not sure I named the portions of the spinor correctly (real,complex), but it works. For clarity and to save time I didn’t inline the Slerp2D functions or the Spinor type methods, so it generates a lot of garbage. You would need to optimize this to use it in a tight loop somewhere. Any suggestions are welcomed.

As for references, I did some searching and got most of the ‘missing link’ materials I needed to bridge the gap between quaternions and spinors from:


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,  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…