Let’s give it a last push and get the game released on the biggest appstore for PC and Mac gamers!

If we get released on Steam, I will commit to adding the following features to the game, which have been the main things that the players have been asking me for:

1. Making it ‘proper’ 3D driving, with..
2. Hilly/Offroad terrain circuits.. which can be sculpted in the track designer
3. Springy offroad suspension (see technical demo of this below)
4. Bridges
5. Customised, player-uploaded car skins

Here’s some details on the offroad suspension I have been working on: Shiva Raycast Car

You can also get it for Windows/Mac/Linux on the game’s website.
Hell, we even have a Facebook page

For the moment the big test is maybe the Android appstore, where downloads have been solid if not astounding. After a few days it’s now just breaking into the top 100 ‘new free racing games’ list – so maybe this will bring some increased traction. While the ‘new’ list on Google Play is a great concept, it’s always inundated with massively varied quality items, ranging from poorly designed wallpaper image apps (masquerading as games just long enough to spam you with adverts), to 200 clones of whatever lightweight crap is popular this month, right thru to high budget 3D racers. So getting some visibility even there isn’t always easy. The top ranking apps in the ‘new free’ lists are getting tens of thousands of downloads in a week or two, while getting to the top of the ‘paid’ list requires maybe 10 sales. Tells you something huh…

The Musclecar Online player-base is growing steadily; we’re currently getting a couple of hundred new downloads a day and by day-end we’re seeing upwards of 100 users posting laps in the more popular cars. The next couple of weeks will be interesting, and maybe we’ll see whether there’s any viral potential in the social features I worked so hard on!

The game is launching on Desura soon, and if you get a chance to upvote it on Steam Greenlight that would be most cool

Here’s a couple of screenshots from the new 3D camera viewpoint, added in version 1.3:

and here’s the most recent teaser movie made for the Android store:

The game is functionally almost complete at this stage, and we have been listed on indedb.com as well as being approved for distribution by Desura.com. I have pretty much decided it will be free-to-play on every possible platform, with monetization* via in-game purchases and (where appropriate) adverts.

*monetization: somehow that word only looks right with an American spelling. Lol.

After some research I have settled on node.js as a good solution. It’s very well regarded, largely due to its non-blocking, asynchronous model. This essentially means that anytime a resource is required (such as a database recordset) the request goes into a queue, to be called back when the resource is retrieved. In Apache, the model is blocking – the process sits and waits for the resource, thereby stopping any other activity.. this is why Apache needs all those independent processes, so that it can serve multiple clients simultaneously.

The game I have been working on is ‘Musclecar Online’ – a top-down racer in which players build their own tracks, vote on them, and then everyone in the world races on the same track-of-the-day. Rather than being real-time, you race against the ‘ghost lap’ recordings of other players; kinda like Speed Racer

Cache stuff in RAM

Linux has a server’s approach to the file system, of course, which means it uses all available RAM for caching disk files and such, but I figured it would be even better to make liberal use of Javascript arrays (which are really hash tables.. excellent for key-based lookups). So the server packs up canned responses into strings, as much as possible, ready for delivering over the interweb with no fuss or processing. This includes:

a 5-day pack of track layouts, allowing the players to see what’s coming up over the next few days;

per-cartype, per-second frequency bins, succinctly providing the data needed by the client to display a histogram of worldwide laptimes and point out where the player stands versus these;

a temporary array of ghost lap recordings, hashed by user ID for easy over-writing when they improve. This is only used up until 40 players have recorded laps for that car type on that day’s track, and allows random ‘unclassified’ packs of ghost laps to be delivered to players without the need to bother MySql about it;

more long-term packs of ghost lap recordings, separated into 6 divisions (F thru A) – the idea is that the player starts off racing against poor ghosts, labelled as division F, and if they beat these they are allowed to progress to division E, and so on. These longer-term packs are re-generated periodically, but not for the first time until 40 recordings are available for the car type.

Don’t fall into the ORDER BY RAND() trap

I have done some pretty naive stuff in MySql in the past, but running Darkwind for the past 7 years has helped me understand efficient database design and querying. With the characters, vehicles and weapons tables running into the millions, I was forced to. One of the newbie gotchas in MySql is to avoid doing a massive SELECT statement with ORDER BY RAND() LIMIT 1 in order to get a random record. If you do this, you’re basically asking the database server to load an entire table into memory, apply a random number to each record, sort the whole damn thing, and return one row. There’s a few obvious solutions, depending on how well distributed the data in your index fields is. One simple way is just to find your data range (e.g. laptimes min and max), generate a random number in this range, and then SELECT the first row greater than or equal to this laptime, LIMIT 1. Assuming laptimes is an index field, and also assuming there are enough records to make a reasonably even distribution across the data range, this works nicely.

Interesting asynchronous design solutions

Now, I love callbacks as much as the next man, but it can be an old-fashioned PITA sometimes trying to work with asynchronous coding. In a nutshell, anytime you want a resource that may be delayed (database query, file read etc.) you can’t use a traditional flow of control, can’t use loops for multiple accesses, etc. One of the things I have to do in the ‘Musclecar Online’ server is build packs of typical ghost lap recordings, in order to pack them into strings ready for dispatch to the clients. This means querying for each row with a separate SELECT statement, and therefore means 11 car types x 6 divisions x 5 different packs x 4 ghosts per pack = 1320 queries. Embedding each query inside the callback of the previous one certainly isn’t an option, but with a little thought I settled on recursion; a perfect way to unravel the asynchronous tangle. This works nice and efficiently, while still operating in serial (and therefore not choking up any server resources) and allowing nice tidy code. It’s kind of strange I didn’t see recursion mentioned as a solution anywhere on the web while researching node.js. Well, maybe I didn’t look for too long.