Page 7 of 11 FirstFirst ... 56789 ... LastLast
Results 61 to 70 of 104

Thread: What changed?

  1. #61
    WoR-Dev TrustyJam's Avatar
    Join Date
    Jan 2013
    Location
    Denmark
    Posts
    5,133
    Quote Originally Posted by LaBelle View Post

    To Mark: There's a little brown on your nose, might wanna order some wet wipes.
    No need for that. The continued discussion proved that his sentiment was indeed in order (as the poster he replied to continued down a non-progressive path).

    - Trusty

  2. #62

    USA General of the Army

    Oleander's Avatar
    Join Date
    Jan 2016
    Posts
    646
    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.

  3. #63
    WoR-Dev TrustyJam's Avatar
    Join Date
    Jan 2013
    Location
    Denmark
    Posts
    5,133
    Quote Originally Posted by Oleander View Post
    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

  4. #64
    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.

  5. #65
    WoR-Dev TrustyJam's Avatar
    Join Date
    Jan 2013
    Location
    Denmark
    Posts
    5,133
    Quote Originally Posted by EneCtin View Post

    Might be nice to see the queues per regiment and per flag/spawn, as a clue of we're dying to much or we're understrength or we do not spawn fast enough. Nicer still to have a precise spawn queue indicator
    The queues are already on a per regiment basis (flag bearer spawning as well as base spawning) - visually as well.

    - Trusty

  6. #66
    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)

  7. #67
    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.

  8. #68

    CSA Captain


    Join Date
    Nov 2013
    Location
    Detroit
    Posts
    592
    Quote Originally Posted by sunnlok View Post
    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)
    Very nice information, thank you. Excited to see your hard work pay off!
    Just when I thought I was out...they pull me back in!

  9. #69
    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.

  10. #70
    Mark L. E. E. Smith's Avatar
    Join Date
    Jul 2017
    Location
    Manchester
    Posts
    48
    Quote Originally Posted by LaBelle View Post
    To Mark: There's a little brown on your nose, might wanna order some wet wipes.
    Quote Originally Posted by LaBelle View Post
    Quote Originally Posted by sunnlok View Post
    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)
    Very nice information, thank you. Excited to see your hard work pay off!
    I'll just borrow yours instead.

    Quote Originally Posted by Quaker View Post
    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.
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •