Yesterday, I said I'd let you see what goes on in a game dev's workshop. As promised, here we go. (This may seem condescending to those who are game devs, or at least familiar with the process. It's not meant to be. It's written to cut back on the jargon so it's easier for regular gamers to understand.)
First and foremost, for the extremely uninitiated: the 40 year-old moms, the technologically challenged, the ill-informed: there is no magic button. If I had a dollar for every time I've heard "You're on a computer, right? So just push a button! How hard can it be to just push one button?" or something similar, I'd be kicking it will Bill Gates on a massive cruise-ship party, right now.
No. There is no one-button way to make a game. Most scripting programs and game development engines are designed to help out and make up for a very small portion of human error, while coding, but it's little more than a spellchecker. The program won't allow me to miss a bracket, and it will warn me when a variable hasn't been called before it's used, but it can't 100% prevent me from making a mistake. Example:
global.health += 1;
until (global.health == 7.25);
This code has no errors that the program can detect. It's technically not wrong on the syntax level. But as any programmer worth his or her salt will tell you, the code is still incorrect. What happens if I run the code that way? Nothing. At all. The game will lock up completely, and appear frozen/crashed. It will still be running, and 'health' will constantly be rising, but nothing else will ever happen. Why? Because, as is, global.health never does equal 7.25. It can be 7, and it can be 8, but it will never be equal to 7.25. And yes, it DOES matter. I told it to test for health being equal to exactly 7.25, but add only whole numbers. 7.24 is not enough, and 7.26 is too much. Even 7.24999 is still too small. The code is doing until something that never comes. Do-until is a useful but dangerous loop event that runs until the condition defined at the end is met. If the condition is never met, it will remain in that loop and make the game unplayable, because when the game encounters that loop, it stops processing everything else until that loop is complete. It's up to me to make sure that never happens.
That hypothetical mistake I made can easily be corrected simply my making health += .25 instead, or making it test for greater-than-or-equal to 7.25, but it's not always so easy, because you have to 1) identify the infinite loop, 2) locate the mistake, and 3) fix it without accidentally breaking something else. And some times that hypothetical code is buried deep in hundreds of lines of similar code. It's quite a lot like looking for a needle in a haystack. Actually, it's worse. It's looking for hay with a tiny, colored dot, in a hay stack.
Now that we've gotten the magic button myth out of the way, I'll get into the real meat.
As I said, I'm focusing on the base engine first, on my project. I hate to break it to the general uninitiated (basically anyone who isn't a game developer) but the game environment is pure esthetic. Important esthetic, don't get me wrong! But in order to build the game engine, devs usually half-assedly build test areas. They're often bland, lack graphics, are littered with obstacles, items, etc, all for the purpose of testing the game. Most devs leave these in the code of the game, because it's easier to restrict access than to remove it completely, and with the right know-how and a little elbow grease, you can even access them in some of the games.
Super Smash Bros test stage.
Maybe your favorite game has a test map/level in the code somewhere. We typically create a place to work the kinks out of the base engine, in. This place is often neglected, messy, and usually remain undecorated. This is because the test area is for our eyes only, and are normally not intended to be accessible to players. A lot of the time, we put in the minimum amount of effort possible, while working in the alpha phase of a game.
For the uninitiated, you may be aware of games being in beta. Minecraft was in beta for a while. Some of you may not realize that there are other phases.
Pre-Alpha: Putting together the bare bones of the project. There may not even be any graphics, yet.
Early Alpha: This is around when the engine starts to fill out. The game, in this stage, can kinda, sorta be played, but it's not really a game. Features will still be a WIP, or completely absent, graphics will still be placeholders or flat missing, etc.
Alpha: The base engine is complete. The game is playable from a technical standpoint, almost everything that can be done is there, and works.
Late Alpha: The engine is ready for use and abuse, now we start to plan and construct the parts the players will play in, and get rid of those pesky optimization issues, and grind out the tiny things, like misaligned sprites, and whatnot.
Early Beta: This is usually the phase VIP and MVP players and testers get access to. A game world will be forming, maybe even parts of the story will be there. Some graphics are still to come, some features may be added in, etc.
Beta: This is often more open to a small, limited public. Some issues are still being ironed out, suggestions from testers and beta play gamers are being noted, graphics and sprites may change once, twice, several times, things that don't really gel with players will be stripped out, and things that can't be fit into the final game will remain in the cutting room, etc.
Late Beta: The game is essentially done, at this point. A glitch or two will need to be hammered out, some small tweaks to be made, suggestions to be fulfilled. Changes during this phase are normally very small, or completely invisible to players.
Launch: The game is released to the public.
When a game is in the alpha stage, we're mostly unconcerned with visuals. We don't really need them, they'd be a waste of time to add, and it makes controlling for errors a little harder: Did the item drop and end up under the terrain, or did it just not drop? Is that NPC falling through the world because they were pushed by scenery, or because their collision with the ground faltered at some point in their code?
You might be surprised what the alpha phase of a game is like, and what things you're not meant to see. Did you know that Legend of Zelda, Ocarina of Time contains actual Arwings from Starfox 64? Not only will they fly around and react like you'd expect them to, they'll also blast at you with their lasers. It's not even a mod or a hack. You have to mess around with the game's code a bit to get them to spawn, but they're there in any old copy of Ocarina of Time.
No, I'm not lying. See for yourself: Arwing Attacking Link
The reason they're in there is because we devs are lazy. You see, the OOT dev team wanted to program in a boss that flies around out of reach and attacks Link. The Arwing AI already behaves much the same way as this boss was meant to, so as a shortcut for testing purposes and AI building, they lifted the Arwing from Starfox 64 wholesale, model, textures, weapons and all, and dumped it into OOT. Once the testing was complete, they made the Arwing inaccessible to players, because it's easier unplug things from a game than it is to completely remove it. With some gameshark prodding, or hacking, you can access the Arwings and force the game to spawn them in-world, during a session. It's not recommended that you do so in the very beginning of the game, because if you can't hit them, they will kill you.
007 GoldenEye on the N64 is full of unused assets, including a test level called the Citadel. Take a look at the video. See the state the level's in? Odd item placement, strange clipping, random and senseless enemy spawns, few to no graphics, no objectives, clearly an unfinished level... That's what a test level is. The Citadel was likely created during the game's early alpha phase, and was probably a hell of a lot less pretty at the time. Probably more functional, too. I'll even go as far as to bet it was among the game's first environments, appearing long before any of the levels you and I all know and love.
Here's a test level from a Sega Genesis game. I've actually played this level on my copy of the game.
Spicy graphics, right there! This is from Vectorman 2. Google some screenshots from the game. It's not supposed to look anything like that.
Super Mario World on the SNES even has a number of test levels. Oddly enough, rather than building one test level to test everything, they built several test levels, each testing only one thing. In one of the test levels, you can even find classic Piranha Plants. You know the ones, they hide in the pipes like in Mario 1 and 3.
So, for those of you wondering why I don't have anything to look at in my game, it's basically the same reason as most other devs. Not only am I doing as-needed development, but even if I had graphics, I wouldn't waste time decorating my test level with anything but the essentials. I could spend a week fully fleshing out a test environment, and decorating it like the real portion of the game would look, but all that would get me is a leg up on the graphics, and days of wasted time. It would look nice, but in the end, I'd still have to work on the engine, on top of wasting an enormous chunk of time worrying about things that don't matter while in the alpha stages of a game. I'm sorry to break it to those waiting for screenshots of the in-game world, game devs just don't care what the test map looks like, to us. If we don't need it for testing purposes, we're not going to spend the time adding it in. That's why, if you go back to yesterday's post and take a look at the first image in it, the player character is standing in a dark blue void. I haven't gotten around to collisions, yet, so all there is to see are a WIP main character, a few guns on the ground for testing items and inventory, and Bowser sprites for testing the gun. You're even not going to see the test level. I'm probably not even going to leave it in the code.
Sorry the alpha stage can't be more glamorous, but developing a game is like building a car: frame first, operative parts next, then when it's all working, you can worry about the body, the paint, the decals, and the interior. If the first thing you do when building your new car is run out and pick up some fuzzy dice, then you've wasted your time, and now have little more than fuzzy dice sitting around, waiting for a rear view mirror to hang in, and no car.
Like I said in yesterday's post, I'm working towards a playable demo. If you're patient and don't make me waste my time picking out screenshots to display and writing progress reports, you'll get something tangible to look at very soon. If it's that important to you, I can probably write some progress highlights every few days, but it's not going to be anything more than my progress report data from my last post. At least, not until I start bridging the gap between late alpha and early beta. Right now, I'm in the earliest points of the early alpha. (And wasting even more of my time writing this. But I felt like I should do this to aid in clearing things up for those who aren't familiar with what goes on at a dev's desk.)
And to preempt the inevitable "Oh my god, how long does it take to make a game? Seriously!" comments, here's a time-lapse of Shaun Spalding making a short, quick, simple game for Ludum Dare 32. Ludum Dare is a game dev challenge where game developers have only 48 hours to make a game from scratch, all on their own. If you've ever wanted to get a glimpse at what we do, why it takes so long, and what it's like to develop a game from the ground up, that video is great for giving you just a small idea of what a day in the life of a dev at work is like. Be patient with us. Look what we have to go through. We may love what we do, but if anyone has ever told you game development is easy, they haven't a clue in hell what they're talking about.