New UI

The new UI is finally live on the test server! There are still some things that are missing (the whole Help needs to be done), but it is functional.

If you want to play a game against a real human, feel free to drop me a word :)

The most common question: what is your business model?

Development is going well - the game is now fully playable with the new UI on the development server, so I'm confident for a first beta in January. I take the opportunity to address a question I have been asked often (the second most, after "what is your game about"): how will you make money?

I won't go into details on the various business models there are around. You can find many websites that do it, and for French-speaking readers, a fellow friend game developer has written a nice summary here.

Having played quite a few of so-called "free" online games (from Zynga games on Facebook to your average resource-and-empire-building game on the browser), I have always been frustrated by the gap that always exists between people who pay, and people who don't. While it may seem logical (after all, if I invest money, I should reap some benefits), it feels very unjust to the vast majority of your players - the ones who don't pay.

I thus told myself that when I would make a game, I would not allow players to use real money to gain competitive advantages. Especially in The Five Orbs, which is geared towards one-on-one matches, every player will be able to have a fair fight with anyone.

This being said, I still need to earn money if I don't want my game to turn into a hobby alongside another day job. The main alternatives I have are :

• Advertising. I'm generally against ads on game sites, because it pollutes the immersion and the overall experience. In-game ads, however, could be something feasible depending on the circumstances (you could have a "Coca-cola" object that grants you temporary bonuses for instance), but I'll keep them as a last resort.
  
• Selling "confort". Meaning selling things that make the game more fun to play, or make the controls more convenient. Travian does this for instance: you can buy a "pack" that gives you more detailed combat reports or that allows you to automate constructions. While I like the fact that it does not give any real game advantage to a paying player, I still think something is not right: you could do a great UI, but you purposefully give players more cumbersome controls so that they will want to buy your pack.
  
• Selling cosmetic items. In other words, items whose sole effect is to look nice. This includes additional skins (in my case, new avatars), clothing, house decorations, etc. depending on what your game offers. This is the point I will concentrate on at first. Ideally, I would like to never sell anything else. But depending on how things go, I may look deeper into the "confort" and "advertising" zones. The only thing I will not do is sell gameplay-changing items or bonuses.
  
• Lastly, the subscription model may still be in. One of the things players don't like with free-to-play (apart from the "if you don't pay, you can't compete" side that I mentioned before) is that they have a hard time evaluating how much the game will cost them (per month, per year, etc.) Subscription-based games have the benefit that you know exactly how much they will cost you, and can then rationalize the cost against the time you spend on them. An option I strongly consider is to allow players to pay (e.g. for a week) to get access to everything that is on sale in the game. When the subscription is over (and not renewed), they still keep access to the items they have bought individually.
  

Of course, all that is still theoritical. The game is not live yet, and the harsh reality may prove that all these ideas are but a dream, and insufficient to make a game make enough money. But I'll try hard, and hope everything will turn allright :)

As usual, any feedback is welcome. Have fun :)

PS: here is a list of articles I found interesting that relate to game monetization:
http://www.gamasutra.com/blogs/MichaelFergusson/20100830/5853/Game_Design_Virtual_Goods_and_Social_Games.php
http://chronicgamedesigner.blogspot.com/2011/08/rising-cost-of-free-to-play.html
http://www.gamasutra.com/view/feature/6457/the_fwords_of_mmos_freetoplay.php
http://www.gamasutra.com/blogs/TylerYork/20111111/8869/Game_Monetization_Lessons_from_Magic_The_Gathering.php

Facebook pages

I have created two pages to start communication on social networks. For now I am only using facebook, and depending on how it goes I may try going to G+ (which I use mainly to follow other game developers) or Twitter (which I don't use at all):

• The main page
  
• The dev page, whose goal is to provide frequent updates on how everything is progressing.
  

Feel free to like them if you want to get notified on updates :)

In the meantime, I'll keep the blog for more detailed posts or important updates.

New fighting interface

Two weeks ago, I sat with a couple of friends, and looked at them struggling to understand what on earth was happening in the fight view. Some things I knew were not really user-friendly (like having charges appearing from nowhere, without any notive), and others I was very far from it. The most striking example being the progress bar. It was not clear what this showed. Do I have a limited time to do something? Does my opponent have to do something? Is it something else?

We discussed about the general problems of the interface, and they provided me with very useful insights. I have spent most of my time since then to create a new interface, which is, hopefully, clearer.

It is still not totally finished (there are still some non-blocking bugs around, and I need to add the contextual help), but you can still play around with it.

I took the opportunity to undertake some refactoring of data structures that were overly complex, and separate my infrastructure into three different environments: a development server (which I use internally to validate that when I upload something to Google App Engine, it still works as it should), a test server (which is the equivalent of the previous site), and a production server, which will host the game after launch (not available yet).

Without further ado, I encourage you to check out the new interface at http://test.thefiveorbs.com
As mentioned, it is a new server, so you will need to recreate your accounts.

And more then ever, feedbacks are very welcome :)

Have fun!

Brainstorming new moves

The first release is getting well under way, and I am confident in having something publishable by the end of the year. Apart from the new UI, there are still some balance issues to solve, a new ranking system to put in place and some bugs to fix.

But it is time to think of the next release, which I would like to have around March - April. And the main content of this release will be the skill tree; in other words, quite a few new moves (I'd like them to be around 20 in all, depending on what can of moves I can come up with).

I have thus started A brainstorming forum, where I will write down new ideas as I have them. Some will probably be worthless, others will look good on paper but won't fit once in the real game, and a handful will be ok.

If you are interested to, you can participate to this forum, either by submitting new ideas, or commenting on the existing ones.

And as I'm aware that nothing beats playtest to sort out the crappy ideas from the good ones, I'll try and work on a way to easily implement new ideas and play with them once the code for the current release is done.

Have fun!

First tutorial

The first version of the tutorial on the basics for The Five Orbs fighting is now online! It is accessible directly from the chat page.

There are still a few things to be improved in the display, and is in English only, but it is fully functional. If you try it, I'd be glad to hear what you think of it, where it could be clearer, where it could go faster, and everything you would like to say about it. The more feedback I have, the more I will be able to tailor it to what new players need to know about the game.

For thoses interested in a try, the address is still the same: http://realtime.thefiveorbs.com

Bamboozle first tentative fix in place

The new version has been loaded that includes both the limitation on the number of times a player can cancel a move (now set at 2), and a stronger penalty when being blocked (block time has been multiplied by 2).

It's still being prototyped, so no fancy UI nor image. And the server doesn't enforce the limitation yet either. But this should be enough to test :)

Fixing the Bamboozle

After having played a couple of "real" games (i.e. against real humans), the feeling that the Bamboozle is underpowered is confirmed. The matches are vastly dominated by Attacks and Blocks, and a couple Bamboozles pop up now and then, but with a ratio around 10:1. And when the Bamboozle is fired, it is typically to counter a Block that has just been fired, not really to take advantage of the Bamboozle power.

Just to recap, the Bamboozle is a Magic (that interrupts Blocks but that gets interrupted by Attacks) that does exponential damage, provided that several Bamboozle are fired consecutively. Damage-wise, to make it worth an Attack, you need to connect your third Bamboozle.

The problem

However, it is practically impossible to chain two (or three) Bamboozles in a row. The reason is that once the first (or second, depending on how soon your opponent wants to stop you) Bamboozle is fired, an easy reaction is to fire an Attack. If you do this, the possible outcomes are:

• Either your opponent has fired their next Bamboozle, and you will interrupt it (the Attack being slighly faster than the Bamboozle)
  
• Either they have done an Attack themselves, and it will be a draw. However, their Bamboozle chain has been stopped.
  
• Or they have done a Block (the natural counter to the Attack you just did). However, being able to cancel the move you are currently firing, you can simply switch to something else once the Block has been fired. You will have lost some time, but the Bamboozle chain will be broken.
  

And so, if you want to stop a Bamboozle chain, the worst thing that can happen to you is losing the firing time of the Block your opponent is doing.

So, once your opponent decides to stop your Bamboozle chain, they can do it easily.

What to do?

The goal is not simply to make the Bamboozle a move people fire more. To do so, simply multiply the damage done by 5, and you've got it (and then you have to tune it to not overpower it, but the idea stays the same).

The goal is to make the Bamboozle a move that people use, wanting to connect several in a row. And, when they know that their opponent is about to counter it, take advantage of the situation. In other words, in the case you have been able to fire 3 Bamboozles in a row (your next one will be at 16 damage!), your opponent is bound to Attack to counter you. If you're sure they will, you need to be able to Block, and take a real advantage by doing so.

I don't have the solution yet, but I'll use this post to explore several trails.

The first thing that seems natural to do is to make this switching out of Attack more difficult. I don't really want to make move cancellation impossible, because it is still an interesting feature. If your opponent Blocks and you were firing an Attack, a mind game comes in play: will you cancel your Attack because of the Block (in which case your opponent had better fire another move, since the Block will be useless), or will you go on with it, in which case your opponent should not do anything and wait for you to be Blocked?

Another possibility could be to change how the Bamboozle works. Instead of forcing it to be consecutive moves, it could be changed to "as long as you don't fire an Attack, or are not hit by an Attack". Which means that a player intent on going with strong bamboozles will llmit themselves to Blocks and Magics, possibly for the whole game. Which means the opponent can try going for full-attack, and cancelling them if they see a Block coming, effectively negating all possibility for the Bamboozle player to launch anything that brings a Green charge.

This again brings back to the fact that it is too easy to cancel a move being fired, and escape the Block. A possibility could be to limit the number of times a player can do so. For instance, each player can cancel one or two of their moves once per game, or have a strong penalty when cancelling the move (like a delay on the next move). This would still allow for mind games (as long as cancellation is possible), but limit it to a couple of crucial times (like when you are firing a fully charge Energy Blast).

Let's suppose from now on that the number of times you can cancel your moves is limited. I don't think that, by itself, it is sufficient to restore the Bamboozle. In the initial scenario, the Attack is still a no-brainer to a Bamboozle chain threat. The worst penalty for the one firing the attack is either the Block penalty, or the cancel move penalty. Given the current Block penalty, it is a safe gamble to take (especially since there is still a chance that the one firing the bamboozle will try and go for another bamboozle). So increasing the Block penalty is another way to try it (maybe simply increasing the block delay by one would be enough).

TL;DR

As of today, the Bamboozle cannot be played the way it is intended: it is too easy to counter it, with close to no penalty. Possible ways I will be looking at are making it more difficult to cancel a move being fired, and increasing the Block penalty.

But as usual, it would be easy if things could just be figured out by thinking about them. Next step will then be to prototype these changes, and see how it goes.

New bug fixing release

Taken from the forum post:

New features
- You can now choose not to display the fight rules every time.
- The game is localized in both French and English.

Bug fixes
- When you go back to the login page (using the Back button of the brower), you are now automatically disconnected from the chat.
- Fixed some bugs on the rankings display
- Background images are now of lower quality, and their size has been reduced by 4. This should improve the loading time of the various screens.
- Starting a fight does not shuffle the players on the right in the lobby
- Images no longer have a white border attached to them (a big one ^^)
- Resizing the application now works properly on all page. It brings a scrollbar on the home page, and resizes the components on the other pages.

White borders on transparent images

For some time now, all my transparent images have been having white borders. I tired every CSS attribute I could find, but none of them worked.

I then came accross a post of someone who had the exact same problem. I was not crazy, this happened to other people!

Strangely enough, it looks like the solution is to not use an imgtag, but a div when you specify the source image in the CSS. I tried it, and it works :)

First UI version finished!

I have finally finished the first version of the User Interface for The Five Orbs. Of course, the design still looks rough, but there are colors, and we're not invaded by TextBoxes anymore :)

As usual, you can find it at: http://http://realtime.thefiveorbs.com

Login UI update

A new version of the login UI is online at http://realtime.thefiveorbs.com.
I like the background image a lot :) It is a free image found on google image, but I cannot use it for commercial purposes. I'll try and see with the author if I can keep it somehow :)

Apart from that the UI is iso-functional with the previous one. I've added a small "news" section, and will work on the "description" part to try and make something that looks good.

If some of you are interested with 1v1 against real players, I'll be glad to be your opponent - it's high time I started really playtesting this thing.

Have fun!

Small udpate

A new version of The Five Orbs has been pushed today. It concerns the real-time version of the game. The changelog is:

• The password is now encrypted. So when you create your account, even I won't be able to know what your password is.
  
• An e-mail address is now requested at account creation. For now, it is used only to reset your password in case you forget it. You can create an account with an invalid e-mail address; it just means you won't be able to reset your password if you ever forget it :)
  
• Added a short rules explanation at the beginning of the fight.
  

In addition, some small bugs have been corrected:

• Cannot move the chat during the fight anymore
  
• The size of the move details panel on the right is now fixed.
  
• The error that occurred when retrieving the leaderboard has been corrected
  

As usual, any feedback is welcome :)

Interface - New version

It's been some time since I last wrote here, but I have just finished a first version of the combat interface:

In order to have a first launchable version by the end of the year, here are the main points that still need to be done:
- Improve the interface of the home page. This include a teaser-like description of the game.
- Improve the interface of the chat screens
- Create a "real" interface, with a consistent theme and custom made graphics (this is one of the biggest parts ^^)
- Improve the account management: encrypt passwords, allow one to retrieve a lost password, and change a password.
- Localization (at least in French and English)
- And, most of all, playtest a lot and improve the gameplay.

There are of course lots of minor things to do as well, but I'll tackle them as they come.

Interface - Current state

Nothing much to say, but I just wanted to post a screenshot of the current version of the interface for history purposes.

Everything is being done with images coming from google, which more likely than not aren't public. But for now it will do :)

Rethinking the interface

A huge part in the process of going live is to rethink the interface. The current web version has indeed been developed to test the gameplay, but is too crude and too obscure to be going live.

A way I like to proceed when building interfaces is building paper prototypes:

(as you can probably guess, interface design and drawing is not my forte ^^)

 Paper prototyping allows me:

• To draw each piece of the interface separately. If I wish to change something, I don't have to redo all my work, but can only change the part that is affected
• Allow me to play with the different pieces and see how to arrange them on the screen
• Allow for "live-testing", i.e. take a potential player, have them interact with the paper interface as they would with the digital one, and modify the pieces on the "screen" as they do things. 

The picture above represents a current idea for the interface. It will most likely change based on how the testing goes, but at least it gives me a foundation on which to start - I still have many things to understand as far as client interface coding and implementation goes :)

Going live

I have decided to start building a first full version with the current gameplay (for people who have played the recent cards version, it actually means the game with the 6 revamped moves, but without transformations). This means that it will have to include a proper interface, text translation, bug fixing and of course gameplay experience. In other words, I will focus on polishing the current version instead of trying to add more scope to it.

Hopefully, this will mean that by the end of the year, I will have a first (though basic) version to release for beta testing. The downside is, the gameplay will be more limited than what I had hoped for (and that's something very frustrating, having to postpone all these ideas). But I think releasing as early as possible and then iterating on it will be better for the overall quality of the experience than trying to put too many things in the beginning.

Of course, the game design and playtesting sessions will continue, but as far as development goes, I'll focus on getting something out first.

Stay tuned ;)

Going realtime

One of the main goals of The Five Orbs is to enable multiplayer - in the sense of one team of players against another team of players. We have already played such games using the card version, and it is definitely fun.

The current system forces players to each secretly choose a move, then reveal it simultaneously. Even for team matches, this has worked well with the card prototype. The current only version uses this system, and it works well too.

However I am a bit concerned about online play for team matches. Waiting until everyone has finished their move can be quite frustrating, as it provides an intermittent gameplay. I am not saying this is bad; it has undeniable advantages, such as giving plenty of time for mind games. And perhaps this will be the way to go for The Five Orbs, online.

I would nevertheless like to try a "realtime" version of the game. The difference would be that you would not need to wait for your opponent(s) to play. Each move would have timers (wind-up, cooldowns - people familiar with MMORPGs like WoW know what I'm talking about) that would pace the match. The Speed attribute would then be an indicator on how long you need to fire your move, and a cooldown would apply on each move to avoid chaining the same move again and again to reap tons of charges.

After a few tests, this changes several things. First of all, you have less time to think. Or more precisely, you have some pressure to decide your move during the time you can't do anything - the wind-up time of each move: while firing a move, you can't do anything else until the move has fired. The speed scale for the whole game can be parametered to find the good balance between pressure and time to use your Yomi skills.

Moreover, Blocking becomes different. You can effectively Block only when you have fired your move (which, up to now, is the same as in the card version). However, deciding to Block (i.e. counter an attack) forces you to do nothing until your opponent's move fires. At that time, if they did an Attack, you successfully Block it (and lose if they did a Magic).

The price to Block becomes high. You need to sacrifice some time, which you could otherwise use to prepare another move. The reward for successfully Blocking should then be higher. I have modified the move as such: when the Block fires, you gain B (like today). If you successfully Block an Attack, you gain another B, and the attacker's next move is at Speed + 2 (thus slower).

For those who want to play with the realtime version, it can be found here. But beware, there is no explanation whatsoever, so it assumes you are already familiar with the rules and are willing to to a bit of trial and error to understand which button corresponds to what. The only thing that needs to be said is:
To power-up a move, hold Ctrl while clicking (not a great solution, but this will do for now).

And if you want to stick with the turn-by-turn version, or simply compare both, it is here.

If you have any comment on it, feel free, I'll be more than happy to listen to them :)

Cards explained

Now that the rules and the cards have been published, I have some time to explain the reasoning behind the cards.

Without going back to the genesis of the rules, I decided to go with a Rock - Paper - Scissors relationship between the different moves. The reasons included being able to beat a stronger opponent based on how well you managed to read their moves, and forcing the players to focus on what their opponent was doing instead of merely trying to achieve high Damage Per Second. Thus were born, after many changes, the Attacks, Blocks and Magics.

The cards then fit into three categories. The basic moves, the advanced moves and the special moves.

The basic moves

This category includes the Attack, the Bamboozle and the Block. The goal of these moves was to provide an always-available counter to whatever the opponent might do, as well as a means to get charges.

The goal of the Attacks are to deal damage. As such, the Attack is no surprise, and provides a reliable way to do a fair amount of damage.

The Block is its natural counter. It is slightly faster than the Attack, so that it will fire first (otherwise it wouldn't be much of a use). The first version of the Block was just what is on the card: stop an Attack, and gain B. This, however, allowed the player to mathematically compute the worth of the card. I have 1B, which I can use to power-up the Energy Blast for 3 dmg. So 1B = 3 dmg, so a Block is worth less than an Attack.

The only skill that came into play was reading how your opponent would play, and not "what move is best suited for me now" (also called Valuation). According to the unclear payoffs of moves, I wanted to make them less similar, and introduced the block stun: after being blocked, your next move is slower by 1.

The last of the basic moves is the Bamboozle. The goal of the Magic cards was to be a bit different, and provide some unusual moves. The Bamboozle is for me the most interesting of the three basic moves, in the sense that it strongly affect the next move you will play. Firing one Bamboozle isn't worth much - a mere 2 damages. Firing two in a row makes it as good as an Attack (but still slower). From the third one, it gets really powerful. And it's really interesting to live the mind games going once a Bamboozle has been fired. Should I play Attack to make sure he doesn't get two Bamboozles in a row? But two Bamboozles isn't a big deal, maybe I should Block instead to get my B charge I need to power-up my Energy Blast. Etc.

Once two Bamboozles are out, the reasoning changes a bit. It is more like "he has too much to win if he connects a third Bamboozle that I have to play Attack to stop him". In the end the 8-damage Bamboozle is often that big a threat that it is not worth taking the risk to outread your opponent - unless he knows you're someone who plays safe. Which is why letting the second Bamboozle connect is stronger than it appears: it is not only about the 4 damage, it is also that the next move odds are a lot in favor of the Bamboozling man.

Advanced moves

The first goal of the advanced moves was to provide a mid-term objective to the players. So that they think "I need RR and at least one B to fire my Energy Blast, so I need to play Attack", and their opponent thinking in the same line. In the first versions of the game (including the version that is playable online at the time of the writing), this is what made the random play suboptimal (as proved by the relative weakness of Modnar). It is always more profitable to play according to a strategy than play randomly.

In the current version of the game though, the advanced moves answer specific needs, as illustrated below.

As you may have understood by now, Attacks are not really the subtle moves. The goal of the Energy Blast is in line with this philosophy: do more damage. It also provides a way to convert B charges into quite a lot of damage. To the point that the Energy Blast is seldom worth playing without one or two Bs to power it up.

The Interrupt origin comes from team play. Say your team is loaded with charges (RR, BBB, GG) and you want to throw a strong Energy Blast to one of your opponents. It is however easy for the opponent to anticipate it (that THE move you should do after all) and Block it. And if it fails, they didn't lose much.

The goal of the Interrupt was thus to allow for a coordinated attack. One player Interrupts the target, while the other smashes them with an Energy Blast for 15 damages.

That's why the Instant Guard has been created: to provide a way to counter this scheme (if two moves have the same speed, they both activate at the same time - so the IG is not Interrupted). And that is also why the IG has an alternative way to pay its cost. What's more frustrating than knowing something is going to happen to you and not being able to react? To cope with this, you always have the opportunity to pay 5 life to fire the IG.

The special moves have not been really tested yet - only a couple of solo games - so I will leave them for a future post. And as usual, waiting to hear for your feedback :)

Game rules

As long as the online version, I am working on a physical card prototype of The Five Orbs. You saw the cards in a previous post. They allow me to work on new concepts and test them without any cost. That way I can easily try out new things, and discard or adapt them when need be.

Without further ado, here is the link to the rules. It is a first draft, so very unpolished, and will probably remain so until I am confident the rules will not be changing all the time as it is the case today.

And the PDF containing the cards is here.

The rules probably contain at least some obscure explications or phrasing. Unpolished not meaning not understandable, please let me know, and I'll detail or rephrase.

New release

A small release this week, as I'm mainly busy working on the new rules for team play and a first prototype of real-time play. The changelog is:

- Date indication in chat is now displayed according to the client's locale
- Very basic draft of rules accessible from the fight screen
- Number of games played displayed in leaderboard

Unfortunately, it is not possible for me to update the current leaderboard with the number of games that have already been played. I did not store enough information on each game to easily compute this number, and parsing the logs will be a big hassle.

So, unless it proves absolutely necessary, the number of games played (finished, actually) starts at 0 for everyone.

As a reminder, the url is http://test.thefiveorbs.com, and the link is also present on the right column of this blog.

Print and play!

... except you'd have to know the rules first, as there are no downloadable rules yet.

I've starting playing with nanDECK and made a first set of cards. And I've just seen that it's really easy to add files and images to blogger, so here I go :)

The Five Orbs deck

3 vs 3

Team play continues! We had a 3 vs 3 team match the other night, and I finally have some time to write down how it went.

The play session

The play session included friends who had never played the game before (or only the very old version of it, which amounts to the same thing). To avoid making things too complex, we decided to stick with the rules with which we played our first 2 vs 2 match.

One of us took on to write a detailed log of the game. I thus have a full table that records all moves for everyone on each of the 18 rounds of the game. We can get many other stats from this document, but I'll publish them in the next post.

On a very high level, the main points are:

• We won :)
  
• Our team clearly focused the attacks on one person (12 targets on 11 rounds, against 13 on 17 rounds for the other, and 15 on 18 rounds for the last one). He was also the first target of our Energy Blast (the most powerful move), which led to its death after 12 rounds.
  
• The rest of the game led to similar conclusions as last time. With one less player (and already behind in terms of life totals), the other team could not do much. So the question as to how to deal with this kind of situation arose again.
  
• Nevertheless, it was still fun. The fact that a dead player can't do anything in the game anymore and has to wait until the game finishes is a negative point, but I hope that the changes we'll bring to the gameplay will help with this.
  

Post-game discussion

Once the game finished, the main testers and I sat down to discuss the points to be improved. Our main concerns were:

• Give teams to avoid being reduced to fewer players than the opposite team, or at least let them come out of this situation with decent fighting chances.
  
• Avoid "the more you win, the more you win" effect.
  
• A couple of balance issues.
  

Additional dynamics

One thing we wanted to do was to help teams adopt different kinds of strategies. We have thus designed a specialization system, that allows a player to specialize in one of the three main areas (damage, control and support). Basically, Control allows player to interrupt other moves more often, Support will earn more charges for the team and Damage is rather self-explanatory :) With each of these specialization will come one additional move, that will replace the standard strong opposite move. For instance, someone specializing in Damage will replace the "Instant Guard" with a new "Dragon Punch".

Limited charges

When a team is gaining the upper hand in terms of life total, it often comes hand in hand with an advantage on the charges. While this may be disputed (you already do damage to your opponent, AND you get additional charges??), it works fine for now as is. However, what the winning team was really gaining was the freedom to strike whenever they wanted. As soon as you have accumulated enough charges to fire your boosted Energy Blast, the opponent is one the defensive. They know they can get hit really hard at any time, so they must be cautious. Which means that as long as the winning team doesn't fire the move, they have an additional advantage. The issue here is that waiting to use the move has no drawback. Take a game like Street Fighter IV: you can get a power bar to fill up (depending on the moves you do and the damage you take), and once it is filled up you can launch a devastating move. If you fire your move immediately, you can hope to get a full bar again later on in the fight. So in this case, the cost of waiting is a potential loss of a second move later in the game. We have decided to apply a similar limitation on The Five Orbs. The charges will now be limited to (4 + 1 * number_of_players_per_team) charges per team. This will not only force team to fire their strong moves if they want to keep on winning charges, but hopefully will also force them to decide on a strategy to get the appropriate charges (you wouldn't want to be stuck with 2B, 3G and 1R while wanting to fire an Energy Blast).

Small adjustments

In addition to this, we will try some small adjustments:

• You gain a charge as soon as you fire the move, regardless of what becomes of it (a blocked attack will earn you 1R now)
  
• Instant Guard is really underpowered, and Interrupt should be a bit stronger. Not decided on what to do with them yet.
  
• The Block additional effect has been removed (it was useless as it was). Might add a new effect to bring some power back to the Block.
  
• Still no combo
  

So quite a lot of new things coming in the next match :)

New release

A new release is out!

- Slightly improved handling of presence in the lobby. Players whose connection drops will now not be present in the lobby anymore.
- Added a Level attribute to the ranking ; it is an easiest way to compare two players. The details are still available.
- Changed the display of waiting players in the lobby.
- Rethought the handling of fight challenges to other players, to make it less confusing.
- Added icons for players you have challenged and who have challenged you; added an icon for Modnar
- Player names that are in fight are now in italics
- The Level is now the prevalent measure of the player's strength in the lobby. The details (mean and uncertainty) are still available when mousing over the player's name.

Note on level: I believe it is interesting to have a simplified way to compare two players. However, the current level is a bit awkward. You go up and down quickly (while levels tend to mean you're getting better, so up only), you skip levels a lot in the beginning, and you can rather easily get a negative level. So I'm not really happy about it. I will need to wait a bit and see how it turns out with real data, but I could replace that with something slightly different.

As usual, waiting to hear your feedback :)

First team match playtest

Last week saw the first real match between teams of players. Not the usual one-on-one match, but 2 vs. 2!

First things first: that was fun :) The game was clearly unpolished, some rules needed tweaking (rules changed between each game, and once again after the last match), but it was interesting and fun to play.

Our main concern at the beginning of the game was to avoid having a no-brainer strategy consisting of taking out one of the two players first to get into a 2 vs 1 situation. We discussed several adjustments to get to it.

The first rule we adopted was:

If you are targetting someone, and are targeted by someone who isn't your target, this player gets a bonus

The goal of this rule was to simulate a case where two players would gang on one player of the opposite team. The attacked player then adopts a defensive stance, trying to parry the attacks of both attackers. And during this time, the attackers are wide open to an attack from someone else.

This of course is a very simplistic simulation, but it still gave us a good ground from where to start. The first game went on, and was pretty one-sided. One team got the advantage early on, and it kept widening during the whole game. The losing team forfeited after one player got taken out.

The post-match analysis mainly revealed that one move was strongly imbalanced (it was easy to smother another player), and that a given combination of moves lacked a proper counter. We fixed this, and went on to the second game.

For the second game, we decided to try and apply the "take one out first" strategy, and concentrated our attacks on one of the opposite team's players. We got a bad start, but eventually managed to take them out. The situation at this point could have been seen as close: the single remaining player had the same amount of hit points than both of us combined. However, as expected, it is more or less impossible to survive in a 2 vs. 1 environment.

We then all agreed that the 2 vs. 1 situation is something we should have a clear answer to. Several ideas were proposed: the ability to revive a fallen ally, a change in how players were allowed to play when the 2 vs 1 situation would arise, etc.

In the end, we decided that there would be no heal (my call, I don't like healing) and no revive ability. We would instead focus on giving the teams the tools to avoid facing this 2 vs 1 situation.

The main idea we have had for this was to allow players to "transform", or "specialize", during the game. For instance, you could trade Blue charges to get an improved defense and reduced damages. Or be more efficient at interrupting someone else's moves, or dealing more damage, etc. We still have to test all of this though (we played only two games) - so stay tuned for fresh news :)

New release

A new release of The Five Orbs has just been published:

- Fixed bug that caused Modnar to sometimes fire an invalid move - thus crashing the game
- Fixed display of special characters (é, â, etc.)
- Leaderboard
- Basic chat in the fight screen
- Basic tooltip on fight moves
- Lobby notification when game ends
- Players in a fight still appear in the lobby, with a marker
- Modnar is explicitely referred to as a bot

Hopefully this will make the game a bit easier to play. I still need to add the rules of the game and a description of the interface to make the game playable even by first-timers. Later on this will be properly included in the interface itself, but I am more looking for a quick fix here.

I will now mainly work on the core mechanics and dynamics of the game. I've had a first test session this afternoon with my favorite playtesters, and some interesting things came out :)

I parallel, I will improve a few aspects of the web version:

- Better handling of fight challenges
- Add some help in the UI (even a crude "view rules" would work)
- Link to the blog and the forum
- Improve handling of users "presence" in the lobby
- Know when it's your turn to do something, or your opponent

Have fun!

First playable version

Sooner in the afternoon, I have finally be able to complete a repeated series of full human vs. human games.

There are of course still a lot of features missing, a few bugs, no documentation or guide whatsoever, and a very simplistic User Interface.
I have put in place a forum where to raise every issue there still is, suggest improvements, or simply discuss about the game. I will try and link it (as well as this blog) from the game itself soon.

Without further ado, the first prototype is at http://test.thefiveorbs.com
And the forum is at http://thefiveorbs.freeforums.org

Waiting to play with you :)

First milestone - A complete game against Modnar

Two days ago, I have fought on the web my first complete game against my intelligent computer, Modnar. Well, intelligent... It plays at random, so it is usually not that much of a challenge. Except that I played more to test the various combinations of moves and find bugs than to win (so essentially random), and I lost :(

The implementation still has some bugs (we couldn't complete a two-player game yet), but it is an important milestone nevertheless.
I'll disclose the URL once it will be stable enough (hopefully soon enough).

About roles - unequal and unclear payoffs

As a continuation from a previous post, here is another interesting article by Sirlin on how Rock, Paper, Scissors can be transformed:

Spicing up RPS

Different things happen depending on which option you win with — this is where the unequal and unclear payoffs come in.

Having different payoffs gives players reasons to choose one move over another. At a different scale, this is what happens in every strategy game. Early rush in an RTS can be effective if pulled properly against an unprepared opponent (the $10-rock Sirlin refers to), so most experienced players will know to prepare against it (and play the appropriate version of Paper).
The objective here is really to provide the players with clear different alternatives. Ideally, each option would be quite different from the other ones (think about early rush / full economy / mix of them), in such a way that it makes it difficult to calculate (or predict) which option will be the best choice.

The issue with the current game is that the payoffs are too clear. Throws and attacks are equivalent, and give charges. The block also gives charges, which can - at least for now - be easily converted into damage, and compared to attacks and blocks. The only real differenciation for now comes from the -1 speed the opponent gets if they are blocked.

To address this, I am contemplating giving "roles" to each of the three actions. A short analysis on roles can be found on this article on Halo 3:

Roles need to have actual functional differences. Rock-paper-scissors is not actually good design, as the 3 roles are completely identical. The depth in any multiplayer game comes from the roles and their interactions

This agrees with what I've been feeling lately. Part of the apparent randomness comes from the fact that Attack and Throw have the same role, each one being simply a counter to another move. And even Block is not that different, since it allows the player to chain attacks afterwards.

I have not given that enough thought yet (I am currently busy building a basic implementation of the current version of the game; more on that later on this week), but what I'm thinking about is:

• Attack stays as is, i.e. a means to directly inflict damage to the opponent
  
• Block roles will be geared towards "powering-up"; this is in a way similar to what it is today, but I'll need to emphasize more the power-up side, and possibly decrease the potential damage you can inflict with a throw (for now, you can combo as easily after a throw as you do after an attack)
  
• Finally, the Throw will have to be the most heavily impacted. It will become something more like "special ability", "magic", or something of the like. In this category, you could have things like "until you are hit, your attacks do double damage".
  

The critical step will be to keep this Rock-Paper-Scissors relationship, since this is what balances all the moves. With the projected outline, it is easy to imagine a game where you can always block and never suffer any major damage. This is why the "magic" category should provide ways to prevent this.

This is all a bit blurry for now, and needs to be given some more thought. I'll let it simmer while I finish the first coding part of the project, and will probably come back to it during the week.

See you soon :)

A bit about coding

For the last couple of weeks, I have been starting working on the implementation of The Five Orbs. My first goal is to provide a basic adaptation of the current rules in an online, web version. There will be no fancy sprites, no elaborate UI... only the bare minimum to play a game.

The goals of this first, barely-playable version is first to discover the technologies I will be working with (more on that later), understand how to build an application and find out about the more risky parts of the implementation as soon as possible. It will also allow me to play with remote testers and get their feedback. And finally, when it will be implemented, it will allow me to build first statistics on how the game is played, which moves are most played or win most, etc. This will be a very important step towards achieving good balance.

Technologies

This post is tagged "code", so obviously I'll go a bit more technical here.

My job is that of a Java developer, so that would obviously be my choice for the server. Concerning the UI, I had done several mini projects with various technologies. Namely:

• An implementation of the board game Agricola using Adobe Flex. I loved developing in Flex; the IDE is great, the language is intuitive (especially for someone with a Java background like me) and documented, and it offers some really convenient features (like data binding). However I had troubles keeping the size of the application and its performance in check (mainly concerning the memory consumed).
  
• A mini sandbox game using JSF. At first I found the technology great, but I soon found that I missed many things that I loved when I was using Flex. This is a JSP framework, so no Object Oriented Programming. You were in charge of making sure that what you built was compatible with all modern browser (while Flex runs on a Flash virtual machine, which takes care of cross-browser compatibilty). And it being a JSP / javascript framework, it was harder to debut than Flex.
  
• At my job, I have worked a bit with plain JSPs, and with a combination of JSP / YUI (or at least a derivation of it). Everything I said about JSF applies here too.
  

None of these struck me with an obvious choice (although if I had to choose, I'd go with Flex). I looked a bit elsewhere, and I decided to go with Google Web Toolkit. It allows me to code both the server and the UI in Java, offers great debugging tools (when developing, you actually run your UI code as Java code), and all the browser-compatibility issues are handled by GWT (the Java code is compiled into javascript before being deployed in production). The community around it is very active, it is properly documented, and for now it meets all my needs. The one thing I regret is that the graphical editor is less easy to use than the one from Flash Builder.

Deployment

I looked then at where I could host my application. Unfortunately, it is not easy to find cheap hosts for Java apps, so I was a bit stuck. I then read about Google App Engine, and found out it met my needs. It alleviated me from the burden of managing server loads, database replication and back-up, scalability, and so on. While there is some controversy concerning GAE (especially since they decided to change their pricing policy), so I must be careful to build my application in the way that makes it as independent from GAE as possible.

Development environment

I'm a big fan of Eclipse (I have worked a bit with NetBeans), so this was a no-brainer. I also decided to use Maven as a build and dependency management paradigm. The good point with using GWT and Eclipse is that they go very well together. The Google Plugin for Eclipse offers everything you need. GAE is very well integrated too, and I never have any need to go outside of Eclpse for anything. To the point that I'm questioning my choice to use Maven, instead of a full Eclipse-based environment. Indeed, Maven adds some overhead to the compilation process and makes integration of some features (or other libraries) not so easy within the Eclipse / GWT / GAE world. However, Maven makes my project standardized. If I decide to go out of GAE, I won't need to change anything to my process to keep my efficiency. I can integrate with Continuous Integration frameworks. And the community is active and provides a great support, so it mitigates some of the integration risks.


This post has already been going for some time, so I'll leave all the discussing about real code and design to the next one :)

Yomi and conditioning

As usual, great posts from Sirlin, my Yomi master:

Yomi Layer 3

Rock, Paper, Scissors in Strategy Games

An extract from the first article (emphasis is mine)

Yomi is the Japanese word reading, as in reading the mind of the opponent. If you can condition your enemy to act in a certain way, you can then use his own instincts against him (a concept from the martial art of Judo)

The important part here is that Yomi comes from experience. If you have never played or read anything about Rock, Paper, Scissors, you will have no idea that people have a general tendency to play Rock as a first move, so you'll play what you perceive as randomly - and probably throw a Rock.

But more experienced players are conditioned when playing against a rookie. They know that a random RPS player will probably throw a rock, so they'll go for paper to grab an easy win.

And the same logic applies to games, including The Five Orbs. The key here is to have moves that have unequal rewards (which is where the current design probably fails for now). In that case, you know that your opponent is likely to fire his strongest move, thus breaking the apparent randomness of RPS.

And what's more, you can condition your opponent into being predictable. To take a personal example from a recent play session of Street Fighter 4: being what you can call a n00b, I don't have much experience in fighting games - and I am definitely not at the Yomi Layer 3 described by Sirlin, given my lack of dexterity to even properly execute the moves I want to do.
However, by always chaining two moves together (in my case, a kick while jumping towards my opponent - to force a guard up - followed by a low kick), my opponent ends by always following the high guard with a low guard. End at this moment, they are vulnerable to a throw.

And this is what I want to achieve in The Five Orbs: always create a situation where each player will have a move they will be most likely to fire, so that Yomi can come into play. And the role of the game will be to provide the players with interesting choices all along the fight to make them not want to play "at random".

Assessment of the game system

As promised a while ago, here is a first assessment of the gameplay (what has been currently built, as well as what is planned) against one checklist provided by Raph Koster in his book A Theory of Fun:

This isn't an algorithm for fun, but it's a useful tool for checking for the absence of fun[...]. Simply check each system against this list:
Do you have to prepare before taking on the challenge?

With the current version, it's a no. However, character building will provide the player with multiple choices to do before taking on a fight:

• Level up in a way that fits her overall strategy. In other words, learn the new skills (or upgrade existing ones) that she will be able to use best in combat.
  
• Choose among all the moves that are available the most suited ones. The choice can be made either on personal preferences, or because the player knows the opponent's playstyle, and adapts accordingly.
  

Can you prepare in different ways and still succeed?

From what is said above, that is obviously a goal :) Playtest will tell me if that's really the case though.

Does the environment in which the challenge takes place affect the challenge?

It depends on what you mean by environment. If you define it by "all the factors that live independently from the player", then it includes your opponent. Given the nature of the game, and her being a human, your opponent will definitely affect the challenge.

Are there solid rules defined for the challenge you undertake?

Yes.

Can the rule set support multiple types of challenges?

That's difficult to answer. Given that the challenge changes with each opponent (or at least it should), I would say yes. Moreover, the rules will have to be compliant to support a team vs. team confrontation.

Can the player bring multiple abilities to bear on the challenge? At high levels of difficulty, does the player have to bring multiple abilities to bear on the challenge?

The abilities a player need seem to be several fold:

• Strategy to decide how to level your character up. Levelling up will (hopefully) include tough trade-offs to do, and having a strategy and being consistent with it will be crucial.
  
• Tactical skills in order to decide how to prepare and lead a fight. Even though the tactical aspect is still limited in the current version, it will evolve with additional moves being available.
  
• Intuition, or Yomi, during the battle to execute the above tactics.
  
• In team matches, team play will definitely play a preponderant role.
  

Is there skill involved in using an ability? (If not, is this a fundamental "move" in the game, like moving one checked piece?)

No skill to use the ability (contrary to games like Street Fighter). The skill will rather be on when to use a given ability.

Are there multiple success states to overcoming the challenge? (In other words, success should not have a single guaranteed result.)

It being a "death match", there is for now only one success state. Either you win, or you lose. I have ideas to tweak that a little, but it is only vague ideas for now, and I don't think it will really affect how the player feels about how she'd done in the fight.

Do advanced players get no benefit from tackling easy challenges?

After a match, the players gain both experience points and ranking points. And both of these will be computed according to the difference between the players, so that an advanced player will have close to nothing to gain by beating a weaker player.

Does failing at the challenge at the very least make you have to try again?

Hum... I don't really see the implications of this one, so I'm not sure I'm really answering the question. Like in sports or in fighting games, a lose or a win is only a step towards mastery. So whatever the outcome of the fight is, an ambitious player will have to try again.

If your answer to any of the above questions is "no", then the game system is probably worth readdressing.

As said in introduction, this is not a guarantee that the game will be fun. At the very least, it avoids the pitfalls raised by Raph Koster.
Now there is some work to make it fun :)

C'est parti !

I'm now officially dedicating my working time to building The Five Orbs. I have decided to take one year off my current job to give it a real try.

Besides all the planning I need to do to give myself a clearer mid-term vision, that means I will have more time to post on this blog. From now on, I'll try to post something at least on a weekly basis, and hopefully more often, especially in the first weeks (I have quite a few draft posts waiting to be published).

And since this blog is about game development, I'll try and categorize the posts with two main labels: game design for everything related to, well, game design (the majority of the posts until now); and dev for all the technical aspects of the game development.

And now... on to work!

Discussing balance

A nice article discussing balance I found on Sirlin.net (the ones that have designed the Yomi fighting card game) :

What's in the pipe - The meta game

The fighting system is the core experience of The Five Orbs. However, it will get enriched by a few other aspects:

Character progression

Learning new skills will allow your characters two main things: new skills, and new spells. Spells are only an idea for now, and I have not put much thought into them yet. The core idea behind the new skills is that the player will have to choose only a handful of skills to use in combat among the whole set of aptitudes they will have unlocked.

Multiplayer

This is yet to be developed. I'm thinking for now of three main aspects: apprenticeship, teams and guilds. Each level has its own characteristics.

The apprenticeship is useful to form a bond between a newcomer and an experienced player, and help the newcomer integrate the world more rapidly.

Teams are the "fighting unit". People on the same team strive to develop common strategies and work on their play to achieve results together.

And guilds are vaster groups of people. They share higher-level goals and objectives ; I found out that guilds are most effective if they have a physical representation of some sort in the universe, which is not possible for now in The Five Orbs. I have a couple of ideas to make guilds worth it though, but I'll go to them in a future post.

What's in the pipe - The fighting system

So, these were the current rules of the prototype. A few playtest sessions have already revealed some flaws or possible improvements, and the bigger picture contains many more things than what I have tested until now.

In no particular order, here is what I am thinking about.

About combos

I am not a big fan of the chaining of moves being based on the speed of these moves. It is very restrictive, and links two things that are not necessarily tied together, thus preventing a mix of moves (like a slow move that could be chained with any other move).

I have thus considered adding some kind of icons to show, for a given move, which moves can be chained into it, and what moves I can follow it up with. As an illustration, just imagine that the attack move has a "fire" icon on the left, and a "water" on the right ; this would mean that it can follow-up any move that has a "fire" on the right, and can be followed by moves that have a "water" on the left. Easy, right?

During the latest playtest, a friend suggested an intersting way to evolve this. In fact, the evolution has two parts:

• First, don't necessarily associate similar symbols together, but rather have two halves or symbols that "match". If the left of one card fits with the right of another, even if they are from different symbols, you can chain them.
  
• Then, don't limit the chaining to left and right. By building a two-dimensional grid of moves during combos, you can contemplate all kinds of effects (like moves being surrounded by several moves are stronger, or chains that are longer than they are wide are quicker, etc). And I can see it go very nicely with multiplayer fights too.
  

Following this, the rule of 25% decrease will probably need to be reevaluated

Rock-paper-scissor

The latest playtest had a friend point out that, to him, the outcome seemed too random. Given the circular nature of the rock-paper-scissor relationship, you could spend hours trying to second, third, fourth... guess your opponent, resulting in a random play to stop the inifinite loop :)

I am not personnally convinced of this yet, but I admit he has a point somewhere. You play more according to what your opponent is supposed to do than to accomodate your own strategy. To cope with this, I'll try and weaken this RPS relationship. Meaning that if you lose the exchange you could, under certain conditions, still fire your move.

One point that I need to be careful about is to still keep this RPS relationthip, since this is what allows for "yomi" (read what your opponent will most likely do).

Real-time vs. turn-based

The card version lends itself pretty well at simultaneous play. However, when you are in an online environment, I see turn-based play more as an artificial remnant of board games, and it often ruins the overall experience.

Being a fighting game, I expect this to be even more true for me. So I'll probably go for a real-time fighting, based on timers (fire and cooldown counters) à la MMORPG.

Current rules, version 2

As promised, here is a condensed version of the current rules. In other words, the rules of the game as I playtest it.

Basic moves

• Every player starts with a total of 50 life points. The first to reach 0 loses.
  
• To decrease the life total of your opponent (and protect your own), you can use three kinds of moves: blocks (B), attacks (A) and throws (T).
  
• These moves follow a rock-paper-scissor relationship: the block beats the attack, the throw beats the block, and the attack beats the throw.
  
• Attacks and throws each have a speed attribute. A quicker move beats a slower one (from the same type), and ties with a move with equal speed.
  
• Each player chooses a move in secret, and both players reveal it at the same time. The moves are then resolved with the above algorithm, and damage (if any) is dealt. The players each take the move back in their hands, and start a new round.
  

Charges and special moves

• When each basic move is successfully executed (i.e. when it wins the exchange), it can grant a charge. For instance, a successful attack grants an A charge, and a successful block two B charges. The charges are then accumulated are available for the whole duration of the fight.
  
• The charges can then be used in two ways: either as a cost to start a move, or as a power-up when a move successfully hits. For instance, I need to spend two As to fire the Energy Blast, and if it hits, I can spend up to three Bs to add additional damage.
  

Combos

• When a move succeeds, it is possible to chain with another move (combo) instead of gaining a charge. The opponent cannot react to this move (it is thus a sure hit).
  
• To chain a move, the chained move must be strictly slower than the original move. A third move can then be chained if it is slower than the second, etc.
  
• After each move, the damage done decreases by 25%. The first move is thus at full power, the second at 75%, the third at 50%, etc.
  
• In the case of a block, only one move can be chained.
  
• When in a combo, no charge can be gained.
  

And I think that's pretty much it for the current rules.

Chosen pieces

I've started reading some game design-related books, and I thought I'd share some advice that I found in there. The quotes below are not what I find most interesting in these books, but rather concrete advice that I could put to use quickly.

From A Theory of Fun

This isn't an algorithm for fun, but it's a useful tool for checking for the absence of fun[...]. Simply check each system against this list:

• Do you have to prepare before taking on the challenge?
  
• Can you prepare in different ways and still succeed?
  
• Does the environment in which the challenge takes place affect the challenge?
  
• Are there solid rules defined for the challenge you undertake?
  
• Can the rule set support multiple types of challenges?
  
• Can the player bring multiple abilities to bear on the challenge?
  
• At high levels of difficulty, does the player have to bring multiple abilities to bear on the challenge?
  
• Is there skill involved in using an ability? (If not, is this a fundamental "move" in the game, like moving one checked piece?)
  
• Are there multiple success states to overcoming the challenge? (In other words, success should not have a single guaranteed result.)
  
• Do advanced players get no benefit from tackling easy challenges?
  
• Does failing at the challenge at the very least make you have to try again?
  

If your answer to any of the above questions is "no", then the game system is probably worth readdressing.

I'll try and post the rules of the game system as it is today, and match it against this checklist to see where the "nos" are.

From LevelUp!

Foreshadowing is a powerful tool to get a player excited qbout the activities and dangers found in a level. Building anticipation is just as important as delivering on it. In all my years of making haunted houses, I've found that a scare is bigger and better if the victim knows it's coming. It's waiting for the scare to happen that drives them nuts.

For me, I guess that would mean to give the players a glimpse of what they will be able to get (and preferably make them want to get it),. Doing this would increase the emotional reward for the players when they get this long-awaited skill or orb for instance.

From Reality is Broken

[...] Initially, the researchers were perplexed by the gamers' positive emotional reaction to "complete and unquestionable failure in the game". When we fail in real life, we are typically disappointed, not energized. [...] After much consideration, they concluded [..] The players hadn't failed passively. They had failed spectacularly, and entertainingly. [...] The The right kind of failure feedback is a reward.

A key point for me in playing online, persistent games. Usually, failure is perceived as something to strongly avoid, since it often goes hand in hand with some kind of loss (XP - therefore time - equipment, money, possessions - in building games like Travian or ManKind - etc.). If we want the players to look for interaction, and keep looking and defying each other after a loss or failure, the cost of loss must not be so high that they only want to quit.
For The Five Orbs, I have thought of several options. First, no "material" loss when defeated. The ranking may fall for instance, but the player should not feel they have less than before the fight.
The "entertaining" loss immediately made me think about "fatalities" in the Mortal Kombat games. The fight is over, but you still have a mean to interact with your opponent. In that case, it was a means to destroy them even more, but you could think of many other possible interactions (like congratulations, mocking, respect, even the old fatality) that could have real in-game effects.

And the one simple trick used over and over again [to make players feel epic] is this: always connect the individual to something bigger.

One of the core aspects will have to be the multiplayer experience. And by multiplayer, I don't mean one vs. one, or even team vs. team, but how large groups of people could interact together. It's a part of the game I have not given many thoughts about though.

[...] any good game [...] needs compelling goals, interesting obstacles, and well-designed feedback systems.

Yeah, another checklist! :)

[...] good game mechanics. Player action has direct and clear results.

Again, the feedback system is a key point.

So, next step for now is to take my existing game system, write it down here, and check it again all of this advice.

Depth first, accessibility later

Quite a lot of things have changed since the last post - I've been rather lazy with keeping this blog up-to-date. I'll try and catch up with the few evolutions that the rules have been through later on.

In the meantime, I have realized that I may be going around in a bad way with my prototype. In my head, the goal was to have as many people playing it as I can, so that I can get feedback and correct what is wrong.

The main issue with this way of thinking is the notion of "accessibility". I want people to be able to play the game and tell me how they feel about it. And this means often people who have never played it before, or even who are not too keen on games in general.

The obvious result is that I was trying to get my game easily understandable and easily explainable. The downside to this is that I am probably discarding options before I have even tested them, on the simple ground that "it would be too complex".

Another approach, that I will try and go with, goes in another direction. Get a pair of dedicated playtesters, who will know your game as much as you do. Try and build something as deep as you want it to be; in other words, build the complexity, strategical choices, and all the richness you want without caring for people for are new to the game and might not get it. This way, the game will be as meaningful as you want it to be.

Then, once you have the depth you are looking for, work and make it more accessible. This may lead to compromises on some complex features, but at least you will work on the finished game, and know the tradeoffs you will have to make.

So, that's where I will be heading now. Time to find willing playtesters :)

Draft of the rules

Just as a memo, here is a draft of the rules following the modifications mentioned in the previous post. These rules date back to one month ago, and have since then evolved.

• Each player starts with 100 life. The first to reach 0 loses
• Each player can perform all the moves she has learnt beforehand. They fall into the following categories:
• Attack
• Throw
• Block
• Each move has the following characteristics:
• Category
• Attack power, which represents the amount of damage dealt
• Defense power, which represents how well the move resists to an attack
• Fire time, which is an indication as to how long the move takes to be fired
• Cooldown time, which is the time the player needs to wait before she can fire this move again
• Resource(s): each move, when fired, may add one or several resources to the temporary pool of resources
• Accelerator: if the resource(s) indicated in the acceleration are in the temporary resource pool, the move is accelerated
• Cost: some moves require additional costs, like permanent resources or momentum
• Gain: when the move successfully fires, the resources are added to the permanent pool
• When a move is accelerated, its fire time is decreased by 1.
• When a move is fired, its duration is added to the total duration of moves for this player. The moves then fire in order of duration (shortest cumulative duration first)
• Blocks trigger when the opponent's move triggers

Combos: only some moves may start combos. Combo is a separate phase, and isolated from standard combat. When combo starts, can chain moves (need to decide based on what).

• Each resource added lasts for the time of the combo. You can then cumulate resources
• Each move done in the combo must be accelerated
• Starting move gives the first resource(s)
• Some moves should not be usable in combo (e.g. moves that grant too many resources). Resource should be limited at 1, or 2 at most to avoid ramping up too fast to finishers.
• Each step in the combo chain grants 1 momentum. Some finishers require momentum points, usually more than the number of different resources needed (to avoid being fired too quickly).
• The player who is under attack must have ways to break the combo.
• For each move, the defender can choose a special counter, to which a resource is associated. If the counter succeeds, the attack fails and the combo stops. This way, the longer the combo chain the higher the risk (but the higher the reward).
• If ten resources, around half a chance to block a level 6 combo.
• Avoid making this symmetrical. Give incentive to the attacker to use certain resources (already the case with the moves they will try to fire), and for the defender to block using certain resources. E.g. associate a main resource for the block. If successfully blocks using this resource, the combo breaks and the defender can chain a combo.
• Success is share at least one resource as the attacking move.Need diversity in attacking moves then.
• Add "finisher" moves to combos. They finish the combo, and are usually strong. The goal of the combo will then be oriented towards firing this move (standard moves in combo do small amount of damage, but accumulate resources).
• Finisher cannot be blocked
• The stronger the finisher, the more resources / momentum it will require

If combos (or more precisely, finishers) are a great way to deal damage, must avoid the "starter spamming" strategy.

• Starters work only if opponent doesn't block
• Starter is cancelled if hit while preparing starter
• Starter works if it hits when opponent is preparing throw or attack.

Use janken relationships (like yomi):

• block counters attacks
• block adds its resource, and slight stun on the attacker (like +1 for next duration)
• throws ignore blocks
• if throw while blocking, same as if opponent was simply idling. No stun on success, since a resource will probably be granted, which gives a speed bonus
• throw doesn't work on opponent who is preparing an attack. Throw is cancelled, and attack fires immediately.

First playtest

Since last time, I have thought quite a lot about the combos, and how I want them managed. The points that seemed crucial to me are:

• They should be handled in a different way from the usual fighting (in this case, there is a phase dedicated to the combos, outside of the normal fight). This will give them their special flavor, and highlight how they are different from the normal fighting process.
  
• Introduce a "progressive difficulty". The longer (and more powerful) the combo is to be, the more difficult it must be to pull off. The hard step here is to make sure that this difficulty is not too much luck-based, which could be very frustrating.
  

With this in mind, and the janken relationship of moves found in Yomi, I have built a first set of basic rules for the game, as well as a first prototype.

And today was the first playtest with a real partner. Talking about an opponent at this step would be presumptuous, as this first playthrough was mostly about figuring out which parts of the rules made sense, which concepts were worth keeping, and so on.

The first problem there is with the game today is the symmetry. Indeed, the game regularly (beginning of the game and after each combo phase, mainly) goes into a state were the situation is completely symmetrical. All moves have equal probabilities of success and equal profits, so the choice becomes totally random.

The second issue was the lack of strategical choices. The choice of the next move is indeed influenced only by the previous move, and by what I want to do as a next move. But it stops there. There is no global orientation of the moves (at least in the normal fighting phase - the combo phase is a bit more interesting to this respect).

So the next step will be to make some adjustments. I think I will get rid of the starter moves, and rather offer the player the possibility to pay some extra resources to start a combo following an attack or a throw. This way, she will be more likely to gather the resources needed to fire the combo, and will have an objective.
And in a similar way, the opponent should be able to take resources from you, to incite players to start combos soon after they have the ability too.


So quite a few things to change before the next playtest.

Stop making sense

I have shamefully taken the title of a couple of articles found on the Internet that tackles the question of sense and realism in videos games, and that have helped me on my particular issue.

From the beginning, I was trying to wright my fighting system as a reflection of real-life boxing or martial arts. And this has been very helpful for me to uncover ways in which I wanted to go, for instance on how to chain combos (in the real world, you give a punch, and your body is pushing forward. It is thus easier to chain with another punch (the one-two) than with a backkick for instance).

However, it has implicitely set boundaries to my imagination. Since then, I had been trying to fit every move in this "moving forward", "unbalanced", etc. framework, while it should have been only a means to help me figure out what I wanted to do.

A friend of mine helped me find fighting board or card games, to look at how they are built. Two of them caught my eye:

• The Universal Fighting System, and
  
• the Yomi card game
  

I have learnt a lot, and had quite a few ideas, simply by reading the rules and reviews of these games. The important point here is that they do not sacrifice gameplay for realism. I have now taking my basic concepts ("forward moving", "balanced", "unbalanced", etc.) and abstracted them (I am using resources like "fire", "wind", etc.). This allows me to simply create fun moves, or moves that would go well with each other, without trying to stick to a realistic representation of a fight (which no one really cares about). Reading these games have given me quite a few ideas though, and I am in the process of changing some parts of how the fight should be run. I have a few basic ideas for the general moves, but I want now to focus on a big part of every fighting system: the combos.
And hopefully, this will also affect how standard moves are dealt with, so I will likely need to review my whole system soon.

Prototyping

I have added three first moves (two basic kicks and the corresponding counter), and restricted the first counter to work only for "hits" (and not kicks). I have done some very basic testing, and it starts to be difficult to think of an always-winning strategy. The counter is now limited to when you can practically guess what your opponent's next move will be (is this too big a nerf? Statistically, a counter deals almost 2.5 times the damage a normal hit does though).

There are two points I am not really happy with yet:

• The guard and evade moves look more time-winning distractions than moves that are really usable. Guarding considerably reduces the damage received, but doesn't put the defender in any favorable position. And evade only increases the chance of the opponent missing and going to unbalanced state. The way this state is handled today acts merely as a short delay before the next action.
  
• Random behavior seems the winning strategy now. While there is no guarantee of success, constantly hitting while preventing the opponent to anticipate looks the best option. I already have a couple of ideas to incite players to play moves with a purpose in mind, and will try and test them soon enough.
  

The next step for me is to provide a strong system simply based on the elementary moves I have added up to now. It includes balancing the various strategies, and finding a real purpose to the defensive moves. To do so, I'll take my testing one step further, and try it with other players. A simple deck of printed cards and dices should be enough for some real-life prototyping.

First results

I had decided to start with a few very basic moves:

• A basic hit
  
• A combo hit, that is better fired when the player has a "forward" position, to reflect the "one-two" combination.
  
• Guard and evade moves, which fire instantly and go on until another move is selected
  
• A "counter", which has a lower rate of success but can negate the opponent attacking move and retaliate immediately
  

I also decided that for moves that were not fired from the "ideal" position, a precision penalty would apply. All being set, I started to play out a few encounters on a sheet of paper. I quickly found strategies that would ensure a systematic win, and recalibrated the various parameters of my moves. I made sure that, statistically, no one (simple) strategy was overpowered. However, it now appears that chaining hit / combo hit, while not overpowered, wins most of the time. And most of all, that the opponent does not have any good way to retaliate. This initially was the goal of the Counter move. However, the move was too strong, and an opponent always playing Counter would statistically win most of the games. I saw two options:

• Increase the cooldown of the counter to prevent a full-counter strategy. The issue I saw with this is that players would still counter whenever possible.
  
• Decrease the strength of the counter, which is what I did, and what led to the current situation.
  

I am now trying to find a way to solve this. Why don't repeated and relentless attacks work in real life? Why do professional boxers vary their attack pattern, guard and launch a real hit only when they think they have a chance to connect? First, attacking continuously is tiring. And since the opponent would be constently guarding, the ratio damage done vs. energy spent is high. Then, if a martial artist repeats again and again the same move, she becomes too predictable. The opponent can then anticipate and land a succesful counter hit. If the attack pattern is varied or unpredictable, it becomes much more difficult. I will now look at these two directions:

• Introduce (or not) a kind of "fatigue" attribute
  
• Make the counter specific to some moves, like "hit", and introduce a new category of moves (e.g. "kick"), against which the counter will be useless / weak. And of course restore a bit of power to the counter move.
  

Building the fighting system

I've started to try out a few approaches to this combat system. I've quickly dismissed a real-time engine, where skills would come from proper timing (e.g. what you see in console fighting games). Browsers are not guaranteed to be fast, and it does not really accomodate with lag.

I'm now considering something closer to what is done in MMOs. I like the timer with cooldowns approach; it gives a good impression of real-time, while still leaving a few seconds for each player to decide on the next move.

However, the issue you often see in MMOs is that fighting consists of repeating the same couple of moves as much as you can, without needing to analyze what your opponent is doing. In my game, I would like to incorporate a strategic perspective. I'd like the skill to come from "fighting intelligently".

So I need the player to be able to choose her next best move based on:

• The player's current status (has she just been hit? What was the last move? Is she moving forward, retreating?)
  
• The opponent's status
  
• Any knowledge the player would have gained from the first moves exchanged in the fight.
  

Given the last point, I need my system to be rather slow (at least for the beginner period), and for the fight to last enough for players to decipher patterns in their opponent's behaviour (does my opponent vary her moves? Is she more the counter type?). For the first two, I need for a move to fire differently based on what the player has done before. For instance, it should be easier to dire a combo hit after a first one has successfully landed rather than if the player has just been hit. Similarly, it should be easier to hit someone who is off-balance or has her whole intent on hitting you rather than when she is trying to guard or evade your blows. I want first to build a working system with a few basic moves (limiting to a couple of different hits and defenses), and add complexity once this is more polished. I am now considering a few elements:

• Basic notions like time needed to fire a move, cooldown, damage / defense / evade stats for each move
  
• Each move has an ideal starting position, and a finishing position. At every moment, the player is in a given "position" (for now very basic, like "balanced", "balanced forward", "unbalanced"). When a move is fired, the player's position will change (e.g. after a hit, the player will be "balanced forward", to mirror the momentum she has gained when dealing the blow). And if the move is fired from their "preferred" position, it gets a bonus.
  

I will now build a few basic moves, and try and see how they work.

Core system

So, how do you go when you have decided to make a game?

The first reflex I had was to choose a "category". "I want to make a strategy game" or "I want to build an RPG-like game". This has obvious advantages: you are in a familiar environment, and can rely on your players knowing more or less what they will have to deal with.

Precisely because of this, I don't really like the approach. Your creativity will be limited by the constraints of the genre, and the risk of doings things just because they are done in other similar games is big (if I had decided to build a strategy game, I would probably have decided to include several types of resources without thinking about the reason to do so, but only because that is what strategy games are supposed to be about).

So first I want to decide on what my game will be about. What will the main feature of the game be? What will be core experience of my game?

One of my prerequisites is that skill had to play a part. I feel that games where "experience" (which more or less equals the time psased on the game and/or money spent on it) quickly get hollow. However, I am not confident in building a pure skill-based game. You need a very polished and balanced system (that moreover takes into accounts the limitations of the browser-based genre, e.g. some players will have slower platforms, and this should not impact the experience) to build a succesful skill-based game.

What I aim at is a system where the casual player can still have fun (and need only to understand the basic mechanics), enjoy and progress in the game, but which only players who really take time to understand the system can master.

As a core system, I've decided to go for "fighting". It's the most basic element in MMORPGs today, it lends itself very well to multiplayer, and there is a lot of room for innovation and improvement.

Next step will be to draft a basic combat system, that integrates everything above.

First post

Where do I start... Ever since I was a kid, I've always dreamt of building my own video game. Since then, I've starting to work in the computer industry, and developed some skills in programmation. And suddenly realized that it had now become something within my grasp.

Oh, I'm not talking about a big 3D game, but rather a browser-based game. This kind of game has been popular for a long time (I've player my share on Travian, Ikariam or more recently Shakes & Fidget), and they are more in line with what I can develop.

So this blog will be about how I go about developing this game. I'm really no blogger, so I'll have to push myself to write something on a regular basis, but I hope I will be able to capture the main phases I go through. Everything will probably be a bit rough for the first posts, but I hope it will get better as I get used to writing.

So, here we go!