βAn idea is worth nothingβ β probably every game designer has heard this mantra. Only concept and implementation are important. It is only on paper or on a computer screen that an idea begins to take on meaning and form. And I asked myself: are there any basic principles for turning an idea into a concept?
Inside is a translation with a brief theory and practical advice for everyone who is waiting for inspiration or does not know where to start.
Grab a pen and paper, let's get down to business. As you read this article, write down any ideas that come to mind. I ask this because I want to convey one important message: game design is what you doand not what meditate. To become a more effective specialist, you need to learn how you work.
If you have a brand new notebook, fill its first pages. Now everything is destroyed, he has lost his sacred integrity. Maybe it has bad ideas. Cool!
Here's a thought for you: everything that is written about game design, if there is no clearly expressed opinion of the author, is useless. Did you get the gist?
Of course, I'm joking, and not in a good way. If you are not a scientist who is interested in researching game design, then most of what is written is unlikely to help in practice. Books and articles suggest that there is some right path, formula or guide in game design. In fact, no one has any idea what they're doing. And more importantly, the value of designers lies precisely in the fact that they work in a unique way. There are many different points of view and approaches, and not every game designer will be able to solve a certain problem.
I want to help you find your own design voice and style. Let's talk about the basics to get you from a person with ideas to a problem solver. Being the first one is fun, but the second one gets paid.
The article is divided into two parts. In the first, I share my philosophy. In the second, I describe practical tools with which you can set up your own workflow. If I were you, I would skip the first part and move on to the second so I can get right into the practice. But, oddly enough, some love manuals and theory.
There is one question: why read another article about game design when so much has already been written about it? If you stop reading right now, please remember that really motivate, on youtube games, and already done in fact. You need to work now: turn on the computer and get down to business. Waiting for inspiration is an unproductive, energy-consuming and too unreliable approach.
Do you want to know why I am against thinking? Then let's get started.
Part 1: game design = practice
Experienced game developers have one joke. It talks about newbies with awesome ideas for the games they want to make. Only these guys have no idea how much you need to do for this. We all read about the guy who is looking for programmers, artists and composers to create an MMORPG. That being said, he only has a couple of paragraphs about a game very similar to the ones he plays.
To some extent, this joke seems funny to me, and I agree with it. Of course, ideas by themselves are worthless if they are not implemented, if they are not concrete enough or too ambitious. But any idea can be a nugget, from which the designer will create a great game.
But the ideas themselves are not a strong enough basis for development. They can be a good start. The only important thing is that it is the idea that makes you get to work. Pay attention to this thought: the idea makes you get to work. The work itself has nothing to do with it.
It makes no sense to think about game design
Unless your goal is to waste time. Thinking about playing after hours doesn't make sense. Ideas are vague, and in your head they may sound great. Writing them down on paper, you begin to see the shortcomings: where there are not enough details, what is fundamentally wrong, and so on. Here's an example: the original idea of ββthis article was very good, and look at it now.
Of course, you don't have to stop ideas from springing up in your head. But as soon as it seems to you that they represent something worthwhile, turn them into concepts.
What does this mean in practice? It's simple: write down ideas. For this, you need a pen and paper. If you still haven't taken them, take a couple of seconds to do so.
Concept
As you write down ideas, you are confronted for the first time with an unpleasant and bitter truth: they don't look so good on paper anymore. This is where the work begins - the transformation ideas Π² concept.
A concept is a detailed description of an idea. Try to define all of its variables without going into too much detail. Set the necessary conditions, features, relationships, and so on, until you realize that you have fully dismantled your idea. This is how the original concept came about.
Example (based on )
The idea: you can play tic-tac-toe in real time
Initial concept: players are assigned a symbol (X or O) and choose which one to control by pressing R or L on the controller. Everything else is the same as in a standard game of tic-tac-toe.
Problems:
- Clarity. It's hard to know which character you'll control next.
- Players can quickly find themselves in a stalemate, which is undesirable.
Corrected concept: players are assigned a symbol (X or O) and control a hand that matches the color of the symbol. They can take any character. Everything else is the same as in a standard game of tic-tac-toe.
The revised concept solves the stalemate issue and makes the rules transparent. To find this solution, I had to describe the problem, make a prototype, conduct play tests and finalize the concept.
Design
Design is a detailed description of the concept. In this step, you describe the implementation of all variables. As you break down each part of your concept, you will again ask questions and run into problems. And they will have to be dealt with in order to better understand the system you are trying to build.
A good core idea is never lost to new ideas. Rather the opposite. Look at what the current design offers you, swap its parts, consider them sequentially, play around with the parameters. So cheaper and faster. Introducing new ideas to solve existing problems only creates a bunch of additional tasks and increases the cost of the process. But you can just break the idea into pixels that move around the screen.
Part 2: tools
2.1 Visualization
Mindmap
For brainstorm
A mind map (or mind map) helps you formulate ideas. It's simple: draw a circle and write a simple concept in it. For example, "spaceship". Then we draw a line, write another word related to the first one, and so on. In this case, "shooting" and "fuel" are suitable. This approach helps to see the thematic space of game design. It can also be applied to mechanics to understand how they relate to each other.
This is how the design tree is created. How stable are the links between different branches? The design must be strong and reliable. Otherwise, there may be too many different features and independent systems. Can you implement them? How many goals do they have?
For order
A mind map also helps you organize ideas and see how different elements interact with each other. Visual display of the relationships of existing things and their places in the system allows you to build a common design logic. The first includes the second, the second includes the third, and so on.
Is such a relationship necessary? Is it possible to remove some elements without affecting the game?
There are many other tools for brainstorming and displaying ideas, but game designers manage to formulate the initial idea quite easily. Inspiration can be found anywhere. Launch the game you like and build its mindmap. What if we swap some elements around? Maybe there will be a new game that you would like to make? Or will you get the seed of a new idea? Don't wait for inspiration, make it come.
2.2 Execution
These tools are based on rational game design, which Chris McEntry spoke about in . Only I am always too lazy to finish reading articles and slightly modified the principles described there so that they fit better into my workflow. Try to do the same.
Table
You can use Excel or any other tool to create such tables. The first step is to reduce all our mechanics to simple descriptions. Then we put them in the first column. We do the same with the first line.
The task here is very simple. You need to go through the columns and note the relationship with the elements in each row. We analyze each mechanic and get all their combinations.
In the process, we record how our mechanics interact with each other. Are they compatible? Or not? What problems might arise?
A very convenient approach. If a new mechanic appears, you can compare it with what is already applied in the game. And you will see how many interesting relationships it generates. Too few? Maybe you shouldn't include it? You decide.
As usual, you need to write everything down to keep track of your understanding of your own system. This helps to understand which elements are worth developing and which do not deserve attention. It is impossible to do it in the head, it is necessary to transfer everything to paper.
Userstory
User stories perfectly reflect the gameplay of your title. They are one single sentence in the following format:
As [role] I want [action]
This tool works in two directions at once: to understand game design and to understand the player. From a game designer's point of view, you will be able to express your intentions in simple sentences and be clear about what you want to create. From the player's point of view, you will be able to understand what you would like to do in the game. The second will show the missing elements that you haven't implemented yet in your design. Plus, you will pay attention to what needs to be better worked out and developed.
Example
Let's say you're making a survival RPG. The player has a hunger meter that can complete the entire gameplay. This scenario generates stories like this:
As a game designer, I want the player to use resources sparingly.
As a player, I want to freely explore the world.
As you can see, in this case, the stories contradict each other. With this in mind, you can make access to new territories free. At the same time, the player must monitor his funds so that he can buy food and water.
Cards
You need to make cards or any of their virtual counterparts. Write down all the core mechanics and axioms of your game.
Let's say you're making a platformer. In one card we will write "You can jump", in the other - "You can run." In another one - "You will die if you touch the snake."
Put all the cards on the table. Stir if you like. Let's remove one of them.
What does the game look like now? What happens if the player can't jump? How to deal with this problem? Can other mechanics be used? Has the game become more interesting?
We remove another card or make a new one and put it with the rest. Try different options. Describe the resulting games on paper.
This is a super useful tool for brainstorming. It works great when you're stuck with a design and don't know what to do next. Perhaps in this situation it is worth getting rid of an element that you really like in order to see how the design can be developed in this situation.
Create your own tools
Often I take well-known tools and change them for myself. I choose what suits me. No matter what tool I end up using, they work like thought machines that I run ideas through to get results.
Concept β Pass it through your tool β New concept
Try to create a tool to help you find compelling concepts for your game. And use it.
Prototyping
People can't play with your ideas. They cannot play your records. They can only play your games. And that's the only way to truly appreciate your design.
If you do not have the necessary technical knowledge and colleagues, it is time to address this issue. If you're on a team with programmers helping you, make sure they get your ideas onto the screen quickly. If production gets stuck, speed it up, that's your job.
Examples
It doesn't matter what tool you use. The main thing is to get your ideas into the game, test and iterate them as soon as possible.
Put in the effort, tidy up your prototypes, and give them the right names is good practice. This way you get reusable projects and blocks that you can copy-paste from one project to another. Not a very elegant approach, but it's not that important: focus on getting your ideas across and turning them into a game.
Finally, I want to remind you of an important principle: the main thing is work. Ideas are just part of the process. Pick the tools that allow you to articulate, communicate, and retain the flexibility to iterate and re-strategize as needed.
If you read this article without picking up a pen and paper, then you missed the point.
Source: habr.com