Interactions between game objects in a RPG

Started by
6 comments, last by Eliburgi 9 years, 8 months ago

Hello community,

I want to start with programming a 2D RPG soon, and whilst planning the project, there occured some problems. One major problem is that I want a flexible architecture, so I can easily add new things later on. So I want to de-couple the different game parts/objects, for example there should not be any collision code inside the player class. Or another problem I am struggeling with is, how do I let the player interact with all kind of world objects like treasures, traps, NPC´s,... without having alol that code in the player class.

I read a very interesting post about that. There was a event system explained: For example if I the player wants to move he fires an event BeforeMove(Vector2 desiredPos) and the tile map and obstacles react to that event in their own class or so and if they collide with the player they set isPlayerAllowedToMove = false. So the player can´t move that frame. Or for example if I want to implement traps, I could create a event inside the trap class which fires an event, lets say DamagePlayer(int damage) and the player has a way to react to that(by loosing life). Is this a good approach, or do I couple things even more with that(I am not quit sure).

In my last projects I handled Collsion in a collisonManager which had references to the player, and the enemyManager and then I simply checked for collison. I also thought of lettin every object have an event OnCollison, but the problem with that is, that I wouldn´t know which objects collided, so I couldn´t interact differently.

So I hope someone can help me with my problem.

Have a nice day :D

Advertisement

It's me again ;)


I read a very interesting post about that. There was a event system explained: For example if I the player wants to move he fires an event BeforeMove(Vector2 desiredPos) and the tile map and obstacles react to that event in their own class or so and if they collide with the player they set isPlayerAllowedToMove = false. So the player can´t move that frame. Or for example if I want to implement traps, I could create a event inside the trap class which fires an event, lets say DamagePlayer(int damage) and the player has a way to react to that(by loosing life). Is this a good approach, or do I couple things even more with that(I am not quit sure).

In the described implementation the player's game object does not know about terrain (i.e. "walkable" or "blocked") or traps. That is decoupling. Question is now, how is their response coded?

When "isPlayerAllowedToMove = false" is an action that accesses a field Player::isPlayerAllowedToMove then the terrain and traps need to know that "Player" is a "moveable", in the case of traps even that it is a "vulnerable". And what happens if a monster gets trapped?

Well, the original event BeforeMove is obviously one that deals with movement. It seems me okay to let it either have a boolean field "isBlocked" that will be set by the terrain and gets interpreted by the original sender, or else it has a pointer back to a Moveable which provides a Moveable::cancelMovement() routine that is called by the terrain. Because also monsters can be handled this way, it is more generic than "isPlayerAllowedToMove = false". The latter of the both approachs, however, may lead to let your game objects inherit many interfaces. The former one is even more decoupling.

Now coming to traps. Here causing a damage is something that is not meaningful within the movement event itself, so the idea of generating a new event is fine. However, sending it as DamagePlayer is IMHO again too specific. Instead, with using the sender of the original message and generating an TakeDamage(origSender, damage) would be better.

BUT: You need to take into account what I've written in your previous thread: Order! You should not use BeforeMove(sender, where) within traps to generate a Damage(origSender, damage) event because the trap cannot foresee whether the terrain will eventually block movement. Instead you should use Moved(sender, where) to trigger the trap, or else your world state will get wrong. Even if you collect and resolve events first to avoid the above ordering problem (which means more trouble than you may think) with respect to the player's game object, the trap itself will left triggered although the player hasn't moved onto it. So you see, ordering is mandatory.

Wow thanks about your answer. I didn´t think about the order, damn. Now it sounds more complicated, than I originally thought it would be. But what impresses me is, how fast you can investigate in my problem. How long are you game programming already? Sounds like you are a professional.

And for interacting, I also had a new idea. I add an event layer to the TileMap for teleporting between maps or when the player is near a sign and presses let´s say space than an event gets fired(for example opening a dialogue window). Would that be a good way to go?

The general solution is that you have events tied to regions of your map -- in a tile-based game with tile-based movement (as opposed to tile-based game with sub-tile or pixel-by-pixel movement) its very easy to just attach events to tiles. Then, depending on the event, when a player "touches" a tile (e.g. tests whether he can enter it), or when a player occupies that tile, the event is triggered. The event could be anything -- it could cause the player damage, it could cause the map to change (e.g. cause a door to open), teleport the player to a different place on the map, cause damage to the player, or kick off a cinematic cut-scene.

Often times, the effects of these kinds of events are defined by a script, although its reasonable to implement event functions in normal program code too, if you think its best to avoid the complexity of integrating a scripting solution.

If you have sub-tile or pixel-by-pixel movement, or a non-tile-based game, its basically the same concept except you have to define the trigger regions differently and/or think a bit harder about what constitutes "touching" or occupying a region? For example, you might decide that occupying a region means that a single point under the players feet is inside the region (or, effectively, this means that the player is more than 50% inside the region).

throw table_exception("(? ???)? ? ???");

Wow thanks for your answer. So thats the right way to go? If so I could finally start coding(yeah :D). I am using the Tiled map editor for my tilemaps(don´t want to spend a lot of time on making my own), so do you or anybody know how I can implement events there(I would have thought on an event layer, but such a layer doesn´t exist in tiled). When looking in the interent for information I can´t find anything reasonable to work with.

Anyone an idea?

I even have a new question(sry for all that questions, but it´s my first bigger game): I use sprites from here :http://www.pinterest.com/pin/447615650437593300 and my problem now is that when I would want to animate the player attacks then the image would be drawn at the most top/left position(when aligned to top left) and so it would look like the player is moving right when I want to play the forward attack animation(because of the alignment when drawn). So how could I solve this?

Thanks for help :D


I am using the Tiled map editor for my tilemaps(don´t want to spend a lot of time on making my own), so do you or anybody know how I can implement events there(I would have thought on an event layer, but such a layer doesn´t exist in tiled). When looking in the interent for information I can´t find anything reasonable to work with.

Layers in Tiled have a kind just to distinguish between graphics and bounding boxes. The former one is a Tile Layer, the latter one an Object Layer. What you do with that is out of the scope of Tiled. So, create an Object Layer, give it a defined name, and add bounding boxes to it. When you import the TMX into your game look at the names of the layers, recognize the names, and handle the layers accordingly. You probably need to add an own Object Layer with a specific name for every type of event you want to integrate.

BTW: Please stop pasting new problems into threads that already deal with other problems. If you have another problem then start another thread. Thanks.

Ok thanks. So this topic would be closed now :D

This topic is closed to new replies.

Advertisement