Horde3D

https://launchpad.net/slide

"A framework library for developing interactive applications based on the Horde3D engine. Intended primarily for cross-platform game development. Slide implements pluggable states, event handling, and game objects."

I've been working on this as practice as it's been a while since I've done much coding. Not that exciting to look at, but here it is nonetheless!

It's a little rough in spots, and there are definitely some features that could be added. I included a sample which is based on the "Knight" demo, adding a couple of things like mouselook and model picking (there's 2 knights, and you can click and set the animation weight individually). You can also press 'Tab' to reset, which is implemented as a state change. Feel free to grab the code and play with it, though I'm afraid the CMake files have not been made fully cross-platform yet, so Linux only for now.... work in progress.

Any comments are welcome.

The next stage is to gut the "Actor" part and make the object system component based and data-driven. I will as closely as possible follow Horde3D's handling of xml files and apply it to managing templates for game objects. You can see a mock-up of what a "knight.entity.xml" might look like in the "components" branch. In the description of that branch you can also see links to the articles which inspired this redesign.

Great to see that you are creating an open source game engine, or at least parts of it. I'm eager to follow your progress!

Thanks, marciano!

I've been doing some more work conceptualizing the loading and instantiating of game objects from xml templates.... starting to feel like I will be duplicating a lot of the work already being done in Horde3D's resource manager.

I'm now looking at the possibility of implementing this as a resource extension. Does this seem feasible or is it going to end up being a mess?

We had this discussion before:

http://www.horde3d.org/forums/viewtopic.php?t=214

Personally I would write a separate resource manager for the game engine. It is not much work (you can also look at the Horde resman to help you getting started) but gives you the flexibility you need. For the game engine I would probably also do file accesses directly, something the Horde res manager doesn't do (for good reasons).

Best of luck to you, I've been working on something along those same veins and I've found it to be rewarding.

On topic:

I think it would be silly to couple so tightly to Horde as using it's resource manager would force you to. If later you decide to support another API, you've got more work to do.

As marciano said, it's not terribly difficult to write a resource manager. Even if you get fancy with templates, it's still easy compared to any other system you'll have to write.

I have to ask, link Do you plan to release this work as open source?

Do you have any game design documentation ready for public scrutiny?

Best of luck with both projects. Thought it would be nice if people with similar goals joined efforts to create a more complete solution.

More than likely open source, not certain as to under what license yet.

I've got mounds of hand-written "Jon-style" UML that I really should rebuild in Visio. I'll have to make it my task for the evening.

Combining is always a good thing, but it looks like Mb108 is going for something more general purpose while I have a singular "flexible only in abuse" direction. Several of my systems are in fairly agnostic DLLs though so their shareable easily.

It's on my to-do-shortly list to check out mb's work more thoroughly to see where I can contribute and help out.

Thanks for the feedback on the resource manager, I do see the point about flexibility in supporting other API's.

It's true I have been heading in a more general direction, as this is very much a "learning project" which isn't served by being too specific. I'm not so attached to an end product, and am very willing to switch gears if there are other (probably more complete) projects in the works.

PS don't rush too much to check it out! Currently the "actors" branch is a very simple implementation, and the "components" branch is concepts and half-written classes. My goal is to have basic functionality in components by the end of the month.

I'm currently working on something similar. It's a game engine for my game project with some some students in computer science and 3D animation. Ive already implemented ODE and some event handling, and i'm planning to create a level editor/ressource editor/physic editor. I still have a lot to do.

I wish you good luck with your project!

Mikmacer, I'd be interested in how you're doing event handling. I've got one working implementation and a couple of ideas, but nothing I'm very happy with.

Update time!

There's some progress on using XML templates for game objects, mostly the core of support. I still need to write up more components that can be added to the entities. I'll post more about that when it's more finalized, right now it's very much in flux.

Then I decided I liked the "everything is a plug-in" approach and re-did the framework from the ground up. This sidetracked things significantly.

At this point I realized that the way I was doing the plug-ins was basically a signal/slot implementation, but not as nice. I toyed with the idea of creating my own generalized signal system, but decided that the combination of template voodoo and function pointer black magic would give me a headache and I should really get back to adding more components. If people need signals, they can use libsigc++ or boost.

Then I ran into a doorframe and got a concussion. Quite a funny incident actually. Since I now had a continuous headache anyway (along with blurry vision and general confusion) I decided to tackle the signal/slot problem. I figured my head couldn't get any worse, and I'd rather futz around with that than mess up other parts of the project due to my state.

My head's almost back to normal now (such as it is), and there's a whole mess of new code adding support for signals of any return type and up to 2 arguments, slots made from non-member or member functions, and a class to collect all the results of the slot calls and make sense of them. I think it even works. 2 arguments isn't much, but the way it's done it's fairly simple to add more if needed. Tedious, but simple. Overall I wouldn't call it an amazing work, but it does the job, manages to be pretty lightweight, and hides much of the template nuttiness from the user.

i.e.

(signal<> can be filled in with return type and argument types; here we let it default to all void/no arguments)


That's all for now! Top of my todo list now is to fix up a decent Horde3D plugin and associated components so I can justify posting my progress to the Horde3D forums.

I'm very much in the same situation as you are. I also started some GameEngine approach based on entities and components. Although I didn't start to realize the components as plugins I wanted to try this in the next weeks.

I think event handling is the most important functionality of the engine if you want to design a clean and flexible implementation. Currently I have some kind of sendEvent Function for each entity that will send a GameEvent with a GameEventData struct to all components listening for this event within the entity.

But I'm not very happy with this approach because the type of available events are fixed and you have to introduce a new event for new functionality.
But that may be also an advantage if it comes to integrating a new component. Since you know about the existing events you can just register the component to the existing events and easily exchange an existing one with your new one.

But what I'm really not sure about is the handling of the messages. Lets suppose the following example:

We have an entity 'Player' that aggregates a physics, graphical and keyboard controller component. And we have a room where the player entity will be placed in.
Now the player will be moved by the keyboard component and therefore will send a transformation event. Normaly the graphical component will take the event and adjust the graphical representation of the entity. But what if the physics component is present and want to block the transformation change because there is a collision with one of the room's walls.

Currently I have the concept of a checkEvent and executeEvent method. If a component want to change the transformation it first calls the checkEvent method with the transformation event's data. If none of the components aggregated in the entity returned false, it will call the executeEvent method and all components interested in the tranformation are updated.
So in the example above the physics component will return false in the checkEvent method. Additionally it will take the transformation send to the checkEvent method and integrate it into it's internal world representation. On the next update iteration of the physics world the physics component will try to send the transformation adjusted by the physical calculations to the other components. This way things like collision or friction etc. have been integrated into the transformation change initially triggered by the keyboard controller component.

Next to some things I don't have figured out yet, there a two problems with this approach:
- Transformation changes will be finally integrated with a delay of one update iteration (usally one frame if you call the physics update every frame)
- If more than one component returns false in the checkEvent method the transformation may be never integrated because each time a component want to execute it's adjusted transformation event it will be catched by the other component that want to control the transformation.

I hope my contribution to this discussion doesn't cause another headache

I used the same strategy of having a base class that all events derived from, and I sent all events to all entities by loading them up into a big event handling queue. Events had an identifier that could be queried, and then each Entity could decide what to do with it based on the type returned.

I ran into the collision problem while I was making my as-yet-unfinished Pong clone. With that I just took into account that other systems were also receiving the events. So when the collision detector received a transform that caused a collision, it generated a second transform event that would "cancel out" the first and correct the position (the graphical component ends up handling 2 transform events for that object before rendering). Con: might end up generating lots of extra events. I have a suspicion that given exactly the right circumstances, you could end up with infinitely counteracting transform events.

Another solution is to give components priority for event handling, and let them modify or generate new events as they get passed down. Then you can register Physics with priority 1 and Graphics with priority 2. Physics will receive the event first and modify it as needed before passing it down to lower-priority components. On second thought, it's probably better to avoid modifying, and instead just generate a new event from Physics. If you use std::priority_queue, half the work is done for you. Not great because adding new components may turn into priority shuffling, but might not be that bad.

I agree that deriving new event classes for new functionality is kind of a hassle. The alternative I'm thinking of is to push all functionality into the Entities, leaving only the identifier in the Event (and maybe a pointer to the generating object). The problem remains how to handle the associated data, but maybe that could be fetched through a callback. The example would be to have the Input component send a "keypress" event. Anybody who decides they want to respond to that can query the input component for which key and decide for itself how to handle it. It might end up being a bit of a kludge, I need to play around with it more.

No headaches this time, just a late night and some furious note-taking!

Why don't you just write an arbitrary data class that stores basic classes that wrap variables with an identifier (hash or regular map). You'd only need an identifier enum and the data container class for your event class then use a strategy or some other class based approach solely for handling the different events of the identifier enum.

Basically something like from GPG 2 article 1.7 "A Property Class for Generic C++ Member Access" only not creating pointers to the variable of a class but actually creating the data.

I can send you'd code if you like, and you could do a quick test to see if that sort of thing works. I haven't tried using it for that purpose yet, my event managing currently isn't doing anything but queueing things for deletion in a deque.

I have not yet worked on the event system but I was thinking about a some kind of signal system too. At this moment, I only have implemented the basic system for the game object. If you want to know how it will work, check this example:



The returned value when an object is created is the index of the object. Soon enough, I will do a typedef for this. It's my first attempt to create a game engine so maybe im doing many thing wrong but I'll try to learn a lot from this project I will surely release an open source version of this engine when it will be more advanced but this engine is build mainly for my game project.

So there's a "Value" class which wraps up arbitrary data, and then the Event or EventData class maps Value objects to identifiers... I think I get it, and I like it.

What about using boost::any for Value? (http://www.boost.org/doc/libs/1_35_0/doc/html/boost/any.html") Maybe I'll use that for now and then replace it with a homebrew later.

I should really start picking up those GPG books, but if I have too much reading I don't do any coding.
If you wouldn't mind sending me the code for reference, I'd be grateful: mattb108 @AT@ gmail.com