This is part 3 of an ongoing series of articles.Part 1 - "Choosing a language, additional libraries and development environments."
Part 2 - "The Wall."
Part 3 - "Design and distillation."
Part 3 - "Design and distillation."So moving on from my previous posts which were more instructive, I'm starting to find myself in unfamiliar territory. While firmly entrenched in the drudgery of basic C++ tutorials, 'if' this and 'while' that etc, I find my mind wanders to more conceptual subjects of design and structure and I start to think about my game and how exactly it'll work.
From my observations, the Indie gaming scene encompasses a wide range of setups from the original bedroom coder to the teams of ex-professionals who are striking out for themselves, and well, Popcap et al. Its a remarkably diverse community but most development falls into the category of the bedroom coder and as such, usually the programmer wears a few hats, one of which is design.
Before becoming a programmer, I was a web designer. Back in the days of the dotcom bubble at the turn of the century, artistic skill wasn't a requirement of web design, and thank god because I'm crap at art, but I was capable of making technically balanced and attractively laid out pages through an unnatural (to me,) process of protracted planning and thought.
I'm currently uncertain of my proficiency for game design, its not drawn art -thank god, but I suspect good game design is an art. So like my inner web designer, I'm going back to basics and starting at the beginning.
“I've decided.” I said, “I'm going to learn C++ and make games.” Triumphant in my decision, the next thought I had was, “So... what game shall I make?”
Well when it comes to game design, the first thing you need to decide is what genre you want to make your first game. There are some interesting arguments for what you should try to tackle first, certainly your limited by capability, but assuming you were the worlds best programmer, there's a level of complexity in some genres that make them poor choices. My first though as a gamer of a certain age, was to remake some classic 8-bit game from my misty-eyed retro fan boy past. Certainly I'd LOVE to remake Wizball, Dynamite Dan or Nebulus -and the technical limitations of the 8-bit machines meant the games were comparatively simplistic, certainly possible to attempt as a first project, but for whatever reason, I decided I would make an adventure RPG.
Within any genre of games, there are a number of sub-genres or types of game. With shmups, there are horizontal scrollers, vertical scrollers, bullet hell, platformer shooters, abstract shooters and more, the choice of sub-genre can be as important as anything. Within the RPG genre there are many choices, certainly there are the western RPG's and the Eastern RPG's which differ quite a bit stylistically, Linear and non-linear storytelling as well as combat systems all come into play when considering how I'm going to build my game.
I started by thinking of which games epitomised the essence of what I wanted to accomplish. This was easy, I'm a big fan of the Zelda games and especially Links Awakening, so I used this as my base. Next I decided, I should write up all the features of an RPG that appealed to me, putting these into bullet points is actually very useful for what I'll discuss a little later on, but here is the list of features I considered important for the game I want to make;
- In-game combat (I dislike battle time systems like the FF series.)
- Large play-areas with distinct styles (like deserts, forests, villages etc.)
- A skill system for improving the players abilities through the game.
- An inventory system
- Upgradable weapons
- Magic – Upgradable via skill system.
- Dynamic NPCs (I'd like them to do more than stand in one place and say the same thing over and over)
- Companion NPCs (on screen, not just merged into the main character)
- Mini games! (what's an RPG without a fishing mini game?)
- Dynamic and complex storytelling.
- Sub-quests! Granny left her puppy chained to the shop in the second dungeon, ZOMG!
These are a non-complete list of generalizations but already its possible to look at these and break them down into components of game coding which can be prioritized, for instance, an early goal might be to create a tilemap engine and map out a scrolling (or screen flipping) map that's at least larger than the screen. Another early goal might be to have your main sprite on-screen, under joypad control and able to swipe his sword, but I'm rushing ahead again. This list also helps me shape the structure of the game, in my head, I already know how I want it to play but its weird because I have no art or sound, it pretty much looks like a modded links awakening
When you boil any genre down enough, there is a single, simple concept. You need to understand that single concept and strive to get to that point for a start, it seems more daunting until you do this. The single simple concept of an RPG is you have a character that can move in eight directions on screen, there needs to be a tilemap engine to handle the lay of the land and collision detection. From this basic shell its possible to bolt on all the other features.
With relief that my first goal is not as complex as I feared, I turned to fleshing out the specifics of the game mechanics. The most important aspect of my game (for me) is storytelling. I have developed a rich and complex story which I had originally planned to write a novel on, but the realism of time constraints and frankly, writing ability have put the kibosh on that idea, so I adapted the story to fit an RPG.
You could argue this is a waste of time, the story can be fleshed out once the game engine is up and running and your ready to map out the levels and so on, in fact, I believe it could be very important to consider story almost from the start. I intend my game to be “epic” in scale, I do not want my story to be hindered by limitations of the engine so I need to know of features that may need to be implemented and I don't fancy patching large code changes part-way through a content phase. As it turns out, there are a couple of features specific to the requirements of my story that need early attention and once I have my base engine in place (the previously mentioned simplest concept,) I can start prototyping them. Its worth noting that once you accomplish your base engine, you should commit this to your version control software or even make a copy that you can use for prototyping, I intend to.
There is plenty more to talk about in game design, but I think I'll spread the rest throughout the development, discussing the problems and solutions I have come up with as I get to them.
My next step is to get to the prototype platform I have talked about, this may take a few weeks, so I'm not sure yet what the next few entries of this article will cover, but I'll try to make it interesting
Developer
