Archive for the ‘The design of VGS’ Category

Fun: The final achievement

A long time ago I read a thread on a gamedev forum where the opening poster asked what was ‘fun’ and how was it achievable in a way that would raise the ‘addiction’ factor. I found the question to be very interesting but the debate around it, considering that was a gamedev forum, extremely poor.

Most of the people that participated in the thread could not separate their development background from their playing background. Remember the Gamer != Game Designer post? It’s pretty much the same argument but on a later stage. Why is this important or relevant? Read on…

Copying formulas

I’m betting that a huge percentage of flash game developers/designers implement features in their games because they’ve seen it in sucessful games. If it is successful it is usually named: high-scores, achievements and so on are excellent examples of successful features.

Implementing it enhances a game, for sure, but does it increase the fun and entertainment value? I bet you’ll say YEAH! but can you explain why? We are just copying formulas, not really digging why we are doing it.

Categorizing

Well we keep doing it… When we do a certain game genre, we are categorizing our game. Again we are copying a formula but by doing it we are giving the player an opportunity to filter what he wants to play. Don’t take me wrong, this is more than fine. After all we do want players to play what they want or that will take the fun out of the experience. Why does it take the fun out of the experience?

Understanding the factors

By copying formulas we are adding factors such has re-playability  and by categorizing we channeling that value. Both work if the game has value on its own and most don’t! It does not matter how many success formulas you include or how you categorize your game if you ultimately fail to understand why is a game fun and entertaining.

Some developers simply copy entire games and it works for them. I think they are convinced they have achieved a higher state of game design knowledge… well… I’d love to see them do something new under a different name, just to see what would the reaction of their fans be.

On the other hand, developers that understand the factors that create a great experience do wonders, they create new genres, make the gamedev theorists and journalist come up with new terms and I’m under the impression they don’t even think about it. The mob simply follows their lead.

So what are the factors?

That’s up to each one of us to find out I guess. Being a Raph Koster fan I believe that factors reside in the purest of forms, in understanding how the brain processes the experience. My personal view on it is that if you apply that basic processing to a target audience, it will work. Our talent and experience only makes it work more or less, but it will work! That’s the basis of how I design.

I bet other developers will have other ideas, but this whole post is a “think out of the box” kind of thing. What I’m trying to express is that if you don’t think in terms of your own gamer clichets. Don’t think that you like multiplayer, or that a certain game was cool because it had swords. Think on what will the reaction be to something you create. Think what is the typical player of the game you are creating. Think on how you’ll reach him or her individually. Stereotype your player, not you as a player.

Mental Note #1

Hi all…

Too much talking about Bold Pixel Engine! Time to move on a bit… for some unrelated reason I took a look at my personal blog that I left a long time ago.

I found a “Quotes” category there and gosh the ammount of mental notes there is overwhelming, mostly on game design. Things that were written a long time ago in some of the early game design books that live in many of the older developers shelfs. Some of the things that were written contradict many of the things that aspiring developers think, sometimes reading it can be cruel… doesn’t mean it is not true.

Today I bring you Chris Crawford, like others I might write here, one of my favorites.

Complete amateurs whose only relevant skill is programming undertake to design games with no further preparation than their own experience as game players. Those who overrate their own understanding undercut their own potential for learning.

Chris Crawford @ The Art of Computer Game Design

A flash game must have…

A lot of info spread through the web about what flash games must have or not. Here’s our take on it:

…a mute button

Although everyone will scream their hearts out that a mute button is a must have, I beg to differ. Since Atomik Kaos that we changed the mute button (or key) for an entry screen that asks if the player wants sound and music. We did it because it personally annoyed me to enter games with bad audio and music and have to wait until the place where the developer decided to put the damn mute button.

We received a lot of feedback praising such a decision and one rant about it because the sponsor intro sounds played because the decision screen was after the sponsor intro… that one negative feedback completely forgot that even with a mute button, it would hear the sound way before the usual mute button showed up.

…saved data

Some games need saved games, others don’t. But saving data is more important than just saving your game state. You can present the player with a lot more stuff if you get used to gather statistics.

I won’t go to long with this since it’s very game specific but you can do some very nice things, such as present end-level or game-over statistics that will keep the player going.

…right mouse button context menu

Someone mentioned this in the FGL chat. I personally only took it off twice, both times by request. I understand that it is something that I’ll probably address now that I’m conscious of it, but I never felt or received any feedback about it for our games.

…the right instructions

Don’t throw all the instructions at once at your player. As he progresses through the game, give him the info he needs for that task.

Often instructions are loads and loads of text that no one reads. Everyone did that mistake at least once.

…pause on lost focus

Some games have it, others don’t. For the download market it was a feature that every portal asks for, in the flash market I honestly prefer not to do it.

This is quite easy to explain. Most flash games take a small area of the whole web page where they are embedded. Usually and unless the mouse is the input of the game, the mouse is taken off the game because it’s pointless to be there and it is just covering something.

In my opinion, catch and pause the lost focus event only if your game is time dependant and the mouse is the player’s input to the game. Appart from that it can be pretty frustrating.

…user input customization

Some developers do it. Most don’t. Give the user the option to configure keyboard input that feels most natural to them. You can then leverage the ’save data’ feature to store those preferences locally. Thanks to Phil Peron for pointing it out.

Nothing else occurs right now, so feel free to pop up something I might have forgot and I’ll write it here!

Later folks,

Vlad!

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.

« Older Entries