I had asked about the flag spawn timer and I think Trusty's reply was something to the effect of it being a guesstimate rather than your actual position in the queue.
Yes, Fancy managed to make it guess correctly much more often in one of the previous updates however, but you are correct that it is still indeed a guess as we don't network the position of all client positions in the queues as we've been advised not to by our programmers due to the cost of it.
- Trusty
Cost. What cost? Bandwidth? When you're sending realtime 200 peoples worth of movement, looking, stance, shooting data at the start of a game you send much more data then for 150 people playing and 50 waiting to respawn (which need only 2 numbers once per second form the server (position in their respective queue and the queue length). Overhead on server should be negligible for those 2 queues.
Server cost? That's already rented, can keep it at 100% or 0% load for the same money.
Really, I do not understand what this cost can be.
Might be nice to see the queues per regiment and per flag/spawn, as a clue of we're dying too much or we're under strength and will receive few reinforcements or we do not spawn fast enough. Nicer still to have a precise spawn queue indicator
Last edited by EneCtin; 05-07-2019 at 02:46 PM.
The Reason i advised against sending accurate queue positions at the Time was mainly because we had no reliable Profiling Data at that point and the servers were already under an insane load.
All the new system we add are designed to minimize any impact on server performance and network bandwidth where possible.
So in regards to the spawn queue that would be avoiding to iterate over all the queued Spawnables(which are listed by their entity ids since the spawn points are set up in a way to allow spawning non player entites as well), queuing the spawnable component and packing the queue position with the serialized data.
For the serialized data it matters in what way they are serialized since the impact on performance and bandwidth is different depending on the methode. (RMI, bulk entity data serialization)
Per-Frame updates are avoided at all cost if no data has changed, so the spawnpoints just transmit their queue lengths and queue timer when the queue changes. (Player removed, added, spawned etc.)
Right now we know, that the performance bottlenecks on the server are happening in the network thread.
Meaning, that game thread has to wait for over 100ms on the Network thread, since its busy processing and sending all the data out which was accumulated over the last frame.
This on one Hand means that runtime performance concerns for gamecode can be taken a lot more lightly (at least on the server, the client is a different story), but on the other it also means that we need to think about every extra bit of data we transmit to the clients and try to find a way to maybe reproduce it there instead of sending it.
The actual implementation of the feature is trivial complexity wise, but we aren't many Programmers and have a lot on our Plate that doesn't necessarily allow rapidly switching between tasks that aren't complete blockers and just popped up.
If the current way the spawn time is displayed to the user causes too many problems, we will of course work on fixing that.
At the moment i am busy with completely overhauling the core system that deals with the social/lobby/matchmaking aspects around the game, primarily to address the problems with joining and finding servers, but also to create a nicer and smoother experience playing together.
(Joining friends, forming parties, server matchmaking, player information, clans, etc)
That was a great insight you've shared with us, thank you. Almost (almost ) am feeling bad for pushing for it. Did not expect and really appreciate the level of detail.
I'd like to offer a suggestion on the network thread. If I understood correctly, each client receives a serialized batch with all changes to all objects in the game since last transmit. That means a complete update but a lot of non important data is included together with gameplay critical data. The ideea is to divide this data into 3 serialized batches, one high priority, one low priority and one no priority.
In the high priority batch you receive the changes that can affect your gameplay (someone turned to look at you, someone got in your visible area, someone aims at you, someone shoots at you, etc). No need to include in this batch that player X died somewhere I cannot see or other events that cannot influence me. You save bandwidth.
In the low priority batch you include events that cannot influence you (hidden or unseen movements, all the other changes, sounds etc). This batch is sent less frequently, thus saving bandwidth. Since aiming takes 2-3 seconds, if someone is not aiming at you, you are in no imminent danger (network wise) so that kind of data can be included in low priority batch.
The no priority batch is the respawn queue, and that is sent just between players in the queue (queue position, current length of queue). For those in the respawn queue, there is no need to send the high priority batches or the low priority batches. Save more bandwidth.
Basically, it's choosing what needs to be sent immediately and what can wait. Don't have the figures, but if 75% are in game and 25% are respawning, the bandwidth requirement might be about 60% of full complete batch, maybe less with low priority batch. Meaning increasing server cap, maybe.
Last edited by EneCtin; 05-07-2019 at 05:30 PM.
CSA Captain
My biggest concern with this game is the limitation of the very rigid Antietam vision the developers seem to have. Antietam can and should be its core, but it could offer so much more.
It’s more of a re-enactor simulation than intuitive fun for gamers which is fine if the developers want to stick to that very narrow niche, but gees what an opportunity squandered.
If you added some more player gaming tools to make the game feel more intuitive, possibly limited player recognition options and a random map generator, the customer base would expand markedly because the game would be more variable and replayable.
Last edited by Quaker; 05-08-2019 at 10:21 AM.
I'll just borrow yours instead.
Another one. Enjoy the game or don't play it - the game will never fit your exact vision, you're not making it.
We can all make suggestions, but sly digs at the devs and veiled pleading really don't help your cause. It's hard to ideas seriously when they're followed with "if the developers want to stick to that very narrow niche" and "the customer base would expand markedly". They're not children, you know.