if(lots of conditions)
{
    doSomeStringCopies();
    if(a certain condition)
        doSomething();
        doSomethingElse();
    doFinalStringCopies();
}

Bear in mind that the consistency of indentation of the actual code was nowhere as nice as above.

Notice the problem? doSomethingElse() will be called irrespective of the secondary condition, resulting in bad things happening because a certain field does not contain a valid value for the doing of something else, but is entirely valid in terms of the business rule.

This is why you always surround your compound code structures with braces: because you never know when someone’s going to slide a “fix” into your code and neglects to add the braces. Several people (who have obviously never been burnt by this problem, and if they have, they should have their keyboard license removed from them) might think that bracing a compound structure which contains only one statement makes the code look uglier or more unreadable, but it definitely makes it a lot more maintainable.

(As an aside, I have a feeling that this is one of my more poorly written entries. Shame on me, I know.)

So, let’s start at the most basic iteration of the game itself, ignoring any details such as interface and representation. As I stated in the original article, the game can be summed up as Dope Wars in space. Thus, the mechanics of the game may be summed up as follows:

1. Sell any inventory so as to make a profit.
2. Buy more inventory at a low enough price to ensure a profit in the future (the nearer in the future and the higher the profit, the better).
3. Travel to a different location, repeating the process from step 1.

This process is repeated until a pre-set time limit is reached, with travelling using one time unit, and inventory actions being “free” actions. The end goal of the game is to amass as much wealth as possible within the time limit, in effect competing with yourself to better a personal best high score.

Each turn, the inventory prices are randomised according to a item’s base value and some measure of variance. The skill involved in the game then relies on the player’s ability to recognise the base values and variances of inventory items, such that they know when a certain item is at a “low” or a “high” price, corresponding to a “buy” or a “sell” on the part of the player.

To add an additional level of randomisation to the game, random events may be introduced that alter the player’s stock or money levels, or drastically alter the variation in prices. This may be implemented using non-uniform random number generation, such that smaller variations are more common than extremely large variations, which may well count for a mere fraction of the random number space, but may potentially yield vast gains for the player.

At this basic level, the game does not invite many opportunities for strategic play, since the game may effectively be “broken” if a player collects enough data about inventory prices, disregarding any random fluctuations/events. The next article in this series will outline some of the ideas I’ve had to expand the gameplay to make the game more interesting and challenging to a player.

Megatrader Main Menu

For the past week, when I haven’t been working, I’ve been spending a good deal of my free time developing a J2ME mobile game. The basic premise is Dope Wars in space, albeit with less drugs and more futuristic trade goods. The inset image is the main menu screen running in the WTK emulator. Right now, I’m more or less at the point where I can actually start on getting the game up and running, having spent the time thus far on getting all the support functionality down (such as drawing text using my custom fonts and being able to easily support different resolutions, since I’ll be targeting at least QVGA and QCIF+ displays).

Initially, the game will be fairly simple, featuring only simple trading: buy at planet A, travel to planet B and sell, rinse and repeat until the time limit is hit, with random price fluctuations as per the drug busts in Dope Wars. In the future, there are a couple of distinguishing features I want to add to the game, such as competing against computer-controlled traders and being able to buy different ships which affect their cargo space and travel speed, amongst other things.

Megatrader: Planet Screen WIP

For the ship travel speed to be meaningful, a distance matrix of the distances between the planets will be calculated at game initialisation, with the distance and travel speed affecting the number of days that elapse when travelling from one planet to the other. To make this an attractive option to the player, distant planets will have to have a higher bias for delivering higher yields (meaning prices are inflated or reduced more than normal), making trips to distant planets a potentially lucrative expedition, but on the other hand, may end up causing the player to lose precious time; and in this game, time is indeed money.

Another idea I toyed with was that of having a simple economy built in, especially if other traders are taken into account as well. If a trader reaches a planet before you and sells an enormous amount of one cargo, the demand will experience a sharp drop, causing the price to plummet. On the other hand, if you get to a planet and fill your ship’s cargo hold with a cargo type, supply decreases, and the price will increase to the next trader’s detriment.

An old favourite I’d thought about when designing an earlier trading game is that of black market goods. These goods perform a function similar to the distant planet idea, in that they are a potential source of a higher than normal income. Whereas distant planets are not guaranteed to have a higher price, black market goods will always fetch a higher price. The risk involved with black market goods is that the player stands a random chance of being caught by the authorities, resulting in the cargo being seized and the player receiving a hefty fine for their transgression.

There are a couple of other ideas on the whiteboard, so to speak, but for now I’ll be concentrating on getting the basics done and working, and figuring out the One And True game balance for the basic trade goods (i.e. pricing, fluctuation biases, etc.). Another thing that will limit the implementation of all these ideas is the possible limitations on code/data size on the mobile phone platforms: at the moment the QVGA version of Megatrader already weighs in 357KB. Most of the JAR’s size is caused by the background screens, which are rather varied in terms of their colour content. Since J2ME applications use PNG as image format, images that are not uniformly coloured and that do not feature consecutive strings of the same colour tend not to compress that well. Depending on how many screens I still have to add, this may or may not become an issue. If it does, I’ll have to drop a fair amount of the detail present in the screens, something I am loathe to do, since it’s about damn time we have a mobile Java game that looks good, for fuck’s sake.

Hopefully I’ll have a playable version of the game by the end of next week. And after that… well, maybe I’ll have a gander at that iPhone SDK. Or, considering I might be looking at getting a Windows Mobile phone soon, I’ll see what that old beast we call the .NET Compact Framework can do for the world. But that’s getting ahead of myself. I have to finish one version of the game first!

Terra: Full Heightfield

One of the homework assignments for our Graphics course was to implement a terrain renderer using a quadtree structure. After reading up on it a bit, I attempted to implement the method described by Ulrich’s article (although I won’t lie: the working demo code given in the article helped a good deal with that part). The image above is the end result of the terrain renderer, along with the quaternion-based camera library I implemented for the previous assignment.

Terra: Wireframe Heightfield

The random terrain in this example was created by generating a 1024×1024 image in GIMP using the Solid Noise filter and saving it as a PNG, which Terra uses to generate the heightmap. The image used to texture the terrain was created by applying a gradient map to the grayscale heightmap, and adding an embossed version of the grayscale heightmap on top of the gradient mapped heightmap to give the illusion of a directional light source.

The inset image is the same scene as the first image in this post, but rendered in wireframe mode. If one looks closely, one can see how the adaptive quadtree algorithm uses more triangles for high-detail parts of the heightmap, and less (”bigger”) triangles for less detailed parts.

Finally, the last image below is also the same scene as the other two images, but with a detail factor 2¼ times higher than the first two images, also rendered in wireframe, highlighting the increased number of triangles.

Terra: High Detail Heightfield

Enter Selenium. More specifically, the combination of Selenium Remote Control (RC) and PHPUnit.

Selenium RC is a Java server application which launches instances of the browser(s) you specify, and then puts them through the paces of the tests that you define using plain old PHP and PHPUnit, checking the assertions you define. In other words, you get the effect of a real user using a real browser, without having to do all the grunt work yourself. Win-win.

The current version of Selenium RC (henceforth referred to as SRC) I’m using (version 0.9.2) works like a charm, but requires a small tweak to work with Firefox 3. When SRC instantiates a new instance of Firefox, it creates a temporary profile and installs a Selenium extension into the profile. This extension’s maximum Firefox version is still set to the Firefox 2 versions, so it will silently fail under Firefox 3, leaving you to gnash your teeth in frustration while you sift through Google to find out why the damn thing isn’t working.

Fortunately, the fix is simple. It involves unpacking the selenium-server.jar file, and changing the install.rdf located under the customProfileDirCUSTFF directory, so that the maxVersion element contains the value 3.0.* to work with Firefox 3.0.

From there on, you can either pack everything up again into a new JAR (which I didn’t bother with), or simply run the server in its unpacked form.

Next time, I’ll dish up a small sample of how to actually go about doing that funky thing we call testing with Selenium RC and PHPUnit.

Running the detector with the -O2 optimisation flags yielded the following statistics:

pcronje@gecko modelchecker $ mpirun -H localhost ./deadlock -q -q
[0] Resource usage statistics:
 * Store memory (bytes) : 192000
 * User time   (work)   : 2.568160
 * User time   (total)  : 2.652165
 * System time (total)  : 0.008000
 * Page faults/reclaims : 0/1461

Switching over to -O3 yielded:

pcronje@gecko modelchecker $ mpirun -H localhost ./deadlock -q -q
[0] Resource usage statistics:
 * Store memory (bytes) : 192000
 * User time   (work)   : 1.520095
 * User time   (total)  : 1.604100
 * System time (total)  : 0.016001
 * Page faults/reclaims : 0/1463

Not bad. Force of habit running a Gentoo system makes me go -O2 by default when optimising.

Interestingly enough, running the deadlock detector across two systems yielded the following statistics (the number in square brackets indicate the process ID of the printing process):

pcronje@gecko modelchecker $ mpirun -H localhost,localhost ./deadlock -q -q
[1] Resource usage statistics:
 * Store memory (bytes) : 96000
 * User time   (work)   : 0.872055
 * User time   (total)  : 0.948059
 * System time (total)  : 0.028001
 * Page faults/reclaims : 3/1628
[0] Resource usage statistics:
 * Store memory (bytes) : 96000
 * User time   (work)   : 0.880055
 * User time   (total)  : 0.972060
 * System time (total)  : 0.008000
 * Page faults/reclaims : 7/1623

Obviously, the memory usage is neatly halved (since that’s just how the state generator I’m using to test this sucker works), but the interesting thing is the decrease in runtime. I would’ve thought that the communications overhead involved in throwing work items around between processes would’ve made the whole thing about as fast as swimming in tar. I guess the smaller memory footprint is making the difference when the analyser reads through the work item store or something. It’s something I’ll look at once I start properly evaluating the project.