Game Programming - communication between game objects in 2d

Question

Hello, recently I have been trying my hand at coding a game in C#. I'm not using XNA for this, as I thought I would learn more if I coded the game from scratch (although I am using a multimedia engine).

I'm trying to design a 2D RPG game - a bit ambitious I know, however I have a reasonably well understanding of at least the basic parts of the game (ie the 'boiler plate' code), and I've reached a part where I don't know where to go from here.

In the 2D game, you progress through the game via walking around different 'areas'. Once you hit a 'portal tile', you are transported to the next area etc.

I'm having trouble understanding how these area object should be set up. This was my first idea: Each area has a few different collection structures (for example, a visibility quadtree, a collision quadtree, an AI entity List etc). So if I were to add an enemy entity into the game, it would be put into the visibility quadtree, the collision quadtree (because you can collide with entities) and the AI entity list. When the area receives an update request, it tells each of these structures to update themselves, which in turn tell the entities to update themselves. All good, so far.

My question is this: What if this enemy needs to communicate with other objects? For example, it might need to know whether the player was in a certain range of it. Or whether it had been hit by the player. Or where all the collidable objects are in the area (so it could pathfind).

The first (and bad) solution to this problem would be simply to pass each entity a reference to each collection. But this obviously encourages tightly coupled objects, which is not good.

The second solution I came up with was for each entity to be able to query the area, via message structures. So an enemy would be able to say "Give me a list of each entity within X distance of my position" and the area would return an answer. However, this would get increasingly difficult as I would have to code more and more possibilities into the area ("Give me a list of entities that are not within X distance of myself", "Give me a list of all entities with health lower than X" etc).

What I'm looking for is a time tested solution to this problem of inter object communication, and basically how to set up an area. I suppose it would need some kind of messaging system as well, although I'm not sure.

Thanks for reading.

Answer 1

I think the best option for this kind of things is to use a lot the Observer pattern... create events (deciding how generic or concrete is another design decission) and make your objects to subscribe to the ones they need.

For example, your engine can fire collission or proximity events when 2 entities are near, but those will only be received by the entities that are interested. You can do some optimisations to check only those conditions with observers suscribed.

I don't know if this is common place in games and I have never actually used it in any game (yet), but I've thought plenty of times about it and it's the option that I like the most.

Answer 2

You could look into the Mediator pattern. It would allow you to have low coupling, but yeah, you would have a lot of code in the mediator object(s) to facilitate communication between the other objects. But I think it's either one or the other. And then this is preferable. It would also allow you more freedom to do tricks, like queuing certain update requests and handle the requests at more opportune times, or to do batch processing of a lot of requests instead doing them one by one which would (hypothetically) impose some sort of overhead.

Answer 3

Well one aproach would be to setup a client/server architecture. So the server would handle all game world updates and internal logic and the client would only ask the server if it can do certain actions. The server would then respond and the client would only then draw and update the game screen. Non player entities would do the same. The only difference would be the client is human controled and the other entities are computer controled. This would at allow you to seperate the game world setup and events and updates from entity logic.

The "message system" you mentioned is called the application protocol and can be a complex esoteric binary system, or simple human readable strings which I would recommend. As the player moves the server will send it a list of entities that are within sight of the client. Non player entities would operate the same way. That is by asking the server for permission to do things, or for information about another entity that the server previously sent it as it moved about and came into the entity's view, and the server responding with the appropriate answer or information.

If you were to implement this with sockets you would have the obviously benefit of intrinsic network play as the server would not care if the client were connecting on the same machine the server is running on or if the client is across the continent. This may not have answered your question specifically with code but I hope it was at least food for thought.

Answer 4

This is usually much easier if you have an object above the entity doing the management. (eg. the 'world' or the 'game'.) It can see easily which entities are in proximity to which others and send events and notifications accordingly.

If entities need a bit more context to make meaningful decisions when they're being updated, you can always have the world pass in that context in some form. But let the world manage the partitioning and placement of entities rather than needing entities to worry about that directly.

(Also, why a quadtree? For a 2D rpg a coarse grid would probably be much simpler to implement and equally useful.)