Hobby Videogame Development: 20 Questions

Apr 30, 2013

Backstory: in 2010, I wrote an article like this one published, in condensed form, in Game Developer magazine’s Career Guide. This is an extended version (50% more content!), republished here with permission. I’ve written about a handful of these points elsewhere in the blog, some before the article and some after, so this also hopefully serves as a handy starting point for people coming to HobbyGameDev for the first time.

This post is available in audio form.

Music excerpts at the start and end are by Kevin MacLeod, via Creative Commons, from incompetech.com.

Transcript of the Audio:

For my first decade making videogames, I was a hobbyist. I created dozens of freeware games without any intention of making my living from it. Since then I’ve found joy in helping others get their start in hobby videogame development. A handful have gone on to be professionals in the industry, but many are content to just be making videogames as a pastime.

Alas, certain questions seem to frequently pop up that are preventing a whole lot of people from getting started, trapping them from making progress, making it hard to finish projects, or leaving them unable to get the most out of their games once finished. Because so many of those same questions seem to appear for so many different people, I’ve collected here the responses that seemed so far to have best helped the people I’ve worked with.

Let me be clear that these aren’t just guesses or theories. In addition to my own volume of work I’ve also seen hundreds of developers getting into small-scale noncommercial videogame making with various attitudes about it, some of whom fall off the rails at various stages, while others roll on project after project.

Questions About Starting

Out of the many people that are capable of making videogames, that want to make videogames, why are so many of them not making videogames? These are the questions I have heard people explain as blocking them from getting started.

Question 1: How can I raise the money needed?

Answer: AAA videogame development can cost tens of millions of dollars. Hobby videogame development can be done entirely for free. Think of commercial videogame development as architecture and construction; think of hobby videogame development as making pillow forts out of anything in reach. If you are spending money on making your pillow fort, you are doing it wrong.

Question 2: What’s the best platform, distribution channel, or strategy to make money?

Answer: Has this question ever kept anyone from picking up a basketball, learning guitar, or taking dance classes? When, in rare circumstances, people do wind up doing those things professionally, they aren’t doing it for the first time when someone offers to pay them to do it – they did it for years out of a love for doing it. Art and shop classes don’t begin with an introduction to marketing, not only because that’s a fundamentally different skill, but because overemphasizing money early on can spoil the craft.

Question 3: What if I’m not a good artist, or programmer, or designer?

Answer: In that case – and this is usually the case – you will have more to gain than someone who is already good at those skills. Practical application is a great way to learn. The goal initially is just to be functionally capable of doing those tasks, in order to create something from nothing. In the same way that anyone can draw or sing (even if not incredibly well), anyone can build a level, anyone can make a 2D sprite, and anyone can learn enough programming to at least make something simple. After that, practice will lead to making things that are increasingly more involved.

Question 4: If I can’t make the next Halo or Final Fantasy, why bother?

Answer: You have numerous advantages as an independent developer that the huge videogame studios don’t.

You can see your own ideas come to fruition. You can follow your gut. You can play around with designs that would be far too crazy to bet on if the financial yield had to recoup 3 years of full-time employee salaries. You don’t have to prove anything to anyone except your players (and/or maybe yourself) – there’s no asking permission or trying to win anyone over.

Enjoy your freedom, and find ways to make the most of it!

Question 5: What if my heart is set on working with huge games, and making a career out of it?

Answer: Another way to get started, that can help meet this frequent request, is by modding. This option may work out better for people interested in specializing in modeling, audio, level design, and genre-specific programming. Before I was creating games from scratch, my first development experiences were making tweaks, weapons, and levels for Command & Conquer, Doom, and Descent.

Not every commercial game is feasible for modding, however many of the most popular PC games from the past 15 years have great tools and active communities. This is an entirely different subject than hobby game making though: google for modding, and you’ll find everything you need online.

Indecision Questions

Buridan’s Donkey is a parable from philosophy in which a donkey, standing before two equally appetizing bales of hay, was unable to decide on a reason to eat from one pile rather than the other. Paralyzed by indecision, the donkey starved to death, next to more than twice as much food as it needed.

In other words: any answer to these next questions is better than no answer. Pick one and run with it.

Question 6: Which programming language should I use?

Answer: If you want to make high-performance downloadable computer games, I recommend C++ (use SFML, Allegro, SDL, or DirectX for the graphics/sound/input). If you want to make smaller games that can be played on the web without players needing to mess with installation, I recommend ActionScript 3 – this compiles to Flash programs, and can be used for free without Adobe’s Flash CS animation tool. Modern console and PC games are almost all programmed in C++, whereas ActionScript 3 projects dominate casual online game sites. I have seen students that I am working with get great results from XNA, although that is not something that I have used in my own projects. Unity has also been gaining a lot of ground in terms of enabling solo developers or small teams to make impressive cross-platform 3D and 2D games.

But here’s why I brought up Buridan’s Donkey at the start of this section: the only wrong answer is no answer! Don’t be the donkey that starves to death in front of twice as much food as it needs, don’t be paralyzed into indecision by there being more great and valid ways than ever before to make videogames. Get started on any of them, be ready to learn a lot as you go, and even if you find that you change your mind later for the next game, a lot of that same learning and process will transfer smoothly into the next platform you work with. Pick one that you can find at least a few finished games were made with, and get started!

Question 7: Which tools should I use?

Answer: I’m partial to free tools that get the job done: I suggest GIMP for 2D images, Blender for 3D models, and Audacity for editing recorded sound effects. In Windows, I program C++ projects using Bloodshed Dev-C++ 5 (though for more recent developers Code::Blocks has largely taken its place), and ActionScript 3 projects using FlashDevelop. On Mac I tend to get by with TextWrangler and recompilation scripts.

Question 8: Which part of my dream game should I work on first?

Answer: If it’s really your dream game, and you want it made right, you won’t make it the first project that you work on. I recommend getting a healthy chunk of beginner errors out of your system by making a few very modest and simple projects first.

There are two strategies for thinking about scope that I have found effective in guiding initial planning:

The Console Decades Ladder Make something of 70’s complexity first – on the order of Pong, Breakout, or (if you’re feeling fancy) Missile Command. Once you have one or more games of 70’s complexity behind you, move on to one or more games of 80’s complexity, before going on to 90’s complexity, and so on, sticking at whenever phase you prefer.

The Demo is the Game If you made a shareware/demo/lite version to show off what the game is about, in an effort to rouse excitement about the full product, what would need to be in that version? Plan on completing the game at that scope as the final draft. If it comes out well, you can build upon it for a longer or more involved follow-up.

Question 9: Are some game types safer than others early on?

Answer: In my experience overseeing and assisting with student projects, RPGs and side-view character-based genres are the most common failed or cancelled first-timer projects. This is due largely to their hefty art requirements.

Design the game with your art quality and quantity constraints in mind. Some 2D genres – such as overhead racing, side-view flying, abstract puzzle, and overhead space shooters – require virtually no animation, such that merely rotating and sliding static images via code will suffice. The other major benefit to these game types is that they often do not require hand-designed levels, instead spawning opponents semi-randomly, which saves the development effort required to create a level editor, level format, and levels.

Note too that online multiplayer is often much more complicated to build and test than a local-only game. Sticking to single player projects, or videogames where players can share the same screen and keyboard, can greatly simplify technical matters. To provide a sense of scale for what can be involved, for several of the student/hobby projects that I’ve seen support online multiplayer, they spent a full semester building the game in single player or AI opponents or local multiplayer, then needed an entire second semester – literally doubling the project’s time – to focus on getting online multiplayer ready for release.

Question 10: What should I put in my design doc?

Answer: It’s a trap! There’s no right answer to this question, because I think most hobby videogames should not have a design doc.

Starting by writing a 20-page design document is silly, and usually a misuse time for a beginning developer. This is like someone that has never cooked anything before trying to invent a recipe in Microsoft Word, or someone that has never worked with wood before trying to invent a woodworking project by sketching. As soon as the actual project starts, that plan has to be either thrown out (a waste of past time) or constantly updated (a waste of future time).

Use an image editor (GIMP, Photoshop…) to make a rough mock-up screenshot showing how the game might look when running. This will get you thinking about pixels and user-experience. Then write just enough code to bring the screenshot to life. If writing something down helps, I’d recommend keeping the treatment to under one page, and focusing on notes about gameplay rather than the game’s fiction.

Project Finishing Questions

Unfinished videogame projects are not victimless. They waste the talented work of anyone that helped make content for the project, they cheat players out of an opportunity to explore someone else’s imagination, and they cause a severe morale hit to the developer(s).

Fortunately, just a few causes tend to be responsible for the overwhelming majority of sunken hobby projects. That means that each can be addressed on its own here:

Question 11: What can be done to keep stress and social politics from pulling the team apart?

Answer: Keep the team as small as possible, to minimize the probability of severe personality mismatch.

Minimize the project’s duration to several months, or ideally even less for the first project or two. Any rough tensions, frustrations, and misunderstandings that might be present between people on a team are likely to grow if a project drags on.

Going into a project as a lead, make sure that you’re ready and able to functionally (even if not as well) complete any of the kinds of work that you’re bringing aboard team members to help out with. Your ability to fill in for missing areas to keep the overall project on track gives other developers on the team the confidence that no matter who else leaves the team, the show will go on and their work will appear in a finished game. This confidence can help keep others productive.

Question 12: Are 5 programmers, 5 game designers, and 5 artists enough for 1 game?

Answer: If nearly everyone involved is a beginner, then that’s far too many people for 1 game.

Bigger teams lead to more ambitious plans, longer project schedules, more communication challenges, more development bottlenecks, and more conflicts of both style and opinion.

I’ve seen student hobby projects with 25 members give up, as the project leader claimed that the team wasn’t big enough to finish, while a half dozen teams of 2-4 members all completed their games.

Encourage the group of 15 people to split into 5 teams of 3, and overall you’re more likely to see a yield of 3-5 games, instead of 0. Don’t put all your eggs in one basket, avoid diffusing the clear responsibility of one person ambiguously across multiple people, and aim to create an atmosphere in which teams can learn from one another’s independent investigation or experimentation.

Question 13: How can a project be protected from feature creep?

Answer: When the game is in finaling mode, beginning perhaps halfway or three quarters through its scheduled development time, generate a list of the bare minimum that needs to be done before the game can be considered finished.

Now here’s the important part: only allow that list to shrink!

There are two ways to shorten the list: complete the item it refers to, or cut the item. Whenever you can make a cut without decreasing the quality of the game – even if only because it allocates more time to doing other tasks that must be done – make that cut.

If this sounds ruthless or contrary to the idea of hobby game making, note that until it’s finished, it isn’t a videogame. A garage full of carved up scrap wood is not the sign of a woodworker – a homemade spice rack and a new chair are. Just as the outside world does not want to drive a 90% working car or live in a 90% finished house, no one wants to play a 90% completed game. The other catch is that until it’s done, it’s impossible to even say what “90% done” really means; sometimes we have to start over to fit all the pieces together, which puts a perceived 90% much closer to 45%. It’s either done, and a videogame, or it isn’t, and it isn’t. As the old Apple Computer line goes, “Real artists ship.”

Question 14: When should we stop polishing the current idea?

Answer: Iteration – the cycle of tweaking, trying out, and repeating – is an important part of polishing every game. However, tuning offers diminishing returns, adding less overall value with each pass. It doesn’t take long before the game is as good as it’s ever going to be, the tweaks are too minor to affect user experience, and it’s time to wrap things up in order to advance to the next idea.

The old 90/10 rule of thumb suggests that 90% of the player’s attention and enjoyment comes from 10% of your work. If you can’t find something to tune that’s likely part of that 10% the player will notice or care about, test the game a few more times from start to finish without introducing any new changes, then call the game done.

Question 15: Why does “finished” work keep getting thrown out?

Answer: This happens when a project’s decisions are being made in the wrong order, causing everything to change whenever anything changes.

If the main character’s jump height is changed late in development, that will potentially break every jumping area in the entire game. Until enemy health, weapon range, and movement are finalized, levels should be throwaway test cases; after those decisions are finalized, and levels are made based on them, those values should not be revisited. Aim to make decisions in an order that minimizes thrashing.

Finished Project Questions

What is one to do with the game after it’s done? Read on:

Question 16: Why aren’t more people playing our great game?

Answer: First and foremost: do some marketing. Use Screenflow on Mac or Fraps in Windows and cut together a simple gameplay trailer with some music over it. Tip for that: record with music disabled in the game but sound effects on, then for the trailer add different music and decrease sound volume, so the video won’t jump in music or be without sounds. Make sure people know about it. If it’s something you’re pretty proud of, enter it in a competition. Blog about it. At the very least tweet and post to Facebook about it, tell your friends, share it with online communities, don’t just finish it then shove it in a directory to gather virtual dust. Games are meant to be played. No matter how great it is, no one will download it or even visit the in-browser URL if they don’t know what it is, and how to get to it.

Assuming that you have achieved some visibility on the project, the other possibility is that people are having a hard time getting it or running it. In many cases, this happens because the project isn’t well explained on the web, was packaged improperly, or wasn’t tested on alternative browsers, operating systems, or machines.

If it’s downloadable, either set up a single-file installer, or create a nicely organized zip file with ReadMe.txt/PDF instructions inside it. Try running the game from a few different computers, to verify that the package you’re giving out to the world isn’t assuming a particular library or framework is already installed. Present the game’s online link alongside a description plus a few screenshots.

If it’s a Flash-based game programmed in ActionScript 3, consider posting to sites like Kongregate or Newgrounds. This often involves little more than creating an icon and writing a short description, and can get a few hundred plays minimum, thousands in most cases, and sometimes tremendously more.

After spending months on a game project, spending even a few more evenings making it presentable can have a dramatic impact on the number of people trying the game. This is time well spent.

Question 17: How can I keep my mind engaged between projects?

Answer: Game making is a form of speaking, and the time between projects is an ideal time to catch up on listening. Our minds can fortify mid-development, filtering attention based on “does this apply to my game?” Tear that filter down, let things in, and expose yourself to some new ideas.

I strongly suggest carrying a pen and a small notepad, to jot down thoughts – not to save them because they’re valuable, but so that you can be free to move past them. You’ll encounter and come up with a ton of mediocre ideas throughout the day, and they’ll get stuck in mind until you let them out. Simply putting the gist down on paper can free your attention from juggling it, making it easier to move on to finding and considering the next ideas.

Question 18: Is there any way our game could have been better, given the same time and effort?

Answer: Don’t spread the development efforts as thin. Focus the love. The same amount of attention that could be poured into a poorly-made medium-sized game, could instead be applied to a well-polished small game. Remember too that any partly unfinished game could have been a completely finished slightly more modest project.

Control scope every step of the way: plan with it in mind, develop with it in mind, end with it in mind. If great ideas come up during development that won’t fit in the schedule, record them for possible implementation in either an update, sequel, or later project.

Question 19: How important is it to get everything that I made into the final game?

Answer: Films and novels are edited aggressively, and much to the benefit of the end result. Most videogames probably should be edited aggressively, too, and this can include chopping out parts that are finished. In game design, if the inclusion of something is not improving the overall experience, then it’s getting in the way of the elements that do.

Now, if it’s a student project, and it’s just friends working together to get experience on a hobby project, then it’s definitely worth considering ways to include at least some work from all contributors if possible, especially those that genuinely committed themselves to doing their best possible work for the game. If something is bad enough though, at least try to figure out some way to get that developer to do another iteration on it, or arrange the game in such a way that it won’t block / gate access to content by other developers on the team. If it’s really, really bad and additional iteration can’t seem to fix it, see if they’re open to the possibility of making something else from scratch to replace it, or if the kind of work they were doing just wasn’t coming out at usable quality (ex. their character art just isn’t coming out right?), see if they’re open to contributing in some other way (assistance with sound? leading some external playtesting efforts? something!). At the end of the day though, recognize that an awful level or puzzle or encounter early on may prevent players from experiencing the other content later in the game that came out well, and fairness to an individual developer many need to be balanced with fairness to the team as a whole.

If it’s all your own work in question though, because you developed solo, don’t be bashful about ruthlessly cutting the worst parts away before release. Is the only part of the game that really came together well one of the minigames? Consider carving away the rest and just releasing that minigame. Seriously. Or at least separately, in addition to still also releasing the rest of the game (heck, for an interesting little experiment, pay close attention to how responses vary to the two).

The best 30% of anyone’s ideas or work are better than the other 70%. This seems obvious, yet so few people act on it. Think about it like a simple English paper for school, something we all learned in middle school: there’s more to do in going from a first draft to a second draft than fixing spelling and grammatical errors – for videogame projects most people skip the revising and focusing altogether as if their first output was a second draft and they’re ready to fix up little bugs then call it a final draft. Ever play a game that you would have recommended to friends, if only “they had cut that one part out?” Find that part in your game, and be brave enough to cut it!

Great developers make self-editing part of their process. Strive to create more content than the game is intended to have or than it needs to have, and going back to trim out their worst material to leave only the best. Need 12 levels? Make at least 15 to choose them from, or if you want a better set of 12 levels, make 24. (Then resist the temptation to pollute your end result by including at the last minute the very garbage that you consciously decided to throw out.)

Question 20: Is it possible to know how often my game is played, and to partly retain that audience?

Answer: Keep metrics. Use StatCounter or Google Analytics to keep track of how many people visit your game’s website. You might be surprised which of your projects gathers the most attention. Whether you’re sharing excitement with family, trying to recruit new team members on a later project, or updating your resume in an effort to go pro, it would be nice to later know whether your game had 3 or 3,000 or 3,000,000 plays.

The second piece of that question is to link back to your site, either via a menu button in the game or through a shortcut in the game’s start menu folder or at least include the URL someplace in-game. This enables satisfied players to find out more about your current and future work. Even if there isn’t much on your site now, there may be in 5 years, when you’re still pulling in traffic from old games you made back in 2013.

If You Haven’t Already… Start Today!

Good luck!

Learn and practice team game development with Gamkedo Club.
Membership worldwide. Professional support. Proven process.

Subscribe by e-mail to receive weekly updates with Gamkedo.Community interviews and YouTube training videos for game developers!

All contents Copyright ©2017 Chris DeLeon.

Site production by Ryan Burrell.