Eidolon 0.2.0

My progress on Eidolon hasn’t been as significant as I would have liked – the new semester has started, and as usual that’s meant that I have less time in the evenings and weekends to work my way through my todo list. That’s not to say progress hasn’t been made, just that I’m not where I want to be. This is what we’re looking at now for the client:

new_eidolon_1

So, what’s been done over the past few weeks? This is the set of new features:

1) Saving! There’s now a saving system in place for client settings, which means that it’ll remember positions of windows and anything you’ve done to configure the interface. That was more trouble than you might think, because Unity’s serialization system was written by an angry God that hates mankind.

2) Action bars. There’s now a set of action bars at the bottom right of the screen, and you can use these to give yourself some quick action commands which also respond to key presses. Currently these are set by typing in a command to the main input bar and right clicking on a button, but that’ll change later.

3) Selectable icons. You can now click on items in the immediate meeple tray and ‘select’ them. Then, any command that uses the text $selected$ will use that target when you hit an action bar. So, ‘crush $selected$ with weapon’ will become, for example, ‘crush hugo with weapon’ if you have his icon selected in your meeple tray. Again, this will get smoother as time goes by.

4) Displayed messages – in the top right of the screen is now a ‘message explorer’ that lets you step through game output. This won’t be the only mechanism you get for this, but it does mean that the game is now roughly playable through the client. Not entirely though, because a lot of work is needed at the level of the lib to make sure all the necessary information is sent to the client. For a lot of commands, no input at all is parsed by the client because of the way the communication packets are constructed.

5) Messages coming from the MUD are now appropriately ‘chunked’. A graphical client is a different thing to a text client in many respects, but one of the most significant is that text gives an element of linearity that data transfer by itself cannot implement. For example, if I have three separate calls to write some text to your screen, one after another, you as a player can’t tell the difference between that and a single call that outputs three lines. However, from the perspective of the client that’s not true because each chunk of text is its own ‘unit’. So I had to write some routines to collapse output that was likely from the same source, and interleave it appropriately in the client so that when you step through messages you get the right ‘unit’ of these.

6) A quest interface has been added, allowing you to explore which quests you’re on and what information is associated with them. You can see that below:

eidolon_quest

There are also plenty of small things underneath the surface – lots of small efficiencies, code refactorings, and minor steps towards having the right functionality across the game. Plenty of bug-fixes too. So, there has been progress. Every day though reminds me of more things that need to be completed, so the *sense* of progress isn’t quite there. There’s nothing technical that will stop it being done, it’s just that there’s a huge amount of work left to do before it’s feature complete, much less actually fun to use. But we’ll get there. We’re still in the discouraging area where every day the end goal gets further away, but I’m hoping that it can be completed in some meaningfully substantive factor by the end of my summer break.

There are no *major* architectural elements needed now – persistence was the last of these, and now that’s in place. The rest of it is mostly marrying up game output and client output, and adding in the actual *playability*. Action bars went a long way towards having that, as you can now play the game ‘World of Warcraft style’ – set up your main commands, and switch between them. They don’t show cool downs or the like yet, but they will. Eventually you’ll be able to open up a list of all your available commands and drag them to the buttons, choosing your own icons as you do. That’ll be a big step towards seeing this as more of a graphical game that just so happens to connect to a text game, rather than at the moment when it seems like a weird abstraction layer on top of a CLI.

My next few major entries on the todo list are:

1) Look at combat, and see how we can make that tractable for gameplay. I suspect for that I’ll look at taking the NPC you have ‘selected’ and cycling a model or image for them into the centre of the screen, then doing WoW style floating text on top of that showing the kind of combat output you’re getting. Other enemies you’re in combat with will jiggle away in the meeple tray.

2) Support clickable conversational keywords in NPC chats. They’re not there at the moment. You can see in the first image the start of a nascent speech bubble system – I don’t know if that’s going to stay. It might be the case that you use the bottom right output to handle it. We’ll see what works best.

3) Doors. Jesus, look at the doors on that thing. I don’t want doors to be ugly textures applied to cubes, I want them to be 3D models of their own that are embedded into the walls. That way I can more easily handle ‘open’ and ‘closed’ doors as well as making it look less dreadful.

4) Stackable and resizable windows. I like that you can drag the various UI windows around, but I’d really like if you could drop them on top of each other and create a stackable tabbed window that lets you switch between different output types. That way if you want a super minimal layout, you could have it. Unity doesn’t support draggable windows by default, so I had to write some routines to do that. It also doesn’t have tabbled displayed, or resizable anchors. All of that needs coded. Not especially difficult, but just another damn thing on top of all the other damn things.

Along with this is the ongoing work of making the client and the lib talk to each other – that’s a project in and of itself because it doesn’t make sense for *all* game output to go to the client – sometimes it’s handled through its own distinct packets. I don’t want the room description to appear in the message box every time it would be sent to a text client, for example. So each command has to be handled independently. Soon, you’ll start to see some benefits of this yourself as the client stubs are expanded – they’ll feed into the MXP supported by the game already because they work off the same basic system.

As usual, miles to go before we sleep but every update I think is showing meaningful progress.

I’m planning for another bug-fixing patch at the end of the month too, just as soon as I can sit down and clear out the report to the (almost) zero open report standard I’ve been aiming for [1].

Drakkos.

[1] There are maybe three open bugs that are a bigger deal to fix than I can devote, but discounting those that we’ve been patching with an open, unaddressed
bug-count of zero for the past few patches. That’s ‘open’ reports, rather than those still considering or marked as ‘fixing’.

Leave a Reply