Irrlicht has a full event system, and objects can inherit from the irrlicht event receiver interface to hook into it. Despite this, I think it makes more sense to bypass this and use a single dispatch function which runs with the main loop.
I think in the long run, it will be easier to make changes in a single place to change how users interact. Since we’re not going to use the event system to control the npc characters, there’s no reason to put it there. In some cases, individual objects may use the event system– notably, there’s an irrlicht console available which does that.
This reduces the complexity of the objects we’re creating, since each object does not need to inherit from the irrlicht event system.
This reduces the computational complexity– instead of calling every object’s OnEvent for each keyboard event, just the eventreceiver gets that, and the dispatch function takes care of passing on events appropriately.
Finally, we don’t really need the responsiveness of a separate thread for handling control at the moment, and if we get to the point that our framerate is so low that we do, we have other problems.
Here’s a quick rundown of what’s going on with FI3RST 1.5 right now:
- DynamicObjectList: Adding objects supported, object removal not ready
- CharacterList: Adding characters supported, character removal not ready
- Inventory System: Adding/removing objects to/from character inventory supported, inventory display in game available, object inventories not nailed down yet
- Remote interface for BEHAVE: Character/object insertion available, character motion control working.
- Object/Animation metadata: Schemas created, basic examples (simple character model, the defuse kit) are working
- Camera: Custom camera not yet started
- Keyboard controls: Set up a simple custom event handler which includes contexts– separate contexts allow changing the keyboard mapping easily
- SSPS Integration: Some stubs in place, but not yet started
- Text console: Text console class is available, currently hooked up to irrlicht logging system. Need a second console for displaying character speech/actions
- Splash/loading screen: Splash screen is in place, but irrlicht doesn’t like rendering anything to screen– even 2D, ignoring the scene manager– while it is loading a level. Possibly a deadlock?
- Director: Planning for a scenario director, which can take care of executing events such as earthquakes, as well as just loading necessary scenario-specific dynamic objects into the game. Scenario descriptions will be XML.
- World class is in, but not doing much at the moment
- FI3RSTManager class handles game session recovery, as well as dropping objects/characters in as they are requested
Other minor items: The issue with the textures on the objects I have loaded in so far was just because the irrlicht level I created has no lights in it. Once I dropped in an ambient light, it’s apparent that textures are loading just fine. The pause functionality is not quite right at the moment; for some reason, the irrlicht game timer doesn’t seem to be pausing the way I expect it to.
BehaviorShop interface: BShop (and BEHAVE) can take advantage of the character/object metadata files. BShop will also want to make use of the object inventory thumbnails.
Actions and speech aren’t really in, and I can’t say that character motion is finalized until we get SSPS in; the key item here is that SSPS will be involved in ground clamping, so we need some valid data before that goes in. Irrlicht collisions work for the camera, but likewise, this is something that won’t really be in place until SSPS is integrated. I plan to go ahead and use the irrlicht collision methods, but use SSPS to select which objects actually need to be tested.
It’s not over here….
I can’t find it here, either!
Oh no! I’ve lost me torso too!
Alas. At least I didn’t lose me boots this time.
Since I want the ActionModel to take care of action resolution, and there to be only one per agent, it can’t be used directly by the agents. Really, though, this is a good thing. The ActionModel also needs to store some basic state information for behaviors—if following a path, it needs to keep the path around. It should at least track the effectors so it can figure out when they actuallly run.
So I’ve added an ActionModelInterface class. It has storage for some basic state, hold onto the SubsumptionPolicy of the layer, and has simplified move/speak/act request functions. This should actually simplify behaviors, and to some extent, the ActionModel, quite a bit.
This functionality could just be folded into the Behavior base class, but I think this approach is better. If nothing else, it makes for easier testing, which is important right now.
