Artillery Progress & The Platform System Explained
[h2]Hello everyone![/h2]
We thought it might be a good idea to give you all a bit of an update as to the progress we’re making regarding two of the most complex systems we’ve yet to develop: Artillery & The Platform System as well as list some of the release blocking issues currently stopping us from releasing artillery in its current state despite the great amount of anticipation surrounding it.
[h2]Artillery Progress Report[/h2]
Since we last showed you any of the artillery in action we’ve been adding fully functional limber carts containing Shell, Case & Canister rounds as well as being moveable in much the same way as the cannons themselves are. We’ve also polished a number of animations as well as having updated the firing particles of the cannons. Another addition is the displayed “Elevation Angle” shown in the lower left corner when turning the elevation screw of the cannon. This is the total of the barrel elevation as well as ground slope combined and should prove very useful for gunners wanting to shout out angles to the other crew members after successful hits. We have also added a 2nd quicker speed when strafing with the limber cart pole, the cannon trail spike and turning the elevation screw. This will allow crews the ability to quickly turn the pieces most of the way (holding shift) with the faster speed as well as use the precision of the slower speed (letting go of shift) to properly aim the piece.
We have also populated all of the battlefields with the correct batteries at the correct locations (based on the exact key moments the skirmish areas portray) as well as added capturable forward battery deployments for each individual active battery (This is basically our way of giving the battery crews a forward spawn just as the infantry regiments have their flag spawns).
Here is a quick video we recorded of the above new additions.
[previewyoutube][/previewyoutube]
[h2]Artillery Release Blockers Detailed[/h2]
As we know just how anticipated the deployment of the first version of artillery is by many of you we have decided to give you a quick rundown of the current major release blockers we are working on fixing. Please note that this list is the current list and that it may grow in future internal playtests. It is also possible that several of the below issues are caused by the same bug.
1) Reset the state of artillery pieces when the round is over.
2) Look into cannon firing sounds and particles not triggering for some clients when firing - once this is triggered it appears to be in place until a game restart.
3) Sometimes the inserted shell is not removed correctly from the player, leaving him in a shell carrying animation pose without a shell and allows him to switch to the rammer as well, enabling him to both load (with the invisible shell he holds) and ram the cannon on his own without having to grab a new shell.
4) Sometimes cannons and limbercarts will lose their proper physics behavior. Their proxy will be broken and they will be pushable by the player if they are walked into. They are also not allowing any seats to be interacted with in this state. This has been reproduced by having a limbercart (note: the cannon in this experiment did not break - the limbercart did however) interacted with/pushed, etc. so it is no longer in its default position on the skirmish area, then quit the game and rejoin the server. It will now be in a broken physics state where it is pushable and non interactable as described above while all of the rest of the limbercarts that haven’t been touched by anyone are still fully physicalized. Cannons have also been seen to break in the same way but it has not been reproduced by the above test.
5) All of the rounds inside the limber chest are sometimes invisible. You can still see the text above them and the second you pick one up they all come into view. This was seen on the Dunker Church skirmish area, Antietam in the Carlton Battery, CSA.
6) Friendly (and possibly also enemy) players killed by the explosion of a shell will sometimes appear dead for everyone but themselves. They are in fact alive and can be seen by their nametags moving about. While invisible they can still damage other players so this is a major release blocker.
While the above can give the impression of it going to take a lot of work to fix we are confident that we indeed are in the last phases of development before the update is ready for deployment. We hope the seriousness from a competitive game’s standpoint some of the above issues are will help you understand why the update has not been released yet.
Once the release blockers have been dealt with we plan on hosting a public dev branch test of the artillery patch prior to its actual release on the live build of the game. We will be sure to let you all know the when and how’s as soon as testing is ready to start.
[h2]Technical Issues in the Alpha[/h2]
In the wake of the last few weeks of posts by our community highlighting some of the issues they are currently (and have been for a long time) experiencing in the alpha we felt we needed to explain to you all what is being done in order to fix them. We therefore asked Philipp - the other part of our programming team not focusing on the artillery, to explain what he primarily has been up to since the alpha was released on Steam Early Access nearly 18 months ago.
[h2]The Platform System[/h2]
Hey, I am Philipp and one of the Programmers on the War of Rights Team.
I have mainly worked on core systems like Game rules, Spawning or Networking to name a few.
For quite a while now, since January last year, I have been focused on a rather large and difficult undertaking that we deemed necessary to make developing War of Rights easier and allow us to deliver a viable online multiplayer experience. That being a completely new Platform / ”Lobby” system.
[h2]What is it?[/h2]
The job of the Platform system is to handle all functionality relating to a “Platform” the game is currently running on.
Some of the crucial features being:
- Authentication
- Matchmaking and Server discovery
- Connection handling between client and server
- Platform related data exchange (Usernames, Clans, etc.)
- Chat
And some of the less crucial ones:
- Friends/Clans/Groups
- Ability to join games your Friends/Clan/Groups are on
- Rich status display about what you are doing to other (i.e. “Attacking on map x for side y”)
- Statistics
- “User generated content” (Icons, server banners, etc.)
[h2]Why is it?[/h2]
Right now, our online functionalities are being handled by a library that was designed for ps3/xbox360 era p2p style gaming, onto which we added the functionality required for steam servers. Since we released into early access this has been an ongoing headache. It makes it far too difficult for our small team to debug issues relating to connection failures and other connectivity issues. Adding new functionality is also a pain every time and might cause more issues down the line. In short, our current solution is not viable if we want to keep expanding on it.
[h2]What does it solve?[/h2]
A completely new implementation allows us to separate all online functionality into its own module and focus on solving issues that have plagued the game since early access release, which we so far are barely even able to reproduce, let alone debug.
Some of the issues that this will fix or help us fix are:
- Stuck on establishing context
- Random disconnects
- Failure to reconnect to a server
- Failure to connect to a server
- Server mass drops
- Servers not showing up in the list
- Connections to other players staying active after disconnecting
- Lighten the load on the game networking module and thread
[h2]What does it allow us to do?[/h2]
Apart from allowing us to properly debug and fix all our connection issues, it also allows us to implement some planned features as well as hypothetical features down the line so we don’t need to rip everything apart each time we want to add something.
Some of the planned features are:
- Proper error messaging for networking related issues. This includes a description of why a join attempt may have failed or a message that tells you why you have been kicked/banned from a server.
- Integrate with Steam’s friend system so that you can join your friends and groups directly from the Steam client.
- Integrate with a backend service that allows us to supplement user data with our own persistent data. This makes it possible to integrate the company tool into the game itself.
- Backer reward cosmetics
Some hypothetical features this system allows us to implement without an insane amount of work:
- Cross battle persistent data
- Game events
- Server slot reservation based on company or event
- Expanding to other platforms in the future (Epic, xbox, playstation, switch, phone, microwave)
- Platform cross-play
[h2]Why is this taking so long?[/h2]
As you might imagine, this is a huge amount of work for a small team like ours and involves threading, networking, serialization, and other fun stuff.
The key here is to get it right and build a sustainable framework that is maintainable as well as extensible. This includes designing it to allow for easy integration of the different Platform Apis. (Steam being the main one, but lan also needs to be implemented for internal testing).
So, finding a combination of tools and learning them has been quite a challenge, but we hope to release the first iteration of this soon, and alleviate some of those ongoing connectivity woes.
That’s all for now - we can’t wait to eventually bring you the platform system, posed to fix or at least help to fix a number of some of the most reported and annoying alpha issues of the game and also heading into public testing of the artillery patch with you all as soon as the pesky release blockers have been dealt with!
We thought it might be a good idea to give you all a bit of an update as to the progress we’re making regarding two of the most complex systems we’ve yet to develop: Artillery & The Platform System as well as list some of the release blocking issues currently stopping us from releasing artillery in its current state despite the great amount of anticipation surrounding it.
[h2]Artillery Progress Report[/h2]
Since we last showed you any of the artillery in action we’ve been adding fully functional limber carts containing Shell, Case & Canister rounds as well as being moveable in much the same way as the cannons themselves are. We’ve also polished a number of animations as well as having updated the firing particles of the cannons. Another addition is the displayed “Elevation Angle” shown in the lower left corner when turning the elevation screw of the cannon. This is the total of the barrel elevation as well as ground slope combined and should prove very useful for gunners wanting to shout out angles to the other crew members after successful hits. We have also added a 2nd quicker speed when strafing with the limber cart pole, the cannon trail spike and turning the elevation screw. This will allow crews the ability to quickly turn the pieces most of the way (holding shift) with the faster speed as well as use the precision of the slower speed (letting go of shift) to properly aim the piece.
We have also populated all of the battlefields with the correct batteries at the correct locations (based on the exact key moments the skirmish areas portray) as well as added capturable forward battery deployments for each individual active battery (This is basically our way of giving the battery crews a forward spawn just as the infantry regiments have their flag spawns).
Here is a quick video we recorded of the above new additions.
[previewyoutube][/previewyoutube]
[h2]Artillery Release Blockers Detailed[/h2]
As we know just how anticipated the deployment of the first version of artillery is by many of you we have decided to give you a quick rundown of the current major release blockers we are working on fixing. Please note that this list is the current list and that it may grow in future internal playtests. It is also possible that several of the below issues are caused by the same bug.
1) Reset the state of artillery pieces when the round is over.
2) Look into cannon firing sounds and particles not triggering for some clients when firing - once this is triggered it appears to be in place until a game restart.
3) Sometimes the inserted shell is not removed correctly from the player, leaving him in a shell carrying animation pose without a shell and allows him to switch to the rammer as well, enabling him to both load (with the invisible shell he holds) and ram the cannon on his own without having to grab a new shell.
4) Sometimes cannons and limbercarts will lose their proper physics behavior. Their proxy will be broken and they will be pushable by the player if they are walked into. They are also not allowing any seats to be interacted with in this state. This has been reproduced by having a limbercart (note: the cannon in this experiment did not break - the limbercart did however) interacted with/pushed, etc. so it is no longer in its default position on the skirmish area, then quit the game and rejoin the server. It will now be in a broken physics state where it is pushable and non interactable as described above while all of the rest of the limbercarts that haven’t been touched by anyone are still fully physicalized. Cannons have also been seen to break in the same way but it has not been reproduced by the above test.
5) All of the rounds inside the limber chest are sometimes invisible. You can still see the text above them and the second you pick one up they all come into view. This was seen on the Dunker Church skirmish area, Antietam in the Carlton Battery, CSA.
6) Friendly (and possibly also enemy) players killed by the explosion of a shell will sometimes appear dead for everyone but themselves. They are in fact alive and can be seen by their nametags moving about. While invisible they can still damage other players so this is a major release blocker.
While the above can give the impression of it going to take a lot of work to fix we are confident that we indeed are in the last phases of development before the update is ready for deployment. We hope the seriousness from a competitive game’s standpoint some of the above issues are will help you understand why the update has not been released yet.
Once the release blockers have been dealt with we plan on hosting a public dev branch test of the artillery patch prior to its actual release on the live build of the game. We will be sure to let you all know the when and how’s as soon as testing is ready to start.
[h2]Technical Issues in the Alpha[/h2]
In the wake of the last few weeks of posts by our community highlighting some of the issues they are currently (and have been for a long time) experiencing in the alpha we felt we needed to explain to you all what is being done in order to fix them. We therefore asked Philipp - the other part of our programming team not focusing on the artillery, to explain what he primarily has been up to since the alpha was released on Steam Early Access nearly 18 months ago.
[h2]The Platform System[/h2]
Hey, I am Philipp and one of the Programmers on the War of Rights Team.
I have mainly worked on core systems like Game rules, Spawning or Networking to name a few.
For quite a while now, since January last year, I have been focused on a rather large and difficult undertaking that we deemed necessary to make developing War of Rights easier and allow us to deliver a viable online multiplayer experience. That being a completely new Platform / ”Lobby” system.
[h2]What is it?[/h2]
The job of the Platform system is to handle all functionality relating to a “Platform” the game is currently running on.
Some of the crucial features being:
- Authentication
- Matchmaking and Server discovery
- Connection handling between client and server
- Platform related data exchange (Usernames, Clans, etc.)
- Chat
And some of the less crucial ones:
- Friends/Clans/Groups
- Ability to join games your Friends/Clan/Groups are on
- Rich status display about what you are doing to other (i.e. “Attacking on map x for side y”)
- Statistics
- “User generated content” (Icons, server banners, etc.)
[h2]Why is it?[/h2]
Right now, our online functionalities are being handled by a library that was designed for ps3/xbox360 era p2p style gaming, onto which we added the functionality required for steam servers. Since we released into early access this has been an ongoing headache. It makes it far too difficult for our small team to debug issues relating to connection failures and other connectivity issues. Adding new functionality is also a pain every time and might cause more issues down the line. In short, our current solution is not viable if we want to keep expanding on it.
[h2]What does it solve?[/h2]
A completely new implementation allows us to separate all online functionality into its own module and focus on solving issues that have plagued the game since early access release, which we so far are barely even able to reproduce, let alone debug.
Some of the issues that this will fix or help us fix are:
- Stuck on establishing context
- Random disconnects
- Failure to reconnect to a server
- Failure to connect to a server
- Server mass drops
- Servers not showing up in the list
- Connections to other players staying active after disconnecting
- Lighten the load on the game networking module and thread
[h2]What does it allow us to do?[/h2]
Apart from allowing us to properly debug and fix all our connection issues, it also allows us to implement some planned features as well as hypothetical features down the line so we don’t need to rip everything apart each time we want to add something.
Some of the planned features are:
- Proper error messaging for networking related issues. This includes a description of why a join attempt may have failed or a message that tells you why you have been kicked/banned from a server.
- Integrate with Steam’s friend system so that you can join your friends and groups directly from the Steam client.
- Integrate with a backend service that allows us to supplement user data with our own persistent data. This makes it possible to integrate the company tool into the game itself.
- Backer reward cosmetics
Some hypothetical features this system allows us to implement without an insane amount of work:
- Cross battle persistent data
- Game events
- Server slot reservation based on company or event
- Expanding to other platforms in the future (Epic, xbox, playstation, switch, phone, microwave)
- Platform cross-play
[h2]Why is this taking so long?[/h2]
As you might imagine, this is a huge amount of work for a small team like ours and involves threading, networking, serialization, and other fun stuff.
The key here is to get it right and build a sustainable framework that is maintainable as well as extensible. This includes designing it to allow for easy integration of the different Platform Apis. (Steam being the main one, but lan also needs to be implemented for internal testing).
So, finding a combination of tools and learning them has been quite a challenge, but we hope to release the first iteration of this soon, and alleviate some of those ongoing connectivity woes.
That’s all for now - we can’t wait to eventually bring you the platform system, posed to fix or at least help to fix a number of some of the most reported and annoying alpha issues of the game and also heading into public testing of the artillery patch with you all as soon as the pesky release blockers have been dealt with!