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!