Doing Ludum Dare

I participated in Ludum Dare 45 this year.

Ludum Dare is a semi-annual competition where you attempt to make a game over a single weekend. There are two flavours. The first is the “Compo”, where you have 48 hours to make everything as a single individual (no teams). You must release your source code and all art must be your own (or, properly derived from existing assets that you have rights to use). The second is the “Jam”, where you have 72 hours, can work in a team, and enjoy slightly more relaxed rules.

I chose the Compo because it’s meant to be the ultimate test of your game development skills: 48 hours to develop everything yourself. The result of my work was Robo-Fort, shown here:


The theme for the competition was “start with nothing”. My application of this theme was that you started with nothing by having to push boxes and build a fort to defend precious cargo. You started with no fort, so you had to build one.

(Some folks, however, took this entirely to the next level: some entries had no graphics, resources, or even levels, and you had to find/build/buy them yourself in order to make the game playable. Now that’s creative! You should check them out.)

Before I started, I set a few ground rules for myself. I would still eat, shower, and sleep. I would also allocate a lot of time at the beginning to sort through my ideas and decide what I wanted to do. It turned out, this wasn’t a problem. When the event started, I was already an hour’s drive away from home and out with friends for a social obligation. That gave me plenty of time to let ideas marinate in my head after the theme was released. When I finally arrived at home, the event was already 3 hours underway and I had a fully formed idea of the mechanics and game play.

A rough timeline of my progress looks something like this:


Here are some personal tips I embraced that contributed to my success in being able to finish Robo-Fort on time.

  1. I intentionally gave myself a ton of time at the beginning to sort through ideas. The 3-hour delay before I got home didn’t concern me in the slightest. That time to think before coding is required.
  2. My morning routine (breakfast, shower, coffee, etc.) helps me focus, so I made sure to still do that.
  3. Test continuously. I would periodically stop at natural breakpoints and just play the game.
  4. Slept 8 hours each night to keep me from writing bad code or (worse) making bad decisions.
  5. My goal was to have a minimum playable version done by Saturday evening (after about 32 hours).
  6. If I got stuck on a non-technical idea, I immediately set the project aside and did something different (like washing the dishes) to let me think. The worst thing I could do was waste valuable time coding when I didn’t have anything to code.
  7. Lastly, I allocated the final hours on Sunday for music, since I knew that this was my weakest “skill”.

Ultimately, the Compo is not just a test of game development skills. It is also a test of self-knowledge, because in order to complete your game, you must force yourself to be the best version of yourself you can be. Even if it’s only for 48 hours. Plus, the skills you apply for the Compo (e.g., think and plan before you code, know what you have time for and what you don’t, etc.) apply to regular game development, too.

Robo-Fort (LD45 Submission by Geoff Nagy) Sun, Oct 6 2_18_45 pm.png

Games are judged on the Ludum Dare website by the other participants over the following several weeks after submission according to a “karma” scheme: in order to get your game judged by other players, you also have to judge others’ games. This was a ton of fun and I played about 60 over the course of the next several days. It was really something to immerse yourself in so many different fun worlds, and in each game, the developers’ passion shone through. I played one of the games that ended up winning, and the winning title was well-deserved.

Robo-Fort ended up scoring 360th overall, out of 2613 submissions. That’s within the top 14%, so not bad. (And top 6% in the “Graphics” category!) Some folks had difficulty seeing my (rather broad, in hindsight) interpretation of the theme (“start with nothing”), so that’s something to keep in mind for next time. Overall, Ludum Dare 45 was a fun experience that I’d recommend to any reasonably experienced programmer or developer looking to challenge themselves and test their skills.


Making My Models

Game art is really not one of my strong suits. I mean, don’t get me wrong – I think Hypergate looks pretty good. But first and foremost, I consider myself a programmer, not an artist.

Here’s a 3D model I built back around 6 years ago at the beginning of Hypergate’s development. (I couldn’t find the original textures.)


This was originally an enemy fighter.


Not bad, but I think my more-recent Hypergate art looks better:


The Validor A, a new fighter in a future update.

Now, having worked previously with some truly talented game artists during my brief time in the VR industry, I know that my art skills don’t come close to theirs. But, I recognize that my improvements were only possible through lots of practice. And you can learn too.

The goal of this post is to provide a brief outline of my workflow for building and texturing 3D models for my games, including Hypergate. It’s a relatively simple, methodical approach that works for me.

Our case study will be the Validor A, the new fighter shown above that will be part of a future Hypergate Content Update. The focus here will be on high-level steps, not artistic design. This is also not a technical tutorial on modelling.

So, let’s get started.

1. Build the Model Shape

The first step – and really, the hardest – is shaping the model. Blender is my tool of choice. It’s free, has great community support, and is regularly updated.

I usually start with a cube and extrude. I’ll sub-divide a few faces and add loop cuts here and there. My approach is to first focus on the large details. My space ships tend to have big wings, gun turrets underneath, a cockpit, and a few greebles on top or below. I’ll start with the large pieces like wings and the nose to get the shape figured out. As always, I’m prepared to use Ctrl-Z as I iterate. The Mirror modifier in Blender is a great way to ensure that my design is symmetrical.


Once the wings and nose are worked out, I’ll shape the cockpit. I’ll add greebles on the wings to aid the appearance of appropriate scale. This can be done using the Extrude command. I’ll extrude cylinders for turrets or antennae, and shape boxes into fins. Cylinders work great for rear thrusters, too.

2. Add Seams

Seams define edges where you want to cut your mesh when performing texture unwrapping. Think of it like slicing up a stuffed animal or an orange with scissors: if you wanted to paint each segment of the animal or fruit on a flat canvas, where would you cut to get the flattest and easiest-to-paint segments? The red lines in the wireframe image below show the seams.


A rough starting guideline is that I’ll usually want to add seams on the natural sharp edges of my model. This minimizes the texture distortion and provides a bit of robustness if I’m going to use a lower-resolution texture. Of course, there are exceptions, and I always end up adding seams elsewhere as required.

3. Unwrap

Unwrapping is an iterative process. After adding seams, I make sure I’ve done it right by doing a simple unwrap and viewing the resulting UV islands.


Enabling “Stretch” for “Angles” in the right-hand Properties toolbox helps to visualize distortion.

Chances are, I may need to add a few more seams here and there and repeat the unwrap process to eliminate distortion. I miss seams accidentally on my first try all the time.

4. Adjust UV Islands

After I’ve unwrapped the model, I’ll apply a simple diffuse texture of a checkerboard with lorem ipsum text to my model. The checkerboard helps visualize scale and the text indicates direction. (Often my textures will include text like safety stickers.)

I’ll now translate, scale, and rotate the UV islands until I get the appropriate levels of detail for each component of the ship. Often I’ll group related UV islands together to make texturing easier later on.

In rare cases, I might need to go back and add more seams and do some re-unwrapping. “Pinning” UV vertices is very useful for ensuring that vertices I know to be correct won’t change during subsequent unwraps.

5. Exporting UV Layout and Texturing

My image editor of choice is GIMP. For small fighters in Hypergate, I’ll usually export a 2048×2048 image of my UV islands from Blender for texturing, although the final in-game textures end up smaller than this for reasons I’ll explain later. For larger objects like cruisers, I’ll usually export 4096×4096-sized UV layouts.

In GIMP, I start by adding a base colour layer (off-white, in the case of the Validor A). I colour individual UV islands, add some panelling, warning stripes, service panels, warning stickers, arrows, some text, vents, rivets, LEDs, and engine glow. I also add dirt and scratch layers. The “Layer Mask” feature in GIMP is a great way to add the appearance of worn-out paint or labels. This becomes the diffuse texture of the model.


I’ll also export emission, specular, and normal maps. These are just exported versions of the diffuse texture with the appropriate layers turned on or off, and further separately tweaked. The “Normal Map” plugin for GIMP is how I build my normal maps.

6. Applying Final Textures

By now, I’ve got diffuse, emission, specular, and normal maps for my model. In Blender, I’ll replace the original checkerboard material with a new one that uses these four textures. I’ll create four “Image Textures” in the “Texture” tab, setting their “Influences” appropriately.

7. Final Optimizations

2048×2048 is a pretty large texture size for a 10 meter fighter travelling at a couple hundred meters per second. This can eat up valuable GPU memory, takes longer to load from file, and is simply just an unnecessary level of detail. For small fighters in Hypergate, I usually export the following image textures:

  • Diffuse: 512×512 RGB PNG
  • Emission: 256×256 Greyscale PNG
  • Specular: 256×256 Greyscale PNG
  • Normal: 512×512 Greyscale PNG

This generally gives good results in terms of both level-of-detail and image sizes. Larger or slower objects are assigned larger textures to maintain good visual quality.

The model itself is exported as a Wavefront .OBJ file. I’ll export several levels of detail for each object. (The Decimate modifier is really useful here.) The small fighters typically have the following levels of detail, although it varies on the model:

  • High quality: 4,000 – 6,000 triangles
  • Medium quality: 2,000 – 4,000 triangles
  • Low quality: 1,000 – 2,000 triangles or less (I just set the Decimate modifier to the bare minimum that maintains the general model shape)

So how long does this entire process take? It depends. When I rush myself with this kind of work, it usually results in poor quality and more mistakes. A ship like the Validor A might take me about 2-3 days’ worth of full-time work, from start to finish.

I hope that this guide has been somewhat useful. Like I said, it is rather high-level. Comments are more than welcome if you have suggestions or would like more details on a particular step.


Effective Level Editing

A few years ago, I completed a project called Dactyl. It was a 2D asteroids-shooter-type game. There were 25 hand-generated levels populated with mines, asteroids of various types, useful equipment, and automated turrets.


To visualize each level before I implemented it, I used graph paper and a pencil*. Once I felt a level was complete, I plugged the object coordinates into a text file, and then fed the file into the Dactyl engine. And pop, out came a new level.

This approach definitely wouldn’t work in Gateway. The size of each level (up to about 20km!), especially considering the differences between, say, the 10 meter fighters and the half-kilometer battle cruisers, made drawing complex scenarios to scale next to impossible. Making changes to level designs would also be painful: erasing a group of 30 fighters and shifting them over a kilometer would quickly eat away at my eraser and my sanity. Besides, my hands aren’t steady enough for that kind of nonsense.

Dactyl levels were sketched out by hand.

Dactyl levels were sketched out by hand.

The solution for Gateway was to build my own level editor.

I’ll admit that I didn’t spend a lot of time investigating existing solutions. I was (pretty) sure that there was (probably, maybe) some level editor somewhere that would offer the right parameters and would allow me to drag, drop, and configure all of the game entities I wanted onto the Gateway playing field, but I really didn’t feel up to downloading and trying various existing editors only to find that each one was missing a crucial feature.

Ah, yes…implementing things from scratch rather than using existing solutions. I often do this with smaller projects for a number of reasons: (a) I believe in doing everything yourself at least once, (b) it’s often more fun, and (c) I can usually whip up something small in less time than it would take for me to learn to use an existing tool. (I recognize that this is a twisted combination of both laziness and diligence.) I also (d) like to be intimately familiar with the code I use, and this is easiest when it’s code that I write myself. Additionally, my own level editor could be completely customized for exactly what I needed it to do. (Besides, by the time I started considering developing my own, the back burners in my brain had already fired up and began doing the work for me. I think somewhere back there I knew very early that I’d have to write my own.)

I intentionally wanted to keep my editor’s feature list as minimal as possible, since I’d probably only use it specifically for Gateway (although it could be altered without much effort for similar games) and didn’t want to spend too much time adding features that weren’t absolutely necessary. I just wanted the bare essentials for designing levels quickly and easily…so, there were hard choices to make.

C# .NET would be an ideal choice for this project, since I’ve worked with it extensively on a variety of projects. This meant that graphical user interface elements like buttons or text boxes wouldn’t be a problem. The next thing I had to consider was whether or not I wanted a 2D or a 3D representation of the world in my editor. There were pros and cons to each.

Advantages of a 3D level editor:

  • Entities could be moved around the environment and viewed from the player’s perspective
  • Everything could be viewed as it would appear in-game: for example, depth or height would be easier to determine than it would be in a 2D, top-down view

Disadvantages of a 3D level editor:

  • Harder to implement than a top-down representation in terms of entity selection (picking), transformations, etc.
  • C# .NET does not feature built-in 3D support and would require using GLControls or something similar (I wasn’t adverse to this, but it was another layer of complexity I wasn’t sure was really necessary)

Ultimately, I decided to go with a 2D representation simply because the style of the game didn’t place a whole lot of importance on an object’s height or altitude within the game; the flight controls are more like flying an aircraft than a true 6DOF fighter (I did this to make the game simpler and more accessible to players). Thus, the world could fairly easily be represented in a top-down fashion. Of course, objects exist at many different “altitudes” in the game, but not to such a degree that it was critical that this be represented clearly in a level editor intended solely for myself.

Next, there were issues of scale to consider. I wanted to have missions that could potentially be around 20km by 20km in size. I also wanted everything in the editor world layout to be visible all at once without zooming or scrolling. Ultimately, I decided on a layout pixel size of 600×600, with every pixel being equal to 30 meters in real space. That was more than precise enough for my needs and resulted in a playing field of 18km by 18km.

My choice of scale had one unfortunate implication. The smallest unit of size that could be represented in my editor was 30m (1 pixel), but the fighters in Gateway are around 10 meters long, which was one-third of the smallest visible unit in my editor. Cruisers, being around 600 meters in size, could be represented to scale with 20×20 pixel sprites, but fighters posed a problem. I decided to simply make the fighter sprites larger than they would be in real space by several pixels in each direction, to allow easy visualization and selection with the mouse.

scale issues

Without some changes, the fighter sprites would absolutely be too minuscule to determine orientation, select with the mouse, or even see properly.

Next on the list was to decide the kinds of features I wanted to support in terms of building worlds. Tools like selection, translation, and rotation were essential. A ‘snap’ functionality would be immensely useful in terms of both moving (snap to grid) and rotating (snap to angle). Since I’ve used Blender a lot, I decided to support Blender-style keyboard shortcuts (which often don’t require modifier keys like shift or control) to make things familiar and faster: ‘A’ to toggle selections, ‘G’ for grab, ‘R’ for rotate, etc.

After about two weeks, I had a fully-working editor. It only had a minimal set of features, but that was all I needed.


Level-building in progress. The player and a few wing mates are spawned far away from the action. The editor is just as much fun to use as it was to implement!

Team colours are represented by the highlights around objects. A grid in the background is used to determine distances. A few other tabbed panels are used for scripting music, dialogue, etc., and basically just contain multi-line text boxes.

Developing a level editor has been a very interesting and exciting experience for me. If anyone has experiences or stories working with level editors (including their own), I would love to hear about them in the comment section below.


* As a side note, I have entire sketch books full of old game level designs from way back when. Maybe I’ll post some.

Some Case Studies

Game programming is something I’ve been interested in since I was about 11 years old. I started by making simple programs and games in Visual Basic. Shortly afterwards, I made my bumbling way into the world of 3D game development, and I completed many projects using DarkBASIC. All of my games were very simple, but this is the reason I finished them: they were small and built on well-established mechanics such as jumping, collecting treasure, shooting, or racing against time.

Featured below are a few of my favourite completed game projects from way back when. They were all made for my own amusement, and are all from a time when I could barely program to save my life. Or make game art. Or anything.

Goblin Stoppers


Jump from platform to platform as you try to escape the lava-filled cave. Home to baby dragons hungry for their first taste of goblin flesh, the cave is also rumoured to hold treasure that renders the finder completely invulnerable…

I consider this to be my very first fully-playable computer game. Its simple mechanics, combined with a small map size, made this project a reasonable first.

Space Havoc 1, 2, and 3


Fight for your life in open space against skilled pilots determined to prove their worth.

The first version of this space-based combat game was incredibly simple, and started to grow in complexity as the project matured. It spawned a total of three titles. There were a few attempts to make a much more complex fourth title, but these designs eventually became part of Gateway.

Cavin’ In


Fight against time to collect all the treasure in a maze from which no one has ever returned. Lava flows around every corner, while fire goblins lie in wait for their next meal.

The idea here was to navigate through a dark cave in search of treasure, avoiding lava and catching glimpses of scary fire goblins while a lightning storm raged outdoors. Again, this was a very simple game with a simple goal: run through a large maze collecting items as you go, before time runs out and the cave collapses.

Space Fire


Use an assortment of weapons in a deep-space duel to the death. Only one of you will survive.

This was a two-player game, where each player had an assortment of weapons (laser bolts, laser charges, and missiles) with which to kill each other. Players could also take cover behind the asteroids (which could be destroyed, too). Unfortunately, no one ever played it with me more than once, because I was too good at it.



A twist on a classic sport, Shufflespace puts a 23rd-century spin on a well-known game.

The goal of this game was to aim and shoot a laser from the far end of a shuffleboard, and take down all of the miniature aliens at the other end. The alien formations could be customized, and the game even supported something called “live mode”, where the aliens would walk around at random, making them more difficult to hit.



Lost in a frozen maze, you find yourself attacked by vicious monsters that have made the cavern their home. Armed with only your wits and an ice-spewing gun that freezes everything it hits, only tenacity will ensure your survival.

This game didn’t have any time limits, but there was one important constraint: your gun had limited energy and depleted quickly as you fired. Energy crystals found within the cave would help to replenish its reserves, but most of them were guarded by the locals.

Water World


While not technically a game, this partially-submerged cavern was a good way to test various environmental effects and AI behaviours. Rumour has it that deep within the depths of the stone fort inside, mysterious life advice lies scrawled upon the ruins.


Finish or Fail

I have a list of unfinished projects as long as my arm. It’s taken me a while to develop the discipline necessary to see my goals through to the end. So, this week’s post will be all about the various causes of project failure that used to plague me, years ago.

Of course, this list is not exhaustive, nor are these categories mutually exclusive. Readers are more than welcome to contribute their own insights.

  • Feature creep. This one hardly needs explanation, and has been the bane of my existence more than once. Too many times have I been unable to resist the pull of flashy features that only served to broaden the scope of my project to such a degree that I could not possibly finish it.
  • Massive changes to the system. A particular game called Wing comes to mind. (This was, in fact, yet another precursor to Gateway.) I had a nearly-finished game engine, support for exciting environments and missions, and a story ready to go. My younger brain thought that it would be a wise idea to upgrade the core graphics engine I had written to something more modern. Instead, all that ever became of Wing was a whole lot of shader bugs and rendering issues. While I could have easily reverted to previous, working versions, I had become so disenchanted with the problems I was having that I ultimately dropped the project. (Fortunately, a lot of the AI and flight mechanics code now reside in Gateway, which has saved me a lot of duplicated effort. So, it wasn’t a waste.)
  • Lack of design. This was an important lesson to learn. Many of my failed game projects began with visions of flashy graphics, advanced particle or rendering effects, or even a single unique gameplay mechanic. Having not given any thought into these projects other than, “this feature is going to be really cool”, they were, of course, doomed to disappear, not having a drop of substance. Since then, I’ve learned that quick, graphical demos are a great way to showcase flashy effects, and that you should have a solid plan in mind before touching a single line of code.
  • Lack of commitment. Being a game dev hobbyist means you’re free to work on whatever you want. I’m constantly being harassed by new and exciting ideas, even as I work on Gateway. Even a well-planned-out game isn’t guaranteed to be completed if you can’t pick your projects wisely. The trick is to choose something that you know you can complete. Initially, this should be something simple, and as you gain experience, you can take on the big ones.
  • Too much commitment. Or, in other words, learn how to take breaks. Your game isn’t going anywhere. Contrary to popular belief, your passion for your project will not dissolve if you set it aside for a week. In fact, you’re likely to return to it refreshed and excited as ever. Constantly pressuring yourself to work on it without disengaging for a while is a sure way to get sick of your project real fast, in favour of some other shiny jewel.

Originally, my failed project, Wing, was about a group of young anarchists trying to buck the system and disrupt a benign, powerful empire simply for fun, when things get out of hand and they find themselves being actively hunted for their increasingly risky crimes. For your viewing pleasure, here are two screenshots. The resemblance to Gateway is fairly apparent if you look closely.

Three established friends test the player's ability to face intense combat odds.

Three established friends test the player’s ability to face intense combat odds.

The player dives low to avoid being caught on radar.

The player dives low to avoid being caught on radar.


Deliver the Difference

Several years ago, I began work on a project called Space Havoc 4, but never completed it.* During SH4‘s development, I had a relevatory experience.

You see, around that time, Bungie had just released Halo Reach. Being (somewhat of) a Halo fan, I checked out the reviews and screenshots to see whether the game was worth my time. It looked good, but my heart sank when I saw screenshots of Reach‘s space-based missions.

It took a little bit of introspection to figure out why. It was a silly thing: what I felt was a bit of jealousy combined with the disheartening feeling that whatever SH4 would turn out to be, it would not compare to what a major game company could produce.

In any case, I got a copy of the game. When I finally got to the space combat missions, I was pretty excited to see if they would live up to my expectations. To be perfectly honest, they didn’t. While the graphics and mechanics of play were polished (as always), it wasn’t terribly fun for me. This is probably because I was expecting epic space battles with tons of battle cruisers and hundreds of ships — while I have no doubt that Bungie could have delivered on that front if they had wanted, they chose not to.

So, in a way, hope still remained. I felt that I could produce something more fun, mostly only because the gameplay of Reach‘s space combat didn’t blow me away. In other words, there was room for improvement, and I didn’t feel “threatened” the way I had before. To be honest, I suspect that this will always be the case: the unique visions I’ve had for any of my games (either completed or not) have never been duplicated in any commercial games I’ve ever played. Is this just dumb luck, or is it because no two games, even with the same genre and similar appearance, are ever the same?

While I can’t speak to how many hobbyist game developers might have given up on a project because they feel they’ve been “scooped”, I’m sure many have experienced the same feelings I have regarding this issue.** I’ve since realized that these emotions are entirely uncalled-for, if only for the simple reason that no one — big-time company or not — can make the exact vision of what you want to see come true except for yourself.

Don’t put existing games up on a pedestal. Don’t be intimidated like I was. Challenge existing games and find ways to make them better. This should be a constant exercise. Nothing is above criticism. Everything can be improved. Your vision is unique, and the world needs to see it come to life.


*  Fun fact: little did I know that this failed project would become the precursor to Gateway.

** For the record, Space Havoc 4 was never completed not because of the Halo Reach incident, but simply because I couldn’t figure out the mechanics of various aspects of gameplay, namely the space gates, how they work, and how to destroy them — a problem I’ve resolved in Gateway.

Managing With MMD

You’ve got a free evening and a brain full of story. Ideas enter your head and then exit without closing the door, leaving your mind wide open for new ones. How do you decide which ones to put into your game, and which ones get the axe?

In an ideal world, we’d have the time and talent to say, “all of them”, but moderation is required for anything to be completed. My own approach is to use a categorization system that I call the MMD ranking model. It places all of the possible major features of a game into one of three categories in terms of how important it is (and likely) that each feature will be implemented. At the onset of every game dev project, before writing any code, I’ll sit down with all of the features and sort them into one of the following:


  • This is the simplest category of the three, and always contains the least number of entries. What should be included in this section is a complete list of all of the features necessary to turn your game into something playable. This is surprisingly minimal. You’ll be surprised to realize that it doesn’t take much to make something fun, and that many extra features you might dream up aren’t strictly required (although they might be nice to have).


  • Middle grounds are always tricky. In my experience, this has been the longest section of the three because it enumerates most of the awesome features that I think would really make my game kick some serious ass. This might include additional enemy content, fancier weapons, or optional missions. The omission of any of these items won’t ruin your game, but it might not hurt to promote one or two of them later on to the above category for some extra fun. Just don’t get carried away.


  • It might seem kind of stupid to include a list of things that you won’t be putting in your game — this is obviously a lot. (You’re not going to put a Goomba into your Halo video game clone. Hopefully.) This category is really meant for the ideas you’ve had that are unfeasible for your project, due to (a) time constraints, (b) severe lack of technical knowledge, or (c) because they’re generally not focused on the core purpose of your game.

I should point out that the items ranked in these lists don’t have to be purely non-technical. Your implementation will dictate many things about what your game can and cannot do.

Of course, I wouldn’t leave my readers with just a description and tell them not to slam the door on the way out. Here’s a real example of an MMD list I developed while I was working on a very basic, minimal 3D game library a few years ago. The list evolved over the lifetime of the project, and items that were implemented were removed as things proceeded.

Must-do (remaining):
– Triangular prisms, pyramids (easy; make a couple new primitive types)
– Camera functions: follow, point (see previous code)

– Changes sprites to use Shader code (easy)
– Frustrum culling (see BGOGL)
– Particle library in 3D (import from Wing)

– Animated model loading
– Support for user-defined custom shaders and rendering


Lighten the List

There is generally always a long to-do list of things you need to implement when you’re working on something. While a little knowledge of what remains can help direct your efforts, my own experience has been that to-do lists can actually be detrimental to progress.

While I don’t deny that lists can help you focus your efforts and assist you in determining what to tackle next, I find them to be incredibly demotivating. Whenever I make a to-do list (regardless of how close I am to finishing a project), the sheer number of outstanding tasks inevitably makes me want to roll over and give up. In a previous post, I mentioned that individuals tend to overestimate the amount of work they can accomplish in any given length of time, and this optimism is a great motivator. Making a long list of what I need to do tends to curb this optimism, and makes it hard to enjoy what I’m working on.

Another thing worth mentioning is the “grass is always greener” syndrome. I’ve lost count of how many times I’ve looked at a continuously growing list of tasks and caught myself thinking, “You know, I have another idea for a game that would be much easier than this.” Of course, I know better now — any game is going to have a to-do list just as long as the last.

My solution to this problem is actually very simple, and is comprised of two parts. First, I’ll outline a set of immediate tasks that I want to tackle within the next week or so. I’m not talking about goals like “Finish the damn game”, I’m talking about (very-)short-term goals and milestones. This is usually a brief list of 2-4 small features. Here’s an example of what such a list might look like:

  • Refactor to read player settings from file
  • Correct missile material and LOD settings
  • Implement sonic push cannon ordnance

In addition, I’ll maintain a second list that describes in detail all of the things that I’ve completed, even if the items on that list weren’t originally on my list of things to do. This allows me to see my progress (which is, surprisingly, very easy to forget) and keeps me highly motivated. I have a very long list of things I’ve accomplished with Gateway, and it makes me feel good to read it.

If you’re worried that by not enumerating every minor outstanding task you’ll somehow make a mistake or forget something, you should direct your concerns elsewhere. You should already have a feature list that you’re sticking to, and this is good enough. You won’t help yourself by breaking everything down and realizing how much work is actually remaining. So, trick your brain into being optimistic by making a short list, and enforce that optimism by keeping those goals attainable and documented.


Powering Through Problems

Game dev isn’t easy. No one can deny that it’s incredibly rewarding, but there are also moments where sheer frustration will make you want to throw your PC down a flight of stairs, or out a window because the stair violence doesn’t convey how you really feel. Taking breaks is not a bad idea, but the game will never be finished if you continually set it aside or refuse to pick up your project again out of frustration from a temporary lack of progress.

The real issue is that problems like these can be very demotivating. It’s hard to see past a problem until you’ve fixed it. In my experience, the majority of game dev problems can be placed in one of the following categories.

  1. Technical problems: “I don’t know how to implement X.”

    This is the most common category of problems that a beginner will face. It’s also the most challenging, both from a technical perspective (because you’ll often have to learn something new that is non-trivial), and from a personal perspective (because it’s frustrating to see a lack of progress on something so important to you). These kinds of problems always have a solution — there’s always a way to implement something, and knowledge can always be acquired. This is a fundamental truth, and don’t let anyone tell you otherwise. If you lack the knowledge, get it. Take that extra linear algebra class or buy that GPU programming book. If you possess this level of commitment to your projects, nothing can stop you from finishing them.

    The other alternative is to find resources online. Need a collision system that supports concave geometry, but don’t know how to make one? Someone else probably does, and it’s most likely online for others to use. (I’m a firm believer that you should do everything yourself at least once, so try to aim to understand code that you download, if possible.)

  2. Design problems: “I don’t know what approach to take/feature to develop.”

    I’ve had entire projects come to a halt because of my inability to make design decisions, or because they got out of hand. There are two strategies I’ve generally embraced when I can’t make up my mind:

    Stay away until I’ve made up my mind. This is a pretty good approach. I certainly don’t want to end up in a situation where I continually change my mind and keep re-implementing things as a result. If I’m not sure about something, I just let it sit for a while. The better choice will eventually become clear.

    Just run with one of them. If it’s not a very important decision, I’ll often just choose arbitrarily. The key here, though, is to make sure you stick with your decision so you don’t end up wasting time flip-flopping in the middle of your coding session. Make a decision, even if it pains you. And that’s final.

    I should point out that you could spend forever designing a game or making decisions about features. The point of “just running with one of them” is to avoid wasting time philosophizing about what might actually be a really trivial thing. When deciding which of these two approaches to use, try asking yourself: “Would my players really care?” If you think they would, then maybe sit on it for a while.

  3. Debugging problems: “I don’t know why my game does/doesn’t do X.”

    “Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.”

    Brian Kernighan

    This is another bad one. Debugging is often a very painful experience, but the single best piece of advice I ever received regarding debugging was this: “Know your data”.

    If something doesn’t work properly, don’t just stare at your code and think about it. If thinking was enough, you wouldn’t have run into the problem in the first place. Print out some useful information. Get your debugger going and watch those variables. You’re only going to get so far without these tools, and by using them, you’ll find that you’ll solve your problems a whole lot quicker.

So clearly, there is no shortage of issues one can face. But, successful individuals power through these problems because they’re committed to seeing their vision come to life, and they know how to meet a challenge head-on. I encourage you to do the same.


Starting Out Simple

In addition to eating one’s vegetables, not running with scissors, and otherwise playing nice with others, there is a ton of useful advice that I wish I had known earlier on. Game development is one of the most fun and rewarding hobbies I can think of, but it can be tough to get started. If you’ve just begun your foray into creating your own digital worlds, here are some pointers that might help to make the road ahead a little smoother.

  1. Make your first games simple ones.

    It’s a well-documented fact that beginning game developers have inflated expectations in terms of what their first projects should look like [1]. While optimism is always encouraged, a sprinkle of realism is often beneficial and might result in actual success, not to mention an incredible feeling of accomplishment.

    A bad judge of a project’s difficulty will base their decision solely upon technical issues. “Is this game technically and programmatically feasible for me?” is not the kind of question you want to ask yourself. Instead, try asking: “Can I complete this in a reasonable amount of time?” For a first simple game, aim for a completion time of around a few weeks. (Of course, this will vary greatly on a person’s prior level of programming experience, but 1-3 weeks is a near-enough goal that it won’t seem too overwhelming, while still allowing you to accomplish enough to feel like a rock star afterwards.) Remember, it will probably take longer than you think it will, so scale back your goals if necessary. Having a single completed game feels way better than any number of unfinished ones that you’ve quit working on.

  2. Write small demos.

    Once upon a time, whenever a fancy particle system or terrain-rendering engine came to mind, I immediately wanted to write a game in which to use it. Naturally, such projects were never completed. I’ve since come to learn that what I really wanted was not to build a game for these systems, but to simply showcase them somehow. Graphical demos are short programs built solely for the purpose of demonstrating some new technique, and are perfect in this regard. These small projects are a great creative outlet for any of your new ideas without having to create an entire game to support them.

  3. Don’t care about art.

    So, you’ve implemented your combat mechanics and your menu screens. Your wizards can cast spells with beautiful particle effects, and you’ve optimized your ragdoll physics system to death. All that’s missing are actual humanoid models, since your avatar and everyone around you are currently being rendered as grey boxes.

    You might be lucky enough to already have digital art skills, but many of us can’t draw a straight line on a computer if our lives depended on it. Not having the assets necessary to make a game can be a setback, but don’t let this stop you. The Internet is full of websites dedicated to free 2D and 3D art, as well as sound effects and music. If you’re planning on distributing your game, though, make sure you’re aware of any copyright or licensing restrictions.

  4. Play lots of games and read lots of books.

    If you’d like to learn how to write good games, then you should play them. You should play some bad ones, too. Play a lot of games and figure out why they’re fun to play (or conversely, not fun to play). This perspective will be invaluable as you set out to design games that you want others to enjoy. You should also be reading game design and game dev books. Buy every one you’re interested in that you can get your hands on: they’re far better than anything you’ll ever read on the web (including this blog).

  5. Get some air occasionally.

    Sunlight is popular and free year-round. We’ve already established the importance of taking breaks, and it certainly bears mentioning that some of my best ideas have come when I wasn’t thinking about game dev. You’ll never know when inspiration will strike — it often hits you when you’re busy enjoying something else. So, don’t be afraid to step away and do something else…your project won’t go anywhere while you’re away, and neither will your motivation.


[1] Saltzman, M. (2002). Programming Theory. In Game Design: Secrets of the Sages (4th ed., p. 283). Indianapolis: Pearson Education.