I recently saw a post that asked the infamous “How do I create a ‘game’?” question that clutters this forum not infrequently. Something caught me, before I replied with the go-to answer that essentially demands the user to clarify their goals and start smaller. There is a reason that people ask this question so often, and perhaps we can give better advice.
There are different categories of beginner’s post that we see, some of which are outlined below:
- I would like to copy an existing game. But better.
- I would like to produce a (massive) multiplayer game, with a single man team.
- Are there any tutorials on how to make a game?
- I have an idea (four lines later) I need team members, please join.
Some of these examples are a little overstated, but they demonstrate some different attitudes that we see from new (and existing) forum members. A few points need to be clarified to give context to the stance of the members of this forum;
- We are all here for mutual benefit. Otherwise, there is no reason, no necessity to be a member.
- We are here on a voluntary basis. We are not obligated to help anyone, but we will nearly always, because of the aforementioned clause. (And because it benefits us in the long run).
- The older members of this forum, whether they have shipped a game, finished a game, or even started a game, have quite a lot of authority in the realm of the anticipated success of a project. “They’ve seen it all”.
I am by no measure the best developer here, but I believe that I have been here for a substantial period of time, during which I have experienced many failures and successes, of myself and other teams.
So, this thread will be split into three different categories:
- Where to start.
- How to encourage people to work with you.
- Points to consider
Where to start?
If you’ve never created a game before, then it helps to think about what a game is. Most people’s definition of a game is an interactive experience. This necessitates a few areas of game design and development already:
- Facilitating an interaction
- Communicating the result of an interaction.
These two aspects of development are intentionally vague. Games can be conceived with entirely different storylines, interactive interfaces and purposes. But these traits are still ever present.
It is important to remember that the above points are dependant upon the concept of the game. For most developers, that is the place to start. Some starting points for game concepts are:
- What is the purpose of playing the game? What experience will the game bring to the player’s life that doesn’t already exist in one form or another. For FPS games, it is often the feeling of immense importance and dominance. This aspect of the game will help infer a genre.
- In what way will the player interact with the game? Usually the interaction mechanics stem from the concept, but some games (such as Portal) are shaped around the interaction mechanics more so that the reverse.
When people start creating interactive experiences, it is not uncommon for them to become so ensnared by the interesting experience of creating a game, that they forget the most important person of all; the player. Underlying programming and technology is interesting for the developer, but only the consequences of its implementation will interest the player.
So, where do you start? Well, it is conventional to develop a storyline, with a subset of experiences you wish for the player to play through. As I have said, this is only convention. The most important aspect of designing a game is to have a single unique concept that you can build a base upon.
If you start with a unique storyline, then writing a detailed series of scenes, chapters or experiences will be important when you come to write the GDD. If you design an interesting weapon, or tool then defining a subset of possible interactions and results will be useful.
It is important to remember that this first step should be evident throughout the entirety of the game’s development cycle. If you decide for centralise the game around a tool’s mechanics, then the majority of the experiences should necessitate the use of such mechanics implicitly, rather than by blind obligation. At least, it should be the case that the player wants to use the interaction method that they have been given, rather than being forced into it.
Recreating an existing game concept is a challenge, technically, but it doesn’t offer much stimulation for the player, who will inevitably compare it to the original experience. It is very difficult to better a previous experience because you will either fail to meet the original design, or you will add a new experience which detracts from the original concept.
How to encourage people to work for you
Before we answer this question, there are a number of criteria you should meet, and ask yourself if you do!
- Do you have a game design document?
- Do you have a drive for quality?
- Are you able to organise and commit time and resources?
- Do you have realistic goals?
Writing a game design document is important, but not as great a challenge as one might expect.
Here are a number of useful links:
The purpose of a GDD is to denote everything that drives the game’s mechanics. It must outline the mechanics, the benefits and possible negatives of each mechanic. As well as this, taking the philosophy “If it’s not in the GDD, it’s not in the game” is a good way of setting the mood for writing. You don’t need to reference all the details in geometry for example, but enough that one could imagine the level is a good sign.
The GDD isn’t solely there to educate new team members. It provides you with a features set that you would like to realise by the end of the process, and it helps keep you on track when distractions, confusion and scale can get in the way of the process. It’s a reference for all development questions like “How tall should this doorway be?”, which really is a question of “Who built this doorway” and “Who uses this doorway?”.
Some additional comments
Asking the big question can be a challenge. Especially with no prior evidence. We all start there some day. I was lucky, and found good team members, but I wasn’t ready for the challenge of a First Person Shooter. No one actively challenged me on that basis for a long while. This was a mixed blessing. I learned from my own failures, and no time could be considered a waste. But equally, If I had known the scope, I could have perhaps produced my own smaller game or two along the way.
You need to tell us what you are looking for in your game. You need to tell us why you need others to help. You need to explain what they would be asked to do, what they will / will not receive in exchange for participation. You need to outline how long you expect the game to take, how you will organise meetings, how you will involve the perspectives of the team members.
So many people will write “Maybe, if I make money you guys can have some too”. That’s not a promise. You should start with “I intend to sell this game on N platforms” or “This will be a free download”, and mention the purpose of creating this game; “To realise a dream of mine” is very different from “To make many $$$”.
A good blog to follow is Extra Credits. They demonstrate a strong insight into the entire process, from concept to distribution.
Some say that a common issue with new developers is that they aim too high. I disagree with this. We all aim high, and it’s a good thing to do. I think instead we should say that they rush to the end, too quickly. Never loose sight of your goal, and play the long game. It’s important to realise that these things require lots of different skills, and the road is long. But at the end of it all, it is worth it.
For those who worry about protecting their source code, and the potential implications of the BlenderPlayer and GPL licensing: http://www.gamedev.net/page/resources/_/business/business-and-law/you-dont-need-to-hide-your-source-code-r3503
Be honest, and lastly, good luck