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!

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - November

Pages: [1]
Framework development / Dialogue Editor
« on: March 04, 2008, 07:07:00 pm »
Here's the current state of my work on a dialogue editor :

A screenshot is available here :

The editor can only visualize a dialogue for the moment, but I hope to make it capable of creating an entire dialogue from scratch, or modify one, for the end of this week.

Framework development / Request for a getTopInstance function
« on: February 20, 2008, 11:47:32 am »
This is a request to Jasoka, as he seems to be working on the instance picking functionalities.
So, jasoka, could you think of a getTopInstance function ? Or can the top instance on a determined screen point already be get with the actual getMatchingInstances function ?

By the way, by top instance I mean the instance to which the clicked pixel belongs, if not covered by a semi transparent pixel of another instance. (and the top semi transparent instance if there is any)

I think this will be needed in future, for nearly all in-game click based features (context menu, attack/skill targeting, etc...) but also for editor features (instance dragging)

Framework development / Draft of Dialog system - enhancements
« on: February 06, 2008, 02:07:56 pm »
Since I am away from my computer I'll use this post as a repository for the enhancement/bug fixes I don't want to forgot to add to my diff concerning a draft of dialog system :

Multiline labels :
- C++ side :  splitTextToWidth is called way too often. Labels should'nt call the split function if width = 0 or if text = "", or if neither the text or the width has changed.
- ? side : spot where the display bug comes from : image of the label text seems to be split in two parts separated by a void zone, so maybe it's linked to pychan layout engine, or to spacers, or I don't know...
A good test to spot the weakness would be to try drawing a button in a non-auto layouted container, and see if it is displayed properly.

Dialoguelogic files :
- Should add the possibility of defining global logic rules that apply to all dialogues. It would be loaded by the dialogue manager on init, and passed to every dialogue that is started, which would call both logic functions (global and dialog-specific).
Example : if the metadata param 'hostile' is set to 1, the speaker is set as an ennemy of the player and combat will begin : this should apply to all dialogues in a game,  but can differ between the games itself, so we don't want to it to be implemented in the dialogue system itself.

- Should make the base dialoguelogic functions get the line or the node object itself and not just the line or node ID, so the functions can easily get any embedded metadata.

- onLineSelected could be merged with conditionalNodeDisplay, but it would be less intuitive, so in fact it's not an enhancement

Dialogue class :
- I think I forgot to make it check whether a line or a node of the same ID has already been loaded before loading one.
- I also forgot to fire the onNodeDisplay and conditionalLineDisplay in the displayNode() function of the dialogue class, if needed

Miscellaneous, adjustments :
- Remove 'import dialogueloader' in
- Remove all debugging prints I added to track bugs
- Remove call to self.update() from DialogueGui.start()

Framework development / 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...

Framework development / Contextual Menu -> Object managing ?
« on: January 23, 2008, 06:00:16 am »
In a recent diff Sleek implemented an Instance Menu, which is a good start because it will raise questions about the game engine itself. This Instance Menu is not dynamically defined for now.

But ultimately, this Menu (I'd call it Contextual Menu) should get informations from the object the cursor clicked on to know what ContextActions it has, or what ContextButtons it must show when right clicked.
This require game engine to have an object manager, which would manage all game objects, load objects properties and return them to any script requesting them, but also modify them. Objects could be map instances, but in cases like items, there will be an object without an associated map instance, until the item is released by it's container (character or object).

I've wandered in the engine code to see whether such object managing was implemented, but since i'm not a master of C++ so I can't really tell.

Pages: [1]