The smallest, simplest videogame projects, the type of videogames we make to learn about videogame making – Pong, Breakout, Tetris, Atari Combat – still involve displaying graphics, playing sounds, and taking keyboard/mouse input. Unfortunately, many programming books don’t cover those seemingly fundamental operations. The reasons for that absence are simple: (1.) with a good framework, those are trivial things to do, though how they’re done depends on the framework selected (2.) without the use of any framework, those can be surprisingly complex and advanced things to do (needing to hack assembly to change monitor resolution or plot pixels, writing specialized code to decrypt image/audio file formats, etc.).
The decision to use some sort of existing foundation, then, is clear. The trickier decision, and one that many beginning developers get hung up on, is the decision of which.
Levels of Abstraction
First, to clarify some terms, as I’m using them here:
1. Programming Language – The pattern and features usable in text that the computer will translate into the program. Examples: C (to create downloadable games), ActionScript3 (to generate web/Flash games).
2. Library/Framework – Prewritten code imported to perform fundamental tasks such as loading an image/audio files, setting screen resolution, and detecting whether a certain input button is held. Ex. DirectX, Allegro, SDL.
3. Engine – Think about this as a finished game, minus the art, audio, and level/puzzle files. Engines specify what types of objects can exist, what types of interactions take place between objects, and the overall structure of the experience. Example: Everyone’s Platformer (source code).
4. Tool/Editor – In the same way that Photoshop is a tool for creating or editing images, tools are built for creating and editing per-game content. Tools are used to arrange and configure an engine’s constitutive elements. Example: Everyone’s Platformer Level Editor.
The higher in that list, closer to 1, the more power and flexibility is left to the developer, but the more decisions and work need to go into creating the infrastructure. The lower on the that list, closer to 4, the more the development experience resembles building with prefab parts, i.e. giving up finer control in exchange for structural assumptions. Whichever tier is accepted as the starting point for a project’s development is the platform (I am not using platform in this scope to refer to consoles/mobile/social/etc.).
(When a scripting engine is present – as in Game Maker and Unity – it exists at Engine level, even though in its construction it often resembles the Programming tier.)
None Are Perfect
The question of which platform to use is difficult because there is no best or right answer. Plenty of options are out there: XNA, SDL, SFML, Allegro, GameMaker, Unity, iOS, Flash, Flixel, etc. They all have strengths, and they all have problems. Some choices are faster to develop on, some are easier to distribute, some have performance issues, and some are easier to learn. Some are biased toward a few genres, and some tend toward a particular visual style.
Even the engines, tech, libraries, and development processes for massive commercial projects can be a bit of a struggle, too – this gets exposed while modding – and in many of the same ways. It’s a mess, but to some degree that’s the nature of arranging millions of bytes to create an experience or simulated mini-universe. Awkward workarounds for seemingly basic tasks, platform-specific hacks, lack of decent documentation, etc. Learn to love (or at least accept) working with the chaos.
Make Sure Someone Has Used It
Put simply: don’t embark on a journey that no one has ever returned from.
Find out whether videogames have been finished with the foundation you’re considering. Anything notable? Is there variety in the projects done with it, or do they reek of a reskinned, easily spotted pattern? Lack of examples is a clue that an option may lack critical pieces you’ll rely on – either in its functionality, its level of organization, its ease of distribution, or outside the code itself, as in the documentation, examples, or developer community.
Goals and Considerations
I advise against starting with a commercially-focused platform (ex. iOS, XBLA, ads/microtransaction-driven). If someone got their start in painting, basketball, or guitar with an expectation of being paid immediately for doing it, what are the odds of them realistically sticking to it? This means choosing a platform on which the results can be distributed without anyone else’s approval, and without spending significant money on licenses that would need to be recouped through sales.
Likewise, learn to work solo – and have some tangible, complete results to show for it – before trying to assemble a team. You’ll have more to offer, which in exchange can improve your say regarding the direction or implementation. This is reason to shy away from any platform that assumes or imposes team structure.
More specifically than that, it depends on your priorities or goals are. There are many right answers, but here are a few:
Goal A: Get Better at Programming
Work your way up the abstraction tiers, starting with 1 (Programming), and building the higher layers until you’re building and using 4 (Tools).
I suggest learning C, then C++. First as programming languages (learn variables, conditionals, loops, arrays, functions, structs/classes, etc.) before moving into videogame development. Then check out SDL (more versatile but more complex), or XNA (great but Windows/360-only, and distribution can be a pain) for input/graphics/sound/datafile code. C exposes memory and performance at a level many modern languages take for granted, giving a better understanding of what is happening under the hood. C++ builds upon C, into many of the features and concepts that other languages borrowed and expanded.
Note that when learning C++, there are a ton of advanced features which it’s good to know and learn, but which aren’t essential for putting together a typical videogame. Many programmers beginning the transition from C to C++ go about it as “C with classes”, and it’s possible to get reasonable mileage out of that approach before getting into other features of the language.
If larger games are targets of eventual interest, work on creating script or code mods to commercial game engines that have tools for such things. Otherwise, ground-up seems the best path to becoming a more capable programmer.
Goal B: Get Better at Gameplay Design
Work your way down the abstraction tiers, starting with 4 (Tools), and digging into lower layers for increasingly granular changes until you’re modifying 1 (Programming).
In addition to being able to rapidly familiarize with new platforms, being able to execute complete thoughts is also a designer strength, even if the result isn’t as robust/flexible as what a specialist programmer might author. Rough implementation is part of how designers communicate ideas, get results at game jams, etc.
For designing and programming full games, for 8 years I found Allegro a suitable library to work with, and it became my tool for rapid development. Although dated (I used Dev-C++, I believe Code::Blocks may be more common now), it still works. With a few additional extensions it supports png, jpg, mp3, etc., and with only one line of code (putting “END_OF_MAIN()” after the main function) Allegro takes care of all Windows-essential code. I enjoy that Allegro employs an appropriate level of abstraction in how images and text are manipulated, and through using Allegro I learned patterns that I now recreate in other languages/libraries. Whenever projects were completed, I used InnoSetup to create presentable Windows install programs to handle icons, start menu, uninstall integration, dependency checking, etc. (Battleship 88 was among the larger projects I developed in Allegro, though other people have done plenty of other things with it.)
Pick a platform, figure out what can be done with it, do something with it. Repeat. When/if you can dig deeper, try it. The goal in this case is to have a full arsenal of options in your tool belt, so that (a.) when an idea strikes, you’ll immediately know what platform has the right strengths and tradeoffs (and b.) it can help for future design thinking to be based on knowledge of how the concepts fit together.
Goal C: Get People to Play
Whether you come in from Goal A or from Goal B, soon enough you’ll have visibility and functional fluency across the spectrum of code and software at each layer of the platform.
At that point, I think it’s important that the result of our work can be widely shared. This makes it easier to get feedback, show the work to potential employers or development partners, and offer the work to friends and family. Some languages and environments make this easier than others. Anymore, playable on the web without download or installation is a popular standard of convenience. The flip side is that such games tend to yield less prolonged engagement than a local/downloadable game, have lack the raw processing and graphical power of C++ development, and often make it more difficult to do tasks that are comparatively simpler with local coding (such as building a level editor – or even something as simple as displaying text).
If the goal is to get exposure, it’s good to know that currently, AS3/mxmlc/Flash is perhaps the easiest way to handle distribution and tracking. Just take 10 minutes to register a free MochiBot then add the three lines of code, and you’ll always have stats on how many times the game has been played and from where. Take 10 minutes to make a couple of icon sizes then write a 1 paragraph description, upload it to Kongregate and NewGrounds, and you’ll get hundreds (often thousands, possibly millions) of plays in no time. (It’s common for strangers to then steal the swf to post on other portals for account points. You’ll still see the play counts, thanks to the MochiBot, and even see where the file is being played from.)
Compare to: the significant preparations that go into convincing someone to download, install, configure, run, then uninstall a videogame to try it. For hobbyist downloadable games, it can take significant time and marketing effort to get more than a few dozen people to play. Sure, downloadable games (developed in XNA, Allegro, SDL, whatever) can be deeper, are in some ways easier to build, seem more likely to win awards, and are more likely to win a following among their players, yet the ease of reaching so many players in so little time makes ActionScript 3 handy if your major goal is to get your creations in front of players.
Pick Something – Anything – and Use It
All platform options employ some common concepts, and becoming proficient in any approach will improve your ability to pick up other methods. Any answer is better than indecision. Choose a development method, accept (and work with) its particular challenges, and make some videogames.
Subscribe by e-mail to receive an update every month of all new HobbyGameDev articles, videos, and game development resources