Requirements for game functionality
The entertainment function of games is an abstract thing. And to create game worlds in which the user wants to dive headlong over and over again, you have to think a lot. Sarah Santillan, Lead Designer at Boomzap Entertainment, talks about the requirements for creating game functionality. What is needed and what is not in this creative process?
The quick question is: if you make games, do you belong to the software industry?
The short answer is no. More detailed - partly yes, but generally not. To be more precise, gamedev refers to the entertainment industry, which means that your task as a game developer is to entertain people. Raise their spirits and give confidence. Create colorful, exciting game worlds, where they want to dive headlong. For the performance of game tasks, players can get real rewards (development of the plot, beautiful art, cool cut scenes).
At the same time, any text editor like Microsoft Word offers many functions with which you can type something like a review of a book. In addition, you can save typed text or transfer data to an output device, such as a printer.
')
The essence of software development is to create a product that serves a specific purpose. You do not need to create data for software except when it comes to reference documents. The end user himself creates this data - reviews of books, statements, invoices, accounts, digital art, etc.
This is all to the fact that the entertainment function of games is a very abstract thing. And in order to fulfill this ambiguous human desire, we have to develop software as a toolkit for the subsequent production of game content.
1. You need tools (software) to create interactive gameplay.
2. You need data — player classes, enemies, plot — with which the player will be interested in interacting.
3. You need to make sure that the data and the corresponding software are optimized for the convenience of the players.
This article will discuss the requirements for game functionality. At first glance, it may seem that implementing a list of functions according to certain criteria is easier than ever. But things can get confused very quickly.
Making games is a mess
Requirements for functionality are constantly changing. If you start working on something one, say, the combat functional, as soon you will find that you need to create a system of objects for it, a dynamic environment, which in addition can affect the abilities of a certain class of character, and off you go.
In order not to be unsubstantiated, in this article I will give examples from the project I'm working on - this is a mobile game with an emphasis on the Monster Roller PvP battles. Below are three layouts of the same combat system, showing how much the game may differ from the original idea.
The early version of the game is shown in the screenshot on the left, and the final version is shown in the screenshot on the right. The current version was made as accessible as possible: if you select an action mode (modes marked 2-1-1 next to the avatars of monsters), the monster will perform the appropriate action after rotating the slot machine's drum. 1 - attack mode, 2 - mode of using the ability, depending on the role of a particular monster.
The first thing that comes to mind when you see a game with an RPG-like combat system is a system of items, bonuses, a shop, etc.
“Why didn't you think you would need all this?”
“Why didn't you think that you would NOT need all this?”
Making games is a mess, because real innovation is always a mess. On the other hand, innovations can be “iterative” when the creation of something new takes place on the basis of already known formulas. In developing games to one degree or another, both approaches are used. And although developers can be tied to certain formulas (for example, a racing game implies unique tracks, bonuses, etc.), ultimately, you will not be able to make exactly the same cocktail as other industry representatives, where many work eight hours a day for free, just to find the holy grail of entertainment.
Making games is an educational experience. In the beginning you are absolutely sure what the game will be like.
But this tower is always on the verge of falling. It may turn out that your game is completely non-original, or the mechanics are so different that they should not be used together, or it is cool, but it is hard to understand. A certain level of experience, of course, helps to smooth corners - it will be easier for the industry's old-timer to get around the pitfalls than the newcomer. But in any creative process, there are ... surprises. This is the idea of ​​a fresh, innovative approach.
The evolution of functional requirements
We start by setting priorities based on how important an individual feature is to the game. Then we create prototypes of what we want to lay into the game, using sample data. In this section of the article we will look at the components of the combat system.
At the very beginning, our Monster Roller team had several ideas that we wanted to implement in the game:
• The gameplay should largely resemble RPG, but also include elements of the balance of card games;
• Of course, we wanted to add a slot machine reel ...
• ... which would give out bonuses based on jackpots (then another 4 in a row);
• We considered rate ratios;
• “Hold” - a function that does not allow the slot to rotate (of course, for a certain fee);
• Ability to switch between monsters during the course;
• Use items on monsters (obviously, isn't it?).
And this is not a complete list, as well as sketches. Functional requirements may include, among other things, a detailed description of what will be included in them (the data itself), how they will be displayed (interface), as well as performance indicators, demonstrating whether the functionality works as intended.
For example, consider the system of objects:
1. What are the features of the subject? Will it be used on the player’s team, the opponent’s team, or both? Will it have an expiration date? What variables can items affect? Level of health? Attack Power? Regeneration Rate? In percents or integers?
2. Is it possible to use items after a fight or are they spent in combat?
3. Is there a cost to use the item? How is this cost realized? Will it be the number of moves in combat (time value) or something else? Will I need to buy items in the store? If so, for hard or soft currency?
4. What will they look like?
And so on. The document containing the answers to these questions is called the list of functional requirements.
Now let's consider the battle itself in the light of the evolution of all these systems and functions.
The layout on the left was created by your submissive almost half a year ago. The model on the right was developed by a real artist, and this is what the battle looks like now.
The following screenshots show how the functional requirements have changed.
Old top panel:
New Top Panel:
And there and there is an indicator of gold and a settings button. The autogame button, which can be seen on the prototype, in the latest version has moved to the bottom panel (see below).
The biggest change is the appearance of a timer and lights around the frame, reacting to what is happening in the game. We added a timer, since we are dealing with a PVP game - it would be very sad to wait until your opponent at the other end of the world decides how to attack him.
Old battle screen:
New battle screen:
As you can see, on the old layout there were no indicators of choice (arrows at the top of the left screenshot of the new version), as well as indicators of positive / negative effects (note the tiny monster). In addition, the display of monsters in battle has changed. Another important decision we reached is to reduce the number of monsters from four to three. Thus, we increased the speed of the fight and increased the chances of getting a jackpot.
Drums and avatars, old and new:
Here we have changed a lot of things. First, take a look at the cherry symbol. As planned, the player earned cherries for each round of battle, and they gradually accumulated. In addition, they could be obtained as a prize by playing on the slot machine. Like mans or energy in card games, cherries could be spent using items or switching monsters. Nevertheless, we subsequently abandoned both the system of objects and cherries.
We didn't add cherries because everyone does that. We added them to reduce the luck factor and put emphasis on the importance of the player choosing a particular action. Will I use this item or switch this monster? That is, we had good reasons to add items to the game and the cost of using them.
So why is this system rejected?
Looking at the variables characteristic of the monster battle game, you will see many factors that can be controlled without adding another system.
1. Choosing a goal: use auto-attack or focus on one opponent?
2. Abilities: attack, buffs / debuffs, defense, regeneration, strengths and weaknesses of elements.
3. Combo: jackpots "3 in a row", monsters that can enhance the attributes of mates.
4. Composition of the squad: affects the chance of combo.
5. Time to move: a limited amount of time to make a decision.
It is very tempting to add a feature at an early stage of development. This happens because at this stage it is still difficult to imagine how different features interact with each other and affect the gameplay. But to give in to the thought “you need more functions”, on the contrary, is easy, as there is no content as such. Prototyping helps a lot to overcome the temptation to inflate functionality. The system of objects would have to be balanced with all the above-mentioned variables, not only by the developers, but also by the players themselves. The point is that each variable could affect the outcome of the battle, and not just to have more of them.
Oddly enough, in this section of the interface there are two more variables that you can talk about for a very long time. This is the principle of rotation of the drums and the symbols applied to them (Does the slot machine have a hold function? How does it give out a winning combination? How does the slot machine react to stunning the monster? How are the combinations of symbols formed? Does all the slots give the player a chance to get a jack sweat? And so on). But for now, just mentioning these variables will be enough to understand how this functionality has changed.
The last thing we changed in this segment is the Let's Roll button. Although initially it seemed to us that it would be fun to rotate the drum by moving your finger across the screen, many play testers (play test - a great way to determine the requirements for the functionality) spoke in favor of a separate button. So we added it to make the game more intuitive. Want a button - please!
Old bottom menu
New Bottom Menu
So, we got to the last element - the bottom menu. The screenshot of the old version displays the cost of items and switching, but in the end we left only the auto-play button and the switch. Another reason to thoroughly simplify the system, given all sorts of things that the user must keep in mind, is the effective use of screen space. The game Monster Roller and so full of icons, jackpots, elements and goals. If we added another set of visual elements, the player would have to remember even more.
Uh, it was a long article.
So, we highlight the main points:
1. Game development is at the intersection of software and entertainment industries. In order to answer the question “what does it mean to have fun?” You need to use knowledge from several areas.
2. Do not be attached to the established requirements for functionality. The elements of the game change during the development process, and often in a most surprising way.
3. Any game combines spontaneous and iterative innovations.
4. Requirements for functionality cannot be contained in one list. Think about how the feature will interact with other elements of the game, and then list all possible ways to implement it.
5. Create a prototype of the functionality based on the requirements and modify it as necessary.
6. Continue until you realize that this is it.
Congratulations, you have reached the end. Here you have an egg with bacon.
The quick question is: if you make games, do you belong to the software industry?
The short answer is no. More detailed - partly yes, but generally not. To be more precise, gamedev refers to the entertainment industry, which means that your task as a game developer is to entertain people. Raise their spirits and give confidence. Create colorful, exciting game worlds, where they want to dive headlong. For the performance of game tasks, players can get real rewards (development of the plot, beautiful art, cool cut scenes).
At the same time, any text editor like Microsoft Word offers many functions with which you can type something like a review of a book. In addition, you can save typed text or transfer data to an output device, such as a printer.
')
The essence of software development is to create a product that serves a specific purpose. You do not need to create data for software except when it comes to reference documents. The end user himself creates this data - reviews of books, statements, invoices, accounts, digital art, etc.
This is all to the fact that the entertainment function of games is a very abstract thing. And in order to fulfill this ambiguous human desire, we have to develop software as a toolkit for the subsequent production of game content.
1. You need tools (software) to create interactive gameplay.
2. You need data — player classes, enemies, plot — with which the player will be interested in interacting.
3. You need to make sure that the data and the corresponding software are optimized for the convenience of the players.
This article will discuss the requirements for game functionality. At first glance, it may seem that implementing a list of functions according to certain criteria is easier than ever. But things can get confused very quickly.
Making games is a mess
Requirements for functionality are constantly changing. If you start working on something one, say, the combat functional, as soon you will find that you need to create a system of objects for it, a dynamic environment, which in addition can affect the abilities of a certain class of character, and off you go.
In order not to be unsubstantiated, in this article I will give examples from the project I'm working on - this is a mobile game with an emphasis on the Monster Roller PvP battles. Below are three layouts of the same combat system, showing how much the game may differ from the original idea.
The early version of the game is shown in the screenshot on the left, and the final version is shown in the screenshot on the right. The current version was made as accessible as possible: if you select an action mode (modes marked 2-1-1 next to the avatars of monsters), the monster will perform the appropriate action after rotating the slot machine's drum. 1 - attack mode, 2 - mode of using the ability, depending on the role of a particular monster.
The first thing that comes to mind when you see a game with an RPG-like combat system is a system of items, bonuses, a shop, etc.
“Why didn't you think you would need all this?”
“Why didn't you think that you would NOT need all this?”
Making games is a mess, because real innovation is always a mess. On the other hand, innovations can be “iterative” when the creation of something new takes place on the basis of already known formulas. In developing games to one degree or another, both approaches are used. And although developers can be tied to certain formulas (for example, a racing game implies unique tracks, bonuses, etc.), ultimately, you will not be able to make exactly the same cocktail as other industry representatives, where many work eight hours a day for free, just to find the holy grail of entertainment.
Making games is an educational experience. In the beginning you are absolutely sure what the game will be like.
But this tower is always on the verge of falling. It may turn out that your game is completely non-original, or the mechanics are so different that they should not be used together, or it is cool, but it is hard to understand. A certain level of experience, of course, helps to smooth corners - it will be easier for the industry's old-timer to get around the pitfalls than the newcomer. But in any creative process, there are ... surprises. This is the idea of ​​a fresh, innovative approach.
The evolution of functional requirements
We start by setting priorities based on how important an individual feature is to the game. Then we create prototypes of what we want to lay into the game, using sample data. In this section of the article we will look at the components of the combat system.
At the very beginning, our Monster Roller team had several ideas that we wanted to implement in the game:
• The gameplay should largely resemble RPG, but also include elements of the balance of card games;
• Of course, we wanted to add a slot machine reel ...
• ... which would give out bonuses based on jackpots (then another 4 in a row);
• We considered rate ratios;
• “Hold” - a function that does not allow the slot to rotate (of course, for a certain fee);
• Ability to switch between monsters during the course;
• Use items on monsters (obviously, isn't it?).
And this is not a complete list, as well as sketches. Functional requirements may include, among other things, a detailed description of what will be included in them (the data itself), how they will be displayed (interface), as well as performance indicators, demonstrating whether the functionality works as intended.
For example, consider the system of objects:
1. What are the features of the subject? Will it be used on the player’s team, the opponent’s team, or both? Will it have an expiration date? What variables can items affect? Level of health? Attack Power? Regeneration Rate? In percents or integers?
2. Is it possible to use items after a fight or are they spent in combat?
3. Is there a cost to use the item? How is this cost realized? Will it be the number of moves in combat (time value) or something else? Will I need to buy items in the store? If so, for hard or soft currency?
4. What will they look like?
And so on. The document containing the answers to these questions is called the list of functional requirements.
Now let's consider the battle itself in the light of the evolution of all these systems and functions.
The layout on the left was created by your submissive almost half a year ago. The model on the right was developed by a real artist, and this is what the battle looks like now.
The following screenshots show how the functional requirements have changed.
Old top panel:
New Top Panel:
And there and there is an indicator of gold and a settings button. The autogame button, which can be seen on the prototype, in the latest version has moved to the bottom panel (see below).
The biggest change is the appearance of a timer and lights around the frame, reacting to what is happening in the game. We added a timer, since we are dealing with a PVP game - it would be very sad to wait until your opponent at the other end of the world decides how to attack him.
Old battle screen:
New battle screen:
As you can see, on the old layout there were no indicators of choice (arrows at the top of the left screenshot of the new version), as well as indicators of positive / negative effects (note the tiny monster). In addition, the display of monsters in battle has changed. Another important decision we reached is to reduce the number of monsters from four to three. Thus, we increased the speed of the fight and increased the chances of getting a jackpot.
Drums and avatars, old and new:
Here we have changed a lot of things. First, take a look at the cherry symbol. As planned, the player earned cherries for each round of battle, and they gradually accumulated. In addition, they could be obtained as a prize by playing on the slot machine. Like mans or energy in card games, cherries could be spent using items or switching monsters. Nevertheless, we subsequently abandoned both the system of objects and cherries.
We didn't add cherries because everyone does that. We added them to reduce the luck factor and put emphasis on the importance of the player choosing a particular action. Will I use this item or switch this monster? That is, we had good reasons to add items to the game and the cost of using them.
So why is this system rejected?
Looking at the variables characteristic of the monster battle game, you will see many factors that can be controlled without adding another system.
1. Choosing a goal: use auto-attack or focus on one opponent?
2. Abilities: attack, buffs / debuffs, defense, regeneration, strengths and weaknesses of elements.
3. Combo: jackpots "3 in a row", monsters that can enhance the attributes of mates.
4. Composition of the squad: affects the chance of combo.
5. Time to move: a limited amount of time to make a decision.
It is very tempting to add a feature at an early stage of development. This happens because at this stage it is still difficult to imagine how different features interact with each other and affect the gameplay. But to give in to the thought “you need more functions”, on the contrary, is easy, as there is no content as such. Prototyping helps a lot to overcome the temptation to inflate functionality. The system of objects would have to be balanced with all the above-mentioned variables, not only by the developers, but also by the players themselves. The point is that each variable could affect the outcome of the battle, and not just to have more of them.
Oddly enough, in this section of the interface there are two more variables that you can talk about for a very long time. This is the principle of rotation of the drums and the symbols applied to them (Does the slot machine have a hold function? How does it give out a winning combination? How does the slot machine react to stunning the monster? How are the combinations of symbols formed? Does all the slots give the player a chance to get a jack sweat? And so on). But for now, just mentioning these variables will be enough to understand how this functionality has changed.
The last thing we changed in this segment is the Let's Roll button. Although initially it seemed to us that it would be fun to rotate the drum by moving your finger across the screen, many play testers (play test - a great way to determine the requirements for the functionality) spoke in favor of a separate button. So we added it to make the game more intuitive. Want a button - please!
Old bottom menu
New Bottom Menu
So, we got to the last element - the bottom menu. The screenshot of the old version displays the cost of items and switching, but in the end we left only the auto-play button and the switch. Another reason to thoroughly simplify the system, given all sorts of things that the user must keep in mind, is the effective use of screen space. The game Monster Roller and so full of icons, jackpots, elements and goals. If we added another set of visual elements, the player would have to remember even more.
Uh, it was a long article.
So, we highlight the main points:
1. Game development is at the intersection of software and entertainment industries. In order to answer the question “what does it mean to have fun?” You need to use knowledge from several areas.
2. Do not be attached to the established requirements for functionality. The elements of the game change during the development process, and often in a most surprising way.
3. Any game combines spontaneous and iterative innovations.
4. Requirements for functionality cannot be contained in one list. Think about how the feature will interact with other elements of the game, and then list all possible ways to implement it.
5. Create a prototype of the functionality based on the requirements and modify it as necessary.
6. Continue until you realize that this is it.
Congratulations, you have reached the end. Here you have an egg with bacon.
Source: https://habr.com/ru/post/273483/
All Articles