Planet Mud-Dev

We’re still a couple of months out from 1.0[1], but I wanted to make today’s post about what’s coming up in the next few months. Think of it as our 4 minute warning, except instead of four minutes it’s more like ten weeks[2]. Instead of being vapourised by Russian ICBMs you are going to be dropped head first into a zombie apocalypse and left to fend for yourselves. The weeks ahead of us look very short indeed, but we’ve gone a very long way from what’s there on live to arrive at what we have now in development.

Epitaph 1.0 won’t be perfect by any stretch of the imagination – it will be full of typos, it will be full of bugs. I can’t definitively say it won’t cause cancer. Sterility is a real danger. Around 20% of the people who play may receive a sinister phone call during which a whispery voice will say ‘seven days’ and hang up. Basically, Epitaph 1.0 will be what the version suggests – ‘finished but not battle tested’. It’ll mark where we stop being a development MUD and start being a live MUD. It’ll mark where a continuing appreciation of player time and investment must begin. Epitaph 1.0 will see the last ever player wipe – after that, if we screw up we’ve got to fix it properly rather than just pouring bleach down the drain. From Epitaph 1.0, your characters will be safe. Your progress will be guaranteed, as best we can[3]. The time you invest with us will be *valued* by us. But what you won’t get is a completely smooth experience. Epitaph 1.0 is launch day – when was the last time you saw a AAA game with a multi-million budget make a flawless dismount from the development bars? We have a much smaller team and an infinitely smaller budget – we’re going to stumble a bit when we dismount.

So, what do we have lined up for you in 1.0? Well, a gigantic amount of content really. Patch 0.5.2 was on September 1st, which wasn’t really all *that* long ago – but it’s crazy how much more stuff we have in 1.0. We’ve added in a pile of new areas, most of which are outside the city of Dunglen. We’ve got castles, arctic research bases, Scottish islands, far flung observatories and more. To stitch all this together we’ve got a new exploration system and a taxi system. Some of those areas will be available to everyone, some will be available only if you have the right factional allegiances. The major faction you choose to align yourself with takes on major importance in 1.0 – in many ways it defines what subset of the game is yours to play through. You’ll get quests related to that faction, as well as quests related to bringing down other factions. Joining up with a major faction opens up other factions too, each of which with skills to teach you.

I mentioned quests there – I should point out that Epitaph 1.0 brings a few more your way. How many more? Oh, I wouldn’t like us to brag but – ONE HUNDRED. ONE HUNDRED new quests. By the time we actually release, it might even be more. Bear in mind these aren’t WoW style grind quests either. There are games that have been open for years that don’t have anything close to the amount of quest content we have. I’m genuinely blown away by the work that has gone into this by myself and the other creators here. Not every quest will be available to every *character*, but they will be available to every player via alts in other factions. As I say, faction choice starts to make a difference here on in.

Much of the work over the past few months has been in smoothing out the playing experience and making sure advancement is fair and sustainable – that’s a huge part in being able to make the promise of ‘no more player wipes’. I think the advancement is roughly at the speed with which I’m happy now, but I’ll be keeping a close eye on it as we open. Few things are as vital to overall balance as the risk/effort/reward ratios.

Our new dynamic help system really supports the tractability of the game too – even now sometimes advice pops up and I think ‘huh, I’d forgotten that you could do that with that object’. There are hundreds of help entries that pop up contextually as you play through the game, and I think they do a great job in managing the complexity of the world. There’s a huge amount of very intricate content in Epitaph, and being able to navigate it is important. We could dump it all on you in the newbie area, but I much prefer to parcel it out a little more.

It’s not all just refinements and new areas though – we also have a few new game systems that you may enjoy. We’ve added a remote hacking system that I think is a lot of fun. We’ve got new commands – a good few of them in fact. We’ve got new kinds of items and new ways of managing the core activities of the game such as scavenging. We’ve got half price cracked ice and miles and miles of carpet tiles. Check out http://drakkos.co.uk/patches.c?type=details&id=0.9.5 and tell me it doesn’t look awesome. Go on, I’ll wait.

I have said many times in this blog in the past that 1.0 represents a start point rather than an end point. We’re already thinking about Epitaph 1.5 and what we’re likely to have in it. My expectation for the future is that you can expect minor patches on a monthly or weekly basis (bug-fixes, almost exclusively) with more moderate patches twice a year. Major patches (Epitaph 2.0) will come along less frequently – I’d like to say every year but I don’t want to commit to that just yet. 1.0 is also going to mark the start of the Epitaph Federation project. A big part of what we can do after releasing is actually look to see how difficult it is to make a ‘non Epitaph’ version of the Epiphany mudlib. We could have released a mudlib at any time of course, but I don’t believe a mudlib has much value unless it’s battle tested. If you can’t point to a successful MUD and say ‘that was built using this technology’, then as far as I’m concerned a lib just has speculative value. You discover so much of the strengths and weaknesses of a lib from building a game that it’s not even funny. Even now, in the last few months before we release, I’m continually tuning the mudlib to fix bugs, reduce code complexity and empower game features. I expect that work to intensify considerably come release.

What we *can* do once we release though is point to a full game and say ‘Made with Epiphany’. Having proven that a game, and a very rich and detailed game at that, can be developed using our engine we need to look at refactoring it internally. There’s a lot in the lib that assumes a certain kind of game. We assume in the lib that you’re working with zombies, for example. We assume your world is one in which hacking computers makes sense. We need to start abstracting that kind of thing – you might get the hacking mechanics as part of the lib but it should be trivial to ‘reskin’ it so that it looks like anything. You might go through the same basic pattern, but there’s no reason why the player shouldn’t think of it as ‘reading a pirate map’ or ‘dispelling hostile magic’. We’re not set up for that in the slightest at the moment. Many libs get around it by cutting out ‘game specific’ content. I don’t want to do that since my plans are somewhat different. I don’t want a general Epiphany mudlib people can download. I want a federation of MUDs all working on the exact same code-base so that the work we do on the lib is of benefit to everyone. That needs a different approach, and it’s one that we’ll start thinking about seriously after 1.0 is live.

Our plans for 1.5 aren’t especially firm yet, but we’ve been tossing around some plans and ideas and already it’s sounding pretty exciting. 1.5 will see the Epitaph instances (which we’re calling Narratives because we have a different philosophy in mind than the usual WoW slaughterfest). It’ll see us refine some of the systems we’re leaving out of 1.0 and bringing them back into the game in a more coherent way. It’ll likely see the introduction of some form of teaching system (although it won’t be like the DW system). Excitingly, it’s almost certainly going to include some mechanism for ‘crafting’ intellectual property. Being able to code runnable computer programs is almost certainly going to be a developed feature, but you might also see the ability to craft novels, textbooks, blog posts, social network interactions and so on.

That’s the kind of thing we’re hoping to be able to put together on a regular basis for Epitaph even as we’re working on the meatier content of the major updates. I hope this all sounds as exciting to you as it does to me. It’s time to start generating a bit of buzz around our opening to make sure that everyone knows we’ve navigated the treacherous waters of MUD development and actually made it to our destination. That fact alone marks us out as something extraordinary, which is something I’m sure the hundreds of people working on MUDs of their own can attest.

For a’ that and a’ that, it’s coming yet, for a’ that!

Drakkos.
[1] Is that all? AaaaaAaAAAAAaaaaaaaaaaa
[2] Assuming no slippage. It’ll be done when it’s done, but I still feel reasonably confident that we’ll be ready for the end of July. No later than the end of August. 2015 at an *absolute* maximum.
[3] We’re a volunteer MUD, don’t expect us to have a customer service department.

As of yesterday, I completed and merged the first of the three upcoming Evennia features I mentioned in my Churning Behind the Scenes blog post: the "Multiple Characters per Player" feature.

Evennia makes a strict division between Player (this is an object storing login-info and represents the person connecting to the game) and their Character (their representation in-game; Characters are just Objects with some nice defaults). When you log into the game with a client, a Session tracks that particular connection.

Previously the Player class would normally only handle one Session at a time. This made for an easy implementation and this behavior is quite familiar to users of many other mud code bases. There was an option to allow more than one Session, but each were then treated equally: all Sessions would see the same returns and the same in-game entities were controlled by all (and giving the quit command from one would kick all out).

What changed now is that the Player class will manage each Session separately, without interfering with other Sessions connected to the same Player. Each Session can be connected, through the Player, to an individual Character. So multiple Characters could in principle be controlled simultaneously by the same real-world player using different open mud clients. This gives a lot of flexibility for games supporting multi-play but also as a nice way to transparently puppet temporary extras in heavy roleplaying games.

It is still possible to force Evennia to accept only one Session per Player just like before, but this is now an option, not a limitation. And even in hardcore one-character-at-a-time roleplaying games it is nice for builders and admins to be able to have separate staff or npc characters without needing a separate account for each.

This feature took a lot more work than I anticipated - it consitutes a lot of under-the-hood changes. But it also gave me ample opportunity to fix and clean up older systems and fix bugs. The outcome is more consistency and standardization in several places. There are plenty of other noteworthy changes that were made along the way in the dev branch along with some API changes users should be aware of.
So if you are an Evennia game developer you should peek at the more detailed mailing list  announcement on what has changed. The wiki is not updated yet, that will come soon.

Now onward to the next feature!

God, I’m sorry for that title I really am.

As we hurtle towards release day, it’s time to step back and look at the totality of what we’ve done and how it all fits together. There are bits of our game that are older than others, and there are bits that strictly speaking predate Epitaph entirely. Our achievements system for example is a variation of one I wrote for DW MUD and as I have been going over our content I’ve been taking a long, hard look at the achievements we provide. I can’t say I’m very satisfied.

For the most part, they’re pretty standard – but I have decided that’s what I don’t like about them. Thinking back to what I really enjoyed about the first game I saw that used achievements properly[1], it’s striking how few of those design lessons have made it into the selection of achievements we have on offer. Partially that’s an issue of ‘place holding’ where the achievements were put in to indicate <content needs to go here>, but it’s also just because achievements generally tend to be pretty boring and uninspiring across games. You usually get them for completing content you were going to have to complete anyway (Hey buddy, you made it to level two!) or for grinding through game content in a way that extends playtime without adding to development cost.

I’d like to do something better for Epitaph.

At the moment we have a total of 254 achievements spread across a wide number of categories. As with DW MUD, they are ‘tiered’ with achievements usually having ‘harder’[2] versions a little further up the ladder. We have 9 functional tiers of achievement, and our current design relies heavily on this to provide progression. A low level achievement might be ‘kill ten zombies’, and the next one is ‘kill fifty zombies’, then ‘kill one hundred zombies’ and so on. It’s coherent and it provides a sense of accomplishment, but it’s also somewhat… soulless. It’s ‘achievements by the numbers’. No, worse than that – it’s just badgification. Reflecting upon it, as I often do about Epitaph, I have decided that they just aren’t fun.

Now, I’m promising nothing for Epitaph 1.0 – we’ve already got a huge pile of stuff to do before release and that todo list doesn’tget any smaller by adding huge new jobs to it. But what I’d like to do is completely recast the range of achievements we have and make them more interesting. I’d like them to reflect the name – I’d like them to be actual *achievements* and not simply a reward for perseverance. Our achievements cover a wide spectrum of the game, and that’s fine – but at the moment the sheer number of tiers means that being genuinely creative is hampered by the sheer scope of the task.

Our goals system is very similar to achievements, except that goals are pushed on players by Maestro – it’s not that I’m going to get rid of the ‘grind’[3], I’m just going to move it into a system that has much lower visibility. You’ll still get the rewards, if you want them, of crafting ten zillion whatevers, but they won’t be achievements.

Achievements instead are likely to see several things happening:

1. Fewer tiers. Perhaps as few as four.
2. More inter-relationship of tasks. No more ‘churn out five thousand slabs of butter’ achievements and more that follow a player through a more complex and intensive activity.
3. More requirement for player skill.

I still want lots of achievements, I just want them to feel less like the trivial box ticking of flash games like ‘achievement unlocked’[4] and something you can genuinely feel a little surge of pride in having reflected on your player profile. Some of them will remain from the current batch – despite the fact they require no actual skill I am very fond of the ‘login date’ and ‘character age’ achievements – but on the whole I think perhaps for 1.5 we’ll be looking at a complete refresh of the portfolio.

I’m thinking of achievements such as ‘go a full day of playtime without dying’, or ‘heal a group mate from 1 health to full during combat’ or ‘crack a very difficult safe in less than 30 seconds’. All of these would require a certain amount of skill on the part of the player – even hiding in a safe area on Epitaph isn’t risk free since you need to eat and drink. You might be able to get people to donate supplies to your effort, but that would suit me down to the ground. The best kind of achievements offer multiple routes to completion, either through rugged individualism or the manipulation of group dynamics.

The biggest sins with our achievements as they currently stand are that they are uninspiring and they lead to the worst kind of drudgery in play experience. I noticed this back on DW MUD when after having completed a tedious long grind of an achievement people would say ‘Hey, about about an even more tedious grind at a higher tier?’. Adding a new achievement should be like adding a new quest – it should inspire excitement in the playerbase, not ‘ho hum, who cares – another number of increase to an arbitrary threshold’. Even if they don’t enjoy chasing achievements, people feel the need to do it anyway because they are displayed so prominently and, here at least, they are tied to your command and knack points (Which is another thing likely to go away). So, we keep the feature (in the form of goals), lower their visibility (so nobody feels the need to compete) and make the things you actually compete over worth doing.

Perhaps the worst flaw to adopt as a game developer is complacency – to think that just because a task has been done that you’re finished. Achievements are ‘done’ on Epitaph, but that doesn’t let us off the hook. We have a duty to our soon[6] to exist playerbase to constantly be striving to do better. When things aren’t fun, we have an obligation to redevelop and redesign until they are. Our achievements, in my view, currently aren’t fun – changing that will be a lot of work, but it will raise the ‘average quality’ of the game in the process. One poorly implemented or lacklustre feature can really tarnish the sheen of a game. You have to have the dispassion to identify where you haven’t met your own quality standards, the honesty to admit it, and a plan for how you can fix the problems.

In other words – now would be the time for anyone with a grand plan on how they think achievements should be to weigh in! I have my own thoughts, but I’m certainly open to being persuaded. What do you like? What do you hate? What would make you go ‘man, that’s very cool’?

Drakkos

[1] Left 4 Dead
[2] Or more realistically, ‘more grindy’
[3] Some people actually find the grind rewarding. I’m one of them, in many situations.
[4] http://armorgames.com/play/2893/ [5]
[5] I actually completed this. :-/
[6] I hope.

To keep it short, I haven't been working on Smerg much on account of having gotten a job that required a 90-minute commute. However, this week, I started at a much closer job (where I also actually get out on time, and not at 7:00, without overtime pay). This has opened up some more time to work on stuff, and in addition, I have gained some more valuable programmer knowledge.

How does this apply to Smerg? Well, mostly, I'm considering putting Smerg up on GitHub when I get it to a reasonable starting point - probably when it has everything except combat, on account of how complicated it will be and the fact that, without combat, it can still serve as a MU* engine. For those who don't know what GitHub is, it essentially is an online repository (a place where source code goes) that anyone can access, but also allows people to submit change requests or even take the entire repository and make a copy of it for them to work on ('forking'). So someone might say "Hey, this is great, but I want a totally different combat system" and fork off their own copy of Smerg and work on it there.

But for now, I'm going to try and finish off Crafting and other such big important features.