←

Something I’ve been working on alongside the other 1,407 things in the pipeline…check back often for updates! Cursor keys or WASD to move, space to fire, and page up/page down to change your ship’s speed. I’ll let you work out the rest for yourself 🙂

Oh, and click somewhere inside the game to enable control!

Play at half size or full size.

I doubt most of the people who’ve found my blog realise the rotates.org history of pretty-but-useless splash pages. Essentially, the original purpose of this site was to display my current ‘cool thing’ that I’d created. It’s actually a huge passion of mine and great fun to knock something up in a few hours that looks really nice and is uncomplicated and pretty much pointless. I suppose that fits the bill of ‘art’ – thankfully I’m not so pretentious that I’d label it under that banner!

Anyway, after a major hiatus, I’ve created a new ‘splash page’ (for that is all that it is, and will likely ever be) for the online gaming clan I’ve been a member of for 10 years:

www.clan-sqs.com

Really, there’s nothing to discover, it’s exactly what you see. I’d love to have the patience and the skill to work on something akin to Windosill but alas it doesn’t slake my desire to see instant results. If you’d like to see some of my previous splash screens, you can view them here.

I hope you enjoy these little bits of my history – I’m hugely proud of all of them, and they serve to really show how I’ve come along in my profession as a web designer.

P.S. I’ve spent the night drinking Leffe Blonde and listening to Devin Townsend – Ziltoid the Omniscient – awesome 😀

… or lack thereof! Sorry about that, but I’ve been incredibly busy with work recently and I simply haven’t had time to work on my own stuff. I promise in the next few weeks to start releasing some less vaporous material!

Now, back to the grindstone…

Dear Apple,

First let me say I love your iPhone, and I admire what you’re doing in the gadget market – it’s simply brilliant work and I’m behind you 100%. I do however have one small request:

LET ME TURN THINGS OFF.

Not in the next version – NOW. If you introduce a feature, have the common sense to realise there are some people in the world who would like to toggle that feature. When you implemented say, the repeat message alert, did you think there may be occasions when a user may not want to be reminded that he or she’d received a text at 3am in the morning, and their iPhone is in its dock on the OTHER SIDE OF THE ROOM, and so that means getting out of bed and looking at the damn thing just to shut it up?

Oh and you didn’t just slip up with the iPhone. What about when I’m using remote in iTunes? Say I want to have iTunes hidden well away in the system tray while I’m working on my PC (and I don’t want to look at it because its interface makes me cry) and then I may decide I want to pick a tune from my songs playlist. Why does iTunes have to pop up to say hello? If I minimised it, and I’m controlling it via Remote, is there ANY good reason why it has to appear on my screen? Just let me keep it minimised where I want it Apple, it’s not a big ask!

I understand that in many cases you know best, and you invent novel – nay genius ways to interact with your products – I’d just like the ability to once in a while be able to choose to use some of these features.

Cheers,

Lew

I’m sure it’s not just me, but I’ve found that sometimes some of the most difficult and profound decisions you make on a project only occur when you’re half way through writing it. It’s monumentally difficult to work out the specific heirachy of classes in advance (especially when you’re trying to write something modular) and sometimes you just have to write the damn thing before you realise where things actually should go!

The current project tree

So as I tapped away this afternoon, I realised I’d reached a critical point where I was starting to introduce messy hacks to send messages down and back up the chain of command undergoing several changes along the way – it’d stopped being efficient and had I gone any further with it, it’d have become a big nasty mess. At this point what’s needed is for some of the core classes (notably the game, board and renderers) to be refactored and reimplemented. Thankfully as it turns out this isn’t a large job (another huge benefit of observing OO best practices) and things will once again be going smoothly very soon.

Also, I have to thank each and every one of the people who’ve commented, emailed and otherwise shown interest in this project. It’s a great boost to the old morale to know it’s not only myself who’s excited about playing it! I’d like to take a few moments to clear up a few questions I’ve been asked:

• Will there be a beta test? Can I be a tester? An online game is obviously going to require people to help iron out the bugs, and so yes, there will be phases of testing throughout the lifetime of the project (as new features get rolled out for instance – hint hint) and when that time comes, I’ll announce it. The iPhone version will be a different matter, as Apple are (understandably) tight about running code on other people’s devices. As such, when the iPhone version is ready to be beta tested, the only people who will be able to participate are those who have an iPhone development license themselves. Again, I’ll release more information about this at a later date.
• How different will your remake be from the original? This is something I’m very conscious about – basically, Julian knew what he was doing when he created the original. It’s a formula that works through and through (obviously, as people are still playing it!) and I don’t want to tamper with it in any way. However I also see a lot of scope for expansion of the concept (though I might add not to the level of even Lords of Chaos, which I felt over-complicated the game somewhat) with the likes of new spells, new units and so on. It’s important that any changes I make are optional and modular – in fact ‘modular’ has become my mantra for the whole project. I’m by no means the authority on Chaos and its mechanics, and so I’ll leave such things open to tweaking.
• Why isometric? It’s just so cool! Don’t worry though, there’ll be a traditional style renderer out of the box too!
• Can I contribute? At this very precise moment, I’m afraid the answer’s no. My plan is to get the game into a playable and respectable state, and then make it open source. Besides I’d not wish to unleash my ghastly uncommented, undocumented alpha-quality code upon anyone else right now. I’ll make one exception however; if any talented pixel artists wish to update the original unit graphics (and maybe other graphics) then I’d be very interested in hearing from them. As nice and retro as the original sprites are (even the fettled ones I used for the old Flash version by Richard Phipps) I have a funny feeling that it’s only nostalgia that’s making them acceptable to current eyes…
• What’s taking so long? Several things; my desire to get it absolutely right, my commitments to my real life job, my recent weekends spent in the company of my mates and my camera, my evenings spent watching Richard Dawkins on YouTube and working out a way I can apply all that evolution by natural selection stuff to the AI (I jest not!) and the occasional bout of Killing Floor or Left 4 Dead. Be assured this project is not about to disappear, I (hopefully) won’t suddenly be dragged away by ‘real life issues’ and my hard disks and backups won’t miraculously explode.

And now back to the music…

I finally managed to contact Julian Gollop after a bit of detective work, and his feedback has left me elated. They say never meet your childhood heroes, but I think for the first time that rule has proven to be incorrect – he’s an absolutely top bloke, and I have total respect for him.

All of this of course means that I now have the answers I need, and the green light to really take this project somewhere very interesting indeed. I’ve not been very subtle or secretive, but for those who’re just tuning in, here’s a pic:

As I continue writing convienience classes for my Chaos project, I’ve put together something which (with a bit more testing) would be very handy for general AS3 development. It’s a simple to use class for querying an array of objects and returning the results as a new array. You can use it to recursively filter the objects by their properties until you have the ones left that you want – and yes I know about Array.filter but it’s much more usable and cleaner than that!. I’m using this to allow easy access to the units on the board (and I’ll more than likely be using it for the spells and other data structures in Chaos) – but as it’s a very universal piece of code, I think it deserves a place on its own. Keep your eyes peeled in the coming days!

Last night I began to put a polish on the classes I’ve been labouring over for the past few months. The reason I’ve been labouring is that I’m trying to write this game in a way that makes netplay easy to implement. One of the biggest hang-ups has been on the role of a server in the whole thing, and how the data gets to and from it.

A big problem with HTTP and subsequently most of the technology designed around it is the lack of persistence. Simply put, when you visit a webpage, the server will fire up its processing engine, initialise all its variables and objects, read stuff from the database, process your request, then clean up after itself. This is fine for 99% of the things you’d do on the web, but when making a semi-realtime game run over this system, it becomes horrendously inefficient. By contrast, most games will load all the data into memory and it remains there in a persistent state, occasionally being altered by the course of the game.

So, if you want to make a game that runs online, you have an extra layer of complexity to think about in that you have to ‘serialize’ the game’s state into a format that can be sent over the internet to the server, then the server will ‘deserialize’ the data, process it, save it to its database, and serialize a response to send back. There are a few APIs available which handles these sort of operations quite well, but it’s still a complex thing to monitor.

Of course, you could do away with the server altogether (although this isn’t usually an option for a web app), or reduce its task to simply routing the data to wherever it needs to go. There are a few big problems to tackle with this however:

1. Cheating – without a server, this means every client is doing its own verification of valid moves etc. Someone could fairly easily exploit this and send invalid moves.
2. Synchronisation – with no centralised game state to reference, clients could get out of synchronisation.

The answer to both of these problems would be to perform validation on all the clients, so that everyone’s client would have to agree the move is valid within the context of their stored game states in order for it to be passed. This has its own problems of course, as it’s dependent on latency and consistency between client versions, and may make the game feel slow and laggy.

So after much deliberation about how to do it, I think I’ve finally found a way to handle server-driven games. The abstraction between the game data format and the renderer means that I have a very clean set of objects to represent games. By recreating this in C++ or Java on the server side, and using JSON to represent the objects and their properties as they’re transmitted from client to server and back again, I can build up a persistent remote version of the game on the server. Once a game is running, I don’t have to worry about storing and retrieving the data across requests, which eliminates much of the overhead. So the sequence of events that occurs when a Horse moves from tile A to tile B is as follows:

1. The server tells all players that the game is in a movement phase, and tells player 1 it’s his turn
2. Player 1 selects his Horse and tells it to move to tile B
3. Player 1’s client works out the path to tile B (it’s more than one tile away so it requires the most efficient to be worked out)
4. Happy with the path, the client sends the server some data, namely the player ID, unit ID and each step of the path in sequence. It also presumes the move to be correct and shows the updated position (this is called client prediction, and is very important in online gaming to produce a responsive interface – the chance a move will be legal will be many, many times more than the chance a move will not)
5. The server receives the request and checks against its own version of the game to see if the unit can make this move legally; it double checks the path.
6. Having verified the move is legal, the server sends back the player ID, unit ID and its final position.
7. Player 1’s client receives the validated move.

Of course, if the move is invalid, the server will send back a rejection, with the player ID, unit ID and its original position as defined on the server. The client will then move the unit back and display an error. It should be noted that invalid moves will be next to unheard of as long as the server and clients are functioning correctly, and are there essentially to combat cheating.

Finally, to combat disconnections or to simply allow the game to be played over a long period of time and over multiple platforms, the server can send an entire representation of the game to the client to get it up to speed.

In closing, it’s a lot of effort to get a game to work over the internet, but it’s worth it to be able to live out that long held fantasy of playing Chaos with your mates – no matter where they are…