Editor’s note: Brad Talton is an independent game designer and developer. What kind of games? Video games? Board games? Card games? Well, yes. His company, Level 99 Games, creates all kinds of geekiness. In a series of columns here at SBG, Brad shares insights into the game creation process. In this installment, he talks about when the rubber hits the road: taking all your planning and assets and starting to put everything together.
Before I can start putting together the game itself, I have to get graphics in place so that I can have an approximate idea of how it will look. Since the artist and graphic designer are probably not even close to finished with the game’s resources, the developer has to make do with simpler versions for the present. These approximate versions (or proxies) will have the same general shape as the final game resources, and are easily swapped out for the real thing when the time comes.
Even though I don’t have the actual versions of resources ready yet, there’s no time to waste in creating the foundations of gameplay. I know what the final resources will be shaped like, and that’s all it takes to put them into place in the design of menus and interfaces.
Before starting on any other part of a project, I work on the core of the game. In SPCF3, the core is the versus mode. It’s the easiest part to begin with, because there is no need to write artificial intelligence. In fact, at the early stages, you’ll want to be in control of both sides of the field so that you can test out everything from both players’ points of view. It would be terrible if something worked differently for player 1 than it did for player 2, after all.
The core engines for the game are open source and generally bug free. These days, very few game designers write their core engines from scratch. Even bigger-name game developers usually outsource this aspect of design to dedicated game engine companies. (Those are all the other names you see but don’t recognize before the title screen.) Modules like physics, graphics, and sound are just too complex and easily reusable to be worth writing over again for every game.
Since the game engines are in place, all the developer needs to do is coax them to work in the way that the game needs. Even if all a game requires is simple physics, 2D graphics, and mono sound, this is not always an easy task, and requires a good degree of programming knowledge. Each engine behaves in different ways, and so has its own learning curve and nuances to master.
Once the foundations are laid, it’s time to start working on rule enforcement. Video games, unlike board and card games, enforce their own rules. There’s a fairly common mantra: “If the game lets me do it, then it’s not cheating.” (I had to tell cousins this every few minutes back when I was throwing cheap punches with Dhalsim in Street Fighter 2.) This is an unfortunate expectation of video games, but because players expect a game to force them to follow rules, the developer has to rise to this expectation.
Rules are more than setting boundaries to the stage and making sure the match ends when someone runs out of life. It’s important to ensure that damage is assigned correctly, an attack strikes with the right amount of force, and that your balancing factors such as defensive power and offensive power are actually working as you intended.
The rules are different than the actual game balance. When making a game, I try to keep the characters’ information as separate as possible from the actual game systems. The information that describes a character (how much power they have, how fast they are, what their defense is like) are commonly called tuning variables. By storing these outside the game in configuration files, the developer give himself a means to rebalance the game after each round of play testing, as well as to make patches and updates without recompiling the entire project. Keeping all this information in separate files is what allows game developers to make a 1 MB patch to a 5 GB game without forcing you to download the entire game again.
Once the core of gameplay is established, I move on to what I tend to think of as a ‘game skeleton’. The skeleton consists of the main menu and submenus that form the game’s workflow. The skeleton gives you access to the different game modes and menus, even if those are still blank at this point. It’s sort of like a Christmas tree that you can decorate at leisure with new game modes and options.
At this point, the workflow of the game is established, along with what players can do, and how the menus will pull together. Menu design is actually one of the more important and often overlooked aspects of a game’s execution. A poorly crafted workflow or a visually weak menu system can cripple user experience. If the user can’t get to the actual game content within 15 seconds of the game launch (but shorter is even better), then there are problems with the streamline of the interface. Of course, as a developer debugs and tests the game, these shortcomings quickly become apparent.
Personally, I’m a bit spotty in my game development habits. I tend to build different elements onto my game skeleton in no particular order. Since many elements will require coinciding development, this isn’t a bad strategy—arcade mode is built on top of versus mode, and story mode is built on top of arcade mode. But training mode is also built on top of versus mode. So which one to do first? This is an issue of pure developer preference.
The only important point here is to build upwards. I try to intuit which modes depend on which other modes, and which portions of my design can be re-used and re-purposed elsewhere in the game, and then attack the problems of the game in that order. Of course, this is mostly guesswork, but a little experience goes a long way in helping a developer to make the right guesses and save serious hours of development time.
So with a game plan for what order to build my game modes, there is still the task of actually doing so.
In the next installment, Brad will look at transitioning between game modes, building a workflow and creating dependencies.
Character art by Victoria Parker for Level 99 Games.
