You want to make games. The why isn’t important – whether you dig the indie scene, see the design interactive systems as an amazingly expressive act, or think you have the next great idea that needs to see the light of day – you have the drive and creativity, and that’s what matters.
But you also value job security and hate the expectation of working 60 hour weeks. Or you’re a student who doesn’t have connections to get in to a major development studio. Or you don’t want to get swallowed up by a giant company that will treat you like a cog while you work on exciting features like the game over screen or the interactive flushable toilets. Regardless, the mainstream games industry isn’t what you’re looking for, and you’re ready to go on without them.
The goal of this series of blog posts is to give advice on how to create the games you want and to not go insane doing it. None of it will be particularly ground-breaking or revolutionary; if there was a single simple answer someone would have found it by now. Unfortunately, making games in your free time is like dieting or raising children – always more work than you anticipate, but rewarding enough to make it worth every ounce of suffering. It’s also aimed at a rather general audience – you won’t hear me giving detailed analyses of bump mapping algorithms or how to generate really realistic denim texture.
With that in mind, let’s get started with part one.
Where to start?
Before you pop open Photoshop or slather all the Visual Studio .NET gunk all over your computer, you’ll need to decide which technologies you’ll be using to bring your game into fruition. For some people this is a foregone conclusion – and, if they bring a note from their parents, can skip this chapter. For a large segment of the population interested in making.
The Short List
Here’s a very incomplete list of potential engines available for you to use as middleware. If anyone has additional recomendations for missing engines, or corrections about the engines listed here, I’d love to hear them. This list is by no means exhaustive, and has been compiled only with my own experience and that of people I have talked to who have used these engines. If you have any suggestions on how I could improve this list, be sure to e-mail me/comment!
Pros: The license is rather generous, TorqueScript is flexible and easy to learn, the engine can handle a number of higher-level features for you such as collision detection or particle effects, and the speed with which you can put out working demos is tremendous.
Cons: It’s one of the more expensive personal use game engines, it lacks realtime networking code out of the box, and there are a few fundamental problems that simply can’t get fixed without C++ knowledge and access to the source in the $250 version.
Recommendation: A good medium-level engine for those who can afford it. More powerful than Game Maker without requiring the degree of computer science knowledge necessary to work directly with APIs like OpenGL.
Examples: The Penny-Arcade Games use an EXTREMELY modified version of Torque, though it’s not a great indicator of the raw engine.
Pros: Game Maker is cheap and has a sizable community supporting development for it.
Cons: The engine is a bit limiting from a technical perspective, but if you’re looking for a specific lo-fi aesthetic or are someone just getting their feet wet in development this isn’t necessarily a bad thing.
Recommendation: It’s a nice place to start if you want to make an RPG or platformer that doesn’t require jumping through elaborate technological hoops. Technical restraints means that it can be difficult to stray far from the beaten path of conventional game designs, but it can definitely be done.
Pros: It supports a variety of platforms including web-based deployment, which is rather impressive. Other than that, I haven’t used it yet – send opinions!
Cons: It’s somewhat pricey, especially the $400 surcharge for developing on the iPhone. Other than that, I haven’t used it yet – Send opinions!
Cost: As cheap as Free, as expensive as a license to CS3, depending on what tools you intend to use to develop for it.
Pros: Web-based deployment or standalone deployment available as options, inherently multiplatform, huge install base, low system requirements.
Cons: Flash was never designed to be a game engine, so bending it to your will can prove challenging without the right libraries or documentation.
Recommendation: Due to the overwhelming amount of documentation, support, and places you can host your game for feedback/immediate audiences, Flash is an appealing low budget development kit.
Multimedia Fusion 2
Cons: MF2 is among the most expensive indie-friendly game engines.
Legacy Quake Engines
Pros: Totally free professional-level engines!
Cons: … that just happen to be 10-15 years old. Requires a higher level of programming and art asset creation knowledge, documentation ten years on isn’t as great as it once was.
Recommendation: If you know C++ and have decent experience working with 3D level editors to create leak-free levels it’s not a bad option to create rich, 3D games.
Examples: Gravity Bone
Cost: The cost of picking up a copy of Unreal Tournament.
Pros: Comparatively powerful scripting language, extensive mod support, powerful rendering and physics engines.
Cons: If you do anything other than an FPS game you’re basically twisting the engine to do something it wasn’t designed to do, content creation cost for even UT2k4 is non-trivial. UT3 even more so. And you’re limited to releasing only mods, which means no source code access nor any ability to seriously profit from your work.
Recommendation: If you can get a team of talented people together to make an interesting FPS variant, this is a great engine. If you’re one guy out to make a small project about anything other than shootin’ dudes, I’d stay away.
Pros: Extremely powerful physics and rendering engines
Cons: Distribution options are limited to mods through Steam, generally high barrier of entry in terms of content creation and programming skill.
Example: Gary’s Mod, Zombie Panic