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.

Breaks Aren’t Bad

Long ago, my main fear when working on a project was that if I stepped away from it — either to work on a smaller project temporarily, or to just take a break — I would lose interest and subsequently stop working on it altogether. For this reason, I never used to set aside a project, and I pressured myself for months to spend most of my free time working on it.

In hindsight, this wasn’t such a wise strategy. It may very well have been my constant refusal to occasionally set aside my past projects that prevented me from finishing them. In fact, throughout Gateway’s development, I’ve taken a couple of breaks — one of them even two months long — with the full intention of returning to it (and I did).

I’ve since learned that taking breaks from a long project is kind of a necessity, at least for me. Continually working only on a single project, especially a big one, can be overwhelming and ceases to be fun if you put pressure on yourself. It’s no longer fun if it becomes a chore. I do, however, have a rule that I like to follow when working on a large project: no working on other large projects allowed.

Small projects are great: they’re fun, probably simple, and don’t carry the risk of being so intimidating that you never finish. They’re also great confidence boosters, and can help ease that urge to finish something while you’re on your way towards a much larger goal. Taking on an additional large project, however, doesn’t have any of these benefits and only adds to the list of massive endeavours that you’re unlikely to finish in any short amount of time. For these reasons, I allow myself to occasionally set aside Gateway to make room for a quick, amusing project that will only take a week or so. Or, sometimes I’ll just take a break in general and not work on anything in particular.

I’ve learned that doing so doesn’t cause me to lose interest in my game. In fact, just the opposite occurs: after taking a break from a fun project, it becomes exciting to think about again, and then I pick everything up from where I left off. Those other tiny projects I occasionally embrace allow me to do something different and explore other ideas, and make me feel great for accomplishing something. They also keep my main project from turning into an obligation.

So, breaks aren’t bad. In fact, they’re kind of necessary. The next time you’re working on something, don’t pressure yourself into giving it every spare moment you have. Feel free to walk away for a bit if you feel something else calling you.


Adding the Art

My first 3D game programming experience was with a language called DarkBASIC. For those of you who know it, I don’t have to explain why my Grade 9 Comp. Sci. teacher at the time told me to drop that language like a bag of hammers. He also said to man up and start using C++. (Okay, I’m paraphrasing a bit, but he felt quite strongly on the subject. I’m grateful he did, though — moving to OpenGL was really the better option and I quickly learned why.)

DarkBASIC came with a fairly decent set of models, music, textures, and sound effects, meaning I didn’t have to make my own. Soon, however, I found myself needing resources that weren’t included. I started building my own 3D models, textures, and sounds. I enjoyed it, and took pride in my work even if it looked less than polished.

I really hate the term “programmer art”. It comes from the days long ago when programmers were also responsible for a game’s art [1]. Don’t ask me why I don’t like that term, because I’m not entirely sure: I suspect I’m just being overly defensive. Before even seeing my game, when people ask me, “Are you using programmer art?”, I think they’re making an inaccurate assumption regarding the goal of my work. Maybe it even places emphasis on the wrong aspects of gameplay. Or maybe they’re just curious and I’m being oversensitive. Of course, this is just a hobby for me. If I was really serious about my game art, I’d hire someone to do it for me. Or make some artist friends.

When showing off a video game, friends and family would ask me, “Wow, did you make that?” and I quickly learned that I hated saying things like, “Yes, except for the trees and the music and the gun and the sound effects.” Chances are that these fancy assets were the most impressive parts, and not having a game that wasn’t entirely mine was somewhat disheartening. Maybe it was a pride thing, but I wanted to develop every single byte of my game on my own. (Within reason, of course: this obviously doesn’t include things like writing my own graphics library. Imagine that. “OpenGN”.)

(I should mention that the real world isn’t like this. Everyone is expected to collaborate. Rarely is one person solely responsible for the development of an entire project. Almost no one hires a genius and stuffs him into a closet with a laptop and slides pizza under the door.)

In Gateway, I’m developing all of the graphics myself and I’m sure that it shows. The thing is, I don’t really care so much about making it look spectacularly professional. Even with programmer art, “spectacular” is within the realm of possibility. It’s how you use that art that is important. When developing Gateway, I wanted gamers to be thinking about the massive scale of the space battles and the sense of immersion. Who cares what the half-kilometer battle cruisers look like when there’s twenty of them bearing down on your space station, plus a hundred one-man fighters?

It’s important to realize that extremely low-detail game assets don’t made a game less enjoyable — we’ve all unplugged the XBox or PS4 from the TV to make room for the SNES before. The level of graphics on those games don’t make them any less fun to play. (Yes, I realize that the art was developed by professionals, and generally looks polished even if the level of detail is low.) I acknowledge the difference between low fidelity and low artistic quality, but for the same reason that one can enjoy a game with a less-than-mouth-watering graphics experience, one can enjoy a game with programmer art.

Unfortunately, I’m not a jack-of-all-trades. (Or is that “fortunately”? I’ve never understood if this was a good thing or a bad thing.) You might be able to build your own 3D models and textures, but no matter how versatile your voice and acting abilities might be, you can’t voice all of the characters in your game. Undoubtedly, you’ll require some extra people to help you out. This is actually my current dilemma: there’s not much dialogue in Gateway, but there’s enough that I require about 4-5 actors, and I have no idea where to get them from. I’ll let you know when I figure this out.

The other issue is music. Piano lessons that I’ve quit taking more than 15 years ago do not make me a composer. Recently, I’ve become interested in purchasing the rights to some royalty-free music that fits the style of the game.

Finally, the point of this post: if you really suck at art, don’t despair. There are plenty of insanely fun games whose level of detail are very low. There are also 2D and 3D resources available online, for free or for a price depending on where you go. If you want to model everything yourself but don’t have the skills, acquire them…or adjust the style of game to fit. If home-made high quality art isn’t your thing, then tone it down to something you can do reasonably well. Remember: no amount of bleeding-edge graphics can make up for poor gameplay. Some of my all-time favourite, most immersive games I’ve ever played may have been short on graphics, but were long on fun in a way that had nothing to do with art.


[1] Rogers, S. (2010). Welcome, N00bs! In Level up! the guide to great video game design (p. 13). Chichester: Wiley.

Dec. 8 — Where I’m At

Currently, the list of things to do for Gateway is small enough that I can see the light at the end of the tunnel, but most of the major tasks are uninteresting enough that working on them might become a chore:

  • Finish the settings menu screen
  • Implement the music system
  • Build the mission successful screen
  • Write the missions

The first (finish the settings menu) is probably going to be the most boring of all. This just includes things like positioning the widgets and making sure that they all work properly.

Implementing the music system will probably be fun, and not hard at all. I’m ready to purchase some good quality, royalty-free music online, all of which are easily loopable and fit the game style.

The mission successful screen is one I’m currently struggling with. It’s not a question of technical implementation, I just have no idea what it should look like! Should the camera be tied to an outside view of the player’s ship while the user scans over their accomplishments and kill counts? Should the background be a wide, stationary expanse of space? Should there be music for this menu, too?

The last of these (write the missions) is the one I’m looking forward to the most. With the scripting system I’ve built, it will be very easy to create some fun and exciting missions. This stage of a game’s development is one of my favourites: playing with your game engine to see what kinds of cool things you can make it do.

There are still a couple of other minor tasks on top of what’s listed above, but I’ll get to those eventually (once I figure out what they are). In the meantime, here’s a couple of teaser screenshots.

A small fleet of NEA fighters and light combat vessels prepare to engage.

A small fleet of NEA fighters and light combat vessels prepare to engage.

The odds quickly become overwhelming as more and more enemy reinforcements arrive.

The odds quickly become overwhelming as more and more enemy reinforcements arrive.


Fight the Features

If you’re a hobbyist game developer, you’ve most likely had an experience where you keep adding features to your game that were not in the original design. These might include more complex weapons systems, specialized physics, or even new types of enemies. This continual addition of features is referred to as “feature creep”, and it might have even led to the death of your project.

The thing is, time spent adding extra features is time which could have otherwise been used to get you closer to finishing your game. Adding features is sometimes necessary (“Oops, I didn’t realize my ‘mech health system required a much more complex collision system!“), but in my experience, features were usually added “just because I felt like it”.

I attributed this to some weird sense of game developer perfectionism. Maybe the game really needed those extra features, or perhaps I was just getting bored with the game and had lost the ability to determine if it was fun anymore. In my quest to understand this, I decided to look outwards a little, instead of entirely inwards.

For the next little while, I spent a fair bit of time examining video games that I knew I enjoyed playing. I asked myself: are there features in these games that I would want to add or re-work, if these games were mine? Eventually, I stopped looking, because inside every single game, I saw loads of features I would add or change if I could. I began to wonder if the real developers of these games were thinking the same thing. Maybe some of them did, or perhaps even most of them, but their time and budget constraints would have prevented them from expending this effort when the rest of the game still needed to be implemented. What I learned from this exercise was valuable: the desire to add extra features and improvements was perfectly normal. I just had to make sure this urge didn’t get in the way of reaching my goal.

I embraced a new approach when I started Gateway. When a feature was planned and implemented, I left it mostly alone (unless there were bugs). Currently, the only primary weapons available in Gateway are laser bolt cannons. Would I like to implement laser beams or exploding charges? Hell yes, I would. But those aren’t part of my original design, and I don’t want to get carried away.

Martha Graham once said, “No artist is pleased”. While I wouldn’t call myself an artist, I think that the term can be expanded to include anyone who creates anything.

No artist is pleased. There is no satisfaction whatever at any time. There is only a queer divine dissatisfaction, a blessed unrest that keeps us marching and makes us more alive than the others.

Martha Graham

Maybe it would have been all right to allow myself to improve a few features beyond my original Gateway design here and there. Regardless, I decided not to start down that slippery slope and just stick to the features I had planned. Maybe additional features could be added later…but for now, I have to write the rest of the game.

Would it be nice to add certain features to the game? It certainly would be. But, I try to think “bigger-picture” now. I don’t have to create the game of a lifetime yet; I just want to finish the one that I’ve started. It’s just very hard to win a race if you keep moving the finish line.