Archive for the ‘The design of VGS’ Category

Thoughts on user interaction

Doesn’t matter how many games you’ve made or how many tests you’ll perform, you’ll always have a lot of doubts when it comes to how to put the interaction in your game feedback loop.

User interaction grows on me in a weird way. Experience should make it easier, but as time goes by I tend to put more and more variables to the design stage. I want the player experience to be flawless.

Flawless interaction

In my humble opinion for the interaction to be flawless, the following requirements must be met:

1. Minimal interaction

The player’s effort to get something done must be minimal, except if that effort is part of the game’s mechanic.

2. Perfect feedback

The player’s effort to get something done must have its counterpart in the game that must perform the player’s order but also inform the player that the order was received correctly. If the player’s order is not accepted by the core rules of the game design, the player must be undoubtedly informed that it was not possible to perform the action and why.

3. Seamless integration

Both interaction and feedback must be integrated in a way that is natural to the game. For instance, if you have a very simple mechanic and the player action is not allowed, you shouldn’t pause the game and give the player a huge chunk of text explaining why that is happening. A simple sound and some red markings on screen should make it obvious for the player.

Our rules

With all of the above in mind, I look at our current project and decided on the following…

1. Mouse Hover

Every time the player moves the mouse on top of some meaningful element (usually a game token) the game will always produce feedback about the element. The feedback will always be presented in the same screen space. Information formatting will be as similar as possible to all elements, respecting the smaller differences between each element type.

2. Mouse Click

GUI buttons were created to remove unnecessary effort. As an example, given a large playarea where you’d need to find a game token, click it and choose a task by another click would involve the player searching for the game token in the map, clicking it, analysing a set of options and clicking one. We created GUI buttons where the player simply has to click the option he wants.

From the feedback point of view, the button will only be available if all conditions are met to perform the action of the given button. More, if the player hovers the button, information will be given in the determined info space to why the player cannot perform that action.

The only elements that involve two clicks are elements that interact with other elements. In this case, we opted to make the first mouse click select the element and make the element information fixed and then the second click on the element to interact with will create a contextual decision.

Conclusions

What is described above is already implemented in our current project. I predict some tuning of some issues regarding user interaction with the game but the results make the game feel ridiculously simple to play. My biggest question is if this feeling is only ours or if the players will feel the same.

See you all soon,
Vlad

Understanding your players

In my opinion, web2.0 offers a priceless opportunity for game developers. For the first time ever, this is our chance to be face to face with the players that play our games. No second hand information, no idiotic knowledge from people who never cared for a game.

This time it’s upclose and personal between us and the players. You do have to understand them though, because if you are a game developer, you crossed a line that will make you look at games from a whole new perspective. You are unable to walk in the common player shoes. Here’s what I think of it.

You are not above the players

Creating a game does not turn you into some kind of mithological entity that players are supposed to love. Don’t jump on your players with an attitude because you can make a game.

Understanding that most players think they could make the best game ever should also be put into perspective.

Filter your player’s comments

Players will say anything, from verbal abuse to expressions of love. One word punchlines is the way of people saying “Yeah I’m here and I participate a lot but I really have nothing to say!” so ignore those unless something really get’s your attention.

Put comments into context

Imagine your latest game is a fantastic dress-up game with dolls! Then you upload it to Newgrounds and Kongregate. What kind of comments are you expecting? The context in which the player accesses your game is important to his own understanding of the game. You need to find where player, portal and game meet to know what comments to filter. 

Stay in touch with your players

If you read a comment that is meaningful in some way, take your time to react to it in a positive way. Players want to hear from you. They want to know more and keep in touch.

Gamer != Game Designer

I could finish this post right now and I would consider I had said enough. This is sort of a re-post of a post on my now dead Portuguese blog. The basic premise is that a gamer is not a game designer and a game designer is not a gamer.

When I play a game as a gamer, I play the games I like to play. I have fun with the games, I truly enjoy the moment. When I’m playing a game with the game designer hat on, I don’t have to enjoy the game, but rather try to understand its mechanics, dynamics and aesthetics.

Being a gamer is for sure the start of being a game designer, as much as driving is the start of being a race driver, but no one is a game designer just because it plays games, the same way no one is a race driver because it knows how to drive! Game design, like it or not, is a technical work. Game design is not about having ideas for games, but to fill the blanks from the idea to the finished product.

While this is true a bit everywhere, flash market is a great way for gamers to start their crazy journey on game development and as soon as they put a box moving in the flash player they are automagically extraordinary game designers and awesome coders. Well, it’s a start, we can only hope that they work it out with time. I know I went through an automagical phase of my own only to find out that there’s a world of things to learn everyday.

Design that fits

Make it fit

I have an opinion about what separates the common game from the commercial game, mind as well share it with you.

A commercial game fits. “What on earth is he talking about?” – screams that gentleman over in the background. If he even existed, he would be completely clueless about what I’m talking about. Well, let me tell you a story about this imaginary gentleman.

He created a zombie game where the title screen has a stretched ‘googled’ picture from a movie in the background, pink letters in the buttons with the typical Times New Roman, blood splats made from vector circles and cartoon like characters in the gameplay.

Can you imagine this and see why it doesn’t fit? You don’t even need an example to see how wrong it is I hope.

While we are building our games, we need a design that fits. One that takes into consideration the theme and aesthetics of the game while we make sure that there is no shock between the several parts of the game.

This is a mistake that way too many flash developers make, one that jumps right up to any eye, even the untrained one aka common player.

    Newer Entries »