The Dating Game (or, as it was called when released in the US, "The Love Game") was another WAP based game. Well, I supposed technically it wasn't even really a game. It was a social networking application with a bit of a game thrown in. Again, written in Perl, the codebase was huge in comparison to the triviality of Dial-A-Word, and I've got to admit I made quite a few poor design decisions when developing it.

As you can see, we were also straying towards the concept that phones might start having colour displays in them! Oh my word! Of course, almost none did at the time we made this game, but coloured artwork was created anyway (there was the possibility of playing the game via a normal web browser as well, so it was kinda needed)

At its core, users would log into the Dating Game server and create a persona for themselves. A handful of questions about their gender and personal preferences (would you prefer getting a new computer, new shoes, new alloys for your car, etc.) and the game assigned the player a character type and a set of statistics. Then, through the game, the player could search for 'matches' and the game would then allow the players to send messages back and forth (in game, not through SMSs) with them. There was some additional hooking into some other services (e.g. the game could send you a text message if someone matched up with you), but at its core this is all the game was. Essentially, an anonymous chat service where users could talk with other users without the worry of making their phone numbers public or the other person knowing anything really about you - unless you personally wanted to share that information with them.

Personally, I made a huge mistake in setting up the player info backend. I didn't hook into a standardised database system, so the player data was stored in a rather awful manner. This really surfaced when the game was adopted by one particular carrier and thousands of people ended up joining and playing. The server load just spiked (especially in some pretty key areas, one of which being in the match detection code where I was foolishly going through the entire userbase to find matches instead of trimming things down a little), and years later the backend ended up having to be totally reworked (admittedly, the application was also being rewritten as a J2ME app at the time, but nonetheless - it was a poor design decision on my part).

Thankfully, this was my last major Perl based server backend I had to write. And I must say, I don't miss writing Perl one iota.

There was another cute element to the game though, and this was the idea of virtual dates. When you were matched up with someone you could get the game to send you both on a virtual date and report the outcome. The application would pick one of a set of pre-defined date locations (restaurant, circus, winebar, ...) and depending on the stats of the two characters going there the date either go well or devolve into a total fiasco (e.g. if the player's "manners" statistic was low they may turn up late for the date, or if their "athleticism" statistic is low they may end up getting hit by a bottle by the cocktail juggling barman). All the scenarios was hugely outlandish and comical and even a 'successful' date seemed more like a farce, but they were all humourous and added an extra element that players could talk about.

After the Dating Game, Cam and I ended up toying around making a golf WAP game, a combination of artist-generated animations and server created top-down and 3D views. And all in glorious 96x65 black and white. Little did I realise that this would result in 2 years of my working life spent creating 10 different mobile golf games over the coming years...

To start with, I wrote all the server code again in Perl (ick), and the course data was fictitious and completely unbranded. However, based on that, John was able to secure a deal with Digital Bridges, who at the time were looking to fill out their portfolio of WAP based gaming titles. To fit in with their player database server backend, the application needed to be rewritten in Java, a language I was unfamiliar with at the time. Nonetheless, we dived on into it, and it actually turned out to be a really useful stepping stone with (unknown to us at the time) J2ME and ExEn turning up a year or so later.

So, off I went to rewrite the server backend in Java. Looking back at the codebase now it's a mess of object orientation that (in my later years) seems total overkill. But it worked, and that's the main thing. However, how were we going to import the course data from Wentworth? Wentworth consists of 2 courses (East and West), and the data we had to reference was really just some basic overhead course maps (the kind you might find in a golf card from your local course). As a result, we ended up just mapping that directly into a database that the code referenced. Want to see what one of the short par 3's looked like when stored in the database?

;;;;;;;;;;;;;;OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO###################################################
;;;;;;;;;;;;OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO#################################################
;;;;;;;;;;;OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO################################################
;;;;;;;;;;OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO##############################################
;;;;;;;;;OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO############################################
;;;;;;;;OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO#########################################
;;;;;;;OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO########################################
;;;;;;OOOOOO;;;;;;;;;;OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO########################################
;;;;;OOOOOO;;;;;;;;;;;;;;;;;;OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO#######################################
;;;;OOOOOOO;;;;;;;;;;;;;;;;;;;;;;OOOOOOOOOOOOOOOOOOOOOOOOOOOOOO####################################
;;;OOOOOOO;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;OOOOOOOOOOOOOOOOOOOOOOOOOOOO###############################
;;;OOOOOOO;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;OOOOOOOOOOOOOOOOOOO###########################
;;;OOOOOOO;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;OOOOOOOOOOOOOOOOOO#########################
;;;OOOOOO;;;;   ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;OOOOOOOOOOOOOOO########################
;;OOOOOOO;;;; T ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;OOOOOOOOOOOOOOOOOOO####################
;OOOOOOOO;;;;   ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;OOOOOOOOOOOOOOOOOOOOOOOOOO#########
;OOOOOOOO;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;OOOOOOOOOOOOOOOOOOOOOOOOO########
;OOOOOOO;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;OOOOOOOOOOOOOOOOOOOOO########
;OOOOOOO;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;OOOOOOOOOO#######
;OOOOOOO;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;OOOOO######
;OOOOOO;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;    ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;OOOOO#####
;OOOOOO;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;       ;;;;;;;;;;;;;;;;;;;;;;uuuuu;;;;;;;;;;OOO#####
;OOOOOOO;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;        ;;;;;;;;;;;;;;;;;;;uuuuuuuuu;;;;;;;;OOO#####
;OOOOOOO;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;           ;;;;;;;;;;;;;;;;uuuuuuuuu;;;;;;;;;;;#####
;OOOOOOO;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;                        ;uuuuuu          ;;;;;#####
;;OOOOOOO;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;                        uuuu     65559    ;;;;####
;;OOOOOOO;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;                      uuu    65556689   ;;;;####
;;OOOOOOO;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;      a                  5555666889  ;;;;####
;;;OOOOOOO;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;                       555556778889  ;;;####
;;;;;;OOOOO;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;                    555666788889  ;;;####
;;;;;;;;OOOO;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;                   555666777889  ;;#####
;;;;;;;;OOOOOO;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;                 5556667_7889  ;;#####
;;;;;;;;OOOOOOOO;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;   ;;;;;;    665567777889  ;;#####
;;;;;;;;;OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;    776667778899  ;######
;;;;;;;;;;;;OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO;;;;;;;;;;;;;;;;;;;;;;;;;;;;;   877778888999  ;######
;;;;;;;;;;;;OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO;;;;;;;;;;;;;;;;;;;;;;;;;;;    8788888999  ;;######
;;;;;;;;;;;;;OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO;;;;;;;;;;;;;;;;;;;;;;;;;;;  99888999   ;;;######
;;;;;;;;;;;;;;;;OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO;;;;;;;;;;;;;;;;;;;;;;;;;;;;  9999999  ;;;#######
;;;;;;;;;;;;;;;;;;;;OOOOOOOOOOOOOOOOOOOOOOOOOOOOO;;;;OOO;;;;;;;;;;;;;;;;;;;;;;;         ;;;;#######
;;;;;;;;;;;;;;;;;;;;;;;OOOOOOOOOOOOOOOOOOOOOOOOO;;;;;OOOO;;;;;;;;;;;;;;;;;;;;;;;      ;;;;;;#######
;;;;;;;;;;;;;;;;;;;;;;;OOOOOOOOOOOOOOOOOOOOOOOO;;;;;;OOOOOO;;;;;;;;;;;;;;;;;;;;;;   ;;;;;;;########
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;OOOOO;;OOOO;;;;;;;;;;;;;;;;;;;;;;;;;;########
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;OOOO;;;;;;;;;;;;;;;;;;;;;;;;;#########
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;#########
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;OOO;;;;;;;;;;;;;;;;;;##########
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;OOO;;;;;;;;;;;;;;;;;;##########
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;##########
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;##############
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;########################

Ahahahaha - I suck! Ahem. That really isn't how I'd consider storing the data these days. But anyway, so we had the 36 holes of data in the codebase (and note - we even had slope information on the greens), so it was time to create the 3D and top-down renderers. Well, most the work I'd done in my Perl prototype original was applicable here. As the course had no height data, actually working out 3D projection information wasn't a huge problem, however don't forget - we're working in a tiny res and with just black and white here. There's only so many dither patterns you can use.

I think we did rather well. And combined with hand-drawn horizon strips and trees in the 3D views, and Cam's great hand-drawn animations for transitions, the product was pretty good, I thought. Okay, so there wasn't an enormity of game play options or 101 different modes, but for a WAP title I was pretty proud of it. Oh, how times have changed.

Everyone came away after Wentworth Golf pretty satisfied with the end result. As a result, Digital Bridges commissioned us to create another WAP title for them. WAP had been around for a while then and it was already looking like potential WAP sales were reaching their peak and could only suffer a decline from then on, but we were more than willing to continue the good relationship we had with DB and create them another product. But, what can you do in WAP with the Thunderbirds license that they offered us?

Our solution? A combination of different sub-games that the player could dip into and play. Players would end up getting assigned a rank based on the game they were best at and their scores listed in global hi-score tables.

To start with, the player is shown a top down 'scanning' view of the earth from Thunderbird 5 (the orbital space station) and as the player watched, hotspots would be shown indicating calls for help from the Thunderbird crew. Any missed calls would count as a penalty on the player's communications ranking. Depending on whether the indicator was in the mountains, trees or water, the player would then procede to one of the 3 core sub-games.

In the mountains, the player would need to move the Mole (one of the Thunderbirds vehicles) around, trying to hunt down trapped miners. The player only had a limited amount of moves and had to enter moves in continuous chains (e.g. left, forward, forward, right, drill, forward), and time could be burnt away having to mine through rock to reach trapped people. Additionally, the Mole was automatically moved when on certain (sloped) surfaces. Now that I think about it, the game has quite a strong RoboRally feel to it. I guess this isn't surprising as Glenn always was a big fan of that game.

Underwater, the player had to reconnect some power-supplying lasers (I can't recall the in-game reason why). Basically, this boiled down to be one of those laser reflection games where you have to place mirrors, teleporters, light generators, and the like to make the laser beams go from one place to another. We spent quite a bit of time creating levels for this and I remember some of them were really quite nasty.

And in the woods, the player had to stop a rampaging logging machine (based on an incident in one of the actual Thunderbirds episodes). Here, the player is presented with a 3D view (yep - we stole some of the code from Wentworth) from the front of a Thunderbird's cannon which the player could slowly move around. Points were penalized if the logger destroyed the nearby buildings or if the player caused too much damage before shooting the logger apart.

And every so often the vicious Hood would seize control of Thunderbird 5. The player would then need to play an additional number-memory game to break into the striken space station and reclaim control of it.

All in all, none of the games were anything amazing, but as a combination I think the end result was actually quite impressive for a WAP game of its time. I remember attending a press presentation of it up in London when we'd completed it and the turnout seemed quite small. For me, I think that was the final acknowledgement that WAP really was on its way out and that we probably need to start looking at other stuff.

However, I do still have a blow-up Thunderbirds chair that I got from that presentation at home somewhere...

(For you Americans, that's "soccer")

The first downloadable mobile application that I ever wrote was actually in ExEn. Of course, we're still dealing with black and white handsets here (colour would be quite a while coming for mobile app's), but now we're not dealing with a slow client-server interaction where data is fed down to the user in tiny 1KB chunks. No! Now the player can actually download the entire game on their phone and play it in real-time! What a revolution.

Of course, things aren't always that simple. Firstly, well, the game's got to be downloaded onto the user's phone. What does this mean? Well, back in 2001 most operator portals were designed for the sending of text messages and tiny amounts of data. On top of this, handsets weren't the hundred-Megabyte monsters that already seem so blasé these days. Oh no! As a result, the entirety of my first mobile game needed to fit in under 60KB (a positive luxury compared to some later projects, I must admit). That's 60KB for all the code (which is Java, don't forget, so only has so much room for optimisation), text, font, graphics and animations... everything! This was a BIG change from my previous projects where everything could be server hosted and you were just limited by how much hard drive space was available on the server.

So what did they actually want in their 60KB? Nothing too extravagant, I hope?

No such luck. The final game ended up with 8 different subgames in it (a drop from the original 10 that they wanted):

• Taking corner kicks (picking angle and power to try and get the ball to hit the player near the goal, then if successful choosing the jump direction to try and header the ball in)
• Counter attack (where 3 players run up the pitch and the player passes between them to avoid tackles and get a shot on goal)
• Dribbling up and down the pitch, slaloming between pair of cones, a new set being added for each length of the pitch the player succeeds in travelling
• Juggling the ball (rhythm bouncing it off the player's head, knee, foot, or backkick)
• Passing from midfield to a player running up the pitch (another direction and power guaging game)
• Weaving down the pitch side to side and shooting for goal in an attempt to outwit the AI goalie
• Penalty taking (direction, power and spin in an attempt to outwit the goalie)
• Penalty saving (a reverse of the previous game)

And the games didn't even all have the decency of sharing the same sprite sets, so we had several different sizes of graphics for stuff in amongst all that lot.

On top of this I found out that with the ExEn handsets they either had a nice contiguous block of memory that you could request arbitrary chunks from, or you had to dictate at application start up the pre-defined sizes of all the memory block allocations for the entire runtime of the application, within which the underlying JVM would return the best fit of whenever asked for memory (a real world analogy for non-tehcnical people would be like going shopping with just a 50p and a £5 note in your wallet and finding out that if you wanted to spend £1 on something that you'd have to spend the whole £5 and not get any change). And the game had to work in both modes.

I have to say that the game did teach me a LOT about Java optimisation techniques. Optimisation is something I always liked the idea of (I spent ages when we were doing Stampede optimising methods and profiling CPU usage to find our bottlenecks), but when you're given big systems to run on you can easily fall into the habit of getting sloppy. On small handset mobile development spending half an hour saving 30 bytes on your binary size may be a crucial and worthwhile activity. As a result, all of my nonsensical object-oriented approaches that I'd stuck with on the server hosted games went right out the window, all the code in one runtime class, and I started to enter the territory of unreadable code and magic numbers (the end result of a slippery slope you can go down when worrying about optimising too much)

Fortunately, no-one other than myself had to really look at the codebase, so this does allow a little bit of leniancy with regards how messy you can make things. Looking back at the codebase now, I can immediately see several areas where I could have optimised further, but I'm actually surprised that it's not worse! You'd think years and years on there would have been a ton of things I would do differently, but there aren't really. ExEn forced quite a lot on you those days as a developer and as a baptism of fire it obviously did me a lot of good.

Having said that, however, I hated that codebase when I was finished with it. I do remember being quite proud of the penalty-kick goalpost / ball collision code though - completely unnecessary physics model in there to kinda model the curved surface of the post and crossbar and deflect the ball appropriately. It did mean the ball could sometimes bounce off the goalie's feet, hit the underside of the crossbar, then ricochet into the net, which I thought was cool physics in a game so tiny. I doubt anyone noticed but me, however...