So you want to be a game developer and you don’t know where to begin. I’ve been there. A lot of developers have. It can seem daunting to look at the incredibly array of programs available and try to decide what works best for you. You can start with a pre-fab game builder like RPG maker, or you could try something like Game Maker: Studio that requires a lot more work. Or maybe you want to code from scratch! With this list of programs, hopefully game development becomes a lot less scary and unknowable for you up-and-coming developers.
RPG maker is nice; I’ve used it a lot. The coding is already set in place and the visual and audio assets are available, but it really constrains you to a single game type. You can edit things as you like, but without a firm grasp on the fundamentals of development there isn’t a whole lot you can actually change. RPG maker is a fairly good tool for beginners, but I’m going to put you on a path to building exactly what you want regardless of whether it’s a slow methodical RPG or a high action platformer. Let’s start from the absolute ground level.
Programming is one of the most difficult areas to begin learning, but learning to do it is by far the most important aspect of game building. I played through Princess Remedy in a World of Hurt the other day. It took an hour to play front to back. The developers were kind enough to place a sign displaying everything that went into building it: 66 animated NPC’s, 64 ending sequences written, and 6000 lines of code, as well as map design and enemy placement, planning, and coordinating. But that’s 100 lines of code for every minute of gameplay, and I took my time reading every line of text. Obviously there’s no truly proportionate ratio of game time to code amount, but you can get a rough estimate of how much work goes into something simple like this. The game is free to play by the way. I’d definitely recommend it.
That said, thorough testing is one of the most important parts of game development. Testing can keep you from falling through maps because of faulty collision detection. It can keep a 16 hour game from being completed in 16 seconds. Testing ensures that users get the most out of your product without cheating themselves out of a rewarding experience. In short, always test every limit of your game because you never know what could ruin somebody’s experience.
Animating The Dead
When you’ve got a handle on programming, it might be time to take a swing at animation. It’s super satisfying to see your placeholder graphic slowly morph into a new sprite. There are a few different tools you can use for this, and while it’s not strictly required to have a good drawing tablet, or drawing skill for that matter, it can be a massive help in the long run.
First off, watch something on the 12 principals of animation. Then, I would recommend looking at some sprite sheets. Try to compile the individual frames of animation in order using something like MSPaint. Look at how they progress in their strides or their idle animations and piece together what these motions mean in context of their world. Do some concept art of your own; a front and side view at very least. It’ll help you keep track of what your character is going to look like finished. When you’re ready to make it move, start with a walk cycle.
I recommend a simple trial program. ProMotion can build fantastic retro sprites and it won’t cost a thing to get a look at the trial, but the retail price is very fair. Or if hand drawn sprites are more your style, I like Spriter. Spriter can be bought on Steam and actually goes on sale quite often. Both of these are fantastic for getting into simple 2D animation and can easily transition into more professional tools like Adobe Photoshop and After Effects.
If you’re adamant on looking into 3D art however, I recommend diving straight into Maya. It can be intimidating and a little expensive, but there is a free trial and it’s a truly fantastic resource. There’s also the much more conservative Poser products. Poser is a little less weighty, but still quite useful and much cheaper than Maya.
The Hills Are Alive with the Sound of Chiptunes
Sound design is easy to start but can be tough to master. It’s as easy as picking up a microphone and an audio mixer. A running sink can be turned into a rain-forest just by messing with the gain and reverb a bit and adding a few stock bird sounds. Making things sound authentic, however, takes years to master, so don’t get discouraged if that treasure chest soundbite doesn’t quite have the right click to it. The rule of thumb with sound design is if it doesn’t sound right, put it down for a little while and come back to it. It could just be that you’re experiencing auditory fatigue.
For that retro sound, look into chiptune emulators. I’ve recently become acquainted with FamiTracker, and for what it lacks in readability, it more than makes up for in versatility. Some audio mixers support virtual instruments with built-in retro sounds, and there are a few decent plug-ins as well.
Writing, Then Rewriting, Then Rewriting, Then . . .
If your game idea warrants having any kind of story, it might as well be engaging. Start by researching some classic story structures. The Heroes Journey (or one of the more modern achetypes) can be used to describe just about every movie or game you’ve ever seen. It doesn’t have to match frame for frame either. A lot of stories tend to go back and forth a bit before they find their pacing. Note that I said that they can be described with the Hero’s Journey. Can doesn’t mean that it should or that it has to, as there are plenty of alternatives.
Start by bullet-pointing topics you want to hit, plot points, or ideas; whatever it is that makes you want to keep going and fleshing it out further. You’re probably building a world from scratch, so think of it as if you’re building a living creature. Your creature has to have a skeleton or some kind of frame before it can stand tall. Then move on to plotting it out in a sequence that makes sense. Your sequence may change over time, and that’s okay, just make sure it all adds up in a logical way. And for the love of Final Fantasy, don’t make things too complicated. A complex plot-line just leaves a lot of openings for plot holes.
Most important, get used to writing in drafts. Most of my work goes through at least twelve revisions before I’m happy with it. Make sure you write drafts in a way that makes it easy to revise. Nothing looks sloppier than a professionally published work with a few select words omitted.
For example, the Dark Souls 3 Collector’s Guide tries to describe its luck stat on page 18. It states, “In general Luck is a luxury stat, it’s nice to have, but other attributes are more important for first time players and fir”
I don’t have to tell you what’s wrong with that, do I? Ignoring the improper comma use, the writer didn’t even finish their thought! There’s even a huge blank space in the rest of the description container where more description would go! Ludicrously sloppy work. It was probably in mid revision when they were told that everything needed to be saved and shipped out because they were starting printing. In any case this brings me to my next point.
Don’t be afraid to go back to a rough draft if you need to. Sometimes when you’re expanding on a thought, you might get distracted and forget what you’re trying to say. I can’t tell you how many times that happened as I was writing this article. That’s why you we take notes, and then take notes on our notes. Rough drafts help keep your thoughts relatively in line.
Putting A Cap On It
Start by learning some coding and shed some light onto how much work goes into building a game. Even if you’re in a team and you aren’t the designated code monkey, you should have a firm grasp on what they have to accomplish. If you can make a blue dot stay inside a small box and interact with other simple objects in its box, then you can move on to a different field.
Whether you enjoy programming or not, don’t let it keep you from other skill sets. Programmers should understand the animation process just as much as animators should understand programming. A note about the production of Final Fantasy X-2: While working on the Trainer class, designers wanted Paine to have a snake as a companion. A programmer vetoed the idea stating that the animation would be “too hard to pull off”, so they swapped it for a bird. They should have wrote the game in Python (holds for applause). Seriously though, knowing what your team is capable of is vital to the process. Even when you’re working alone, you should know the limits of your capabilities before you get started. It’ll save you long term frustration.
So to recap my recap: Understand both coding and animation. Those two things make up over 80% of the work put into a game. Prerecorded sounds are fine, but you should give a shot to recording your own. Things can look or feel great but if the sound is a garbled mess, people are just going to play on mute. If they play at all. Last of all, writing should be coherent and relevant, but it’s not strictly required to make a game fun.