Wipes and Avatar Capital

Planeshift – who’s Laanx server is one of the few roleplay centric worlds that is not a text MUD or NWN PW – is nearly ready to iterate to version 0.5. Last week, one of the developers, Xillix Queen of Fools, opened a discussion gauging the playerbase’s feelings about a wipe. Predictably, the forums erupted into a massive furor. Planeshift has not wiped in years, despite continual development. I’m not privy to the inner workings of the dev team there, but given that the player reaction to a wipe is going to be highly emotional they have probably been following a trickle down strategy regarding changes; where changes in design are made and slowly filter through the world. If they are at a point where they are seriously considering a wipe and gauging player reaction, then they are probably at a point where they feel that the current database content is a serious technical liability; one that can only be fulfilled with a wipe.

One interesting thing is that the PS team has always been clear that players should expect a wipe sometime and they are certainly not making the mistake that Radu Privantu made on Eternal Lands when he did not tell players to expect a wipe in the future. Yet despite this, opinion is only marginally in favor of a wipe and many, many players are especially vocal in their opposition.

Given that Planeshift is still an avatar capital centric world and that the opposition largely stems from reluctance of many players to re-grind characters at the top of the skill hierarchy, my question is as follows. Would a world design that less avatar capital centric (say with flat skill/level hierarchies) be immune to such drama?

Memotica Stimuli

Memotica’s stimuli are part of the world trinity of actions, entities and stimuli. In Memotica, entities have state, actions change that state and stimuli report about it. I’m putting the finishing touches on how memotica handles complex stimuli. In fact, I’m just about ready to start coding the stimulus handling portion of the interpreter code and I need to work out the stimulus corner cases before I call it a day on design and go to code. What I’m looking for is ideas on how to accomplish the same flexibility with less complexity and additional corner cases so that we can do thought experiments before going to code.

The Memotica stimulus is a complex – but flexible – beast with a certain life cycle. A stimulus entity is created from a meme when something needs to be reported to a client. This client could be anything; a user, an AI superclient, another system, etc. This stimulus then goes through a series of life stages before seeing the light of day.

Stimulus Life Cycle

Filtering – A stimulus entity may contain “controversial” elements. A controversial entity is any entity in Memotica that is dependent on a condition being true. The very first step in bringing a stimulus to the light of day is filtering out untrue controversial entities.

Resolving – The filtered stimulus may undergo a process of “in context” transformation. “In context” means that it is subject to the state of any or all entities currently in play. Creating dynamic text strings must be done in context. The smell of roses is quite distinct from the smell of mold and it is possible to build both from the same stimulus by substituting different nouns. Which one is created is determined by the state the universe. Are there roses nearby? Is there mold nearby? It is not only text that may require resolving. Is the ball blue? Is the ball red? How big is the ball? How much does it weigh?

Resolving the stimulus may tell us that we have a blue ball, 30cm in diameter that weighs 100 grams. It tells us nothing about how we might inform the client of this information. That is handled in the next step, rendering.

Rendering – A resolved stimulus must now be prepared for a client. Rendering is out of context and does not require access to the state of any entity outside of the stimulus (or stimuli) at hand. Rendering the ball for a player’s 3D client might involve creating a COLLADA file with a ball mesh and a blue texture. Rendering the same ball for an AI engine might involve building a short message, [BALL, BLUE, 30, 0.1], that is readable by that particular engine. Rendering the ball for a text client might involve selecting the fallback text description.

Any particular stimulus may skip any of these steps. A stimulus with no controversial entities need not undergo filtering. The COLLADA renderer for the ball may be perfectly happy with the filtered entity and may not need any interim resolving. Resolved Unicode text probably needs no additional rendering beyond having its text string plucked out. A stimulus entity that is simply syndicating the state of an entity for another system may skip all of the steps between creation and being forwarded to its destination.

Stimulus Cluster Metameme

To delve deeper, first we’ll start with the stimulus metamemes. Stimulus is a simple switch with no attributes. Its children are AnchoredStimulus and FreeStimulus. If our child is a FreeStimulus, then it simply displays whatever descriptor (e.g. a text string, a mesh, a texture, etc) assigned to the free stimulus. A free stimulus is uncontroversial unless it has a ConditionalStimulus as a grandparent.

Anchored stimuli are a bit trickier. Their existence depends on their children. You would use an anchored stimulus if a supporting piece of information is required. One example is meshes. A mesh alone is useless. It needs a material. If the material can’t be displayed, then we wouldn’t even bother sending the mesh to the client. To find the materials, we would need to use anchors.

In general, this is how an anchored stimulus works:

• An anchored stimulus can have one or more free stimulus children. Any free stimulus children of an anchored stimulus are non controversial, but the anchored stimulus is itself inherently controversial.
• For the stimulus to be resolvable/renderable, at least one grandchild ConditionalStimulus must be true. The anchor member of an anchored stimulus is a collecting point for its controversial members. This Anchor entity may have 1 to n StimulusChoice entities. It is useful to note that FreeStimulus may have member StimulusChoice members by proxy as well, via the SuccessorStimulus; which I’ll discuss in a later post on creating text conversation trees.
• StimulusChoice is a mechanism for filtering controversial stimuli. A StimulusChoice may have one or more ConditionalStimulus member entities. ConditionalStimulus is the actual controversial entity. It is a pairing of a stimulus and a condition. As mentioned in my earlier post on names and aliases diagrams, when a stimulus group is filtered, only one of ConditionalStimulus’ members is flagged as true. This is the first one in the list that returns true on the condition check.
• SuccessorStimulus is a wrapper for additional stimuli that have conditions attached, allowing us to build recursive tree structures of stimuli; known as stimulus clusters.

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?

Some interesting ideas on PW economies

Some interesting ideas on PW economies

Chris (talin) Brown published an interesting concept for a PW economy that draws some inspiration from Sam Lewis’ GDC presentation on the subject. I’m not sure how it would work in practice as it relies on a hypercompetitive PvP environment ala Eve or Darkfall, but it is interesting.

Design Documents – Yes, you need them!

Hallsofvallhalla started a conversation on Friday questioning the value of design documents. I think he is mostly wrong and partially right. I’ll start with why I agree because that is easiest. Most design documents that I have seen are not terribly valuable because they focus solely on the color of the bike shed. They discuss things like level layout, class abilities, races, etc. and ignore the deep decisions about the physics of the world; how it actually works. The design doc should be useful to all team members; not just artists and designers. Now the other side of the argument:

Architecture Matters

Persistent worlds are certainly complex enough to require serious planning. Part of preproduction – and an important part of the design document – is figuring out how to do the hard problems. How will inventory work? How can it be implemented? Etc. Etc. Unless you want to constantly be throwing your work and starting over again, these things need to be worked out before you write a single line of code. All too often, I see freshly started projects publishing screenshots, which hints that they have skipped preproduction entirely.

While writing the Angela interpreter engine for Memotica, I’m reaching the point where I’ve got the core of the interpreter to the point where I’m writing the brokering mechanisms for actions and stimuli. I designed the overall, high level architecture of the engine over a year ago and looking back on it now allows me to continue without flailing about and redesigning the whole choreography. In short, the time spent then is saving me considerable time now.

The ship needs a rudder

Where is the project going? Is it still going in the same direction as six months ago? Or is it adrift and rudderless, buffeted by whatever is being talked about on the project’s forums?

A dirty secret about community/indy teams

One of halls’ argumenents against design documents is that it acts as a straightjacket that restricts creativity and makes the project less interesting to portential team members. One of the dirty secrets is that half of the people who show an interest in helping out a project are useless. They have neither the work ethic, nor the patience and tenacity to stick with the project and be productive. They will happily shoot the breeze on your forums and pontificate endlessly. Do you really want these people setting – and changing – the direction of your project? 90% of the other half are only valuable if they were recruited at the right time and there is consensus on vision; two things that are only possible after the valley of tears phase.

The valley of tears

Every PW project goes through the valley of tears. This is the phase in the project when the interesting theoretical discussions have been had and it is clear that it won’t take weeks to realize the world, but months and years. It will seem that “nothing is happening and the project is going nowhere” for long stretches as the foundations are laid. This is a time when no flashy screenshots are created, but instead the plumbing is laid in. In the worst case scenario, you will be the only person sticking with the project during this time. Projects whose leads allowed them to turn into designed by committee, vampire/puppy/rainbow monstrosities tend to die tragic and lonely deaths in the valley of tears; identified only by the lonely husks of once active forums that will one day disappear into the great 404. You didn’t let it turn into something that you are not entirely happy with during the pontification phase did you? Because it is your passion and drive that will see the project through to the promised land on the other side.

Please tell me that you are recruiting your team at the end of prepreproduction!

You have a prototype. It may be butt ugly. It may not be very performant and will need the attention of better programmers than yourself. The important thing is that the project is past the valley of tears phase, is picking up speed and has direction. The people you recruit at this phase will be attracted to:

• The fact that it has direction. Hey, we have all been on teams with no rudder or team stuck in perpetual pontification mode. Being on a team that is on the move has its own attraction and for years has been one that Luca Pancallo (Talad) of Planeshift has used in dev team recruiting drives.
• The vision. In the pontification (a.k.a. early design) phase, you will inevitably find that others want your goth-vampire world to be about puppies. Perhaps those puppies could have a vampire option as a compromise, but rainbows are much more important. The kinds of people who join because they read your design doc are true believers.

The live team that runs the PW won’t be the same as the one that initially works on it

I don’t say “built” or “delivered” as community worlds are never finished and are always works in progress. People come and go on the project and over time the composition of the dev crew will change. The people coming in will need to sign onto that vision. When a player (always a self identified “ideas” person) starts pontificating about how you need to change your world, you can point him to the vision. Not having a clearly defined vision contributed to Etilica’s death spiral. From the perspective of the leads, I was probably a rogue developer. If there was a design doc to refer back to, we probably would not have been in the habit of surprising each other with changes.

A final caveat. The document need not be set in stone

A design document needs to be a living document. You’ll want to prevent the pontificators from rewriting your design document, but you’ll also want the committed team members to effect change as long as they earn the right. As these committed team members get their ideas accepted, the design doc should be updated to reflect the new status quo.

How do people feel about meta-roleplaying?

Creating alternate player personas has a long history in roleplay environments and it does always stop at the character. Some players are open about their real world selves and are clear about the level of the roleplay. “Hi, I’m Bob the sales manager from New York, but my character is an evil elven mage”. Others meta-roleplay player personas to a greater or lesser degree. I never thought about it much and tend to assume that player personas – especially those players who are coy about their own identities – are likely to being meta-roleplayed. I thought about the issue again as there is a thread on the Planeshift forums about meta-roleplaying. The discussion’s OP clearly did not think it was a good thing and complained about “wasting time” showing a player the ropes when they already knew them. From the perspective of the meta-roleplayer, it makes sense not to let on that the player persona itself is being roleplayed.

My question is how do people generally feel about meta-roleplaying.

There was once a player. She was a good roleplayer and had an easygoing and friendly personality; which made her easy and fun to play with. This made her popular wherever she went. It made her so popular in fact that she would get a storm of tells whenever she logged in and felt that her character received “special” treatment. So one day she tried an experiment. She created a new account and logged in with a new character on her alt account. She found a completely different experience. She found that people behaved less familiar and more respectfully with the new “player”, but also more aloof. She considered it refreshing to simply be able to roleplay anonymously and developed a habit of using alt accounts, sometimes dual boxing them to misdirect any suspicions that might develop that these multiple players were in fact the same person.

On an old Neverwinter Nights PW, the GM (DM in NWN parlance) team members always used alter egos when logging into the forum or game to mask their other identities. This was usually done to shield the GMs from a storm of GM’ing related tells when they were off duty and to prevent players from acting differently around players that they knew were GMs. Some were an open secret and everyone knew that GM persona X was in fact player Y, but some were closely held and players in the community would gossip endlessly about the identity of new GMs.

Then there is the whole subject of myspace roleplay.

My last example is potentially the most interesting as it had shades of a story about a tree. The player was a man. He played a female player playing a female character. There were multiple levels of roleplay. He had gone to great lengths to build his player persona. He had created a yahoo profile many months beforehand using the femininized version of his name and a photo of a moderately attractive woman in the profile. This is a classic meta-roleplayer step; to give the alter ego a believable internet footprint that can easily be googled, but not enough to cause cognitive disconnect when “she” does not meet other players at gatherings or speak to them by voice. The female “player” was extremely outgoing in the community that “she” played in and became a highly networked player. Over time, she amassed a small following of “fanbois”. He was a US Army reservist. When he was deployed to Iraq, she went to Iraq and the community followed “her” experience there. She was able to acces the game from the war zone and remained active.

The meta-character had developed personal relationships with some of the other community members. When she was coming down to her last weeks in Iraq, she sent a quick message that she had been badly hurt by an IED. I had been expecting this. The player persona was starting to make commitments to visit other players after returning from the war zone; commitments that could never be fulfilled without letting the cat out of the bag. He was getting in too deep with her and killing her off in Iraq was a wonderful way to get out of the bind he was in. She “survived”, but was only intermittently active and eventually disappeared into the ether altogether. Aside from my misgivings about having highly networked players who are meta-roleplayed, I’d certainly be happy to have him play on my next world. That guy is a master roleplayer.

How do others see meta-roleplay?

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.

Deep Physics – Momentum, Moment and Rotation

In this installment of the deep physics series, we’ll continue turning animations into salad by looking at the rotational dynamics in animations. As a note of warning to the reader. I will try to explain some physics in a clear manner, without equations, but there is an element of leaving the bike shed behind in this discussion.

We’ll refer back to our sword swings in Monday’s post as our starting point. The important thing to note is that swords do their fine work by turning rotational kinetic energy into entropy. We’ll discuss the role of the first two laws of thermodynamics in a later installment. But before we can deal with energy dissipation, we have to get to the point where we have that energy to dissipate. This means accelerating the sword through its swing arc.

Rotational kinetic energy is analogous to linear kinetic energy; with the moment of inertia standing in for mass and angular velocity standing in for linear velocity. Moment of inertia is a funny beast – and an extremely important one in the dynamics of mêlée weapons. Inertia is the predisposition for all objects to continue with their current state – i.e. resist change. Moment is a term for a bending/turning force. Thusly, moment of inertia is the predisposition of an object to resist changes in how fast it turns. Moment of inertia is composed of how heavy an object is and how that weight (mass really, strictly speaking “weight” is the force mass experiences under the influence of gravity) is distributed. If you were to hold a bucket of water in your hand and spin yourself in circles, you would find this much easier to do than if you were holding that bucket of water on the end of a ten foot pole. The latter had a higher moment of inertia, even if the mass is unchanged.

Another interesting thing about moment is, the more MoI that a rotating body has, the harder it is to stop; obviously. This means that it has a greater rotational kinetic energy and momentum of rotation; also known as angular momentum. This is of course why a maul head on the end of a 3 foot handle is so much more effective at splitting wood than one held directly in your hand. So the shape of a sword and how it is positioned determine how hard it is to swing, as well as how hard it hits.

So our sword moving through an arc hits something. We know this because the physics engine determined that the collision shape of the sword hit the collision shape of something else. We simply assume that the sword comes to a complete halt, or that it rebounds depending on the material that it strikes. Whatever momentum is lost translates to kinetic energy lost to entropy. This gives us a clear, consistent, measure of damage that is consistent and removes the need to have a “sword” entry in a weapon damage table. In fact, it relieves of the need for such a table at all for kinetic weapons. We simply track kinetic energy and changes.

In the next installment, we’ll review a methodology for tracking moment of inertia, angular velocity, momentum and kinetic energy.