As the title says, you gain experience shortly after you needed it, or in this case, knowledge I gained after abandoning my project that would have been useful at the start.
Basically, those are all the questions and tasks I should have tackled before I began. This post is partly for me and partly for anybody who also wants to start his own projects like me: HEAD ON!! . I guess many people are like me, when you have an idea you want to get started ASAP! But you tend to profit from stepping back and ask yourself some important questions, you have to be sure it is the right project at the right time.
This is in no way the best or only way, or the only questions to answer, this is only what I will be doing in the future.
Why do you even want to make a game, what is your personal goal?
This question isn't asked often enough. Why do you do it? It's maybe the most important question you need to ask yourself, everything else, the goal of your project, depends on it. This isn't a philosophical question, your answers can be very trivial like "I want to make a living", "I want to learn about X". Maybe you don't have only one goal but serveral, in that case you should settle on one main goal. The answers alone seem a bit useless, but they get important together with the next question, so bare with me.
What is the goal of the project?
Again, the answers can be very simplistic like in the first question ("I want to sell it"). Now if your main personal goal and the goal of the project deviate, you inevitably run into problems. For example, if you want to learn but the main goal of the project is to be profitable, then you probably are working on the wrong project. If you want to learn, it is important to be able to fail, sometimes you learn more by failing instead of accidentally getting it right.
What technology do I use?
Unless your goal is to learn a specific platform, toolset, language etc. this is the wrong question to ask yourself at this point. Don't settle on your technology to early, maybe there are better tools for the job.
Alright, I got everything. I have this great game idea, let's do it!
I was there too, you have written your game idea to paper, and are keen on working on your game, but wait, you missed something!
Do you know which mechanics are more important? Do they even fit the game you have in mind? Do the mechanics even tell the same story as the story?
Before I ramble on, I want to say something about how you get your ideas.
Very often, you come up with an idea by mixing existing games or genres together, because in your head, it plays like the next cool game (my earlier post about that). But that's not the only way to get new ideas, for example: the fine people at Valve came up with "Left4Dead" while AI Programmers were testing new bots for Counter Strike. They were fighting as a small group of human players against a large number of bots who only used knives and they had incredible fun while doing so.
Dissecting the game
Let's go back to Left4Dead, I think it is an easy game to dissect when you have listened to the developer commentaries, some things become strangely clear. I am no professional, everything I write here is purely based on my understanding of game design.
I'd say, every game has a core principle, the core gameplay, how you would describe the gameplay in one sentence, many unarmed enemies against few armed players. That is, at least in my opinion, what the developers at valve experienced and liked while playing against unarmed bots, they played the earliest prototype of Left4Dead.
We then have to set the core aestetics for the game (watch the video at the end, it explains this better than I ever could). For Left4Dead, it is undoubtedly Co-Op, but it didn't have to be. I am sure you could imagine a game where compete against each other player. Both can be explained with the same phrase, but nobody would say that these games are related.
Now why should this matter? Again, let's turn to our poster child. I challenge anyone to find anything in Left4Dead that doesn't enforce co op. From the items, over the levels to the story, everything serves only this purpose. Yes, it also has a competitive aspect when you put 4 vs 4 in the mix, but I argue it isn't a core aestetics, in the end you compare the team effort. Compare this to Call of Duty multiplayer death match, where a good player can essentially win the round while he drags along not so super players. In Left4Dead on the other hand, it doesn't matter if you have an uber player in your team, he can't win alone.
So, why is Left4Dead a zombie shooter? Because it fits perfectly with the core gameplay and the core aestetics. Valve didn't do it the other way around. That's why everything feels right in Left4Dead, there is nothing that seems out of place at least in my opinion.
I think this is by far the hardest step, this is where you see the difference between novice and senior game developers. If you do this right as early as possible, you have a good understanding what it is that you are producing and how valuable feature X is to the game. It gives you a scale to judge your features on.
And now...
...you should have a solid basis for your game project, mind you anything of the above should never change. But the reality is, they often do. If something does change, don't take it lightly, be sure what impact your change has on the game, the project and on you.
I think now
I wanted to write about my own game idea and how I tried to dissect it. Alright then, that will be the topic of the next entry.
Videos
