Multiplayer Interactive-Fiction Game-Design Blog

14 Fractures

One of the "really big" problems of a multiplayer world is that

player's can't change the world in any meaninful way because

any changes would also be seen by other players.

For example: If a village is under attack by goblins, and the

player kills all the goblins, then the next time the player enters

the village, it should be a happy place. However, if the player

fails to kill the goblins, the village should remain a burnt-out

ghost-town for the rest of the game. Thus, there are three

versions of the village: During the goblin attack, successfully

defended, and burnt.

Once solution to this problem is to create a private instance for the

village. However, the village will only ever be private, and

players have zero chance of encountering other players when they enter.

"Fractured reality" provides another solution. Basically, it allows three

versions of the village to co-exist in reality. When the player enters

the village, the player's character is whisked to one of the three

versions of reality depending upon "fracture flags" set in the

character. The same goes for all players, so that it's possible and likely

that players will meet other players in whatever version of the village

they're routed to.

The first step to creating a fractured reality is to fracture some rooms.

You can either fracture all the rooms in the map that need fracturing,

or you can fracture the entrace/exit rooms to the map and have each

fracture redirect the player character to another map.

For each fracture, you need to:

1. 
   
   Create a standard room as you normally would. Since the

   rooms are variations on the same room, you'll probably make several

   copies of the original room, or base the fractured room objects off

   the original room.

   
   
   




2. Come up with a lower-case string that will name the

   fracture, such as "firevillage" or "happyvillage". The default (original)

   version (which is being attacked by goblins) won't need a name.

   
   
   

Several rooms can share the same fracture string; there's no need

to have a "fireinn" and "happyinn" as separate from the village so

long as it's in the same village.


3. For each room, set pRoomFracture to list all the fractured

   versions of the room, as well as what fracture string determines what

   room the character is sent to.

   
   
   




4. If you have an especially tricky situation, you

   may whish to override the RoomFracture() method

   for the rooms.

   
   
   

Once the player has defeated or lost to the goblins,

call cCharacter.FractureAdd(), passing in either the

"firevillage" or "happyvillage" string. You'll

need to also move the character (and anyone in his party)

to the new fracture. If you don't move the character, the changes won't

occur until after the character moves into another fractured room.

If the character is a member of a party, make sure to call

FractureAdd() for the leader of the party, since all

party members take their fracture flags from their party leader.

You can remove fracture flags by calling FractureRemove().

Calls to FractureQuery() will test to see if a flag

has been set.

An easy way to test whether an object exists within the player's

fractured world is to call IsInDifferentFracture().

You may run into cases in a multiplayer game where a NPC needs to disappear in the eyes

of some players, but not others. For example: The player may complete a quest, one consequence

of which is that the NPC disappears.

To do this:

1. Set oNPCThatDisappears.pDoesntExistForPlayer to TRUE. (You can set it

   to a lower-case fracture string, but TRUE is usually easier since the fracture string

   is automatically generated.)

   
   
   




2. When the quest is completed and the character should disappear,

   display any relevent descriptions, and call oNPCThatDisappears.DoesntExistForPlayerSet().
   
   





3. To see if the NPC doesn't exist for a specific player,

   call oNPCThatDisappears.DoesntExistForPlayer. Support for DoesntExistForPlayer() is

   automatic in the game's code, and is handled in other methods such

   as IsInvisible().
   
   

Traditional multiplayer worlds have a problem: Players aren't allowed to kill NPCs, because if they were,

other players would never get to meet the NPCs.

CircumReality has a solution for this. Players can kill NPCs. The NPCs will be

resurrected but after the NPCs are resurrected, they won't be visible

to the players that killed them... thanks to fractures.

To make a killable NPC:

1. Make sure the NPC is based off of the class, cSaveToDatabase. Almost all

   NPCs will be based off this anyway, since the class is necessary for them to remember

   players.
   

   
   




2. Set the NPC's pDamageCanBeAttacked to TRUE, so the NPC can be attacked.

   
   
   




3. Set the NPC's pDoesntExistForPlayer to TRUE, so that if can be fractured.

   
   
   



4. 
   
   Don't start the NPC with any directly created possessions of its own. There

   should be no oFredsShield and oFredsSword for the character oFred (who can be killed). If

   you do this, then only one player will be able to pull the object off the dead NPCs body.
   
   





5. Instead, fill in pLootEquip, pLootCreate, and pLootCreateOnDeath as

   per LootCreate(). Make Fred's sword and shield part of his pLootEquip. That way, every time

   Fred is killed, a new sword and shield will be created for him.

   
   
   

Players will be able to kill the NPCs. Other players will witness the NPC being killed too.

When the NPC dies, its body can be looted. When the body disappear, the NPC is resurrected

in its starting room with new loot. Anything on its body before the NPC dies will disappear.

The player that killed the NPC, along with the player's party, won't be able to see the NPC

after that, thanks to DoesntExistForPlayerSet().