It has come to my attention that I have not updated this blog in quite a while. This is an error that I wish to remedy immediately. Since my last post a lot of fun and exciting things have happened and I have learned a ton of new stuff that I will hopefully write about in the near future.

I would like to announce that Wezzle has been completed and is for sale on our website! It only took two years since Couchware’s inception, but it’s finally here and it looks great. I couldn’t be happier with the way Wezzle turned out. I think it looks outstanding and has some enjoyable and addicting game play.

I would like to give a huge thanks to those who assisted in the creation of the Wezzle. This includes Renee and Sam and all of our testers. If you like the art and music in the game be sure to check out Renee’s and Sam’s websites.

Despite having put the game up for sale, Wezzle is not yet 100% complete. We are still hard at work finishing up a Wezzle demo that will be playable within the browser. Once the demo has been completed, we will be marketing/launching the game to a larger audience (hopefully!). There will likely be a launch party at an as of yet undisclosed location in Toronto. For those interested in coming, fire me an email or check back at this blog occasionally. Cam has also been hard at work at a REALLY cool Wezzle port, the nature of which I can’t disclose at the moment. It will be hopefully laying the ground-work for some of our future projects.

In other news, I have been put in charge of a major project using Java EE 6 which I’m pretty excited about. Some of the technologies I have been using lately include: Maven2, Logback, JPA/Hibernate, JSF, EJB 3.1, and more. Hopefully in the coming weeks I will have something interesting to say about some of these.

Finally, I have bought kevingrad.com, org and net (all currently have no content) and I will eventually be moving this blog to one of those (probably .org).

Test 7 add a ton on top of test 6. This is copied from our official post in our forums:

• An updated Play Now menu that has a look consistent across all menues.
• Added achievements.
• An achievements browser, that allows you to scroll through all achievements in the game and to see which ones you have done, and when.
• An in-game achievement notification. In fact, we’ve added a general notification system that will give you tips and other information as the game progresses (these can be turned off, of course).
• Improved line sounds. As you get more and more line chains, the line sound increases by a semi-tone. It’s quite exciting.
• An improved tile dropping algorithm. You now get fewer random drop-in lines, so that the game no longer feels like it plays itself.
• An improved, peripheral timer. When you get up to level 10 like the big boys, you need to have a better idea of how much time you have. Our new timer does just that.
• An Options Menu.
• The ability to turn off tutorials (once you’ve played them once of course!)
• An new, more intuitive music selector.
• A piece previewer (up in the top corner) as well as an overlayed piece previewer (check the Options Menu from the Main Menu).
• You may now pre-rotate pieces in the queue by right-clicking during a tile drop-in.
• A Windows installer that’ll automatically install Java if needed. Works on 32-bit and 64-bit Windows (including Vista).
• Added new rotation tutorial to Level 2.

If you would like to play Wezzle test 7 (or any of the tests) and you are not currently on the email list, just send me an email and we can get that fixed right away.

Anyway, we were talking about Digsby, and I mentioned that one of the things I dislike is that if you use Digsby for Twitter, they automatically make you follow the Digsby Twitter feed. This is something that is very irritating, I don’t want to have to follow them or figure out how to un-follow them. This should be an option or something.

Additionally, Cam mentioned (and i agree) that he doesn’t like how they try to get you to install around 10 different applications when you install Digsby. This is something that I find in a lot of programs. I often get asked if I want to install Yahoo! toolbar or some such program and this irritates me to no end. I wish they would stop doing that stuff.

However, Cam asked me the following: If Yahoo! approached us and said if you package Yahoo! toolbar with your application, we will pay you $100,000, what would you say? The answer, obviously, was a resounding yes. So there you have it. We are willing to sell out, and I don’t even know what the price point for our selling out would be. So Yahoo! or Google or anyone else out there. If you want to pay us money to package your application, we are willing to do so.

Last night I was hacking around with Ruby and decided that to teach myself how to program better I would do something interesting for Wezzle. I had the idea of taking the XML markup for our achievements and making some sort of generator using our achievement pseudo-language.

Our achievement language basically amounts to what is known in computing as a Domain Specific Language (DSL). Luckily for me Ruby is a pretty good language for writing DSL’s.

I decided to start with the achievements that I find to be the hardest to write, COLLISION. A COLLISION occurs between 1 or many items. There are two seperate types of collisions which can be defined as either an AND or an INTO relationship. These can be seen in the following two examples:

Example 1:

<achievement name="A Tale of Two Rockets" difficulty="SILVER">
  <description>Fire a rocket into another rocket.</description>
  <rule type="COLLISION" operation="BETWEEN">
    <item type="ROCKET" />
    <item type="ROCKET" />
  </rule>
</achievement>

Example 2:

<achievement name="A Tale of Two Rockets" difficulty="SILVER">
  <description>Fire a rocket into another rocket.</description>
  <rule type="COLLISION" operation="BETWEEN">
    <item type="ROCKET" >
      <item type="ROCKET" />
    </item>
  </rule>
</achievement>

While these two examples may look the same, they mean two different things. The first one can be written as COLLISION BETWEEN ROCKET AND ROCKET simply means that two rockets will be activated in a single turn. The second one however would be written like COLLISION BETWEEN ROCKET INTO ROCKET and means a rocket will be fired and activate another rocket by hitting it.

I have written a generator in ruby that takes an achievement (currently only collisions) in the following form:

BEGIN COLLISION
achievement:Rocketeer:BRONZE
description:Fire a rocket into a rocket and fire a rocket and a rocket.
rule:COLLISION BETWEEN ROCKET INTO ROCKET
rule:COLLISION BETWEEN ROCKET AND ROCKET
END

This is currently defined within the program and will output the properly formatted and tabbed XML which you can then paste into your achievements.xml file. The goal is to have it work for all achievements, and I will keep you updated as to the progress should I choose to continue. As it stands, you can find the current version here although it’s a little bit ugly. Please note, you must have ruby 1.9+ in order to run it.

Computers today have tons of processing power. Who really cares about algorithm design when the computer can perform millions of calculations per second? This was a common thought of mine until recently.

When I learned big O notation and performance estimation in university I often thought to myself that I would never need to remember it, and it was not really useful for programming today. I was way off. Big O is something I have recently started using again and encourage every programmer to use as a way of estimating algorithm performance.

When we started making Wezzle we initially began designing without real thought of efficiency. Our initial implementation was all about design. However, we were very inexperienced when it came to actually designing good quality code. We quickly ran into some severe performance issues, and the Wezzle design still has some major flaws that really aren’t worth fixing at this point. One thing I can say with certainty is that my understanding of good design has improved by a drastic amount from this experience.

Our initial game design included the use of Scalable Vector Graphics (SVG). We chose to use SVG because we liked the way they looked and the fact that window resizing was a non-issue. However, we failed to take into account how performance critical games truly are, and how incredibly slow SVG graphics are.

Our initial game was extremely choppy and virtually unplayable on old machines. We spent a lot of time trying to figure out why that was and how to boost performance. Eventually we decided to bitmap our graphics and noticed a SUBSTANTIAL increase in playability and performance.

I was pretty shocked by this entire scenario. First, I had always assumed that performance today was a non-issue, and second, I never thought that the type of graphics we used would make such a huge difference in terms of performance.

SVG wasn’t even close to all of our performance issues with early versions of Wezzle. We had a bunch of calls that were needlessly being made every game tick (we still find this problem with some of our code) as well as various other design flaws that affected overall performance. We had an inefficient algorithm to refactor the board and just in general a lot of areas that could be streamlined. We also had a bunch of performance issues with label generation (which we fixed with a cacheing scheme) and some troubles with phantom references (yuck!). We made extensive use of the built in profiler in netbeans during our first refactoring phase.

Since then Wezzle has gone through countless refactorings and countless optimizations. Another huge increase in performance came when we switched from Java2D to OpenGL (lwjgl). Perhaps in a later post I will talk about some of the various optimizations we have employed in Wezzle, but that is beyond the scope of this article.

Even with all the performance issues in Wezzle, I thought to myself that games are kind of a unique situation that is very performance critical and lots of calculations are happening, maybe performance is only relevant to gaming.

Again I was wrong. As anyone who does any web development can attest to, large database operations can be TERRIBLY inefficient. I am currently under contract developing some code that loads a large number of records into a grid structure. I am limited by the fact that this grid is only usable to us by passing it XML on the client side, as well as various restrictions about look and feel that were dictated by my client. Perhaps in a future post I talk about the multitude problems with the grid I am using, and there are many, but that would take way too much space to type in this post.

Anyway, my first implementation which contained some optimizations took around 15 minutes to update 500 records from the grid. The records were huge and data validation was being done on every individual cell and since the grid had to be submit as a whole (as an XML string) I was parsing and updating the entire grid.

This was not acceptable and also mildly surprising. Going through my code I have optimized even more. I implemented a dirty cell scheme, marking cells which have been edited as dirty so that on the submit I can only validate cells which have been marked as dirty. This assumes that all data already in the database is valid (not always the case!). I validate pasted in values at paste-time and that’s it (once they pass validation, they are considered good from the client side). Finally, I mark records which have been modified as dirty and even though I still have to submit the entire grid, I now only parse the records that have been marked and skip the rest. This has vastly improved update performance on the average case. It has improved updates in the worst case as well, but not by quite so much, a full submit still takes some time.

I’m going to end this by saying that while yes, performance is an issue, it is also sometimes a non-issue. First and foremost you should code something for clarity. A clear design that is slightly less efficient is always better than a streamlined but cryptic design. It is a mistake to optimize something that doesn’t actually need optimization and a big time waster. A popular saying is “design for clarity first and foremost and use a profiler to determine which areas need to be optimized.” This idiom does make sense and makes a valid point, but I would instead say to design for clarity and performance in conjunction as performance can often be a surprising bottleneck.

I’d like to talk a bit about a cool little feature of Wezzle that nobody knows about. Wezzle reads all of its information from XML. Neat!

Ok, ok, so that’s not that groundbreaking. I never said it was, but it IS cool. Because of this, all of Wezzle’s attributes are fully customizable.

The first time you run it, Wezzle generates four files located in your home directory in a folder called .Couchware/Wezzle. Three of these files are XML files, achievements.xml, game-settings.xml and user-settings.xml. The fourth file is the log file.  These files contain your personal settings and achievements, modify them to your hearts content! If you ever run into a problem, you can just delete the file and the game will load the default settings.

I know what you are thinking: “Awesome. Every game has customizable settings, why is this so special?”. Well my friends, it’s special because Wezzle understands XML! What this means is, you guys can create content and as long as it conforms to our specifications (which we will release with or shortly after we release Wezzle) Wezzle will understand it. These three XML files are loaded on top of our base settings, which means things like custom tilesets, custom tile colours and even custom achievements are easy!

I’m going to look a little bit at achievements. Wezzle’s achievement system is a rule based system. What this means is, any achievement can be expressed as a set of rules. For example, if you wanted to have an achievement for scoring more than 6000 points, the achievement would simply contain the rule: SCORE > 6000. Cool.

Additionally, an achievement is only completed iff (if and only if) all the rules evaluate to true. This means that we can combine any number of rules to make an achievement.

A huge benefit of this is that writing achievements is trivial, as long as you know the set of available tags. The achievement system already reads in all it’s achievements from an XML file and is still being expanded. Here is an example of an achievement that is currently in our test game:

<achievement name="Get A Level" difficulty="BRONZE">
  <description>Starting from level 1, get to level 2 without
  getting a game over.</description>
  <rule type="START_LEVEL" operation="EQ" value="1" />
  <rule type="LEVEL" operation="EQ" value="2" />
</achievement>

The achievement is enclosed with <achievement> tags which include meta data for that achievement including the difficulty level and name. The <description> tag is the achievements description as shown in the achievement browser. Finally, all the rules are defined in <rule> tags. Pretty simple huh? As you can see, we defined two rules with this achievement. Rule 1: Start level = 1. Rule 2: Level = 2.

When designing our XML tags for Wezzle we wanted our rules to be as readable as possible. We tried to mimic human speech. Each rule is an AND relationship. The above XML for our achievement can be read like this: START_LEVEL EQ 1 AND LEVEL EQ 2. In other words: “start level equals 1 and level equals 2″.

An achievement is considered completed iff ALL of its rules evaluate to true. Therefore, in order to achieve the achievement listed above, you must start the game at level 1 and your current level must be level 2. This means that if you start on level 2 (or any other level than 1), you cannot complete this achievement.

Now lets take a look at writing a custom achievement. In order to do this, all we have to do is write up the XML and stick it into our achievements.xml file. Wezzle will automatically read this new achievement and incorporate it into the game, including placing it into the achievement browser.

I will walk you through the creation of another one of the available achievements currently in the game. We would like to have an achievement for when a rocket fires into another rocket. In the game the name of this achievement is “A Tale of Two Rockets” and its a Silver achievement.

So to start we make our achievement tag: <achievement name="A Tale of Two Rockets" difficulty="SILVER">. Then we make our description: <description>Fire a rocket into another rocket.</description>. That’s the easy part. In order to get the functionality we need, we have to properly create our rules. The rule we are looking for here is called a COLLISION. A collision takes an operation and a list of items. We will be using the BETWEEN operation and our item types will both be ROCKETS.

Our rules will look like this: <rule type="COLLISION" operation="BETWEEN"><item type="ROCKET"/><item type="ROCKET"/></rule>. This is pretty intuitive. This XML reads as COLLISION BETWEEN ROCKET AND ROCKET. Pretty simple.

The full achievement looks like this:

<achievement name="A Tale of Two Rockets" difficulty="SILVER">
  <description>Fire a rocket into another rocket.</description>
  <rule type="COLLISION" operation="BETWEEN">
    <item type="ROCKET" />
    <item type="ROCKET" />
  </rule>
</achievement>

There’s one more thing we need to make sure of when adding our custom achievement. Within the XML file there are two entries: <entry name="User.Achievement"> and <entry name="User.Achievement.Completed">. By default the only entries in the achievement.xml file are in the User.Achievement.Completed entry. So to add our custom achievement, we will have to make a new entry for our non-completed achievement.

The final file (with a completed achievement) looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<settings>
  <entry name="User.Achievement.Completed">
    <achievement name="Get A Level" difficulty="BRONZE">
      <description>Starting from level 1, get to level 2 without
      getting a game over.</description>
      <date day="27" month="0" year="2009" />
      <rule type="START_LEVEL" operation="EQ" value="1" />
      <rule type="LEVEL" operation="EQ" value="2" />
    </achievement>
  </entry>
  <entry name="User.Achievement">
    <achievement name="A Tale of Two Rockets" difficulty="SILVER">
      <description>Fire a rocket into another rocket.</description>
      <rule type="COLLISION" operation="BETWEEN">
        <item type="ROCKET" />
        <item type="ROCKET" />
      </rule>
    </achievement>
  </entry>
</settings>

That’s all there is to it.

Hopefully you guys enjoyed this and will get to making or suggesting some custom achievements!