FIFE forums

Please login or register.

Login with username, password and session length
Advanced search  


FIFE 0.4.0 has been released on 15th of January, 2017!

Author Topic: Propositions for game Objects managing  (Read 2358 times)


  • Developer
  • Newbie
  • *
  • Posts: 36
    • View Profile
Propositions for game Objects managing
« on: January 25, 2008, 07:36:58 pm »

Edit : As discussed with Jasoka on IRC, it seems the features I was thinking would be needed doesn't require any changes of the engine core.
So this topic is now totally obsolete.

As presented in a precedent post, the fast development pace that FIFE has known for the few last months will soon bring the need of game objects management, along the creation of a first ruleset.

That's why I bring these propositions, so you can tell me what you think about them, and if you think some of them are valuable in any possible way, keep them in mind.

The goal of these is to implement basic game data reading from XML files, managing of this data inside the engine through objects, and handling of data requests. In my dreams (yes, I dream about FIFE :p), the first techdemo would not only show that making a game under FIFE is possible, but also that this game is easily modifiable.

So I studied a bit the engine to see how far it was from handling these features, and found out that metamodel, datasets and objects holds almost all the features needed for a datamodel that would load and hold most of the game data. Objects are just too precisely defined to fit ALL objects a game could contain, and therefore should be renamed as instantiable objects.

So here are my propositions :

*Move engine/model/metamodel/ to engine/datamodel/   (except the grid folder)
*Make the datamodel be constructed by the engine itself. A pointer to the datamodel is passed to the mapmodel when it's created.
*Move engine/model/metamodel/object to engine/datamodel/iobject and rename Object class to IObject -> stands for instantiable object
*Define a basic Object class, that inherits from AttributedClass. Object should be the basic class for ALL game objects : from characters to items, including skills, etc...
*Make IObject inherits from Object
*Adapt functions of datamodel to this new configuration : it will now hold two objects vectors : m_objects and m_iobjects. IObjects will be added to both m_objects and m_iobjects when created, whereas Objects will only be added to m_objects.
*Implement new get functions for datamodel (previous metamodel) that behave more like classic browsing, and take absolute identifier as argument : must pass 'dataset/subdataset/object' as identifier instead of just 'subdataset' to get it
~Maybe implement functions that return only Instantiable Objects (IObject 's)

*Write a python loader to load Objects from XML files, and update the actual map loader to fit with the renaming of Object to IObject.

~Modify AttributedClass so it also contain lists, vectors, and maps of strings.
   XML definition of this metadata could ressemble this :
   <param type='string' Id='identifier' v='value'>
   <param type='vector' Id='identifier' v0='ga' v1='bu'>
   <param type='list' Id='identifier' l0='ga' l1='bu'>
   <param type='map' Id='identifier' k0='key' v0='value'>

~~Model could eventually migrate inside datamodel

I also wrote some totally fictious "use cases" examples, that could be required by a game, to illustrate the needs in terms of engine features :

Ruleset Objects :

In DataSet : Traits
Objects fields :
'id' = 'identifier'
'type' = 'trait'
'level required' = 'value'
'class required' = 'classname'
'prerequisites' = list/vector of identifiers -> others traits needed
'skills' = list/vector of identifiers -> skills granted by the trait
'icon1' = 'iconpath' -> the icon to show when the trait is showed in a type of container
'icon2' = 'iconpath' -> the icon to show when in another type of container
'description' = 'description'

In DataSet : Skills
Objects fields :
'id' = 'identifier'
'type' = 'skill'
'ispassive' = 'true' or 'false'
'target type' = 'self', 'ennemy' etc..
'action' =  'ActionId' -> the WidgetEvent actionid fired when the skill is used (used by the script which will create the skills widgets)

In DataSet : Items/Blueprints/ (or "Archetypes" or whatever else) :
Objects fields :
List of default properties and values of the items. The blueprints are used to instantiate an item in an inventory.

Content Objects :

In DataSet : Items
List of contextual properties and values of the items. Like the number of bullets in a gun, etc...
« Last Edit: January 26, 2008, 07:08:39 am by November »


  • Developer
  • Newbie
  • *
  • Posts: 36
    • View Profile
Re: Propositions for game Objects managing
« Reply #1 on: January 26, 2008, 06:24:20 am »

Use case 1 :

Suppose your game contain 100 different skills, and you have 100 characters, but each character has 10 skills in the skill list at the most.

Solution 1 :
-Store every skills in every character : very counter-productive -> 100 copies of the same exact object, for 100 skills
Solution 2 :
-Store every skills in the player character, and just fill metadata of the other characters to precise which skills they have : not counter-productive, but counter-intuitive : why would all the skills of the game be stored in the player character, since skills are not specific to this character ?
    ->These two solutions also require the possibility to embed attributedclass (the skills) into objects (the characters)
Solution 3 :
-Have a manager external to the characters, and external to the map, that holds such skills
    Solution 3.a :
    ->Implement this manager in the python extensions (an attributedclassmanager, with functions which returns attributedclass based, for example, on a 'Type' field, or on 'Type' + 'Id' fields)
    Ex of request : attributedclassmanager.getAttrClass ('Skill')
                            attributedclassmanager.getAttrClass ('Skill', 'FirstAid')
    Solution 3.b :
    ->Implement this manager in the engine core (where we can simply use the existing metamodel as I proposed)
« Last Edit: January 26, 2008, 06:29:00 am by November »