Doing the split screen, it will be harder to see the creatures before they attack as you lose half of the screen. It would also increase the load on the main computer as it is now handling all of the processing. You would need both people in the same room. What you are suggesting now would only effect a smaller group than what they have planned.
Preferably options for local and online play are always best but I'm no programmer so I don't know the pains of doing any of this (other than what's described in the link now) Maybe spitball the idea of going the implement splitscreen then remote play route if you decide that you want to aim for only 2 player co op I'd personally like the option of it like the X game had and it might be easier to implement faster since it doesn't need networking? Originally posted by BearCatAiJoey:So is splitscreen/shared screen co op not possible? Have you considered doing both, client-server and peer2peer? That system is a bit on the peer2peer side though where the clients start exchanging information and game state changes on both sides instead of just doing everything on one as in a pure client server structure, which brings me to the actual point of the question: and then just communicate the results of those state changes between the client and server. So all the information about bone positioning and such can be run by the client themselves, it basically is just a do this playback animation type thing, the only communication needed is the state of the changed object, is it alive or dead, does it change a number like hp on wall/mech/etc. and animation information that has no impact on the game state, like pretty much all animations that just show something moving but don't change a number. So to me it is kinda always clear where to draw the line between animation information that needs to be processed by the server, like a projectile that hits sth. The only difference to be made would be to sync the projectile creation state with the server, so sending an event to the server from the client when a projectile should be created, letting the server then decide if that already occurred on his side and the projectile is already alive, because the other player which acts as server has already played the animation and created the model, or if it's not there yet and need to be created for potential damage calculations, in case the server player is out of vision and the client player needs to call the server for projectile creations. While this is the case, I don't see where the logic itself prevents the client to run all the animation himself, while keeping the game logic on the server. Or did you mean that currently this is not possible duo to the way it currently is coded and you have to change it to a structure that now supports basic changes to reasearch/mission/inventory states?Īnd also on the animation states, you mention that for example a projectile that occurs on a certain position of the animation is created by the game logic. Where is it necessary here to sync the whole thing every game tick? Personally I don't really see why it would be needed to be synced completely, because logically I would just go for an approach where the server sends a start event, then the client handles most of the event triggers for himself to show the player on the client what is going on and then run a sync state when the timed event has finished to make sure everyone is on the same page again. Like you mentioned that you have to sync the mission log on a timed mission completely every 33ms, as an example of a component that is not optimized yet. While reading there were some questions coming up. Interesting to read, I am really looking forward to the first iteration of coop that comes up for this.
0 kommentar(er)
