mylab

Play Like a Game Designer por Alexey Shkorkin

“Play Like a Game Designer

According to the authors of books and articles, it means you should play as much as possible. Play games in various genres. Don’t just play good games, but bad games too. Do everything you can to improve your gaming literacy.
There’s nothing wrong with improving your gaming literacy, but for some reason, it’s not obvious to everyone that literacy alone isn’t enough. You need to not just consume games, but take a critical approach to them as well.
The results of your critical analysis could take the form of an article or video about how the developers met certain objectives in the game.

1. PREPARATORY PHASE
What to do
1. Play the game. This might seem like an obvious requirement, but our main goal here isn’t to spend a few hours in front of the screen, but rather to examine all the aspects of the game from various perspectives in order to develop as objective feedback as possible.
a. It’s best to beat the game — as long as the game is beatable, that is. If it takes dozens of hours to beat the game, you need to at least finish the main storyline.
b. If the game features asymmetrical gameplay (as in StarCraft, for example) with various strategies, you need to play as various factions and against various opponents.
c. If the game has various difficulty levels, try playing them all.
d. If the game has various modes (single-player, multi-player, etc.), it’s preferable to try all of them. The same goes for board games — play with various configurations and with various numbers of players.

2. Your primary goal is not to have fun playing the game, but rather to make observations that you will then use to perform an analysis. There are no requirements for how to take notes on your observations — just make sure they’re easy to work with.
Try to focus on establishing a connection between design solutions and gameplay:
which solution was implemented
how this was reflected in the gameplay
which in-game resources were employed in order to achieve this
which goal was accomplished by doing so.
These solutions could reside in various aspects of the game, including interface, graphics, sound, balance, controls, game components, etc.

3. You should also take notes of your personal impressions. They won’t have a place in a critical article, but they could influence your thoughts on how a given solution affects the player’s experience.
Jot your impressions down in the form of a “developer’s solution — your reaction” pairing, e.g. “No rally point for trained units — irritating.”
What not to do
1. Don’t read previews and reviews of the game until you’ve played it yourself and written the first draft of your article. First of all, you probably won’t get anything useful out of reading that stuff (you’re more likely to find advertising, emotions, spoilers, unfounded judgments, and useless details). Second, other people’s opinions will just ruin your focus.
2. Don’t rush into your analysis until you’ve completed all the steps listed under “Play the game.” There’s a good chance that you’ll see the game in a whole new light during the later stages, and then you’ll either have to rewrite the whole thing (which will take up time) or just you won’t be in the mood to redo your work (which will hurt the quality of your work).
3. Make sure you take notes and don’t just rely on your memory. You run the risk of completely forgetting certain factors or wasting time looking for them in the game in order to pin down the details.
4. Don’t mistake the rough draft of your article for a complete analysis and publish it before it’s ready. Follow the recommendations from the next phase first.

2. ANALYZING THE GAME AND WRITING YOUR ARTICLE
What to do
1. During the preparatory phase, you identified the connections between design solutions and gameplay. Now you need to organize these connections and flesh them out. If you need to play for a while before you can do this, go ahead and play. The results could take the form of connections such as:
The game has no “fog of war.” This reduces the amount of information hidden from the player and increases the amount of time it takes to get ready to attack the enemy, which in turn increases the importance of scouting.
2. Identify the objectives the developer set for themselves (this is easier to do after doing some work with the connections you found in the previous step). Determine how these objectives were met (or not entirely met) and what was employed in order to achieve this. If the results aren’t clear, spell them out. Try to describe the objectives that were met in such a way that the solutions are reproducible. For example:
Objective: simplify the process of translating and localizing the game.
How this was done: the game has no voice-over — the words in the dialogs are replaced with incomprehensible gibberish, so all that had to be translated was the subtitles and the interface; there is no text in the game world.
Result: the game was released in ten languages simultaneously.
3. If there’s anything else in the game that demands your attention (e.g. a new mechanic, a surprising solution), identify it.
The same goes for elements you liked and for which you were unable to identify an objective or function — set these notes aside; they might come in handy later on.
4. If you have any recommendations on how the game could be improved, they should be specific and well-founded.
a. Specific recommendations are those that describe HOW to solve a problem — instead of “I’d readjust the weapon balance,” write about how you would change the attributes of a certain item.
b. Well-founded recommendations are those that clearly explain WHY a given solution should be changed. When developing well-founded suggestions, it’s best to refer to similar solutions in other games, and not just talk off the cuff.
5. Recommendations for the layout of the article:
a. Identify the developer, publisher, year of release, genre, and platform.
b. Provide a link to a gameplay trailer for readers who haven’t played the game — this will save them time, and they’ll appreciate it.
c. Provide visual aids in the form of screenshots from the game. Sometimes it’s better to make a gif.
d. SPOILER ALERT: warn about spoilers, and hide text containing spoilers.
e. If, despite these recommendations, you decide to talk about your impressions of the game, set them aside visually in such a way that they are distinct from the main text of the article.

What not to do
Here are some typical mistakes that occur when the author of an analytical article mixes their criticism up with something else.
1. Don’t assign the game a rating, and don’t evaluate its various aspects (e.g. 3 for graphics, 4 for gameplay). First of all, ratings aren’t very informative, and second, your goal is not to compare the game to other games. The quality of critical analysis and the quality of the game itself usually have very little to do with each other. The usefulness of analysis is determined by how much the reader can learn from it, and listing specific mistakes in an unsuccessful game can be more valuable than an emotional, praise-filled 10/10 review.
2. Don’t express your emotions. If you can’t stop yourself from providing an emotional evaluation of a certain solution, at least try to provide a logical basis for your point of view.
3. Don’t recapitulate the storyline. Describing the storyline usually isn’t very valuable to script-writers. It would be better to point out interesting storyline developments and how the storyline affects the gameplay.
4. Don’t recapitulate the rules (if we’re talking about a board game). A critical analysis isn’t a tutorial! Try to focus on how certain rules affect the way the game is played.
5. Avoid superfluous details, especially when describing mechanics. A critique isn’t the same as an exhaustive breakdown! A detailed examination of a jump mechanic could be important when analyzing a platformer, but for games in which this isn’t a key mechanic, it probably isn’t worthwhile. If your analysis includes mathematical formulas or lines of code, you’re probably on the wrong track.

3. WHAT YOU CAN GET AS A RESULT
Your result can be something like this. Here’s part of my analysis of Firewatch, with no spoilers or superfluous details.
This is an analysis of a video game, but you can do the same thing with a board game. Board games are typically a little more difficult to analyze, since, first of all, they’re usually more expensive, and second, they’re physical objects (you need to go to the store and buy them, then keep them somewhere — if you’ve got 100 boxes, this could become a problem), but the main thing is that you need other players to play with on a regular basis. If this isn’t a problem for you, great.

Minimal menu-switching
The game doesn’t switch to another screen when you use the map and/or compass. The compass appears in your right hand, and the map appears on your left. Part of the screen ends up getting covered, but the game world doesn’t stop, and the protagonist can keep moving.
You can zoom in on the compass if you need to.
If you zoom in on the map, it will take up the entire screen, but it’s much easier to get around that way. However, the character can’t sprint when you’re zoomed in on the map.
Additional menus don’t appear when you pick up other items either.
You have the option of examining every item you pick up, even if it has absolutely no effect on the storyline.
● Rotating an item allows you to further immerse yourself in the game world (for example, if you pick up a book, you can examine not only the front cover, but also the spine, and read the notes on the back).
● Zooming in on an item allows you to read documents without opening a special menu.

Which objective is being met: immersion, since the player isn’t distracted by extra menus and doesn’t leave the game world.

Suggested improvements:
You can read the documents you find either as an image or as text by opening a separate menu. If you open the menu, the game is paused (this is clear because, for example, a dialog with Delilah will get cut off mid-word and continue when you’re done reading the document). Since the documents are fairly short, this menu could be gotten rid of. Instead, the documents could be reproduced as images, and the player could zoom in on them like the map. However, this kind of dual text is probably in place to make translation and localization easier.

1. Backpack with equipment
There is always a backpack full of equipment such as a rope and an axe next to the exit. Every time the player clicks on the tower door in order to leave it, the main character picks up the backpack before going outside.
Which objective is being met: this solution increases the player’s belief in what is happening in the game. The usual question of “so my character sleeps in his armor?” doesn’t arise here.
Enhancement of the solution: large items are only pulled out of the backpack when they are needed. For example, you can’t just pull the rope out and unwind it — you can only do it when climbing down a rock face. You can’t just wave the axe around either.

2. Character movement
In general, character movement is much more realistic than in an FPS or action-RPG. This fits well into the game world (after all, you’re playing a heavyset man in his forties with a full backpack on his back), but it could be painful for fans of these genres because of the character’s difficulty overcoming obstacles that the player could just hop over in real life.
Inaccessible areas:
Hills and underbrush. These are used to stop the player from going to places they aren’t supposed to go yet for storyline reasons. Once the character gets the rope and axe, these areas become passable.
Impassable obstacles. The character can’t enter the lake — not even up to his knees — but he can pass over small holes and clamber up gentle slopes.
Safety. The character can’t jump off a cliff or hurt himself in any other way.
Jumping. The character can only jump when necessary, i.e. to overcome obstacles. The player can’t just jump whenever they want to.
Sprinting. The developers made some concessions here. You can sprint at any time (except when using the map). There are also no restrictions on sprinting uphill. Running as fast as a motorcycle obviously isn’t realistic, but we’re all willing to suspend our disbelief here for the sake of saving time and cutting back on frustration.

As you probably noticed, the solutions employed by the developers of Firewatch were all focused on immersion in one way or another. Now the question is, “what do we do with this information?”

I suggest compiling a database of similar solutions. It doesn’t really matter what it looks like. The most important thing is that it will allow you to find several working options for ways to meet a given objective — for example, how to teach the player the controls, how to introduce an antagonist into the game, etc.

It would also be expedient to identify unsuccessful or unsatisfactory ways similar objectives have been met.

When it comes to posting things online, publishing individual breakdowns isn’t the best option for the following reasons.

1. First of all, it’s best to draw conclusions about specific solutions based on multiple breakdowns of games in the same genres rather than just a single game. The kind of breakdown I’m suggesting here is probably just a first step that will allow you to gather examples that you can then analyze and use a basis from which to draw conclusions.
2. Second, if you’re writing for a large audience, this audience will probably include a player who has already spent hundreds or thousands of hours on the game. And if your article is missing anything or contains factual errors, this player will point them out to you — in public.

It’s safer and more useful to only post conclusions with examples from multiple games in the same genre.

Once you’ve broken down a number of games (focus on twenty or so, as long as the games aren’t from very different genres), you’ll have enough material to make a “ten ways to…” video. These videos can be more content-rich and useful than most of the stuff on YouTube right now.

And if you’re disciplined, you won’t have any trouble with content going forward.”

e fica também uma história complementar “How indie developers from Russia make games for Google Play and social networks” e que também é interessante.

+infos(versão traduzida e fonte): LINK

+infos(original): https://habr.com/ru/post/491336/

+infos(história complementar): LINK