Hello everyone, Marco here!
This game has been in our plans for quite some time. Initially it was just a platform game, with a lot of jumping and running, which I like quite a lot, and there are some emerging games coming out with this sort of gameplay. I never thought of a character but one day I was doodling around in my sketch book and came up with an image of Bruce Lee wearing boxing gloves and like a firework of ideas exploded in my head. I could see him punching his enemies, kicking them away, and basically running really fast on the scene.
So after some thoughts I started roughing out an idea of what the gameplay would be like, and what setting would it be, the theme as well as the graphic style. I had some ideas, and the task now was to merge them all together in order to get them to work, and not be a mash of game ideas that really don’t go along at all.
Vlad had that concern when I explained to him the idea. He asked “is it a fighting game or a platform game” and really I didn’t know what to tell him, so I just went “erm… well… the… hum… let me get back to you on that one”. And I didn’t. I waited a bit more to let the idea grow and look like something that was plausible in terms of fighting and also in terms of platforms.
But the platforms weren’t really a gameplay element as much as they were obstacles to gameplay, until Vlad said “you know, if we had some physics in, it would add to the overall experience, if the player could interact with the scenery to progress”. And like the rug on big lebowski, that idea tied the game together.
Bruce Ali, a mix between Bruce Lee and Mohamed Ali, will be able to kick enemies off buildings, make stuff fall on them, and other fun stuff that I don’t want to disclose just yet.
As an appetizer, here’s a bunch of sketches from the Bruce Ali Sketch book.
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.
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!
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.
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.
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.
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,