Let me start by saying that the title is a bit misleading. For starters it is not an actual bout but more a decision making process. It also gives the impression I’ll write more about this or that I have some kind of plan about this subject. I don’t, it just happens that I think I’ll travel this road again.

Game Design

The game design for this game states that:

1. The player’s objective is to reach the top of the “structure” (named just to make sense) where the action rolls;
2. The “structure” has several “floors” (again just for easier comprehension);
3. The player can fall to the previous “floor”;
4. It is guaranteed that the player will see at least three “floors”;

Application Design

One thing that I know for sure is that we will be blitting all graphics and that the player token has three different blit objects and two of those rotate thus negating copyPixels and putting the dreadful draw method to work.

Another thing I know is that each “floor” is a tilemap, also blitted and that each tile is 64×64.

And now the assumptions begin. How big is each “floor”? I have no idea but let’s say that a rather large “floor” has 50×50 tiles. If the player will see at least three floors and on later stages all “floors” are rather large we are talking about 7,500 tiles to be rendered with a astonishing number of 30,720,000 pixels to be copied… each frame.

The “floor” where the player is will only render the tiles on screen (88 max) but the other two lower “floors” can potentially be fully rendered given the camera specs. Even if all three “floors” only rendered tiles on screen (which won’t happen by design) there would still be 7,500 objects to manage and that’s tiles only since we need to add to this all the remaining entities: player, enemies, decorations, effects, etc, but to make it worse the bottom two levels will be zoomed and probably in full view which means not only that all their blit objects will be visible but also that at least 5,000 of those objects will use draw instead of copyPixels… Did the headache kicked in already or is it just pure performance insanity?

Implementation

One of the great things about copyPixels is that it only renders the intersection between the target bitmapData rectangle and the source rectangle positioned at the destination point. What this means is that if we have 1,000 objects to render but only one actually has an intersecting rectangle, most of the processing time is running the array, vector or list and – more important and processor heavy – calling the functions that will in the end render.

The draw method also does this with a matrix… more on this later.

The solution was to write a BlitTileMap class that builds the tilemap in one big texture before it is used. While it uses much more RAM this class allows to address pretty much every problem stated earlier.

First and foremost the number of objects managed and therefor the performance lost with running their container (in our case, a linked list) and calling functions. From a potential 7,500+ we now have 3. The other issue that this addresses is the number of pixels it will render or try to render, from potentially 30,000,000+ to the worst case scenario of 1,050,000. And last but not least, considering the lower “floors” will be zoomed out, instead of using draw to render 5,000+ objects it will render… 2!

But the draw method also has a funny and helpful consequence. The smaller the scale, the faster draw executes which in terms of performance is relevant considering the zoom out will be achieved through scale. Less objects taking less time to render will be (I hope) quite a performance boost.

Did I just write all this? Wow!… Later!

Today I’ve been busy along with Pedro, putting together the final sound effects on the game so I could capture footage to create what will be the promotional video for Hajime, our next release. It’s been a huge trip. Not the smoothest but I have to say its been nothing but satisfying. Even Vlad, who has been working on other projects till very recently, was moved by the  VGS logo and splash screen. Something we haven’t seen in a long time, not with all the outsourcing development. It’s nice to be able to put our name one something again, but specially nice that its something we are so proud of.

So, with no further due, here it is, the Hajime video. I hope you enjoy it.

Take care,

Marco

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.

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 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!

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

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.

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.

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.