The Bears Pit: v1.13 Coding Talk » Self-Transforming Items (Pre-Project Discussion)

Home » MODDING HQ 1.13 » v1.13 Coding Talk » Self-Transforming Items (Pre-Project Discussion)

Show: Today's Messages :: Polls :: Message Navigator

Self-Transforming Items (Pre-Project Discussion)[message #293355]

Sun, 13 November 2011 03:46

Headrock

Messages:1760
Registered:March 2006
Location: Jerusalem

Yeah so, if I do ever end up attempting this, it has to be discussed first. It'll be important to find out what modders are expecting from this feature, what can be done, and of course what shouldn't be done.

Concept

If you haven't read about the concept of Self-Transforming Items (STIs... which means this project needs a better name ASAP), the idea is to be able to change an item's properties spontaneously.

The situation now is that the majority of items are "rigid", meaning that the item will retain all of its original stats for the duration of its existence. For example, a gun will always have the same range regardless of what you do with it. Attachments can change the final values, but these have limited practicality. Alternately, we have merges - turning an item into another item by using a third item on it. This is good for some things (like combining items to form the X-ray detector) but not practical for others. Sometimes we just need an item that can transform completely on its own - no merges or attachments involved.

The obvious solution would be to create Self-Transforming Items. The idea is that some items will feature transformation buttons, which allow the player to instantly turn an item into a different version of itself.

Transformation Mechanism

The idea I've always had is that, to transform an item all on its own, all we really need are buttons. In other words, the player gets one (or more) new buttons which, when pressed, instantly transform the item into another one. These would be called "transformators", "mode switches" or whatever other snazzy name we choose.

On the modding-side of the mechanism, modders create two (or more) versions of the item, and using an XML they "link" from one version to the next, basically defining parameters for the transformators (what a shitty name).

When the button is clicked, the game checks the transformation tables as read from the XML, determines which item our target is supposed to turn into, and then simply switches the existing item with a new one.

From the player's perspective, it would seem as though the item changed. In essence, we just switched it with a new item, but the result would be identical - especially if we take care to copy the relevant sub-properties of the "old" item to the "new" one, such as its condition, ammo left in a gun, etcetera.

Basic XML Definitions

The XML for this system should be very simple, but of course will get larger as modders have more transformations to handle. It should probably be as big than the merges XML, or at least of that general scale.

Each entry in this XML contains the parameters regarding a single item. The data is structured as follows:


   
      ###
      ###
      ###

This is the simplest form (more complex forms explained below).

In this XML, the following values are used:

usIndex: The index# of the original item, from Items.XML
usTargetIndex: The index# of the desired new item, from Items.XML
ubAPCost:The AP cost for this action, if attempting during battle.

This defines a single transformation. When the transformator is clicked, the game finds the entry related to the existing item, checks whether to charge an AP cost (or fail due to insufficient APs), and then deletes the existing item and creates an item with the new Index# in its place.

Examples

There are two items which currently are the primary targets for this system: the Folding Stock, and the Variable Scope. These are essentially the items that require the most immediate implementation - though there are many other possible applications for this system that won't be discussed right now.

These are also good examples for how the system works, because they're simple. We'll start with the Folding Stock here, because it's by far the simplest (I'll explain Variable Scopes later on).

At the moment, we have a single Folding Stock item (possibly several, but they fit on different guns or have different stats to begin with). Due to the lack of a proper way to extend or collapse the stock, a Folding Stock exists simultaneously in both a folded and non-folded state. In other words, the game assumes that the stock is folded or unfolded based on the situation, giving the shooter an "average" bonus that covers both of these states. Long story short, the modifiers we give to a Folding Stock are halfway between those of a solid stock and no stock at all.

With the transformation system, a folding stock would have a button which, when clicked, changes the item from "Folded" to "Unfolded" and vice-versa, altering the modifiers to the gun by changing the stock itself, rather than attaching anything to it to make it give different modifiers.

This is accomplished by creating two versions of the same Folding Stock defined in Items.XML. First is the unfolded version, giving bonuses similar to those of a solid stock but also an "AP to Ready" penalty. The second version, the folded stock, gives no bonuses at all, but also does not give the AP to Ready penalty. Both items share almost all other properties (such as weight etc).

The XML would look like this:


   
      Index # of Folded Stock item
      Index # of Unfolded Stock item
      AP cost to unfold the stock, say 15 AP
   
   
      Index # of Unfolded Stock item
      Index # of Folded Stock item
      AP cost to fold the stock, say 35 AP

With this setup, the stock can be folded and unfolded at will, repeatedly, assuming sufficient APs available or not in turn-based mode. So, during close combat, the player can fold the stock to reduce draw costs, while long-range combat or autofire would work better while the stock is unfolded.

After either transformation, the new item will retain only the variable properties of the original - which would probably only be its condition in this case - while all the other properties are altered as per the differences in the Items.XML definitions of the two versions of this stock. Visually, it would seem to the player as though the item hasn't changed - only the bonuses and penalties it bestows have changed. Like fairy magic!

Complex Example

As promised, let's talk about Variable Scopes.

We can use the same format we used above, where the scope has two states: for instance a scope that transforms from 2x to 4x and backwards. This is a fairly simple action. We could assign a 10 AP cost in both directions. This offers our mercs a more flexible combat range with only a single weapon and scope - no additional items required.

But why settle for two modes when we could have three? A scope could theoretically transform from 2x to 4x, then from 4x to 6x, then from 6x back to 2x!

To do this, the modder creates three versions of the same scope, changing only the appropriate optical modifiers (sight range, aimbonus, Scope Magnification in NCTH, etcetera) in each version to reflect the different scope power settings.

The transformations XML would then be as follows:


   
      Index # of 2x version
      Index # of 4x version
      10
   
   
      Index # of 4x version
      Index # of 6x version
      10
   
   
      Index # of 6x
      Index # of 2x version
      10

Voila, a chain of transformations which allows us to iterate through the steps.

In real-time mode, this simply allows us to set the scope to whatever magnification we think we'll need. In turn-based, of course, getting from 4x to 2x means having to spend an extra 10APs (and a needless extra click) going through 6x mode first, which may be annoying.

Reverse Transformation

The solution to the above turn-based issue is to have transformations work in two directions when required. In other words, each item can have up to two transformations defined - going in either direction.

Consider this XML:


   
      Index# of 2x
      
         Index# of 4x
         10
      
      
         index# of 6x
         10
               
   
   
      Index# of 4x
      
         Index# of 6x
         10
      
      
         index# of 2x
         10
               
   
   
      Index# of 6x
      
         Index# of 2x
         10
      
      
         index# of 4x
         10

With this we've created a loop which can be traversed in both directions as required, not requiring us to waste any steps. This is facilitated by having two buttons - one transforming "forwards", the other "backwards", and the player can decide which way he wants to go with each transformation. Tooltips over these buttons will show the name of the target item that will result when this button is clicked, resolving possible confusion.

The second ("BACKWARDS") definition is not mandatory. That way so that you can define only a forward direction if you want - thus removing redundant buttons for items that only require two states (i.e. you only get one button in such case, going forward, instead of two).

Further Possibilities

There are probably many possible applications I haven't even begun to consider yet - though this will be more up to the modders themselves to come up with. Note that naturally, items can transform into anything with this system, you're not limited to giving out slightly-different versions of the same thing. For example, you can turn an inert item into a useful one or vice verse if necessary. Think of it as sort of a "merge", but without requiring a second item to catalyze the transformation.

It's possible that this system could even replace several existing systems, all becoming unified into the use of these buttons to interact with the item. Again, this would require imaginative thinking.

Questions to be answered

1. Better names. "STI" is already taken (duh), and the buttons themselves may need good names so that this system could be easily explained to newcomers.

2. XML format. Is it any good? Is there something missing?

3. Further options. Are there any transformation options I have not considered above, that might require the system to work a little differently?

4. Flaws. What are the caveats with this system, and/or how they should be solved.

5. Interface. Suggestions about where to put these buttons (they'll probably be very small, no need to waste space) and what they should look like (suggested icons). What about hotkeys?