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".