My game engine is completely separate from Dusk. Object types and mixins are abstracted away from the actual map code. I really sort of have two engines - one is Dusk, for the map loading, culling, properties, etc., and the other is the actual game, for the movement, behaviors, objects, etc. All the object type code is part of my secondary game engine, not part of Dusk. Dusk only handles drawing the tiles and telling me when events like object drawing or erasing happen. I then hook into the Dusk base to do what I like with my code.
I do add collision bodies straight to tiles - it makes for a much cleaner result IMO, and it’s easier to build maps with. For example, I might have a wall tile which the player should collide with. I set the “has a solid on the left side” property in Tiled, then I’m assured because of my physics engine that every time there’s a wall tile, the player should collide with the left side. My physics engine even handles flipped tiles, so you can use say that objects collide with the left side a tile, flip it, and objects will automatically collide with the right side. I understand that everyone will have their own approach to things like this (and I have used separated collision and display layers before), but for me, automatic physics tiles that I can just paint onto the map and be assured that will work every time is my personal favorite approach. My collision code doesn’t currently support slopes, but only because I haven’t needed them so far. The capability is there, though, as I use a pseudo-raycasting kind of technique.
I think your statement about similar setups may be correct. Your 7th paragraph (about your approach to what I call object types and mixins) is just about exactly what I’m doing, just instead of using separate objects for added functionality (like your data-only “zone” object), I have object types to create the basic object (the graphic, for example) and mixins which add added functionality. Mixins add directly on to my objects (so, say, a doorway with added “zone” functionality to tell when the player is near) and work in a “stacked functionality” way. So as I mentioned, I can have a ladder (which is an object type for flexibility - “ladder” is a bit of a misnomer; a “ladder” in my game engine just means something the player can climb vertically, so vines, grating, etc. It was the simplest word for what I was looking for) with a lot of added functionality that may not even be related to the object. Though that seems useless, it makes complex objects easy to make. For a real example, my context-sensitive-sign object uses the “sign” object type combined with a proximity icon [displays “press context sensitive button now” prompt], the dialog mixin [add a method to the object to display a dialog on demand], and the context-sensitive-action mixin [call a method on the object when the player is near and the context-sensitive button is pressed]. The result is a nice context-sensitive sign which displays a floating icon and displays a dialog when the context-sensitive button is pressed. By separating the code like this, the engine remains modular and really quite awesome.
- Caleb
P.S.
and don’t go asking for angry-birds-in-a-platformer. Bluergh!
Oh… man… nightmares will haunt me now. :blink:
P.P.S.: Having read a couple of posts above again, I think we may be using the same approach to physics… I ripped my approach directly from this Sonic guide!