This week I started work on peer to peer and managed to get some of the first few steps complete. The client can receive a GUID from the facilitator and then send it through the server and to the host. However I have hit an issue where OSX machines do not receive the appropriate port and instead receive a port of ‘0’. There are also some issues with the peer to peer life cycle as it can break if you play more than one game. I will continue to work on these issues next week and further steps in peer to peer.
Pending tasks are now
Peer to Peer Investigation
Complete network game lobby UI (make pretty and complete all network game modes).
Complete network game restart UI (make pretty).
Research player skins.
Research different arenas and backgrounds.
General tidy up and enhancement of look and feel..
Rivalry Status Update #51 - LAN Games And Bug Fixes
This week I worked on implementing LAN games as an option for network play in the beta. LAN games work as a faster alternative to the current relay server method but only for machines on a local network. Its faster network speeds result from having messages only broadcast within a local network instead of being relayed across to a distant server on the Internet. The network protocol used in LAN is the same as the one used with the relay method but instead clients directly unicast packets straight to the Host where the host then broadcasts game updates directly to all the clients. This feature is now fully implemented into the Beta, so please notify me of any issues you encounter when using it.
I have already found one issue where if you play a LAN game over WiFi the clients network speeds drop to a point where their game runs at around 4 FPS. However if you then switch to a direct internet connection the network speed recovers fully. I am still trying to identify whether this bug is resulting from my local network or if it is a problem for everyone.
I also worked on fixing a few bugs, of which one related to the games frame rate affecting the speed at which you could drag limbs. If you had a monitor that could run Rivalry at 120 Hz (Double the speed at which Rivalry usually runs at). Because the limb dragging force is applied to the limb each frame, It would then also double the force that is being applied to the limb. So if you had a monitor that had an incredibly fast refresh rate. You could potentially kill you opponent in one move. I have now added a dynamic scaling factor which counteracts this effect.
Pausing in a network game now no longer pauses the game as it gave the host the power to control time.
The next step after LAN games is to move onto Peer to Peer games which is very similar to LAN games in that the machines still communicate directly but instead over the internet.
Pending tasks are now
Peer to Peer Investigation
Complete network game lobby UI (make pretty and complete all network game modes).
Complete network game restart UI (make pretty).
Research player skins.
Research different arenas and backgrounds.
General tidy up and enhancement of look and feel..
Rivalry Status Update #50 - Please Help Break My Server
This week I finished the “Optimise protocol” task, making it a binary protocol and it’s about 20 times smaller and faster than JSON which is exactly what I was hoping for. I have also switched the server for the cheapest, smallest server in AWS and would like to see how many people it can support. It’s currently running just in the US so anyone living there should get reasonable ping times. Because I am testing the limits of the server there is a chance the server could go down.
Instructions On How To Join Beta:
(Right click on Rivalry in Steam library and click "Properties")
(Go to "BETAS" Tab and select "Open Beta")
Pending tasks are now
LAN and Peer to Peer Investigation
Complete network game lobby UI (make pretty and complete all network game modes).
Complete network game restart UI (make pretty).
Research player skins.
Research different arenas and backgrounds.
General tidy up and enhancement of look and feel..
Rivalry Status Update #49 - Completed basic network protocol.
Have not posted in a few weeks sorry, been sick with the flu and busy with school assignment period on top of that.
I managed to complete two tasks this weekend.
Fix Highlighting Events in Replay & Network Game The network protocol did not contain any information about when limbs went floppy, undraggable or severed, so limb highlighting was still allowed, even when a limb was not draggable. This information has now been added to the network protocol making limb highlighting consistent over both the host and client.
Normalise Frame Rate across all machines Network protocol frame updates are now capped at 30fps. I have tried 15fps, which is playable but 30fps feels better. I may end up having the frame rate vary to allow for lag. LAN games could have 60fps, normal network games could get 30fps and network games on slow networks could get 15fps. Some of this will come out of the next tasks which involve optimising the network protocol and finishing the LAN and Peer2Peer gameplay modes.
Restricting the network frame rate to 30fps has definitely made it feel better and because of this I came very close to releasing network play into the Release build instead of keeping it in the Beta. However, I know at the moment it is using an unreasonable amount of bandwidth (Megabytes per second) so I am holding off until I have had a chance to optimise the protocol.
Pending tasks are now
LAN and Peer to Peer Investigation
Optimise protocol (Make it compact binary, instead of JSON).
Complete network game lobby UI (make pretty and complete all network game modes).
Complete network game restart UI (make pretty).
Research player skins.
Research different arenas and backgrounds.
General tidy up and enhancement of look and feel..
Rivalry Status Update #48 - Mouse Cursors and Limb Highlighting in Replay
This week I worked on fully implementing mouse cursors and limb highlighting into the replay / sharing feature. Your mouse cursor now has a unique colour based on the hash of your username that is global to everyone. Previously you would be given a random colour which would also be random to everyone else that saw it.
https://www.youtube.com/watch?v=Y84tq5-3tD0
Mouse Cursors in replay now also display your Steam username and will hide all networking mouse cursors that aren’t part of the replay. Previously when you viewed your replay you would see two sets of identical mouse cursors. One was the simulated mouse cursor in replay, and the other were the current mouse cursors in your game. Now the current mouse cursors are hidden when viewing, saving or sharing your replay.
The final thing I added was having limb and weapon highlights visible in your replay. However there are still some issues with limb highlighting events and limbs continuing to highlight even when the players turn has ended. Another thing that has not yet been added is the gentle fade to highlight and unhighlight which I will fix next week.
Pending tasks for next release now include.
Fix highlighting events in Replay
Normalise Frame Rate across all machines
LAN and Peer to Peer Investigation
Optimise protocol
Rivalry Status Update #47 - Server and Replay
Worked on optimising messages for the network protocol, now only sending messages to players if they need to receive them. For example you don’t need to know if a player has joined a team unless you are a player in that game.
Tweaked the network protocol to make message formats more consistent. This was to get multi-node serving working efficiently. I tested the server running in simulated multi-node mode. This is the node that kicks in if the server is busy and it needs to scale up by creating a copy of itself. Normally in single node mode the server works with knowledge of every user in every game however in multi-node mode players in the same game can be connected to different servers.
The Replay UI now enables network player mouse cursors to be visible in the Replay but does not yet include names or a consistent mouse cursor colour.
I’ve also started building towards the development of new arenas and have added canvas scalers to the game and replay arena. This temporarily broke the borders of the box map in replay UI which created some funny replays.
https://www.youtube.com/watch?v=YGbtxSZXB60&feature=youtu.be
The current task/roadmap list I am working towards is
Show multiple player mice cursors in replay
Show highlighting on Replay.
Generate consistent mouse color from hash of player id
Normalise Frame Rate across all machines
LAN and Peer to Peer development
Binary protocol.
Rivalry Status Update #46 - Mouse Visibility in Networking
I have been working on allowing different players mouse cursors to be displayed based on where you are in the Networking UI or what game you are in.
Previously no matter what UI you went in, through out networking you would always see the cursors of everyone who was online. When there were large amounts of people online, it would be hard to differentiate who was in who's game.
Now players can see each others mouse cursors based on where they are in the networking UI. For example if you are in the lobby you will see the cursor of everyone who is also in the lobby. If you are in a game you will only see the cursors of the players who are playing with you in that game.
This is done with two main features. Having the server only send mouse information to users if it relevant to their state in networking, and logic on the client side that decides on whether a cursor should be visible based on your position in the UI. This improves the overall clarity and speeds of networking as less is being communicated.
Next I will be working further on optimising these cursors and then on integrating the network protocol into LAN in binary.
Rivalry Status Update #45 - LAN Play and Binary Protocol
Over the past week I have been working on Local Area Network play and in some areas the binary protocol. More specifically ensuring that separate machines over a LAN network can see each other over different operating systems and network interfaces. As LAN play is just peer to peer but over a local network. I decided I should first create the LAN network protocol, as much of it can be reused for peer to peer.
I also decided to start work on the binary protocol as using JSON slowed down response speeds because of the size of the packets and the translation times. JSON makes network games unplayable for all practical purposes, but it's great for prototyping and has now served its purpose.
Over the next two weeks I am hoping to continue work on LAN play and perhaps try and finish Weapon Pushing once and for all.
Rivalry Status Update #44 - Network Game Rematch Finished and more Bugfixes
In the past 3 weeks I have been fixing many bugs relating to the network feature and got the Rematch Voting system to a finished state. However, I am not entirely happy with how the voting system works and have thought of many different methods that could be used to improve its functionality.
In its current state the Rematch Voting system works by holding a vote where people can then vote to join a rematch or leave the game. But if anyone decides to leave the game then everyone automatically leaves the game and no rematch is held. So in order to have a rematch everyone must vote for it, unanimously.
(Voting System with 3 people voted, and 1 yet to vote. If that 1 person votes to leave in the next 11 seconds then everyone leaves..)
To combat this, I have designed multiple ways to make the voting process more fair. Currently if anyone leaves the game is automatically shut down as there are no longer enough people to support a rematch game (This is the primary reason why the voting system works the way it does.) But if I enabled it so games can continue running even when someone leaves, then I could modify the voting system to be a lot more fair and have the majority vote win. However that is not the only change I would make. I would change it so once a game is over you can either leave, or create / join a rematch. If you fail to decide in 30 seconds or begin to render a replay video then you will automatically leave the game. If someone choses to create a game but only half the original players join, then the game will reopen to the public to be repopulated. I find that this system is a lot simpler as it only adds a countdown instead of a whole new UI and ensures that everyone gets what they voted for.
However, I may not work on this new version of the voting system as it is more vital that I work on features such as LAN games, which is a vital step towards achieving Peer to Peer and removing lag from network play. If you have used the Beta recently you may also notice that Network games are still quite slow. This is because I have not yet improved the network protocol and will only do so when I have finished all the features of Networking.
Rivalry Status Update #43 - Network Game Rematch and Bugfixes
Finally all of my school assessments for this term, are over so I can spend more time on Rivalry.
Over the past few days I have worked more on the rematch voting system and have it close to completion. All I have to do now is complete more testing and account for more edge cases. In its current state someone can call a vote which allows people to then vote to either leave or rematch.
Currently the vote needs to be unanimous on either side to cause any change, and I still have to work out the logic that controls what happens when the vote is uneven, equal or what happens when the timer runs out. But that should be relatively easy as I have already created most of the network protocol controlling it.
