next »

[Rareboy]

Hello guys, I have been analyzing Inotia 4 and I realized, that its not that easy to capture every single aspect of a game, write it down and taking lesson from game ...

So I want to ask my fellow game devs:

1. How do YOU analyze a game in order to take lessons from it?

Do you analyze formal aspects first?
Than you analyze how they affect each other?
Or do you just write down what you didnt like about game and how would you fix it?

Please tell me, it would help me so much since I was having kinda trouble and I dont know if I did it good ...

thank you

[Shine Klevit]

Compare and contrast with games you like, and don't like. Imo, the things you really want to look for are things that neither have, and things where games you like seem to fall short.

Don't be afraid to be nit-picky, or contradict what seems to be sacred truths. Learn to grasp games your own way. Try to avoid any unsavory trends, or to improve on trends that you think aren't meeting their full potential.

Always remember, everything is subjective. So you won't be objectively false by being completely honest with yourself. The secret is finding what you can offer, not what you're expected to.

Once you get in the right mode, however, that's not even the hard part. The hard part is streamlining your ideas and conforming them to realistic goals. However, a freeform analysis process is crucial.

At least, this is what I'm trying to do, personally. I don't have much to show for it yet, so take that for what it's worth.

[Alec S.]

For my own part, I would say to begin with the game as a whole and then break it down.  In other words, think of what the overall experience of playing the game is, and then look at the elements of the game to see how they either lend to or detract from that overall experience.  If a game does something really well, analyze what choices the designer made that accomplished that.  If the game falls apart, figure out what parts of the game didn't fit.

All in all, it's easier to analyze what doesn't work about a game, or what you think would make it better, because when you're playing a game, what doesn't work stands out like a sore thumb.  What takes a bit more understanding is figuring out what does work, and, moreover, why it works within the context of the other mechanics of the game.

[J-Snake]

Here is just one way how to do it, which I tend to use:

I mainly focus on gameplay but see that the rest is also important. So I abstract and extract "gameplay-elements" from games. A game-element is a mechanical interaction within the game, it can be something simple as an action you have to time to evade an enemy attack, or a more complex concept. In the end you have a set of all those gameplay-elements, now the challenge is to build a network of them to assemble an engaging and/or interesting game. Of course you can wrap those gameplay-elements in your unique presentation and also have your own original ideas alongside in the game.

I know it may sound a little abstract but may be it helps.

[Taky]

As a designer I try not to - it ruins games

But - when i have to - I ask myself this "what is the fun". Essentially, (and its been mentioned here?) what is the core mechanic, sometimes, what is the core mechanic that makes this game unique (games often don't have unique core mechanics). Then I see how they branch from the core mechanic, in a way make a mind map coming off of that. That's my process.

[krides]

Analyzing games as a game designer is a thankless task. As Taky said earlier, it breaks the game for you forever, because you're no longer able to see it like a normal person: you see all of the gears and levers, which leads to zero suspended disbelief. On the other hand, you absolutely have to do it every now and then, because it makes your brain work.

I usually break it down into key ingredients and look at them one by one. I do this by asking open-ended questions about it and getting deeper into the mechanics with each subsequent question. This is also known as the top-down approach (also applied to designing games). The questions usually go like this:

1. What is the experience that they wanted to convey with this game? In general, what am I supposed to feel as I'm playing it?

2. What tools are being used to achieve this experience goal? What do I do in this game that makes me experience this thing? (aka listing the dynamics of the game)

3. What are the long-, mid- and short-term motivations for me as a player?

4. What mechanics (aka rules and systems) of the game produce these dynamics?

5. What are the main levers the designer is using to vary the game's difficulty? What gameplay variables are there in the system?

6. If I were to draw a gameplay loop, what would it look like? (e.g., get a quest → explore level and find objective → get reward → repeat)

7. With all of these things in mind, what works well in the game and why?

8. What doesn't fit so well? Is there a problem with one of the variables? Is a game dynamic out of touch with the experience of the game? Is one of the motivations weak/absent? etc.

9. When I'm done with all these, I usually go more in-depth on the user interface and other questions specific to the game I'm analyzing.