Client Nearly Ready for Alpha

I've got an updated, annotated screenshot of my client to share. I feel that the remaining work before it's ready to share is quickly diminishing, and that motivates me, so I hope to have this thing ready to share with others in the next month.

Here's the screenshot:

http://img339.imageshack.us/img339/1793/mudmanuserinterface3ach.png

Some highlights:

Note the lack of prompt spam. Only the latest prompt is displayed, and it's right next to the input box. When you send a command, the prompt dims a little, then lights up again when you get an updated prompt (indicating the MUD is ready to receive your next command).

The latest room description always stays on screen, so you never have to scroll up or send a fresh LOOK command to review it. I think this helps maintain a sense of your surroundings.

The "compass" indicates which of the "standard" directions you're able to travel from the current room. The number pad can be used to send the common travel commands. I say "standard" here because some MUDs have exits like "house, shop, gate, castle", and those aren't well-communicated by any graphical compass.

I'm sending talk to a separate block as well. I've defined talk as any messages with both quotation marks and "say, yell, or shout".

The block at left shows lengthy text, like help content, shop lists, and lore. In Achaea, such text is usually followed by "type MORE to continue". These chunks of text are problematic because they like to gradually scroll off-screen as new text arrives. By sending them to a different block, I can keep them on screen for reading and still pay attention to any new text arriving without having to scroll constantly up and down.

Finally, having eliminated prompt spam and sent room descriptions, chat, and lengthy blocks of text to special areas of the screen, the main text area displays only the happenings going on around me - combat, arrivals, departures, and non-combat actions like inventory management and emotes.

Now I can neatly prioritize my thinking based on areas of the screen - I focus mainly on the output directly above my prompt, and look to other areas as the situation permits.

So what's left?

Some things need doing:

• Including some pre-configured custom interfaces to install with the app.
• Allowing for import/export of custom user interfaces like the pictured UI.

 

Others need fixing:

• Dialogs are functional, but look like crap (not pictured above).
• Dropping very old text to avoid running out of memory.
• Disabling logging for very short play sessions (cleans up the log list).
• Eliminate unnecessary whitespace in all output areas.
• Wrong moves in design mode can get the user stuck.

 

See how short that list is?! I'm excited. Finally, I have to test. I'm thinking maybe 10 hours of standard play in each of Achaea and Aardwolf will be good enough for an alpha release.

 

Please share any feedback you have!

 

Also one addendum - recent questions not addressed in the screenshot... Yes, you can define scripts, macros, and triggers. Yes, you can change the background image and the color scheme. Yes, you can rearrange the user interface without knowing anything about regular expressions (but you need them to create NEW blocks to receive text).

Strategy and Combos in Text Combat

In my last entry, I suggested building a system for magic based on recipes which varied a little from one player to the next.  A player would gather some energy from several sources and arrange them in a sequence, then release them together via an action like punching or stomping.  The advantage is mystery - with a sufficiently large pool of potential recipes and an administration willing to occassionally shake things up, the idea of magic will fill players with a sense of wonder at the possibilities.  Players will not only imagine how they can apply the spells they know, but what other spells might be possible and yet undiscovered.

I promised to take a shot at applying that thinking to physical combat.  The idea of taking several steps in performing a single action, however, doesn't evoke the spirit of frenzied close combat.  So to apply this methodology to physical combat, a recipe should include many steps which manifest as perceivable actions.  After all, physical combatants don't stand still - at the very least, they strike, block, evade, and change stances.  They also enter combat equipped, and usually don't have the option of changing those tools in combat.

Most text games I've played treat defensive manuevers as entirely passive activity - if your character is good at evading attacks, then bad guys will automatically miss him more often.  I'd like to keep that, but to add some meat to combat via combos, I suggest adding defensive maneuver commands, which, when used instead of an attack, drastically increase the opportunity for defensive success and create an opportunity for a more effective attack (through combos).  For example, thrusting with a knife is a basic attack, but when preceded by a successful EVADE, becomes a counterattack which is extremely difficult to defend against (and so is much more likely to connect than the basic knife thrust).

So to illustrate...

knife + thrust = basic knife stab

knife + evade (successful) + thrust = formidable counterattack, difficult to mitigate

Similarly, attacks which use a lot of strength tend to be slower.  Text games usually simulate this by adding extra roundtime after those attacks (4 seconds before your next turn after trying to decapitate someone with a claymore, versus 2 seconds after a typical thrust).  I suggest instead front-loading that roundtime by having the player spend some time gathering his strength for the attack with a command like GATHER.

Another illustration...

claymore + high swing = face-mangling slash attack

claymore + gather strength + high swing = extremely difficult to parry, potential for decapitation

So the ingredients include:

• Equipment, not limited to weapon type (shield or not, weight of armor).
• Explicit defensive maneuvers (parry, dodge, block, absorb).
• Explicit offensive preparation (gather strength).
• Type of attack, or other action commands.
• Sequence.

While the examples above include at most two steps, it needn't be limited to that.  Maybe parrying once, then dodging the next blow, then gathering strength, and finally sweeping someone's leg with a quarterstaff will drop them to the ground?  Also, some character development might come into play - it doesn't make sense for a knife-wielding thief to pick up a claymore and start lopping-off heads, so maybe combo attacks require some degree of experience with specific weapons, physical attributes like strength, or light armor (for that cool escape-from-combat-by-running-up-a-tree combo).

Notice that knowing something about your opponent's combos adds another level of strategy, since you may be able to predict when an attack is coming ("I feel a potential decapitation coming on, best to evade this turn!"). And, just like the magic system I discussed before, there's some mystery - those who experiment with different combinations of equipment, skills, and tactics may discover new special attacks. Subtle administrators can keep things interesting by adding/removing/updating combos as time goes on.

Making Magic as fun as Cooking

In a previous blog entry about professions, I described some suggestions for making crafts more realistic and interesting.  This involved basic recipes which worked for everyone, and "ideal" recipes for the same products which would produce exceptional results - these recipes would vary from one player to the next.  Also, a recipe would involve steps in addition to ingredients, like dipping a hot blade in warm water.  Thus by spending time experimenting as a real craftsman would, a player could himself become better at the craft by gaining real knowledge rather than simply repeating recipes until his "skill points" increased.  Further, players may specialize in specific goods or even in crafting in general, and the benefit would be the ability to produce rare-quality goods.

Generally, the motivation for that topic sprang from my desire to "hide the seams" in text gaming - to make the artifacts of simulation less obvious.  This is roughly analagous to the trend in graphical games to reduce HUDs (heads-up displays, like health bars and ammo counts).  In the case of crafts, for example, the artifacts include:

1. Measure of "skill" simplified to an integer value.  "How good are you at cooking?"  "I'm at level 73."
    
2. Perfectly identical goods from every cook every time.  No matter who makes it, the "Lamb Chop" is the same - "EAT to gain 35 health points over 12 seconds".
    
3. A recipe simplifies to a level requirement and a short list of ingredients.  "Level 32 required.  Place 3x Lamb Meat, 1x Charcoal in cooking pot.  Stand in a room with fire and type COOK".

These blatantly remind the player that his experience is a simulation.  Text games have a greater opportunity to make games feel more "real" in many areas because it's much cheaper to describe and simulate a real life event with words than to render it graphically and simulate it with a simpler controller (versus a command line, with the power of language).  A mediocre writer can paint a vivid mental picture of a blacksmith's forge in minutes, where a 3D artist will require days.  In a text game, someone teaches you to do something with words that never include "hold L and press A" or a cartoony graphic depicting a wiimote waggling left and right.  Each player, then, imagines something vivid and unique (the book versus movie analogy applies here).

Recently, I've been trying to imagine a way to extend this line of thinking to bring the real-life emotions tied to exploration, experimentation, and research to text-gaming magic/technology and combat.  My idea is apply the cooking analogy to these areas - a sufficiently large pool of "ingredients" which may be combined in many ways can create a playground.  Instead of picking skills from a menu (which kills the mystery we enjoy in real life), players will experiment and discover new tools, then gather to discuss and share their discoveries.  So then the question is what to replace the ingredients with, and how to introduce steps.

Here's one example of such a system dealing with elemental magic.  Please share any feedback through comments, and adjust to fit your wider game's design as necessary!

The ingredients are the "standard" elements - earth, fire, water, air.  Combined in a sequence and released the right way, they could make a useful spell.  For example, the recipe for fireball might be 1 earth, 2 fire, 1 air, then punch.  Possibly, adding a couple more units of fire would make it explosive...
To avoid overcomplicating input, let players alias a spell once they've figured it out.  So a player discovers this while experimenting outside of combat, then he names it "fireball" and later in combat, just types CAST FIREBALL GOBLIN.  It would take just as much time to cast as if the steps were entered separately, but only the one command would be needed.

To keep magic mysterious, consider that the order of ingredients would be different for each player (randomized, anyway).  So that while another player could tell you that a fireball involves fire and lesser parts earth and air, some personal practice and experimentation would be needed to get it working for yourself, just like in real life (anyone can tell you how to swing a bat, but you'll miss the ball until you get some practice).

So what good does all this do?

1. Well, there's mystery.  You (and your friends?) can hang out and try new things.  You never know what cool stuff you may stumble across.
    
2. You're not selecting your spells from a list of what's available.  And if details are sufficiently hidden by design, nobody talks to you about level requirements and skill points.
    
3. Since spells don't have administrator-provided names, admins can add, remove, and modify spells quietly.  Admins don't have to tell players "we removed the FIREBALL spell and replaced it with FLAMETHROWER" because the set of commands has not changed.  Players discover that magic has shifted a little (magic is mysterious, after all), and adjust their knowledge.  "That air/water/earth mixture doesn't manifest the way it used to - I'll experiment a little to see what's possible now", or "Hmm that's interesting...  better head back to the mages' tower to discuss this with others".

In my next entry, I'll work on bringing this concept to physical combat.

Other potential enhancements:

1. Let the recipe be a ratio.  Players may cast a spell as light, medium, or heavy to pump a portion of their total spellpower into it.  A weak magic user might need to use "heavy" at least initially to manage a fireball, while an experienced caster could create one with "light", or use "heavy" to call forth a flaming boulder.
2. Allow for channeling (ongoing casting) instead of all-at-once.  A channeled fireball might be more like a flamethrower.
3. Introduce other elements, like "life" or "spirit".  For example, spirit might impact magic directly, to weave a general spell shield, momentarily prevent another magician from casting, or store an elemental charge in an object (like a ring or amulet).  STOMPing a portion of life magic into the ground might trip a far-away bad guy with a vine.
4. Vary availability of specific elements with location or time - earth is strongest underground, life in the forest, spirit when the moon is full.
5. Allow players to specialize.  As they practice fire (or spend more points on fire), they find current spells easier and open up new spells.
6. Provide plenty of verbs for releasing magic.  For example, punch, swing, stomp, release, focus.