Horde3D

You might want to take a look at Very, Very Fast Event Library. I phased out boost::signal once it started eating ~20% of my CPU time, and this has proved a very nice replacement.

_________________
Tristam MacDonald - [swiftcoding]

Quick update!

I am still lurking these boards. This project went on a brief hiatus, but is now in total rewrite to clean things up and bring in some better solutions.

Here's a brief overview:

class Framework
Does basic initialization and game loop. Has a stack holding all active game states. Each State on the stack will receive an update every frame, unless paused. I'm hoping this makes it easier for things like in-game menus, minigames, and popup bonus levels. Pause the current state, push a new state, then pop/unpause when done.

class State
A pure-virtual base class. User derives from this to create a game state, which is loosely defined as receiving updates, and hosting Actors/game objects. A menu, a game level, or a lobby would all be derived from State. Each State has it's own Event queue, but can also send to other States by signaling the Framework with a global Event. Events are processed through a multimap that signals any callbacks registered to the event name.

class Module
Pure-virtual base class. Basically any Actor/game object behavior is extracted into a module. A 3d model, the ability to jump, or firing a weapon could be distinct modules. The user derives from Module, implements the behavior, and thereafter it can simply be 'plugged in' to any game object. One Module might contain the behavior to trigger one of several animations based on the Event received. 'Inventory' could be a module. The ability for an object to be picked up and placed in inventory, could also be a Module. Modules live inside State objects, and communicate with each other through Events.

Pattern
A pattern is parsed from XML, and represents a template for a game object. It defines a type of Actor by what modules they make use of, and what the initial data should be for those modules. The Knight or the Chicago man could be expressed as Patterns (given that the user has written appropriate Modules).

Actor
An Actor is an instance of a Pattern. An Actor is just an ID -- all behaviors exist in modules, all static or shared data exists in the Pattern, and all dynamic data is handled by the appropriate module.


Most of this has been written in a marathon-codedump, so I'm in the process of making sure everything works as intended. I may add a Plugin class so that Framework can call arbitrary user stuff during init (other libraries, etc). I'm also considering adding an input handling class. When things are more stable I'll write up some demos for 'proof of concept', and Modules for easy Horde3d integration.

Eventually the goal is that non-programmers be able to import modules into a GUI tool and compose new types of Patterns/Actors through the magic of 'drag and drop', and by setting a few attributes. The tool will export into XML, and then these new patterns can appear in-game, fully functional, without touching any code or recompiling. New functionality is added by writing new Modules, and does not interfere with existing code.

That's the goal anyway!

I'll make a new post when I'm happy with the rewrite (2wks?). I'll also be changing the name and moving it to Googlecode under a dual license GPL/talk to me.

This sounds promising...looking forward to see more...

Thanks for the encouragement, marciano.

There's still a lot of work to do, but I decided to post one of my test programs so people could get an idea of where this is headed. The code is attached, along with the 2 XML files it uses to define Actors.

The test program's output is this:


The new page for the project is here:
http://code.google.com/p/gestalt-framework/

I'm open to any suggestions for improvement!

I really like the Modules for actors behaviors / actions / etc enough that I'm thinking about kidnapping it.

Kidnapping sounds a little extreme, perhaps we can have joint custody?

I know that you probably mean that you will write your own version, but consider trying the Gestalt project. It needs some cleaning up in terms of the CMakeFiles to be actually cross-platform, and documentation, but it as a whole I would consider it very close to usable... my next phase is actually to work on a simple game to test the framework's feature-completeness.

If you decide to use my framework, I'm happy to help you get up and running, and also I'd love to hear how it goes, what can be improved, etc. Right now it builds on Linux once the GLFW and Horde3D libraries are added to the root directory. If you're on Windows/Mac, the CMakeFiles need tweaking... let me know and I'll find time to work it out.

If not, no hard feelings, I understand there are plenty of motivations for rolling your own.

I have another project I'm juggling, but if I make my milestone next week then I can relax a bit and put some more work into Gestalt.

You're using boost though IIRC.

I'm using Boost::any and Boost::noncopyable, and will probably use Boost::python. What's your take on Boost? (honestly would like to know)

I use the Boost::serialization because it's pretty much THE serialization library. I don't have anything against boost, but I like to keep it away as much as possible so that getting rid of it won't break anything important and I generally prefer to intimately know what's going in my code, especially in the case of things like pools and containers.

so you don't use windows

If you're referring to windows serialization, then still, boost::serialization is THE serialization library.

no I was referring to "knowing what is going in the code"

haha, that's slick

Boost::any is used in one of the main data structures that gets passed around a lot... It does the job and was easy. I kept it hidden from the user though, so that if it caused problems I could rip it out without breaking the interface.

noncopyable is more of a convenience.

Well, if you do roll your own, I'd love to compare notes... always looking to learn better ways of doing things.

I think I'm picturing it a bit different than you are (I might not be, you haven't exactly discussed it a ton, nor does your code make anything truly explicit). Where a pattern would be a classification of a type of module, such as Actions, Messages, etc. The pattern is a basic management class that can be queried by other actions, handlers and such so that they can interact or use those.

I'm picturing for an EntityActions pattern that contains several ActionModules all of which provide an availability function (return true / false), a utility funciton (returning a float), and an execution function that is the action. An ai pattern can set data for the EntityActions pattern (or the ActionModules can be aware of the ai pattern) in which case the ai says "could I, should I, I do / I don't." The patterns can store data that's shared between actions as well as histories of the actions executed. Therefore actions / handlers etc can be masked in a fashion. "Fire weapon" or "throw grenade" doesn't trip the flags that deny "strafe left" where as "currently prone" does deny it.

You can end up with a monstrous web of interconnections that boils down to bool functions, float functions, and void functions, and that's just for actual actions. Eventually the entire system would reach a point where if you drew it on paper, it would look like a neural net from hell, but would be far easier to maintain and use than even a simple n.n.

On the AI topic again, it makes it easier to update the AI with every update of the object in a step by step fashion but still maintaining something like 10 or 20 htz.

I'm picturing the results of a Visitor after an extensive drought mating with a Strategy and never using latex.

Offtopic: If I hear one more nickleback song on the radio I'm going to freak.