Alright, so by now, you’ve done your ground work, and you’re ready to actually start getting into the meat of your production, right? I mean, you have read parts 1 and 2 of this series, right? You’ve done the leg-work of figuring out what exactly this game is going to be, right? Excellent! Then let’s start discussing your work flow, and how you might actually make this happen!
Ideally, you don’t want to be too confined when designing for a specific platform. You will likely want to have the flexibility to port to other systems down the road, so it’s good to consider things like: what programming language will be necessary for you to use, what resolution will be necessary for you to use, and how portable are these going to be to other platforms. But again, this is all part of what you should have been considering as part of your GDD. I’m not going to touch on many specifics, because there are way too many variables out there for me to do that. But an important part of proceeding both with making the game engine (C++? Ruby on Rails? Unity?) and the art (Vector? Pixel? Polygon?) requires that you’ve figured this out.
Now unfortunately, as the old saying goes, a plan is only good until the first shot is fired. I got you thinking about what you’re going to do because it will help to make your journey go as smoothly as possible. Speaking realistically however, I don’t know anyone who has made a game entirely in their head and then replicated it without changing anything. Plan, work, and don’t be afraid to change your target and adapt if necessary. My recommendation is: prototype something as early as possible. If you’re a one man team, my opinion is that getting some sort of a playable thing is more important than getting the art. If a game can be fun with coloured boxes as your characters, then I guarantee you it will also be fun once you have your final art. The reverse is not necessarily true.
Now there’s a couple of schools of thought on prototyping. You’ll have people tell you that paper prototyping is the most important thing in the world, but on the other hand I know from a recent talk with Johnathan Blow, creator of Braid, that he is strongly against paper prototypes. His logic, is that something that is done with paper is not the same as something done in a computer. I tend to agree! Good luck prototyping something like Journey or Antichamber on paper. But that said, there may be many circumstances where a paper prototype could be beneficial, so don’t be afraid to really try to work out mechanics as early as possible and in any way possible. The key is to make sure that your game is fun. Now, you obviously don’t need to prototype the entire game before you get to work on other things, but you need a proof of concept. You need to know that you can get this thing working, and that it will be fun, before you strap yourself in for the long haul.
Of course, you’re going to start coming up with all sorts of ideas while figuring out mechanics. Write them down! It could be in something as simple as a notebook, or journal… but really, if you want the information to be easily found, shared, and backed up… I’d say go digital. This could be something as simple as emails to yourself, or in traditional text documents, but I’d also highly recommend, at a minimum, that you organize your notes into Google Drive documents to allow for collaborative editing, or even better your own private wiki. This can be a bit of a hassle to initially set-up… however I found that once a Google Doc increases to a certain size it becomes very laggy. A wiki on the other hand has the benefit of being organizable, collaboratively edited, and searched, as well as being backed up and easily containing a variety of images, sounds, videos, and linking directly to other content.
I know I said this a couple of times above, but I’ll stress it again because it’s so commonly overlooked, BACK UP YOUR FILES. Your files should never exist in just one location. If you lose your computer to theft, or flooding, or fire, or hard drive corruption, you will be glad that you kept your files somewhere like an online wiki. And should those services ever fail, you’ll be glad that you still have all your information locally too. I pity the poor person who, against all odds, loses their data from both locations simultaneously.
The same way that you’re creating a prototype for the game, you should be making prototypes for the art. This is concept art. So those ideas you’ve been jotting down. What are those? Well, sure, they could be concepts for other games, or ideas you’ve come up with for the current game. Maybe they’re mechanic ideas that you want to jot down so you’re sure to look up a solution to later, or maybe it’s the solution you already came up with and will need to remember it later. But, a large part of that needs to be your mood. How does this game make you feel? How do you want it to make you feel? What kind of colours, or sounds, are you thinking of when you’re trying to make this prototype work? What is this world that you’re creating? Know what you want! This is of course important for you to write down if you’re going to be your own artist… but if you’re working with someone else? I can’t stress enough how frustrating it is, as an artist, to receive direction from someone who has no idea what they want. And from what I understand, sound designers typically have it even worse, than visual artists.
It’s ok to take more than one attempt to get anything right, whether it’s gameplay design, code, sound, or art. You can almost always make something better by investing more time into it. But you will need to be realistic about the time you put into it. It this is an evenings and weekends sort of project, you really shouldn’t expect to be creating the next Shadow of the Colossus. Especially if it’s a small team. The same way you may need to sacrifice features from your game in order to get stuff done in a reasonable time, you may need to sacrifice on your art. At least I think that’s why VVVVVV looks the way it does. Cut corners when it doesn’t really matter. Can you get away with having palette swaps instead of two unique characters? It worked for Super Mario Bros. Despite the nostalgic reasons to create retro games, cheats like palette swaps, and low frame rate animations are a large part of why indies make their graphics the way they do.
Where does the story fit into all of this? Well… honestly that’s a tough call. There’s a great John Carmack quote that says: “Story in a game is like a story in a porn movie. It’s expected to be there, but it’s not that important.”. Now there will be exceptions to this… role playing games, and adventure games are particularly story based, and of course are going to need a lot of development. But Mario? VVVVVV? Those stories are pretty light. Minecraft? Tetris? Not exactly the narrative that makes those games so playable. It really depends on what you want. Do you want your game to be story focused? If so, you better get on that very early on. What’s the point of creating artwork for things that do not support the story? From a film making point of view, everything supports the story, and there’s no reason you can’t take this stance a game as well. But I still support John by saying that the gameplay is essential to get right.
So keep in mind while making this thing, that video games are a multimedia experience. You’re going to be much more successful if you build up the different aspects equally and cohesively. Have a vision, and strive to make it happen. Don’t just stumble around blindly, and don’t leave everything until the last minute. And for the sake of your own sanity, communicate with your partner if you have one. Creating a game is about communicating your ideas to your audience. How can you do that if you can’t communicate with your own colleagues?
