Using Map Objects

[trollson]

Warning: This post contains content which may be disturbing to those of a non-technical disposition.

This post describes a general approach or implementation to allow static map objects to be 'used'. It relates closely to the "Interacting with the Map" thread.

Goal

I want to be able to make more use of the static objects which litter EL's world. At the moment there is very little interaction between characters and these objects, which serve as just eye candy or obstacles to be walked around.

 

I would like to use a forge to help my Swordsmith, or use a bed when I log off so I can start the next session fresh and healthy.

Implementation

When a character 'uses' a static map object (clicks on it with the 'use' icon), a field in their character record is updated to record the object selected (map object id) and their location. Think of this as another inventory or equipment slot.

 

When a character performs a task which requires or benefits from the use of a static object of some type, this field is checked for:

1. The selected map object, if any, is of the correct type.
   
   
2. That the character is still in the same location.
   
   

If this test fails, then the selected object field is cleared. If it passes, it is as-if the character was using, say, the

forge object

as a tool.

 

The selected object field is only updated when a character selects an item, or when it is checked for a task. We don't need the server to keep testing that the character is still in range of the object every time they move for instance. We don't even care if they have moved away and back since selecting it.

Applications

Static tools:

Recipes already require certain tools to be in a character's inventory for the product to be made. They could also require that a static tool be used, which would check the selected object when attempted. There are plenty of examples across the maps -- forges, mills, ovens and stoves, anvils, fountains, etc...

 

Augmenting Items:

Having an object selected may modify an effect when it is applied to the character. A shield spell may give a greater bonus if case when the character is "touching" (selected) some defensive object. Magical spell effects may be modified by different "magical" or mundane objects -- this could be quite extensive.

 

Bed Time:

Perform a selected object check on login (before the actor is placed and possibly relocated); if the character has selected a bed restore health and mana according to how long the character was logged off, less their equipped emu. Reward players for role playing, and putting their characters to bed, rather than sitting out in the rain all night. Encourages people to frequent Inns.

Notes

1. The character selects a
   specific
   object, even though tests require an object
   type
   . If a character selects the forge at
   A
   , but then walks to a different forge at
   B
   , a test will fail because it is not the forge they said they where using.
   
   
2. When we record the selected object, I've left it vague as to the actual numbers to be recorded. We certainly need the
   map object id
   , from which we can obtain the object type and either the
   object location
   or
   character location
   . Recording
   object location
   we allow a character to be within range (1.5m or 3 squares) of the selected object to continue to use it. Recording
   character location
   requires the character to stand in exactly the same location -- lower runtime overhead but more restrictive.
   
   
3. If we don't also record which map that the selection was made on, we must clear the selected object on a map change.
   
   
4. Consider "special events" that could be divined and sought out:
   "A major conjunction will occur over location A at time T, which improve the chances to make something special at a forge nearby."
   [1]
   
   
5. This approach can coexist with other more direct applications of "use" with a map object.
   
   
6. "map id"
   just identifies the map. Presumably this is just an integer (it need not be more).
   
   
7. "object id"
   is the index of the object within the map. Each map has an array of object records. The record then identifies the 3D model of the object, and its location (amongst other things).
   
   
8. "object type"
   is given by the 3D model of the object, where several different models can have the same
   "type"
   . This requires a lookup table to associate object model with object type.
   
   
   

From the above I prefer recording just the map and object id of the selected object. From this all other necessary information can be derived when the selection is queried.

This approach has a lot of potential applications, of which I have mentioned only a few examples. It would give reasons to visit a more diverse set of locations.

 

 

 

[1] This is what I hoped the astrology system would give us.

Edited February 14, 2008 by trollson

[xenkoriu]

Great idea! will get more people to roam about searching for interactable items and populate unpopulated areas.

[Vanyel]

I like this idea. Seems a very well thought out.

[Isenwolf]

sweet! so all those forges and stuff, they can finally have a use. makes it more realistic i think

[Entropy]

That's not a bad idea in itself, but the problem is that it needs to be useful.

For example, the bed idea is not so useful (compared to the effort required to implement it), because it is often faster to just be afk for some minutes with a fast restoration cape/perk, or cast restoration, or even heal, rather than go out of your way to find a bed.

 

The static tools idea is something I had a long time ago, and it is not very unique. Some games (Runescape, for example) require that you are at the right place to make the right item. Implementing this would be relatively easy, but people would hate it if I change the system to require them to go places in order to make items.

 

The augmenting effect is not bad, but again, it won't be that useful, especially during battle, when you don't have the luxury to just go near such objects.

[trollson]

Well, the implementation is about as cheap as you can make it:

1. Record which map object a character uses ("selected object").
   
2. API to get the selected object type, if valid.
   
3. API to clear selected object (optional, but reduces overhead of 2).
   

Then you can start to use the stuff on the maps, and you will find uses for this.

 

The suggested applications are just a few examples, not a definitive list. A test for "selected object is of type..." could be used in many contexts, including scripting.

 

The "Bed Time" isn't meant to compete with other healing effects (though that of course depends on how strongly it is implemented). It as a slight effect, encouraging RP behaviour, and should be trivial to implement if the framework is in place.

 

Lots of slight effects working together can make a richer environment. Can you think of another game reason for the beds in the taverns?...

...no, that would require new animations!

I know of the static tools discussions from a couple of years ago, and was wondering if these where ever going to make an appearance. This is why I made this post for a minimum-effort enabling framework.

 

Static tools need not change anything already in the game; reserve them for newer items, or alternate recipes for existing items, if there is a problem with riots.

 

Static tools can also be augmenting items; a recipe could have an optional static tool, which if used increased the characters effective level when making that item -- so its a lot easier to make that sword if you are using a forge or anvil. Deciding what items would benefit from what static tools, and how much, is a design & balance issue.

 

The use of augmenting items during a battle was prompted from "KF forts" thread, which bemoaned that PK areas where only populated near the entrances. Now, this doesn't solve that issue, but does give a means for terrain and features to become relevant in a fight (though it would be more interesting if characters moved while fighting).

 

 

Hot Spots

 

One thing I didn't mention in the OP, because it requires another component to be implemented, is to combine augment items with transient "hot spots". There would be an interesting game in finding (predicting or detecting) these "hot spots", travelling to their area, and finding an appropriate item to channel their effect.

 

Here, a "hot spot" gives a time and place, and a type of effect. Using a static object in some task, near that location and time gives a proportional chance of channelling the effect. Hot spots may arise from invasions, astrological conjunctions, natural events, etc.

 

If you want make it a race, then the hot spot vanished once somebody successfully channels the effect (uses up its power).

...All purposefully vague to let you map it to different scenarios.

2008-01-22: Hot Spot Implementation Requirements

Since hotspot idea could work quite well with using map objects, I'll elaborate a bit on what is needed to implement this.

 

Allocate space for a few (say 5) hot spot records for each map. Each record need only be a few integers long, consisting of:

• type of hotspot
  -- only one of each type per map. When checking if a hotspot applies, this is what is checked for. A type of zero (0) is no-hotspot.
  
  
  
• position (x,y)
  -- the centre of the hot spot. The effectiveness of a hotspot decreases the further away from its centre you are.
  
  
• time of occurrence
  -- a time stamp when the hotspot is at maximum effect. The effectiveness of the hotspot decreases as the difference between current time and occurrence time increases. A time stamp of zero (0) can be used to indicate a permanent hotspot.
  
  
• strength
  -- how this is interpreted may depend on the hotspot's type.
  
  

That could be as little as 12 bytes per record, or 60 per map for 5 records.

 

API calls are required to set, check, and cancel a hotspot:

• Set a hotspot either updates an existing hotspot of the same type, or uses an empty record, or fails if all records are used.
  
  
• Check a hotspot returns the effective strength of any hotspot of that type for a position and current time.
  
  
• Cancel a hotspot sets a record with matching type to type=0, unless it is permanent. Cancelling a permanent hotspot should require an explicit call.
  
  

Edited February 14, 2008 by trollson

[kailomonkey]

I know forge is the obvious one and we probably need some Other ideas here, but people already travel to their priests to reduce their fails and critical fails (with a temporary level boost). If forges could affect these or the make rare chances I can see people making a choice to travel to them.

 

Also, if we wanted some element of thinking and change (such as the hotspots idea) and wanted to also enhance the use of astrology (it was said that figuring the astrology out would be fairly straight forward) you could have each (in this case) forge fall under a different astro, perhaps due to its owner's astrology sign. In this way a certain place would be favourable to many types of mixers for the period it is in the beneficial regions. Using the existing signs and modifiers.

 

Perhaps this is less for forges and more for magic orb using, or for proximity from an NPC with Astro Transfer abilities (existing ones, including some storages even).

 

 

To try and curve deviation, I like the idea of going to bed, but ofcourse there would need to be sufficient benefits besides freeness. To deviate again with one idea, many believe that sleep and dreams prepare you for the day to come, and others have foretelling dreams. Perhaps a good 8 hours sleep in a comfy bed could reveal your character's astro for the day!

 

Or just the highs and lows of the days astro, something appropriate.

Edited January 21, 2008 by kailomonkey

[trollson]

Most of kailomonkey's suggestions are quite valid, but I'll highlight one point which could cause a headache:

...each (in this case) forge fall under a different astro...

What we should avoid is adding information to the existing maps; if two forges have different properties, then that information would need to be added somewhere, which is expensive.

 

I am trying to find ways to use map objects only using what information we already have, or global information (for example, a table mapping each 3D object model to an object type).

 

Other that that, some of what kailomoney suggests could be implemented using hotspots, some of which could be (semi-) perminant.

[ville-v]

if two forges have different properties, then that information would need to be added somewhere, which is expensive

For mapmaker, items can be different objects "forge1" and "forge2" that just look the same.

 

For player, the effect is something to be found out by trying.

[trollson]

For mapmaker, items can be different objects "forge1" and "forge2" that just look the same.

The map maker just chooses from a palette of 3D models, in which there can be a few variations on the same object type. This is why I make a distinction between the model and object type in the design -- making the table that maps models to types is a prerequisit of this implementation.

 

Adding to this palette, even just making a copy of an object under a different name, is not the role of the map maker, as this new object has to be included in the distribution.

 

But yes, if there where "forge1" and "forge2" models, they could be placed in different object types; but any map maker could then use either model, and the two would be different throughout the world.

 

Don't forget that there is always scripting to handle special circumstances, which could superceed normal behaviour in a particular instance.

[Entropy]

Anyway, if you come with some REALLY cool idea about using map objects, that would not fuck up the game's economy (such as give twice the manufactured items if near some stone), I will consider implementing it.

[ville-v]

Anyway, if you come with some REALLY cool idea about using map objects, that would not fuck up the game's economy (such as give twice the manufactured items if near some stone), I will consider implementing it.

Let there be special items only mixable near some map objects.