Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

I've been creating an RTS game, and I'm a little unsure about how to deal with the above. Right now, I wish to control which units are visible to which players, and I've run into a little problem. Previously, I had three components- render, sim, and UI (untrusted scripted component). However, I'm beginning to believe that this is not the optimal architecture.

For example, given the task that only the relevant units should be visible from a given player's perspective, none of the above components are up to the job. The sim is player-independent, the renderer has no idea about players at all, and the UI can't be trusted. So I've come to the need to introduce a fourth component- a kind of Controller which communicates between the three components and correctly limits the information each one has access to.

Is this the normal approach? Or am I missing a trick when it comes to making the sim, UI, and renderer co-operate?

share|improve this question
add comment

2 Answers 2

I don't see why the sim is 'player independent' - it may be shared across all players, but surely that is the part of the game that decides what each player is able to see. The renderer can get its information from there.

share|improve this answer
    
I think that he may be talking about LOS and enemy visibility for units that are inside the rendering frustum (including mini-map style displays) and not render culling techniques. –  Patrick Hughes May 10 '12 at 17:42
    
I know, and that is exactly what I mean - the simulation would be responsible for deciding which units can see others. –  Kylotan May 11 '12 at 12:36
    
Oh I see, yes, I'm now on the same page =) –  Patrick Hughes May 11 '12 at 22:26
add comment

Right now, I wish to control which units are visible to which players

So you're making a multiplayer game? Then "what can the player see" is an issue of the server distributing information properly. The client is just a rendering engine that displays everything that the server tells it about. There's literaly no connection between simulation and rendering. If the client has any simulation code (prediction code to account for lag or something) then it should work only on the information that the player can have anyway.

There probably could be some optimatlizations logic for each client that would describe what you can and cannot possibly see in the chunk that the camera currently is in (for example you don't have to display chunks that are behind the camera and you don't have to display chunks that are behind a huge mountain), but TBH this seems like a regular issue that's solved with frustum culling or some other forms of culling. There's plenty of articles these kinds of optimalizations.

share|improve this answer
1  
RTS games are peer to peer- every client runs the simulation. –  DeadMG May 10 '12 at 17:00
1  
World in Conflict is not peer to peer, but than again one might argue that it's not an RTS either. –  Koarl May 10 '12 at 21:58
1  
@DeadMG Not always true. I am also making an RTS game and the game itself require that there is only one server at each time. In some games, it is done like this, but most of the time they allow migration of the server (change of who is the server, when the server is lost for example). Mine, by design, cannot. –  Klaim May 11 '12 at 7:01
    
OK, so there are some RTS games which operate different systems, but mine is definitely peer to peer. –  DeadMG May 11 '12 at 13:31
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.