Slick Forums

I am making a basic platformer, I have of course slick. As well as using tiled, luaj, and jbox2d. I am using java Scripting Extension to load LuaJ (so you don't need to know specifically how that works).

I am trying to think of a good way to interconnect graphics, input, map, physics, and a script engine. Without piling them all in one class.

I need to load a map via scripting or via hard coding.
When loading a map I need to be able to adjust the physics, and add sensors based on GroupObjects in the map.
When those sensors are tripped I need to be able to lookup their contents (I can just link a reference for this) and then call the script engine to execute the script.
The script may interact with the player, the physics, the map or even load/change map. (I will likely make a script only interface for these).

Almost every method just ends up piling all these into the same class so they can talk to each other. The other method I can think of is using static calls.

Not entirely against static calls, but still need some help with direction with this.

In short, I am having a problem with structuring the engine in such a way to make connecting the components easy.

I am interested in this too (I am working on a platformer like you). Advices needed! Let's wait for some responses

Since there is no reply really. I will have to map it out by hand, since I cannot come up with a decent method just staring at the code.

I was not active quite some time here and I can't tell you "the best way".

But here is mine:

After all we always have to consider that a game is a single instance thing. You'll never have more then 1 game instance running in your application at the same time. So statics or singletons are the way to go.

What I did in my game (its not a platformer), is that I created a tree like structure. I got a single center class. This class maintains a instance of the class for the game logic and the update/render lists. From this centered class you can for example access the class that contains the game logic, such as the map, the weather, the active player, the other players (its a multiplayer game) and so on. Classes that require is are able to access the centered class to register to the update or the render loop in order to the the respective thing.

So after all its a "kind of" singleton concept with the advantage that I can remove and recreate the centeral class in case I want to reset the application and start the game from the beginning.

Nitram

_________________
http://illarion.org

I use this concept in my games as well. Its a very organized way of handling everything and keeps things simple.

I highly recommend this for any game