Second Contract

First Distribution

May 052013

I’ve put together a distribution of the Second Contract mudlib (SC-0.131250). It’s so basic that you can’t do much more than build it and see that it lets you create a minimal character in a single room with no details. I wanted to get something out at this point for several reasons: it gave me something to work towards, you don’t have to take my word that I’m making progress, and now I have a framework in place for making future releases.

The distribution consists of a checkout of the DGD github repo, the (networked) Kernel Lib github repo, and the Second Contract github repo all suitably arranged to allow easy bootstrapping. I’m using the network extensions now so I can make sure everything will work when I add intermud chat.

Mudlib versions are date based: M.yydddn where M is the major version number (0 for the foreseeable future), yy is the two-digit year (13 for 2013), ddd is the three-digit day of the year, and n is a minor version number used to distinguish releases on the same day. So any version which starts with 0.13 is from 2013, 0.14… is from 2014, etc. Higher numbers are newer releases. If I put out a test release, I’ll mark it as such with a sensible suffix.

What’s in this distribution?

This is just enough to illustrate a game that can boot and have a character floating in an empty scene. Multiple characters can log in, and they will see each other “looking”, but won’t otherwise see each other in the game unless they use the “%who” command to see which characters are active in the game. There’s even some debug output when you “look.”

The README has instructions for getting everything up and running, including which ports to log in to for which types of accounts and access.

Game accounts made through the telnet port are not visible to the Kernel lib as regular users that can be made creators or otherwise able to log in to the binary port. The two are completely separate. Game accounts may have up to five characters associated with them. You can choose which character to play when you log in, and you can only have one character in play at a time.

Note that you should not use this code as the base for a game yet. There’s a lot of unfinished stuff lying around and I’m not going to bother with writing upgrade functions for objects until I get closer to something that is workable as a game. If you play with this distribution, be ready to throw everything away and start over when I release a new distribution.

You should pass the web interface used to manage the game through a proxy of some kind that can wrap it in TLS/SSL for security. The http service in the game is good enough to work with a browser running on the same system, but I haven’t tried to make it handle all the malformed requests that can come in the wild. I depend on a proxy for that.

Next Steps

Besides getting more game systems up and running (such as quest generation), I need to flesh out the web interface to allow editing of details, placement of landmarks, paths, and scenes in terrains, verb handling (including multi-word verbs like “look at,” “turn on,” and “turn off”), and create verbs and actions for moving between scenes or scene details.

Improvising Plots

Systems No Responses »

Apr 192013

One of the reasons I decided to start over a few months ago and develop a new mudlib on DGD was because I wanted to have quests that were built on the fly based on the situation of the player and the NPCs with which they were interacting. Instead of a fixed script that you had to follow, I want the game to be a bit of improv.

I’m sure this could be done using a mix of object clones and save files with FluffOS, but it seemed like it would be a lot easier if I didn’t have to worry about all of that with a persistent driver such as DGD. In the process, I’ve reworked a lot of how an LPC mudlib works. Based on what I’ve seen around in forums and in the free/open source/not-behind-an-NDA mudlibs, I’m producing a mudlib that isn’t just a rehash of old mudlibs. Whether or not it will be useful to anyone else is still up in the air.

Incorporating improv into the game engine means that when you meet an NPC that has a quest, it should somehow fit in with how you are playing the game. The game should be thinking, “Yes, and…” when constructing a quest plot. If the game can’t find a way to advance an NPC’s goals in a way that works with how you play the game, then it shouldn’t offer you the quest.

Adverb Action

Development, Systems No Responses »

Mar 312013

Adverb (Photo credit: Wikipedia)

I’ve spent more of the last week working on the web interface than working on the adverb system, but that doesn’t mean I haven’t been thinking about adverbs or doing any planning. Today, I want to walk through how I see adverbs working in the Second Contract mudlib. Adverbs here will be markedly different from adverbs in the Skotos system. You can use them with any verb, and they will affect the action in some way much of the time.

Adverbs serve a few different functions in a game: constraint modification (make something quickly instead of carefully), voice (shout mightily instead of loudly), or just atmosphere and emotion (bounce joyously or run crazily). Let’s look at each of these in turn.

Continue reading »

Screenshots!

Development No Responses »

Mar 242013

This last week was our spring break, so I was able to spend a bit more time with the game. As a result, I can present a few screenshots to show where I am.

Screenshot of the System dashboard.

The primary means of managing the game and content is through a web interface. The first binary port is still available for emergencies, but nothing beyond the capabilities provided by the Kernel lib is available there. The first screenshot, then, is of the system dashboard.

You’ll notice that the Running Since time is more recent than the Started At time. The former is when the current DGD process began. The latter is when the game began.

You can also change the name of the game here. Changes will persist across restarts of the DGD process, but not across restarts of the game. This is the nature of persistent games with DGD.

For now, I’m building the administrative web application with sections for each major part of the mudlib: System, IFLib, and WorldLib. If there are any configurable things for ToolLib and DevLib, I’ll make sections for them, but they don’t have any now.

Verbs and Actions

Development, Systems No Responses »

Mar 182013

Pattern of nature and people (Photo credit: heritagefutures)

I’m making progress, though not quite far enough along to have something you can log into yet. I have the basics of things, a parser with a grammar and a binder (based in part on the Discworld code), an event handler installer, and a message renderer. I also have a user object that lets you use your email address and password to log in and then create or select a character.

I want to walk through what happens when you type in a command. Let’s use “grab the china from the table then quickly run through the door.” The parser will divide this into two commands and label the parts:

(
  (command
    (verb "grab")
    (direct-object "the china")
    (indirect-object "from" "the table")
  )
  (command
    (adverb "quickly")
    (verb "run")
    (indirect-object "through" "the door")
  )
)

I’m not settled yet on movement verbs taking an indirect object as indicating the point towards which the character moves, but that’s essentially how the commands would parse out with the current grammar if I defined the right verbs, adverbs, and prepositions. The grammar doesn’t support multi-word verbs yet, so no “look at” or “turn on” for now.

Proximity and Movement

Development, Systems No Responses »

Mar 122013

The last couple of weeks, I talked about proximity relationships, environment, and inventory. This week, I’ll explore what this means when we move objects around. Along the way, we’ll see where I’m considering tweaking the proximity system as I’ve coded it so far.

Placement

First, let’s review what we need in terms of placement in the game. We want to specify our relationship with other objects in the scene, landmarks, and where we are relative to other areas of the virtual world. We want to move towards and away from things within a scene. We want to move in ways that make narrative sense, not necessarily spatial sense (i.e., lean against the wall, not stand at position <x,y> with our shoulders touching a vertical surface at <u,v>).

This is easy to do if we have full objects for everything in a scene: each item we can manipulate, each detail we can look at, and each detail of each detail.

Continue reading »

Scenes and Settings, Part 2

Development, Systems 2 Responses »

Mar 022013

Last week, I talked a bit about the graph tracking object relationships with each other. This week, I want to continue by looking at what that graph means for the larger world.

One of the errors in designing text-based games is trying to shoe horn them into the expectations associated with a graphical game. Just as a movie has different affordances than a novel, a text game has different expectations and narrative conventions than a graphical game.

When writing a novel, you don’t specify the exact placement of everything in the scene. Instead, you take what you imagine as the scene and then put on paper only the things that have any significant impact on the story. If the choice of color doesn’t change the story, then leave it out. Same goes for the wallpaper pattern or any other detail. If a lamp is never thrown across the room in anger, then don’t tell the reader about it.

Scenes and Settings

Development, Systems 4 Responses »

Feb 242013

This is an example of how objects in a scene might be related.

I’d like to do a post each week about how development is going in some aspect of the new mudlib. This week, I want to talk a bit about object relationships, environments, and location. As they say, it’s all about location, location, location.

Traditional LPC mudlibs have the concept of environments and containment in which an item can have only one container. The item is either in the container or it’s not. There’s nothing else to it. If you’re developing on a driver such as MudOS or FluffOS, it’s difficult to break away from this because the driver makes it so easy to go this route. Given all the other complexities of building a mudlib, why choose to do something difficult if the driver gives you an easy option?

DGD doesn’t handle the environment. DGD’s philosophy is that if it can be emulated in LPC, then it should be. The Second Contract mudlib doesn’t stick with the traditional room and object distinction. Instead, it lets things play out in scenes and settings. Or it will once we have verbs and parsing and descriptions all playing together nicely.

This last week, I’ve developed the core data management piece necessary to support this multifaceted approach to building scenes. Once I get some of the other things built, I’ll be able to tie everything together and get some interesting results. I hope.

Persistence Pays Off

Development, Systems 2 Responses »

Feb 132013

This architecture diagram is based on the one developed by Skotos.

I’ve developed Second Contract using the Dead Souls mudlib for a couple of years now. I find myself pushing the boundaries of the mudlib and driver to the point that I think it might be easier to start over with a different driver. I’ve learned a lot, but more and more the game is becoming a mass of patches on top of patches.

My day job is that of software architect. I emphasize data-centric, event-driven, component-based designs that allow functionality partitioning based on responsibilities. Given what something is supposed to do, it should be fairly straightforward to figure out which component the code should go in.

This approach works well in the world of REST and linked open data. When you can break a system into a set of micro-services that work through a REST api, you can swap out components without having to rework interfaces. You can take the pieces you need and leave the rest. This is nothing new to someone who is familiar with the promises of object-oriented programming. Realizing the promises is really a matter of choosing the right boundaries between parts.

Many mudlibs today are typical of organically grown object-oriented programs. They’re more spaghetti code than well-organized, though it’s not the spaghetti code that’s the problem. Any responsibility-based organization scheme will have you hopping from file to file to trace an execution path. The problem is that where you need to go next is not predictable. Is the verb handled in the verb object or in the direct object? Is the parsing done by the driver or by the verb object? There’s never a good, clear-cut rule that will predict the correct answer.

I’m starting a new mudlib based on everything I’ve learned over the last few years and what I’ve read about various mudlib architectures. I’ve based the core design on the one described by Skotos. Since I don’t have access to Skotos code, it will be different in its details, but it will have components with well-defined responsibilities.

I’ll post more over the next few weeks/months as I get code together, but here are a few things I’m aiming for.

Dynamic Quests

Systems No Responses »

Feb 072013

Now that I’ve gone over the verbs and gotten them working for the most part, I’ve opened the game back up. A few things still don’t work quite right, but I’ll fix those as I get to them.

I’m starting to rework the job system a bit. There are three types of job: tasks, missions, and quests. Tasks are simple jobs such as delivering an object. Missions are more complex jobs that consist of tasks. Quests are the most complex and result in quest points that allow higher-level advancement.

In other games that need quest points for advancement, there’s often a limited number of quests. The admin know that you’ll have to solve a certain number of predetermined puzzles. This constrains your freedom to play the game your way.

I want to avoid some of that even though I’ve set up the game to require quest points. Here’s what I imagine happening.

Older Entries