Names and Aliases – The Diagrams

Yesterday, I laid out a high leevel overview of a simplified way of tackling disguises and name aliases. Now following the flowchart in yesterday’s post, we’ll build up our Memotica diagram:

1 – The facial recognition part needs to be resolved first. Since the first step is determining whther the face is noticed, we’ll create a numeric condition for that and call it CharacterFaceNoticed. We’ll make it such that if the “Perception” value of the observer is greater than the arbitrary value of 10, then the character’s face was noticed.

2 – We’ll create a second condition called CharacterDisguiseSeenThrough. We’ll be lazy and say that this condition is fulfilled when the “Perception” value of the observer is greater than the arbitrary value of 50. This allows us to re-use the condition argument for checking perception.

3 – The hardest to resolve stimulus is CharacterFaceNormal, since the face must be noticed and the disguise must be seen through. It will be tried first as it has the highest priority. It must meet the requirements of both conditions above, so we’ll wrap them both into a condition set called CharacterFaceDisguisedSeenThrough_CS, which has the AND operator. What this operator means is that both child conditions must be true for the parent to be true. If it was OR, then if either was true, the set would be true and if it is NOT, then neither should be true in order for the set to be true. Strictly speaking, since both conditions are using the same attribute on Observer, only the more stringent is needed. We could do away with the set and use CharacterDisguiseSeenThrough for the same effect, but we want to demonstrate a set here. The three memes to the left of CharacterFaceDisguisedSeenThrough_CS collectively form a namespace wrapper.

4 – If CharacterDisguiseSeenThrough is unresolved, we’ll fall to CharacterFaceDisguised. This uses CharacterFaceNoticed directly.

5 – Lastly, with the lowest priority, comes CharacterFaceUnnoticed. Its condition (a condition is always required with a conditional stimulus) is Memotica.True, which is a dummy condition that is always true.

6 – These three stimuli are of course linked off a single conditional stimulus as only one can be displayed at a time.

7- Lastly we’ll add a few additional sets of aliases. Let’s presume that our character uses two different aliases in each the disguised and undisguised modes. Knowledge of the Aliases is independent of one another. The observer may know one, both or none. The two disguise aliases have CharacterFaceDisguised as an anchor, so that stimulus must be resolved for them to be resolved. The normal aliases are anchored on CharacterDisguiseSeenThrough.

The total ensemble looks thusly.

Names and Aliases

The forum poster topozan started a thread on the MMOPRGmaker.com the other day that made me think. The issue was about hard coded character names; the floaty names above characters’ heads that are nearly ubiquitous. This is often the source of gripes by roleplayers; mostly because people can’t help but metagame them. Common gripes include people knowing names before being told to becoming extra suspicious about disguise attempts to plain old fashioned acting differently when they know that there is a PC around instead of the NPCs that they usually ignore. (one could turn this last one on its head and ask why players are so prone to metagaming NPCs as furniture)

To get names “right”, we have to contend with several issues:

• If I introduce myself as bob to another character and bump into that character again, it is reasonable for that player to see “Bob” floating above my character.
• If I’m wearing a mask, it is not reasonable for him to see “Bob”. If I remove the mask, he should recognize me.
• What about if I’m wearing a mask, but I’m also wearing distinctive clothing? That guy is the mask is probably Bob.
• What about if that character tells a third character my name?
• What about nicknames and aliases? How many people do you know by nicknames or short forms and were surprised to find out their real, full names?
• What if you “know” the disguised variant as one person under one name and the undisguised version under a different name?
• What if you recognize the face, but don’t know the name?
• And so on…

We actually have two separate levels of information in the above example. First, the observer will have to notice the character in the first place. When I mean “notice”; what I actually mean is notice more than . In real life, this depends on many factors. In a crowd, we are likely not to notice the people we don’t know and may even miss ones we know. If the observer is busy or daydreaming, the likelihood of noting the facial features of strangers or recognizing friends goes down. Distance plays a role. Lastly, physical attractiveness. An attractive woman is certainly much more likely to be noticed by either gender. For our example, let’s take the least complicated approach and lump everything into “observer perceptiveness”. Then there is the question of knowing the name of the person you recognize. The logic flow of facial recognition to name association looks something like the chart below:

We can accomplish this fairly easily with Memotica stimuli. Our character is represented by an Agent entity. One of the child memes of the meme Memotica.Agent is Memotica.StimulusChoice. The Memotica.StimulusChoice is a device for allowing us to attach any number of stimuli to an agent. Each StimulusChoice has any number of Memotica. ConditionalStimulus members. The ConditionalStimulus in turn contains a condition/stimulus pair. In plain English, if the condition is met, then the stimulus is broadcast to the observer. ConditionalStimulus tests are evaluated in order of their declared priority, with the one that is first valid being the one sent to the observer. In Memotica parlance, checking stimulus condition and encoding it in an appropriate manner for the observer’s client technology is called “resolving” the stimulus.

We have two separate levels of stimuli in our example. Since the alias of an agent is dependent on the observer recognizing her and then associating that recognition with a name, we’ll need to process this in two phases. Fortunately, Memotica gives us a tool for doing this. A stimulus may be given an anchor. A stimulus with an anchor requires that other stimulus to be resolved before it can even be checked. You might want to do this in the case of resolving different meshes as stimuli; such as whether an agent is seen as a little girl or a demon by the observer. In this case, the texture would be dependent on which mesh was chosen. In our example, the name alias of the agent is dependent on the choice of recognition level: anonymous, fooled by disguise and real person noted.

In tomorrow’s episode, we’ll build the Memotica diagrams.

A Room with a View

I’ve been wondering lately about how to handle scope and scale in a PW. This is related to things like zoning and seamless worlds. Developers on the forums for various engines constantly ask for seamless worlds. Players also often ask for them. Three things strike me:

1. Most of the large worlds that have actually implemented them serve as cautionary examples. The great big, seamless world may seem like a nice bullet point for the marketing list, but it is not possible to actually fill that space with content. So the content in the interconnecting regions becomes procedural. Procedural turns the countryside into flyover territory. Our community and indy worlds are SMALL. There is no way that a group of hobbyists working in their spare time can ever produce the kind of content to even contemplate large, seamless worlds.
2. Indy and community teams are beggars rather than choosers when it comes to engines. We hobbyists/indies are not using Hero or Unreal3 with Umbra. We are using things like Realm Crafter, Torque and Unity. We might use an OGRE 3D based engine that supports paging or they might be running an older version of Torque, such as TGEA. Neither of these is problem free and Garage Games has even removed the paged Atlas terrain from its new Torque 3D version due to the numerous problems it caused. Then the whole issue of resource allocation on the server creeps up.
3. Zoned worlds create a hybrid nodal/coordinate based geography. With coordinate based geography, if I want to travel from the desert to the polar icecap, I’d have to traverse transitionary terrain in between; that is if the designer does not want to break the magic circle and provides a sensible transition from the hot, sandy desert to the frozen wastes. In a nodal system, distance is in arbitrary steps and I can simply ignore that transition zone. You leave the desert and enter the arctic. Zone based systems are locally coordinate based and globally nodal. If fact, you can even do seemingly “impossible” things like having Narnia inside a closet via a zone transition.

But… seamless – or at least very large – worlds have certain advantages, not least for the economy. If currency has mass and there is no universal banking, distance starts to matter. If distance matters, the price of “nice Chianti” won’t be the same in Bangalore as in Tuscany. (in fact, it is about four times as much) That jump between the desert and icecap that takes only as long as a load screen means that it is not hard to bring polar bear furs to the bazaar in the desert and that scorpion venom can easily be delivered to the ice lands. Nothing is rare and everywhere is local. Might there be a way to gain the advantages of large, seamless worlds, while keeping the advantages of a global nodal geography and staying within the small, zoned paradigm that hobbyists and indies have to live with? Here is something that might be worth experimenting with:

• Use a few large zones.
• Reduce the movement rate of characters to something sane. Seriously, using the “default” run in many game engines translates to simulated speeds that are only achievable with motorized transport in real life. Dropping the rates to something that humans can actually achieve makes a 4km x 4km zone take 45 minutes to traverse at a walk and half that at a trot.

These two things already go against the grain. There is increasing emphasis on convenience these days and physically slowing players down is anything but convenient. We are designing for immersion however. Now comes the potentially controversial bit… If two zones are very distant from one another, impose a time cost in travelling there. We have two ways of doing this:

1. Incommunicado - If it takes two in-game days to traverse the forty miles that are supposedly between zone A and zone B and the in-game clock runs at 6x real world clock speed, then that character is underway for 8 hours. The key is that it takes real time to travel between zones. If you want to haul your goods to a distant market, you’ll have to accept that your character will be travelling and unavailable for the better part of a workday. If you want to meet your friends for a run on the evening, everyone will have to plan ahead and send their characters to the meeting point ahead of time.
2. Hybrid Text/Graphical – We need not put the character incommunicado during the transit time. We can implement text zones in between the large graphical zones. On text MUDS, the nodes that are called zones in most MMOs and (and areas in NWN) are called rooms. The character could still be available via persistent worlds’ web page or game client in a series of transit nodes. If the travel is automatic, characters can still be accessed, managed, checked on and even re-directed. If it is manual, then the player traverses a series of text rooms.

Has anyone ever built a hybrid text/graphical world?

Deep Physics – Moment of Inertia and Animation Profiles

In the last installment, we gave a high level overview of rotational energy, momentum and moments of inertia. None of these things are covered in modern “physics” engines. What we call physics engines would better be called “rigid body” engines. This means that we need to devise a way of dealing with these attributes.

Moment of inertia depends on the distribution of the mass relative to the pivot point. This means that you can simply define a number and leave it at that. You have to track your mass distribution. We already have a tool that gets us part of the way there; the 3D mesh from the model(s). If we have a character model and a sword model attacked to a dummy node located at the character’s hand, we have two defined objects and a constant mass, bit the moment of inertia changes every time the character moves. The brute force approach would be to devise a mathematical model – a single equation – to determine the moment of inertia at each. Our swing motion is a smooth motion through an arc and the position and orientation of each mass in that motion results in an and ugly and expensive to solve equation. This is impossibly impractical for each motion permutation, so we’ll impose a couple of tricks.

The Horse can be approximated as a sphere

The above statement means that we don’t need to be exact and we can get away with a lot of approximating. Specifically, we’ll do two things.
We have explicit time slices where we know the exact configuration of the masses in our character/sword system because we have the animation key frame data. We’ll solve I for each key frame only and hand wave/approximate it. This is also how physics engines approximate rigid body motion. They don’t solve Hailtonians or Lagrangians. They step through time slices.
We need to have the mass distribution of each object. It is right there in the 3D mesh and we can pull it out with an algorithm. We can even go a step further and reduce that mesh shape to a collection of points representing the mass distribution of the object. The moment of inertia for a point mass is simply its mass times the distance from the axis of rotation. This makes for a speedy calculation.

The leftmost image is the blade from the sai model that eq2001 put up on turbosquid. The middle is that model with a rough approximation of its mass by individual point masses superimposed. The rightmost image is the resulting “mass cloud”. At each keyframe, we can now easily determine the total moment of inertia. This allows us to calculate such things as angular momentum, kinetic energy of rotation, etc.

In fact, we can take it a step further. If we agree that a character’s “strength” attribute defines his/her ability to generate torque and that a given character would have a “terminal rotation velocity”, where the motion simply can’t accelerate anymore, then we have a few more tricks up our sleeve. If the motion has not yet reached its terminal velocity, then we can – in principle – shift the keyframes around in time. Weaker characters, or ones wielding heavy weapons, now swing slower than strong characters or ones wielding light weapons. We can call this shifting of keyframes an “animation profile”. It is essentially a list of time/space shifts in the keyframes. This requires a change to the way that clients typically handle animation calls; namely that an additional parameter of the animation profile list.

Roleplay Builds

Dana Massey of mmorpg.com wrote an inflammatory piece last week, essentially calling roleplayers on MMOs crybabies and drama queens. The following day, Sanya Weather, also of mmorpg.com and eating bees, wrote a more nuanced piece laying out the problems that MMO operators face when setting up a roleplay server. Given the extra support costs associated with roleplay worlds, it is not a surprise that operators don’t put too much investment into roleplay servers. Also, on the so called roleplay servers, many (most?) players are there simply for the restricted general chat and character naming schemes and not in it for the RP at all. This is a problem for roleplayers. Deeply immersive roleplay is a bit like canoeing on some wilderness lake. You can enjoy the mist, the quiet, perhaps see a moose on the lakeshore and hear a loon. If someone comes along on a jetski, there quiet is shattered, the moose is scared off and the loon flies south for the winter a bit early. The canoeist, who’s trip has effectively been ruined sees only two options; to stew and be angry – becoming like “those who shush you on a campus library on a Friday night” to use Massey’s example – at the inconsiderate jetskier, or give up on enjoying nature and also jetski. Just as there are those who choose to be in the library on Friday night and there are those who choose to canoe on the deserted lake at dawn, there are those who simply want to roleplay in peace. They search about for guilds of likeminded individuals, search for the nooks and crannies where they can roleplay unmolested, away from those who don’t understand, or respect RP. Many simply give up roleplay in persistent worlds because of the lack of immersion. In the NWN persistent world community, those worlds with “lite roleplay” restrictions eventually (quickly actually) turn into “no roleplay” and the only ones where roleplay is really possible are the IC obligatory ones.

Even in what should presumably be the roleplayer heaven of community run, ic-obligatory, roleplay worlds, all is not well. The playerbase is torn between the gamist instinct and the simulationist and dramist instincts. The gamist players- being more focused on the game aspect – will invariably end up with top flight builds that might be a bit of a stretch in terms of character development logic. A certain subset of the playerbase will deliberately gimp their character builds because a blind knight with a severe limp is an interesting character to play. Another subset won’t deliberately sabotage their character’s build, but won’t stick to the excel sheet plan if the roleplay direction dictates something else. This is how you end up with wizard/rogue/shadowdancer/blackguard combinations. This leads to tension between the powergaming gamists and the other two factions and lovely message board threads about “rp builds” and lectures from the gamist faction about the Stormwind Fallacy.

In her article, Sanya Weathers lays out all of the requirements for implementing a roleplay server in a normal MMO environment. In addition, near the end she muses that the game needs to be designed from the ground up to accommodate RP- which – like hardcore PvP – is a nich player set with a unique set of requirements.

All these special needs for a population that won’t exceed 10% of the playerbase, and can’t agree on a single definition of roleplay? It’d almost be more cost effective to make an entire niche game for this playstyle, rather than trying to make a massively multiplayer game that equally appeals to the roleplayer and a mass market audience.

I’m not sure I completely agree that there should be no OOC communication channels. Like David Bowers, I feel that OOC communication actually helps strengthen roleplay. Even NWN fails at being a complete immersion environment, because at the end of the day, its diku-ness is hardcoded in. There will always be a powergaming versus RP tension, even in the best of communities. So what can be done? There are two things in addition to Weathers’ list that can go a long way to building a perfect RP storm.

Character Applications – If you want to play on a world, you first need to familiarize yourself with it enough to write an application proposing a character concept to the staff. If you want to create an additional character, you need to apply for it as well; along with each additional one. Some regard this as an annoyance. That is precisely the point. The theory is that roleplayers who want to be left alone in peace are more willing to jump through these hoops than the inconsiderate, immature, anti-roleplayers who want to grief them as well as the “roleplay lite” players who don’t actually do much roleplaying. Most of the latter two groups are of the opinion that “applications are stupid”. Text MUSHes and some older NWN RP worlds used this technique very successfully.

Rethinking rules – This one is trickier, but anyone designing a roleplay world needs to address the powerbuild/rp-build dichotomy. The best way to do this is to make the character and player domain knowledge one and the same. Make the best swordsman on the server the server be the one played by the player with the most dedication to roleplaying a swordsman; not the one who always skips interacting to hunt. This is not to drive the gamists off, but rather give them incentive to be more IC. By replacing spreadsheet analysis with IC discussions of strikes, counterstrikes, tactics, motion analysis and even allowing them to invent new moves and new styles (via player created content), you remove the powerbuild/rp-build build tension by conflating the two.

Prepreproduction

There are certain things that I’ve done and that I’ve seen done that can contribute to a world imploding during development. As I’d mentioned in earlier installments of the Etilica postmortem and as Phil had also mentioned in the comments, Etilica needed to be “clean” when it left beta. How might have this been accomplished? You need solid preproduction. Professional game developers tend to use terminology derived from the entertainment industry. Thus, instead of requirements, specification, design, development and testing phases, they have preproduction, production, rollout and operation. There is a pretty clean overview of this process, written by Richard Bartle in his book, Designing Virtual Worlds. Some of these bullet points are not entirely applicable to small teams and hobbyists, but the basic idea holds. I can say from experience that you should not skimp on the preproduction phase. I can’t guarantee that having one will be the magic bullet of your success, but not having one will give you grief.

At the end of “preproduction”, you want to have to following two things:

A design document that you can always refer back to - There are excellent write-ups here and here on Gamasutra for writing design documents. “Real” designers may have better things to do than write documentation when they really want to build, but that document will encapsulate your vision for everyone on the team. If your team always remains one or two guys, you can get away with not doing this. This document will entail how the subsystems (of the prototype below) function, how gameplay works, special shticks if the world has any, and basic, bullet pointed lore.

A working prototype with all of the core systems in place - A barebones world with all of the core systems in place should be playable. It may not be recognizable as the one you are planning to build; in fact, it is better if it is not. It does need to have all of your complex custom subsystems in place. Do you have a unique faction system? Do you have a custom dynamic encounter system, loot systems, crafting, character advancement, death, scripted AI, etc? These should all be in place.

A professional team would probably just have something minimal to show case gameplay ideas and leave their implementation up to the programming team during production. For a world build by volunteer hobbyists and indies, you’ll need more. The industry term for a pre-alpha, yet vaguely playable level mockup is a hull. A hull has no visual details and probably only has a plain texture thrown on the geometry to be able to see it in a game engine. It is just for testing concepts at this point.

You’ll need a keel (yes, a play on hull) for your world. You and the team you recruit will be extending it from there, but the foundation remains the same.

What you should avoid:

Resist the allure of “agile methods” during preproduction– Many amateur worldsmiths have probably never heard of agile methods, such as SCRUM. It can be an alluring idea. The central concept behind agile methods involves creating a deliverable every 30 days (or 20 days, or 6 weeks, etc.). The opposing approach, known as waterfall development, is currently out of fashion among software developers. Its premise was first you clearly define your requirements (qualitatively what the software will need to accomplish), then you clearly specify a set of key performance indicators (KPI’s) in a specification document (quantitatively what the software will need to accomplish), then you design it from soup to nuts and finally you sit down to write the code. The idea is that the code will flow and be relatively (not completely) bug free. Waterfall development often suffers from the problem that requirements are not completely known initially, or change, or that a proposed design element is not as completely and utterly awesome as envisioned once coded.

Agile development came into fashion because it addresses this. Taking your development in bite sized chunks has great merit. Ensuring that you have a deliverable every 30 days is a great way to keep moral up (after all, milestones are clearly being reached). A protracted design phase – as happens with waterfall development methods – can give people the feeling that nothing is happening and cause them to leave. I’ve seen this firsthand more than once. Often, there is some guy insisting on doing iterative development from day one. If you follow his advice, your group will quickly make progress and will be passing around its first screenshots in no time. In fact, I’ve seen more than one group on MMORPGMAKER use screenshots as the evaluator of progress. Then sometime down the road, you’ll run into a wall where your world is of undocumented complexity or there is no clear consensus about a particular design point.

Having a design document to refer back to prevents this. Save the SCRUM for production. In fact, you will be practicing waterfall development where preproduction is the requirements/specification/design phases all rolled into one and production is the implementation phase. Learn to love it.

Don’t recruit your team until after preproduction – Remember what I said about members feeling that nothing is happening? During preproduction, there will be a phase where it seems this way. After the initial brainstorming phase, there comes a period when you have to flesh these ideas out and come up with a design document and perhaps some code design to do with it for the prototype. That modeler you recruited from deviant art on the second week? He won’t have anything playable to put his models into. That lore writer you found? At this point, she’ll either start rewriting your cannon or will get bored and go back to whatever forum you found her on. That programmer you found on sourceforge? Programmers have a habit of measuring their productivity by code written. This is especially so for undergrads looking for a project to burnish their resume with. Once you have a design document in hand, have chosen an engine and prototyped your main gameplay elements, your project will look much more attractive and will give a greater feeling of progress. It will be much easier to recruit and hold onto people.

Lastly, having a design document handy when recruiting allows you to recruit them into the vision. I can’t stress enough the need for all of the team to drink the kool aid; even if nobody else in the universe does. This allows your world to have direction and not turn into a herd of cats.

These Elephants Don’t Dance

In my last post – the dancing elephants definition, I mentioned about how medieval European military architecture is unsuitable for use against war elephants and how its verbatim use in fantasy settings opens the door to breaking immersion. The conclusion that a reader might draw from it is that if immersion is a high priority, then I would claim that there should be no castles, or no elephants (or fantastic beasts, magic. etc). That is certainly an option and if a designer is working on a sci-fi, modern, etc. setting, then such reworking of the lore to fit gameplay is easily done. If you are creating an edgy and “different” world, then your task is easier.

But what about fantasy? The dirty little secret of fantasy setting for virtual worlds is that they are perennially the most popular, for reasons that are endlessly debated. What is undeniable is that the tropes are popular. Two of those tropes are castles and large, fantastic beasts. Is it possible to elephant proof a castle – much less dragon proof it; without ruining the feel and turning it into something that players won’t accept?

There is a country where castle builders did have experience dealing with war elephants. This country is India. In the centuries of warfare between the Hindu Rajput kings and the invading Muslim Mughuls, elephants were regularly used as war machines in India. Castles built on the northern part of the subcontinent had to accommodate the use of pachyderms by attacking forces. They did this with a few neat tricks that can be seen by visitors to places such as Jaiselmer Fort and the Mehrangarh Fort in Jodhpur; which is pictured in the header picture of this blog. Both may be slightly different from European castles, but are unmistakably castles in their feel.

The first trick was to have a series of gates and a mazelike entrance to the castle. Each gate came after a 90° (or greater) turn. This prevented any charging elephants from picking up speed – so no charging attacks for them. You can see in the picture below – taken from inside one of the gates at Jaiselmer Fort, looking outward – that there is indeed a 90 degree right turn just in front of the gate. There is a hairpin turn at the next gate, just behind the camera.

You’ll also notice that there is no row of murder holes just behind the door. Instead, there is a raised platform that can accommodate a phalanx of defenders on either side. This forces the breaching elephant to run a gauntlet of spears. If the elephant can be killed in the doorway, it effectively re-seals the passage that was just breached. Murder holes would limit the number of spears that could be brought to bear.

Gates at Jaiselmer Fort

Lastly, circumstantial evidence suggests that elephants don’t much enjoy ramming their heads into spikes. This array of spikes at elephant head level is on one of the gates at Mehrangarh.

Door Spikes at Mehrangarh

Sometimes, keeping your elephants from dancing just takes a hairpin turn and a few spikes.