Re: OpenDrakan ~ A Drakan engine recreation
Posted: Fri Nov 02, 2018 10:16 am
Regarding the separation of renderer code from the rest of the object logic - as well as the general server/client considerations to make multiplayer possible (and actually playable), here's how I think it should look like in the most general terms:
Now the key point, which is not immediately obvious from the block diagram, is how the rendering logic works.
Instead of each object pushing its own updates to the renderer, I think it would be better that each object gets queried by the renderer instead.
Of course this would require each object to have some kind of flags variable, which determines whether the renderer should even bother processing the object - for example, there's no point in attempting to render objects which are not supposed to be visible, those whose models use no textures at all, or those which don't even have any model assigned to them in the first place.
Now, I'm fully well aware that the Riot Engine closely ties the processing of some (all of the?) objects to the visibility states of the layers they are on - but IMO, that's more of a bug than a feature (certainly it causes a lot of bugs!), and it would hardly be missed if it were to be disposed of.
Regarding multiplayer: observe how in my proposed engine architecture, functionally speaking, from the client's perspective, nothing changes if the entire MP intermediate layer is thrown out.
The only difference is that in singleplayer mode, instead of the client's logic interacting with its own local copy of the object data, it instead interacts directly with the server's own object data as if it were the client's.
Alternatively, the MP intermediate layer can be retained, to avoid possibly complicating things - of course the de'd reckoner needs to be disabled then, since there's no network delay with local communication.
The general idea is that in MP, outside of the usual rendering and input handling, the client logic should only perform the most basic tasks required to make the game playable - and even then, only those tasks that can't be reasonably offloaded to the server because of network delays; all of the "important decisions" which have a significant impact on gameplay should be instead handled only by the server.
In other words... in terms of the underlying architecture at least, you need to start with getting the MP to work. SP mode then emerges naturally as a consequence of that.
Trying to do it the other way around (SP first, then MP) would almost certainly lead to disaster; it's far too easy to write oneself into a corner that way.
Now the key point, which is not immediately obvious from the block diagram, is how the rendering logic works.
Instead of each object pushing its own updates to the renderer, I think it would be better that each object gets queried by the renderer instead.
Of course this would require each object to have some kind of flags variable, which determines whether the renderer should even bother processing the object - for example, there's no point in attempting to render objects which are not supposed to be visible, those whose models use no textures at all, or those which don't even have any model assigned to them in the first place.
Now, I'm fully well aware that the Riot Engine closely ties the processing of some (all of the?) objects to the visibility states of the layers they are on - but IMO, that's more of a bug than a feature (certainly it causes a lot of bugs!), and it would hardly be missed if it were to be disposed of.
Regarding multiplayer: observe how in my proposed engine architecture, functionally speaking, from the client's perspective, nothing changes if the entire MP intermediate layer is thrown out.
The only difference is that in singleplayer mode, instead of the client's logic interacting with its own local copy of the object data, it instead interacts directly with the server's own object data as if it were the client's.
Alternatively, the MP intermediate layer can be retained, to avoid possibly complicating things - of course the de'd reckoner needs to be disabled then, since there's no network delay with local communication.
The general idea is that in MP, outside of the usual rendering and input handling, the client logic should only perform the most basic tasks required to make the game playable - and even then, only those tasks that can't be reasonably offloaded to the server because of network delays; all of the "important decisions" which have a significant impact on gameplay should be instead handled only by the server.
In other words... in terms of the underlying architecture at least, you need to start with getting the MP to work. SP mode then emerges naturally as a consequence of that.
Trying to do it the other way around (SP first, then MP) would almost certainly lead to disaster; it's far too easy to write oneself into a corner that way.