So, this entire weekend (and last weekend) has been spent living up to the promise I made about sitting down and focusing on the graphical client work. When last I looked at it, it was a crashy mess, causing hard lock-ups of Unity because of mishandled threads. It would load in a packet of information from the hard-drive, and use that to build up a game map that you couldn’t do anything else with. It was a far cry from where I’d gotten with the first Java version. So I spent last weekend getting the threading and communications up and running, and this weekend getting graphical representation of diagonal directions working. These are the most difficult things to do properly, at least as I felt it when working on the first prototype. While they’re not yet perfect they are solid enough to let you see how it’s going.
So, first of all we have a provisional name for the client. We have Epiphany for our mudlib, Epitaph for our game, and now Eidolon for the front-end, drawing from the Greek definition of an ‘image, phantom or ghost’. It’s not set in stone yet, but I like it and unless inspiration strikes me it’s unlikely to change in the short-term. So when I say ‘Eidolon’, this is what I mean.
So, what does Eidolon do? Well, it:
- Connects to the MUD and negotiates login.
- It sends information to the MUD and pulls information out in the form of special XML ‘client packets’ that strip out all the usual in-stream formats.
- It parses these XML packets and distributes the information through the various client subsystems.
- It takes flat text maps (which you’ll see in a second), and creates 3D world representations of these
- It creates representations of doors, diagonals, and intersections of diagonals that look (relatively) clean and visually parse-able.
- It permits you to wander around the world with the arrow keys, and will before too long permit you to do the same with a game pad.
- It lets you chat on a particular channel (at the moment, our little use ‘code’ channel) and shows the discussion that’s going on.
- It lets you send any arbitrary string of command text to the game.
In terms of what it lets you do when you log on, it’s limited – but all of that hangs off a reasonably intricate combination of architectural elements that allow for new features to be added cleanly. It’s not quite yet where the first prototype was, but it’s much better designed internally and hooks into all the Unity libraries in a way that means development will rapidly outpace what could be done in Java.
So, what’s the biggest feature here? It’s the map rendering. Every time something changes in the game, we get a new ‘packet’ of information sent to us containing the things that have just been modified. That contains a map which looks something like this:
0000000001111111000000000 0000000111111111110000000 0000011111111111111100000 0000111111111111111110000 00011111111111111111*1000 0011111111111111111/11100 001111$-1111111111*111100 0111111\111111111/1111110 01111111*111*111*11111110 111111111\11|11/111111111 1111111111*1*1*1111111111 11111111111\|/11111111111 111111111111@111111111111 1111111111111111111111111 1111111111111111111111111 1111111111111111111111111 0111111111111111111111110 0111111111111111111111110 0011111111111111111111100 0011111111111111111111100 0001111111111111111111000 0000111111111111111110000 0000011111111111111100000 0000000111111111110000000 0000000001111111000000000
This is generated from the MUD side from the ASCII mini maps that you guys can already make use of. It then has to turn this into a 3D grid, positioning the player appropriately and representing exits and the like in a way of which the player can make visual sense. So, that above becomes:
It’s the diagonals there that have been the hardest thing to get working properly, because it’s somewhat more intricate than you might expect – it involves a lot of turning cubes into prisms, rotations and scaling and then hiding some occasionally when certain intersections of direction occur. It involves a degree of spatial awareness of units of representation, taking into account what’s happening not in the current cell being rendered but in all the cells around it. And sometimes things that happen elsewhere override things that happen where we’re currently looking. It’s a pain the hole, in other words.
The display you can see above was a testing rig set up to let me play about with the intersections of exits without needing to change the game geometry, so let’s look at how it functions in the game. Let’s say we start off on Alphabet Street:
| | + | + + + + + + + + *-$-$-$-*-$-@-$-$-*-$-$-* \ + | + | + + + + + |
Which turns into this:
And this in turn gets rendered into the following front end:
I know it looks pretty bad at the moment – I will at some point buy a decent texture pack and make it all look spiffy, but for now I’m focusing on getting it doing what it should. Literally all I’ve done so far is grab a random image of a wall, a random image of a door, and bang the two together. But that’s not the point, the point is – YOU CAN WALK DOWN ALPHABET STREET IF YOU LIKE. You can explore the whole city! Check out this exciting video!
Having reached this point, what time I have left this weekend will be spent on bug-fixing – there’s still going to be a patch at the end of the month even if it’s just a maintenance one. Hugo is busy working on things, as is Woe, so it’s not like the game has to tread water until this is done.
The feature wish list I have for Eidolon is pretty long – dynamic weather effects, sound and animation, support for plug-ins and more. Version 1.0 will probably be a fair bit more modest, but this is the thing that’s going to take us from Epitaph 1.2 to Epitaph 2.0 and then beyond. As such, if you have things you’d especially like to see it support, then let me know. I won’t be in a position to do much other than note them for a while, but note them I will.
CATCH YOU ON THE FLIP SIDE,
 Which I looked at again recently. Man, I had poured a lot of work into that.
 Still a little buggy, but so much better than it was..