Design Issues: Making systems know about eachother (engine)

Started by
25 comments, last by Bob Janova 17 years, 12 months ago
Just that the code you write would include a lot of stuff specific to the project, so it would be hard to reuse it in another. It's nothing to do with static accessibility (if you notice, in the flexible solution the list of components is static too). That is, almost by definition less flexible code will be harder to reuse.
Advertisement
I would agree on going with Core as singleton. I mean there will be only one Core instance in the project. and using it as a singleton and some management I think is good no?
There have been about a billion discussions on this forum about singletons/globals and their evilness (either real or believed). I recommend you find and read these (some are just a week old if I recall right) and will give you a better idea of why so many people think they're evil.

I think a good solid messaging system is the best bet and the one I went with. Globals really don't belong in an OO system. They're unprotected. Anyone can change data and you won't know where/who/when without some serious headaches to debug it.

Honestly your model loading software does not have a need to access your renderer, so why allow it? The only thing that has access in some way to the renderer in my engine is the scene graph. Sound doesn't need to get access to the renderer, so it cannot.

If you only need/want one copy of x module. State so in the documentation. Then if someone chooses not to read it, it's THEIR problem not yours.

"Those who would give up essential liberty to purchase a little temporary safety deserve neither liberty nor safety." --Benjamin Franklin

Think im gonna try this messaging thing ;) Just having a hard time seeing "the whole picture" .. Fairly unexperienced when it comes to large systems...

Learn by doing seem to be a good thing here ;)
I had a friend of mine make a game (simple 2D tetris like game) with no engine. Just build it. Then using the same art assets redo the game as game/engine. Then he built up from there. Seems to be a great way to learn and get something working fairly quickly which is good.

Mike

"Those who would give up essential liberty to purchase a little temporary safety deserve neither liberty nor safety." --Benjamin Franklin

Ok, so ive set up my system as posted earlier (all messages passing trough the core, being dispatched to the right service). Though i have some questions.

With this method, is it smart to run each system as its own thread? And whats the best way of data-transfer between systems? Lets take the renderer, it might need a texture, so it send a message to the resourcemanager "give me a texture!" but depending on the queuesize in the core, the texture-pointer might not have been sent back yet, so it either has to wait for the texture, or draw something without it.

Now, i dont know if this is really a problem, if one uses scenegraphs (im guessing the texture pointers to the objects are set directly in the object-node ? )

Am I thinking to much? :P
You can either have the level loader wait until all the textures have been loaded before making the level the currently active part of the game, in which case your renderer doesn't have to worry about unloaded testures, or you have a 'not set' texture and the resource manager sends a message to the texture cache when it has loaded a texture.

This topic is closed to new replies.

Advertisement