6 things that helped me go from making no games to making my first games
1. Turn off the ways your computer tries to hide technical details
A car mechanic – even more so a car designer and manufacturer – needs to know what a car looks like under the hood, and can’t just enjoy the smooth, shiny, colorful outside like everyday drivers.
Browse online to find out how you can adjust your operating system’s settings to display file extensions and hidden files. Until it’s obvious when looking at a folder that a “.exe” (runnable program on Windows machine) isn’t the same thing as a “.ico” (icon image), it’s impossible to get started because the carburator, car battery, and engine are all disguised to look the same. It’s also useful to realize that the contents of every file, whether a readable .txt file, a nicely formatted .doc file, or a viewable .png image, are all just a string of bits, and often the extension is the computer’s first way of knowing what program is most effective in interpreting those bits for your viewing.
2. Learn to program – generic programming, not ‘game programming’
Just as Paint or Photoshop translate visual arrangements into image files, and Audacity or SoundForce translate listenable sounds into audio files, a compiler is the piece of software that translates human-readable program code into runnable program files.
3. Strive for breadth in your early learning, not depth
Elementary school covers little bits of lots of subjects – it isn’t 6-7 years spent on microbiology. Extreme specialization is best when it comes last, if ever. A general understanding of the main conceptual tools at your disposal, best obtained by first writing simple text programs that display numbers and take keyboard input, can be mastered in a finite time and will serve you well practically as you progress forward. Digging too deep early on into any area of coding specialization could literally consume a lifetime addressing impractical hypotheticals or optimizing for invisibly marginal gains.
You don’t need to learn how to write networking code for an MMORPG, develop AI for a 3D game that navigates hallways in tactical formations, perform advanced physics calculations to simulate realistic jointed animations, or render fancy performance-intensive special effects. People write their Ph.D. theses, establish middleware companies, and build specialized hardware to attack those challenges. Especially as a beginner, it’s best to turn to existing libraries that encapsulate the fruits from those countless hours of labor (Allegro, SDL/OpenGL, DirectX, etc.) or look up example code from books/websites on the subject on an as-needed basis, rather than independently trying to rederive their work.
The main goal is to get a sense of how program code explicitly describes and organizes systems relating program data to output, and input to program data, creating space for our user to relate output to input. Building this connection does not require an especially deep mastery of any particular type of programming.
4. Then figure out how to program a videogame’s building blocks
Once you can do these 5 things…
- Output: Display an image at a chosen position on the screen
- Output: Play a sound
- Input: Respond to keyboard, mouse, or joystick/gamepad activity
- Timer: Execute code many times per second, instead of only upon user input
- Collision Detection: Check when two shapes (approximately) touch or overlap
…you can make virtually any 2D videogame ever made.
Really pause to think about that for a moment. Every 2D game is images displayed, sounds played, input taken, things happening between user input (unless a strictly turn-based game), and certain things changing when the images touch certain other images.
There are, granted, a handful of surprisingly straightforward programming tricks (like tile-based levels to optimize collision detection), and about a half dozen key formulas from geometry, trigonometry, and matrix math that will help you do other nifty things more efficiently. Even still, these are mostly just more clever ways of what you’re technically capable of doing given a practical understanding of those 5 concepts.
Note that if you followed the above link under to download Dev-C++ 5, there’s a handy library you can use with it called Allegro that’s installable via the Dev-C++ Package Manager. It comes with many clear examples, and trivializes the above fundamentals of image and sound loading/use, timers, and input. Collisions, for many applications, are as simple as less-than greater-than comparisons to check for rectangle overlaps, or distance checks between circles. For Linux Allegro, or discussion forums, see www.allegro.cc. For any OS (including Mac), SDL is a powerful alternative that has a slightly steeper learning curve: www.libsdl.org.
5. Be your own supplier of basic art, audio, and interface design
Learn to make simple images (with transparency), record/edit basic sounds, design basic game menus (borrow menu layouts from other old games when getting started if needed, but never use anyone else’s art/audio).
You won’t want your ability to practice game development to be dependent upon finding, waiting on, or counting on someone else to make art and audio for your games. Better to get things done with rough graphics and sounds than to be stuck in the mud with code but no assets, and there is much you can learn in the process of practicing with the tools of other disciplines. When you do begin working with others, you’ll have a huge advantage in working with them by being able to make placeholders to avoid being held back by content creation time, and they’ll benefit from having exact template files handed over clearly answering any questions about dimensions, number of animation frames, and so on.
Free program available for image creation and manipulation:
GNU Image Manipulation Program
Free program available for sound effect creation and editing:
6. Start small. Simpler. No, smaller. Less innovative. Now smaller…
I mention this, in some way, in every newsletter. I will continue to do so. There is no more surefire way to throw off a potential hobby or career in videogame development than to begin by biting off more than can be chewed. Either it never completes, or it completes well below quality expectations, and either way a discouragingly exorbitant amount of time winds up vaporized going into something that you won’t want to share.
For your first few games, start as small as you possibly can, to gain a better sense of how long it takes to generate questions worth answering, answer those questions fast enough to beat temptation to ask more, and implement all those answers. Dice games, sliding puzzle games, games of tag, memory games, and so on make good early projects.
For many people, Super Mario Bros from NES was either their first game or the oldest one they found compelling. I would advise starting simpler than a platformer. Making a camera that scrolls isn’t hard; however, making the images and levels needed to fill a game that has a scrolling camera is incredibly time consuming, and it is far more likely to go well if it’s not one of the first games that you attempt to build.
(Originally posted asGameDevLessons.com Vol. 3 Sec. 1)
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!