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.


Jan. 12 — Where I’m At

Not a whole lot has happened since my last progress report. This has mostly been due to the fact that up until that last post, I had been working on Gateway a fair bit, and was in need of a break. Nevertheless, a few things have gotten finished, and a lot of optimizations and graphics improvements have been made.

I had a bit of an unfortunate discovery several weeks ago, and found that a lot of my in-game models and textures didn’t look as nice as I had originally thought. The next couple of weeks after that were spent re-texturing some spaceships, writing a few new shaders, and implementing a better level-of-detail (LOD) system. The game looks much better — it was well worth the extra effort, despite my overwhelming lack of artistic talent.

An FPN cruiser opens fire as it slowly emerges from a Colossal Gate.

An FPN cruiser opens fire as it slowly emerges from a Colossal Gate.

Here’s a breakdown of some of the more noteworthy things that have been accomplished:

  • Several models were re-textured and some shaders were reworked, for a shinier, sleeker look to the spaceships
  • New LOD system combined with several major optimizations speeds up the gameplay noticeably
  • Mission Success menu screen has been implemented

I’ve also begun purchasing royalty-free music so I can slowly integrate it into the missions and see how they fit. What I’d really like to start once I finish reworking the last of the spaceship models is to start building the missions themselves. A lot of missions ideas are ready to take the hazardous trip from my head to the computer, but there is one major obstacle in my way that I haven’t figured out yet: voice actors.

Each of the 10 missions requires a short briefing, done by different characters at different times, as well as some initial dialogue between your wing mates at the onset of each mission. I expect I’ll need about 5-6 different voices: 2 or 3 for the briefings, and 3 for the pre-mission banter and chatter. Once I’m finished tweaking the last remaining spaceship models, I’ll begin scripting out my missions in detail to determine exactly what I need.


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.