Book's architecture good for action games?

Taulin · Aug 18th 2006, 8:37am

Is the architecture presented in this book actually good for action type games like Mario? I understand the separation of the Doc(actors) and View(models) is great, especially for networking, but isn't it a little too much of a burden for single player games?

Usually a View gets data from a Doc, not the other way around. The view is now replicating the data in the doc and is relying on the doc to keep it updated. I would think to adequately do this would add quite some overhead sending all those messages.

Anyways, I am thinking of trying out this architecture for a few things, and before I did, I was curious if anyone had used it for any action type games yet.

Thanks!

mrmike · Aug 18th 2006, 4:44pm

We use it at work - but if I told you on what project, I'd have to kill you.

Taulin · Aug 19th 2006, 1:41am

I am going to mess around with it, but at what level of granularity do you send updates on player position to the views? For example, if the character were running on an uneven surface, you would almost have to send and create events for every frame updating position and velocity. This would be versus physics determining new position in OnUpdate, and Render just querying the position. Again, I understand not one architecture fits everything, but I am curious if the power of today's PCs can really handle the load of the system you presented in this situation. If you are handling rough 3d environments, then it must.

mrmike · Aug 19th 2006, 11:18am

When there's no network involved - the game logic will send updates at a high frequency.

With a network in the way, the updates can't be sent across the internet at the same rate - so the view on the remote side has to do more intelligent guessing.

This is why sometimes in games like Doom you'll see rockets turn corners and frag someone. On the server side the rocket went in a straight line and got the frag - whereas on the client side the player stepped behind a corner 100ms before the rocket got there. So, the difference has to be made up on the client when it recieves an event like "Dood - you got fragged!". It shows the rocket hitting the player, and the frag really happens.

Get it?

Taulin · Aug 19th 2006, 1:10pm

I understand, but I was concerned about local updates (forget about networking for the moment) in situations that could require a lot of events to be fired, like in the example of uneven groung, or tons of debree, where an actor is in no way moving on a straight planer path. I think my question has diverted to the point where I am stretching for a situation that would of course tax the system, but never arise that much, so it might be moot. No one glove fits all, but hearing you say you are using it eases a lot of concerns. Thanks for the responses!

mrmike · Aug 19th 2006, 3:30pm

Here's a couple of other tidbits that will help:

1. Particles are only visual, so they don't need to be placed by events. For some debris, that doesn't affect the physical world, the same thing is true - they are objects that only exist in the "viewable" world, and can therefor be moved and placed directly - without going through the event system.
2. You can "batch" movement events together, moving lots of objects at once, instead of sending an event for each object.
3. For linear movements, or movements along a predictable spline, the movement can be sent along not as (x,y,z) coordinates, but a % of the movement - you could then send tihs data only when the game simulation and game view would be out of sync.

It's basically the same thought process you go through when constructing network packets.

Book's architecture good for action games?

Book's architecture good for action games?

RE: Book's architecture good for action games?

Have to experiment

RE: Have to experiment

Share