Ticket #252 (closed task: wontfix)

Opened 10 years ago

Last modified 9 years ago

Refactor the Behaviour implementation, saving and loading

Reported by: b0rland_parpg Owned by: parpg
Priority: major Milestone: Evaluation
Component: scripts Version: trunk
Keywords: Cc:
Blocked By: Blocking:
Department: Programming

Description (last modified by b0rland_parpg) (diff)

Problems to be thought about and fixed:

  1. Loading mechanism currently refers to specific classes (actually attributes) to know whether or not it needs a behaviour. Currently there already are 3 such classes. More will be added.

Suggestion: at the very least create a separate mixin class/attribute to be used for all the entities that want to listen for events from FIFE. This class should contain a reference to behaviour and createBehaviour method that creates a dummy behaviour. It is also probably a good idea to fully move the logic of "waking up" into the entities, so that ultimately every class knew how it needs to go to sleep and wake up, what needs to be skipped when saving and what needs to be created additionally when loading.

  1. State machine is currently contained in behaviour object. This means it isn't saved and loaded. So if you save the game while the PC is running across the map, each time you load, you need to make him run again. Aside for being super-annoying, it may also result in bugs (e.g. the open container will be displayed as closed, etc).

!Verify this claim!

  1. There will probably be a lot of code duplication in Behaviour classes for most of the objects on the map. This is because most implementations will just be trivial state machines with couple of auxiliary calls to FIFE as ContainerBehaviour? currently is.

Suggestion: Once the problem is clear and visible, make a good default implementation configurable with a set of states/transitions/actions. The goal is to avoid having to create a Behaviour object if we just want some animation.

  1. At the moment, some quite basic classes contain both the 'model'-like properties/methods and the references to FIFE. Moreover, in some cases we have classes split in two with both halves storing some model values and some references to FIFE (e.g. PC, NPC). This makes pickling impossible and leads to various anomalies if we need to use the pure model without any visual representation in FIFE (e.g. 'imagined' containers like player's backpack and slots).

Suggestion: try to keep pure model and FIFE references separate. One way to do that is to create an intermediate tier that would control the model and FIFE. There's not too much interaction with FIFE, so it's possible that we can avoid having two parallel hierarchies of classes for models and controllers. Needs additional investigation.


Change History

comment:1 Changed 10 years ago by b0rland_parpg

  • Description modified (diff)

comment:2 Changed 10 years ago by b0rland_parpg

  • Description modified (diff)

comment:3 Changed 9 years ago by barra_parpg

  • Milestone changed from Techdemo 3 to Product backlog

moved techdemo 3 tickets to product backlog as we haven't agreed upon sprint goals for techdemo 3 yet

comment:4 Changed 9 years ago by barra_parpg

  • Milestone changed from Product backlog to Evaluate

moving current trac tickets to evaluation milestone

comment:5 Changed 9 years ago by barra_parpg

  • Department set to Programming
  • Status changed from new to closed
  • Resolution set to wontfix

Closing this ticket for now. This might need further investigation down the line and should be done in a spike if so. Once we're actually sure about the details, we can always tackle a specific goal in a sprint.


Add a comment

Modify Ticket

as closed
The resolution will be deleted. Next status will be 'reopened'

E-mail address and user name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.