Eidolon 0.3.0

So, we patched at the end of the last month – that’s a good thing! I also hope we can patch at the end of the this one. That too is a good thing. But, as it has been for the past few months the key focus has been on our graphical client. That development has resulted in a couple of (optional) changes to the game[1] that will be good for everyone. So let’s go over where we are.

One of the things that wasn’t working fully in the past was the add_items in the explorable long description – you’d only get those that exactly matched the add item text. They’d be clickable and you’d be able to read through a room, but it didn’t fully capture everything that was there. I had put that on the back burner though because, to be honest, I couldn’t think of a good way to do it. The problem, you see, is actually quite complicated.

When we use add_items in a room, it consists of a string of text – that string of text is a set of adjectives and a noun, which it works out for itself. So if I have an item such as “large expensive unusually proportioned exotic sex toy’, it gets a noun of ‘toy’ (the last word) and the rest are adjectives. So ‘sex toy’, ‘expensive sex toy’, ‘large toy’ and any combination of that will match when you go to ‘look’ at it in a room. Items can also have aliases, and plurals, and our in-game code handles that all hunky dunky. But…

Let’s look at an actual extract from the Winchester – just two bits:

set_long (“While it was probably never the world’s most salubrious ”
“location before the crisis, recent events have taken their toll ”
“on this shabby, barricaded pub. The windows have been heavily ”
“fortified with boards, bricks and corrugated iron. The main door ”
“into the pub likewise has heavy-duty barricading, with access ”
“permitted via the use of a set of sturdy metal bars. The ”
“room itself is dominated by the wooden counter of the bar. ”
“Above the counter is what is almost certainly a reproduction ”
“winchester rifle. A pool table, looking somewhat out of place ”
“in this austere fortified position, stands off in a corner, and a ”
“jukebox is silent in the corner. A cheap clock on the wall behind ”
“the counter ticks off the hours of the apocalypse.\n”);

add_item (“shabby barricaded pub”, “The stains on the wood and the ”
“stickiness of the floor all speak of a pub that, even before ”
“the infection, a visit was never the high point of the social ”
“calendar.”);

The problem is that there is no link from items to the long description, and the description can reference an add item in any way. We often have dozens of add_items in a room, each with multiple adjectives and plurals and aliases. Given this, how on earth can we put any kind of visual cuing at all on the long description? For example, in the long description above we’d want to identify the following:

…recent events have taken their toll on this shabby, {barricaded pub}… [2]

So in effect I need to match an arbitrary combination of a noun and some adjectives (sometimes) against any possible occurrence of any possible combination anywhere in a long string of text. And then I need to do it for what may be dozens of possible add_items in a room. I also need to do it from the most specific case (shabby barricaded pub) to the least specific case (pub) to properly differentiate between potentially clashing items. And I also need to be able to correctly catch ‘barricaded shabby pub’ and highlight that too, because it’s actually the exact same thing. Blurgh.

In the end I went with a kind of ‘ticker tape’ system, looking at progressively smaller sub-strings of the text and identifying any that matchedany item, and then linking those in the client. But, that can’t be done *in* the client because of the way the querying has to be done against items in a room. So I did it in the MUD. The good news there is that I then thought ‘Well, why not enable this for everyone’ and now there’s a new option that lets you have clickable links (or coloured links) in the long description, so you too can click your way through a the text and its accompanying items:

MXP_Long

Or if you prefer:

Colour_Long

But that’s not quite it, because with strongholds we now have rooms that consist not of add_items, but *actual* items – so not only do we need to match anything that has an add_item, but also anything that has an actual physical item to go with it. But that was simpler to do once the core was in place – if it’s not an add_item, check to see all the objects in the current room to see if that’s what we need.

The key thing is that this now allows me to send a chunk of descriptive room text to the client (with some embedded control codes) so that it can now find every add_item (and environment item) and link them up appropriately:

eidolon_coloured_long

So, that’s awesome. That had been bothering me, and while I’m not 100% enthused about the war-crime of coding that solved the issue, at least there *is* a solution. It wasn’t on my list of ‘things I want to do’ in the last post, but I do what I want. I won’t do what you tell me. You’re not the boss of me.

My list from the last post included combat, clickable keywords for NPCs, doors, and stackable windows. I never got around to doing the latter two, but I made good progress on the others. It’s not fully implemented yet, but combat now comes with World of Warcraft style floating text informs, showing the amount of damage an attack inflicts. I also added an option for this in the game ‘proper’, so you can see numerical output of your damage, which is actually a more significant change than it might appear.

One of the things I inherited from Discworld MUD was, embedded into the code-base, a set of assumptions about how information should be presented to players. Over the years, I’ve modified a lot of these assumptions and adopted a far more open approach to game mechanics. However, one of the areas where that wasn’t true was in the combat system – you’ve always only been given vague generalities about damage, rather than actual numbers. Other than a kind of old-school prejudice against mini-maxing game systems, I couldn’t think of a single good reason as to why that should remain the case[3]. So I decided, at least in the current version of the development game, to switch it on for everyone. It’s a little weird, but interesting to see in testing. I mentioned last time that many of the client developments from this point on would result in visible game changes for everyone – this kind of thing is why. I’m still experimenting with combat (I might end up just using the usual descriptive text anyway), but I’m up for seeing what looks and feels best. My guiding principle is ‘no detriment’ – there should be no information available through the graphical client that isn’t in the base game, and vice versa.

I implemented clickable NPC conversational keywords, and removed the chat bubbles – I didn’t like them at all and couldn’t see a way in which they would ever be suitable for what I was hoping to accomplish. I have some other thoughts about how to handle what I want for that, but we’ll talk about those later. For now all your dialog appears in the bottom right window, like so:

eidolon_clickable_keywords_1

As you can imagine, clicking on a keyword will result in you asking that NPC about that topic.  But this introduced a new problem – not all keywords are revealed in conversation, and sometimes you want to just ask an NPC about something they may not have mentioned yet. So, when selecting an NPC you now get a little text box above their head which allows you to ask specific things without them having brought it up first:

dialog_keywords

And upon hitting return they’ll give you the answer:

respond

Which is nice.

We’re getting close to the point that this is actually a playable client – not *fully* playable, but the major core input and output loops are there, and the free-form text input at the bottom left bridges a lot of the gaps. We remain though a long way from having a *releasable* client, even in a rough, experimental form. One of the difficulties with having a game as deep and varied as Epitaph is that there are a lot of little bits that are going to need their own finessing. The choose your own adventure rooms, for example. Or the crafting system. The help system. How are we going to handle quests[4]? What about the commands that prompt for confirmation? Those kind of things still has to be nailed down in design before they’re coded.

I remain hopeful for a release of Eidolon 1.0 in the summer, but it remains a long, ongoing job to create a genuinely graphical game from a fully text-based backend. I think you can see by now though that there is a world of difference between the simple GUI clients that are now becoming the norm in text gaming as compared to the fully 3D game interface that I’m aiming for. If, when it’s completed, this is half as good as I’m hoping it will be I think we’ll definitely enter a new era of Epitaph in terms of fun, playability and actual player popularity[5].

Drakkos

[1] I reserve the right to switch these off if I can’t improve the performance a little.
[2] Ignore the fact it should really identify shabby, barricaded pub. I gave up on that futile exercise.
[3] The only one that came close was ‘What would the judge command be good for then’, but in the end I decided it still plays an important role in identification and efficiency of experimentation.
[4] Probably through the free-form text input. I don’t see that ever being a thing we can get away from, realistically.
[5] ‘Come play our zombie game’ is a much easier pitch than ‘come play our zombie game, by the way it’s all text’.

Leave a Reply