Hey guys! Rivalry progress has been slow. My university work has been my number one priority which hasnt left me much time to work on the game. Progress is being made but just at a much slower rate.
The latest improvement is camera zooming! This allows players to zoom the Camera in and out of the Arena. I originally thought this wasnt worth investigating as it would be too difficult to control the players when zoomed out but its actually quite easy! This makes fighting on large maps far more enjoyable as you can always see your opponent and dont have to drag the camera as much!
The current issue I'm facing is testing the mapping feature on the server, more specifically facing a couple of issues surrounding websocket connections randomly breaking. Once I have figured this out usual progress should hopefully be able to be made. Remaining tasks are now

• Fix server websocket disconnection issue
• Finish up arenas
• Sound effects and music
• Complete network game lobby UI (make pretty and complete all network game modes).
• Complete network game restart UI (make pretty).
• General bug fixing, tidy up and enhancement of look and feel..

With the start of university break I have started once again working on the map feature! I initially fixed some bugs surrounding arena choice rubberbanding and different edge cases in the network UI. After this I focused on tweaking each map. I added a velocity threshold to all props and crush damage weapons (Sai, Sledgehammer) so that you need a certain threshold of velocity before damage can be dealt.
This was originally implemented so that when the boulders on the stonehenge map are thrown at enemies they actually cause damage instead of pushing the player around. Before this threshold, simply walking on boulders would cause explosions of blood to spray out the bottom of each player's feet as any velocity (even close to zero) would result in a small amount of damage and therefore blood. This threshold has been applied to all props so lightly pushing plates and glasses in the Tavern wont cause blood explosions.
As well as this some weapons have been updated to be more powerful / fun. For example, the sledgehammer has been updated so that it is both more powerful and more forgiving when hitting something lightly. The spear is now more maneuverable but slightly less damaging. Ive found this makes it more satisfying to use whilst still maintaining its strength at long distance and weakness at short distance. Hopefully these changes will make both weapons more fun to use! Ive also been setting up an official discord server which should hopefully launch at the same time as the new update releases! Maps coming soon! Remaining tasks are now

• Finish up arenas
• Sound effects and music
• Complete network game lobby UI (make pretty and complete all network game modes).
• Complete network game restart UI (make pretty).
• General bug fixing, tidy up and enhancement of look and feel..

Over the past three months Ive had to put my head down and focus on university study, who knew machine learning courses could be so time consuming? At least what I have learnt from these courses could possibly be applied to making AI opponents for Rivalry further down the line! In the spare time I did have to work on Rivalry I have tweaked many of the soon coming maps and added an indicator that points towards players when they are off screen.
I also fixed a bug where in replay mode, blood would spray out in intense jets instead of the usual fan that we are used to. https://youtu.be/AHOaGNo9WB8 (Old Blood) https://youtu.be/5l7GV3w4bpI (New Blood) Over the coming weeks Ill be further tweaking these maps, eventually trialling them online before finally releasing them! Also, official discord is on its way! Remaining tasks are now

• Finish up arenas
• Sound effects and music
• Complete network game lobby UI (make pretty and complete all network game modes).
• Complete network game restart UI (make pretty).
• General bug fixing, tidy up and enhancement of look and feel..

Over the past two months I've implemented the last three maps that will be included in the Map Update!! The first one being "The Tavern". The tavern starts with both players on a long table. Various plates, candles, pints and other objects scatter the table. These objects can be kicked and thrown at the enemy to inflict light but noticeable damage.

Three large hanging chandeliers swing when hit and can even fall onto your enemies if you hit them hard enough! This map has the largest number of props of any map. https://youtu.be/raCv-zuQD8g Then there's "The Great Wall''. The Great Wall features the two players fighting along the crenellations of a Great Wall. Two watchtowers extend from either end that can be mounted. However, the most exciting feature of The Great Wall are the three ballistas planted on each tower, and one placed in between the two players at the beginning.
The ballistas can be aimed by pushing and then fired by pushing down on either of the large buttons placed on either side of its frame. When pressed the ballista will shoot a bolt that will tear through any player in its way. (Warning: Prone to misfiring). https://youtu.be/SZT6bf5_gwA https://youtu.be/AHOaGNo9WB8 Last but not least, "The Throne Room''. The throne room consists of a throne placed on the top of a pyramid of steps. The players begin on either side of the throne and battle over its ownership.
A large destructible chandelier hangs above the throne but unlike its tavern counterpart, this chandelier is much heavier and includes dangling sharp crystals that can cut. (It's also a lot fancier). https://youtu.be/EKDRtktl4pM Next, I will be tweaking and testing these maps both in local and network play. If all proves to function correctly, then I will move into the release stage! I will also be adding arrows that point to the players when they are off camera. Remaining tasks are now

• Finish up arenas
• Sound effects and music
• Complete network game lobby UI (make pretty and complete all network game modes).
• Complete network game restart UI (make pretty).
• General bug fixing, tidy up and enhancement of look and feel..

Over the past month I have managed to update the Replay UI to work with the Arena update as well as added two entirely new arenas! The Replay UI now correctly displays mice and can record, render and playback all props involved in an arena. The first new Arena to be added after Sparta is the Colosseum! The new Colosseum starts both players in the arena of the Colosseum where skulls, gladiator helmets and weapons (careful theyre sharp!) litter the battlefield. These can be kicked around to your advantage. https://youtu.be/AxcBxXqBINM However, if given the chance you can escape the gladiatorial combat and fight in the stands. The functionality of the arena is all in place. Only the artwork needs to be further developed.
The second Arena is called the Henge! The Henge is built mostly out of stones. These stones can be pushed around by the player and are very heavy so be careful not to get pinned. https://youtu.be/CTl3jbehFQc
The next arena currently in development is the tavern which will involve plenty of fighting on tables and behind the bar. If anyone else has any suggestions for arenas that would be fun / interesting to fight in please comment below! Remaining tasks are now

• Finish up arenas
• Sound effects and music
• Complete network game lobby UI (make pretty and complete all network game modes).
• Complete network game restart UI (make pretty).
• General bug fixing, tidy up and enhancement of look and feel..

Over the past week I have fixed a variety of bugs relating to the mapping feature with now only a few remaining!
Initially there was a problem whereby props in the Arena would begin to jitter more and more violently as time went on until they began to teleport in and out bounds of the game. I found that this was caused because of the inbuilt Unity physics fighting against the server which was trying to update each props location. This was fixed by ensuring prop objects are stripped of certain physics components. The second bug to be fixed was whenever a network game was restarted the previous arena and players would fail to be destroyed. This meant that while you were choosing your weapons and skins the players from the previous game were able to climb in and around the new players. When you started the new game all arenas would be destroyed and the new and old players would fall into the void below.
(This is a recreation of what it looked like when restarting a network game) This was a result of the game trying to destroy the actual reference to the prefab itself instead of the instance of the prefab.
The third bug was simply that when joining a game if the previous player had already chosen an arena, your game would not know what arena had been chosen. This was fixed by adding the current chosen arena into the join game command. The fourth bug was an issue whereby on the client side, network mouse cursors were limited to a small square in the centre of the screen. If they tried to surpass this square they would teleport to the opposite of the square. This was caused because the mouse coordinates were parsed as a short which is a 16 bit integer value. This meant the maximum a mouse coordinate could travel was 32,767 and when this was surpassed it would overflow to -32,768. By changing this to a 32 bit value the maximum a mouse coordinate can travel is 2,147,483,647. Which should surely be enough Now with the major bugs fixed... It is time to design and make Arenas! Remaining tasks are now

• Finish up arenas
• Sound effects and music
• Complete network game lobby UI (make pretty and complete all network game modes).
• Complete network game restart UI (make pretty).
• General bug fixing, tidy up and enhancement of look and feel..

My final term of University has now ended! I was able to get some work done last break but I wasnt able to get the Mapping feature complete in time.
This was because the server protocol was not designed for dozens of prop transforms to be relayed by the server. This, and the changing of the coordinates system from screen space to world space required lots of unforeseeable changes to be made. This and the combination of final University exams made it very difficult to work on Rivalry. However, I can now say that the arena feature for the most part is functional with only a few minor bugs needing to be fixed. After these bugs are fixed, all that needs to be added is art for the arenas themselves! Remaining tasks are now

• Finish up arenas
• Sound effects and music
• Complete network game lobby UI (make pretty and complete all network game modes).
• Complete network game restart UI (make pretty).
• General bug fixing, tidy up and enhancement of look and feel..

My term of University has now ended which means I can get back into development! Im planning on assigning a couple hours every day to working on the game and hope to get the mapping/arena feature fully implemented by the end of next week. More news updates coming shortly!
Remaining tasks are now

• Finish up arenas
• Sound effects and music
• Complete network game lobby UI (make pretty and complete all network game modes).
• Complete network game restart UI (make pretty).
• General bug fixing, tidy up and enhancement of look and feel..

Arenas The basics of arena/map functionality are now finished. It is possible to not only play different maps locally but also over network games.
The first step I completed when working on the arena feature was to get a movable camera that would allow the user to control what could be viewed. This is now fully functioning and works with all intended arenas. The first arenas that I have added include: The Box The Original Arena
The Inner Circle Simple Arena inside a Circle
Bamboo Forest This was the first arena to include physics objects which are the Bamboo Stalks. The player walks on top of these stalks and the stalks will bend under their weight.
Sparta This arena consists of a large pit that separates the two players. At the bottom of the spit there are spikes that deal damage to both players. There are also two Grecian vase props that can be kicked into the enemy to deal damage
https://www.youtube.com/watch?v=O7Oo5GASbFE I also added a parallax background that currently consists of a couple of pillars and a large looming omniscient scimitar in the background. Once I have proper graphics I hope to implement more aesthetic and complicated backgrounds into each Arena. https://www.youtube.com/watch?v=dixfsfGoP4Q https://www.youtube.com/watch?v=5SrP99wpdiQ While arenas and the user-interface used to select arenas have been implemented in both local games and network games. The only boundary preventing the feature from being released is an issue sending prop transform telemetry over network games. Once this problem has been solved and better background graphics added the feature should be ready to go! Blood I have also added YouTube / Family friendly blood colours to the game which can be changed in settings UI. A large array of colours can be chosen from including my personal favourite"clown".

(An example of Clown Blood) New Weapon Lastly a new weapon has been added The Sai! A blunt, defensive weapon which is light, manoeuvrable and easy to catch other weapons blades. However like the real weapon it has no sharp points and only does blunt damage like the sledgehammer.

Also... the background is white now... Tell me if this is something you want changed or you would rather another colour? Remaining tasks are now

• Finish up arenas
• Sound effects and music
• Complete network game lobby UI (make pretty and complete all network game modes).
• Complete network game restart UI (make pretty).
• General bug fixing, tidy up and enhancement of look and feel..

After finishing my first term at University I can safely say that I am back at work developing Rivalry and have even begun work on a new feature, Maps!
The map feature will enable players to play the game over much larger and more varied arenas. The first step in implementing this feature was to allow the player to control the position of the camera.
This has now been implemented and I am beginning to plan and develop how maps could be selected in the choose weapons UI. After this, the task of actually designing and creating maps will become my next priority.
(Player who now falls through the endless void after escaping its arena) Remaining tasks are now

• Research different arenas and backgrounds.
• Sound effects and music
• Complete network game lobby UI (make pretty and complete all network game modes).
• Complete network game restart UI (make pretty).
• General bug fixing, tidy up and enhancement of look and feel..

Over the past weeks I have been working on both the Scimitar and Buckler. Now they are in the game! The Scimitar in terms of both damage weight is somewhere between the Katana and Longsword. However, what differentiates it when compared to other weapons is both its curved shape and its angular maneuverability. Its curved blade allows it to sneakily bend into areas that a straight blade couldnt, making it perfect for getting around shields. And its angular maneuverability makes it a great slashing weapon with the blade being blunter at the base and sharper at the tip.
The Buckler is a new shield added into the game! For what it loses in size it makes up in maneuverability meaning it can very easily move to defend unprotected areas. While it does very little damage compared to most other weapons it can still be dangerous when rammed into the enemies head or body. I have also updated the skin status badges to be a little MSpaint and more easily recognisable.
I was originally going to make the game music procedurally generated based on how intense the battle was but this game needs to be released at some point.
Remaining tasks are now

• Continue to polish skin feature
• Complete network game lobby UI (make pretty and complete all network game modes).
• Complete network game restart UI (make pretty).
• Research different arenas and backgrounds.
• Sound effects and music
• General bug fixing, tidy up and enhancement of look and feel..

As the number of online players and games has rapidly increased in recent weeks the Rivalry server has been having more technical issues such as crashes and service failures. Because of this I have increased the power and memory of the current Rivalry server! This should hopefully both stabilize it and allow more people to play. Remaining tasks are now

• Continue to polish skin feature
• Complete network game lobby UI (make pretty and complete all network game modes).
• Complete network game restart UI (make pretty).
• Research different arenas and backgrounds.
• Sound effects and music
• General bug fixing, tidy up and enhancement of look and feel..

I have added a new weapon to Rivalry! The Scimitar is a long curved sword that is somewhere between a Katana or a Longsword in both length, damage and mass. What differentiates it from other Rivalry weapons is its curved shape which allows for some interesting new tactics. Only one edge of the Scimitars blade is sharp and does more damage the higher its velocity.
While the scimitar isnt currently released to the public I am aiming to release this weapon as well as a few others (Including fixing the spear which is currently too powerful) in an update within the next few weeks. I am also aiming to fix a few more bugs that have been identified within the skin feature. These include skin lists failing to update and altering the skin list logic. Remaining tasks are now

• Continue to polish skin feature
• Complete network game lobby UI (make pretty and complete all network game modes).
• Complete network game restart UI (make pretty).
• Research different arenas and backgrounds.
• Sound effects and music
• General bug fixing, tidy up and enhancement of look and feel..

Development of Rivalry has restarted! My aim is to continue both working on and refining the skin feature in the coming weeks. My latest change now enables the user to rename their personal skins through the UI instead of manually through the YAML file. I am also planning on adding new weapons to the game soon and any more weapon suggestions would be greatly Appreciated.
I would also like to thank all those who have taken the time to create and share skins online for myself and others to see and use! Remaining tasks are now

• Continue to polish skin feature
• Complete network game lobby UI (make pretty and complete all network game modes).
• Complete network game restart UI (make pretty).
• Research different arenas and backgrounds.
• Sound effects and music
• General bug fixing, tidy up and enhancement of look and feel..

I have posted this to make aware that I'll be restarting development on Rivalry soon(ish)! I haven't been able to develop Rivalry recently because of both high school final year studies and a robot platypus. However, now that my finals exams will be over within the next month I can start once again developing the game. I expect to restart development at some point during mid December after a long awaited holiday!

The Skin Feature is live on the default and Beta version of the game! It's still missing some minor components like ingame renaming but all its major features are complete. I will be fixing bugs and features when people find them. Some major bugs may also be present but I can only fix them if you can find them! The process of creating skins is still a little weird as you have to edit each individual limb using a graphic editor. And changing the name of the skin can only be achieved through editing the YAML file located inside the skin folder. Just remember to not change the name of each limb file and any other important information in the YAML file and the skin should work! Also, I will be checking submitted online skins periodically throughout the week for approval. Have fun creating and sharing skins and remember to create a discussion if you find any bugs! Pending tasks are now

• Continue to polish skin feature
• Complete network game lobby UI (make pretty and complete all network game modes).
• Complete network game restart UI (make pretty).
• Research different arenas and backgrounds.
• General bug fixing, tidy up and enhancement of look and feel..

Over the last weeks I have polished the template limb sprites and fixed an issue relating to network skins loading into local games after a network game has been setup An issue was discovered that related to how skins in network games including sideloaded skins would attempt to display themselves in local games. This would result in a disagreement between the game and the display as even though it the skin was selected, the skin would fail to display. This has been fixed so only skins that are locally owned or downloaded will automatically appear in local games after being used in network games. I have also polished two limbs from the template skin as one had not been cropped appropriately and another had a black outline surrounding it. These issues have each been respectively cropped and and removed. Next week I am hoping to release a Beta which includes the skinning feature! This will enable anyone who downloads the beta to create, download and share skins. I may also add the rebalanced Spear back into the game and see what people think of it. Pending tasks are now

• Polish and debug skin feature
• Steam workshop for player skins.
• Complete network game lobby UI (make pretty and complete all network game modes).
• Complete network game restart UI (make pretty).
• Research different arenas and backgrounds.
• General bug fixing, tidy up and enhancement of look and feel..

Over the last few weeks I have been continuing to polish the skinning feature as well as look a little at possible new weapons with a focus on implementing the spear. It has also been harder recently to work on the game with my final year assessments occurring. The most prominent issue that was fixed was an issue relating to how weapon and skin selections were remembered and displayed across different game modes such as normal and Quickplay. This caused an issue whereby getting weapons randomly selected in Quickplay and then changing to normal mode wouldnt display any weapons. visually this is what you would expect, but if start was then pressed the old combination from Quickplay would be used even if visually nothing was selected. This took longer than expected to fix as it required a lot of restructuring of very old code. The players weapons have also been centered around the wrist of the player on instantiation. This improves the visual smoothness of the players creation as the quick re-positioning of weapons in the first few frames of the match no longer occurs. The spear was added into the game a little under a year ago but was quickly removed as many including I, felt it was too powerful. Ever since then I focused on the implementation of different features such as networking and skinning. I have now re-evaluated it and am now considering different methods of nerfing it without losing its appeal as a long stabby weapon. Previously it was about as sharp as the rapier with a longer range but also suffered from a high mass and lack of maneuverability. I have decided I will decrease its sharpness to a level that is still fun but also less powerful. However, I still need time to balance the exact amount of sharpness it should have. Pending tasks are now

• Polish and debug skin feature
• Steam workshop for player skins.
• Complete network game lobby UI (make pretty and complete all network game modes).
• Complete network game restart UI (make pretty).
• Research different arenas and backgrounds.
• General bug fixing, tidy up and enhancement of look and feel..

Over the last week I managed to finish much of the skinning feature to a point where it is almost ready to be released! I must now only find and fix a few bugs as well as polish already completed features Skins can now be created, uploaded, approved, downloaded, remixed and used in both local and network games! I have also recently changed how choosing skins and weapons work to make it simpler and more intuitive to use. Now, clicking the hands of your player changes the hands weapon and clicking the players body changes the players skin without the need to change any modes.
(New weapon and skin selection with the weapon combo name being listed above the skin name) I have also worked on developing a method that allows for your last skin and weapon choices to automatically appear when playing another local or network game However, I am yet to complete the network side of this feature and must consider how such a system should work with multiple people controlling one player. As more bugs are fixed and features polished the skinning update should end up being released soon hopefully! Pending tasks are now

• Polish and debug skin feature
• Steam workshop for player skins.
• Complete network game lobby UI (make pretty and complete all network game modes).
• Complete network game restart UI (make pretty).
• Research different arenas and backgrounds.
• General bug fixing, tidy up and enhancement of look and feel..

With my assessment period over followed shortly by Christmas time and other heavy duty family duties, I will probably be able to start work on Rivalry again either early or mid January. Happy Holiday!

This week I managed to finish the functionality of sideloading and play the first network game with skins. As well as this, I also managed to fix many gameplay and Character Setup UI issues that have arisen from the implementation of skinning. https://youtu.be/ItBrsERwuPs (First network game featuring skins, This is also the first time I realised that the chat feature is visible during rendering..) Now both uploaded and privately owned skins can be display in network games through sideloading. There are however still some aspects of the system that need to be fixed, For example: if someone joins a game after skins have already been decided, such skin information wont be sent to them and theyll therefore have only the default skin displayed. Many bugs have also been fixed such as player weapons randomly becoming black, highlighting bugs crashing games, and the ability for the display players within the Character Setup UI to reanimate and fly away. Sadly I will have to take a few weeks break off of Rivalry development seeing school exams are coming up again once more (but this time they count). So I hope to continue work either during late December or Early January. Pending tasks are now

• Implement skinning server functionality
• Creating inventory system and skin database.
• Steam workshop for player skins.
• Complete network game lobby UI (make pretty and complete all network game modes).
• Complete network game restart UI (make pretty).
• Research different arenas and backgrounds.
• General bug fixing, tidy up and enhancement of look and feel..

After fixing some issues relating to the skin lists I began work on sideloading, the feature that allows both published and private skins to be displayed in online games. I first fixed an issue whereby Authors names were not being displayed on downloaded skins and then another wherein the player setup skin selection button would skip certain skins when the user clicked through previous skins. With these issues fixed and others identified I decided it was time to start on sideloading.
(Sideloading Interaction Diagram) Currently the user can now select a skin in the online player setup UI which then queries the server on whether it has seen the selected skin. The server then alerts all players within the game and sends information about whether the skin is publically available to download or must be sideloaded through the server. It will then attempt to upload the privately owned skin to the server and then to each player. However, I have yet to get a player to fully sideload a skin to another player as a few issues have arisen surrounding network play that must first be fixed before more progress can be made. Next week my goal is to fix these issues as well as any remaining issues within the skin lists and then hopefully get more work done on sideloading. Pending tasks are now

• Implement skinning server functionality
• Creating inventory system and skin database.
• Steam workshop for player skins.
• Complete network game lobby UI (make pretty and complete all network game modes).
• Complete network game restart UI (make pretty).
• Research different arenas and backgrounds.
• General bug fixing, tidy up and enhancement of look and feel..

With the skinning buttons functionally complete I decided to focus on allowing published skins as well as private sideloaded skins to be displayed online. However, in order to ensure that these features could work efficiently I realised that it would be necessary to allow viewed online skins to be cached locally and then used for later. Because of this, the speed at which viewing skins has increased as you no longer have to reload a skin off the server every time you see it again. I have also generally decreased the time it takes to view online skins by displaying the thumbnail of the skin while the actual skin downloads in the background. Before, each skins high definition thumbnail would downloaded as you scrolled through skins, but when you selected one it could take up to 10 seconds until it all downloaded. So now, by displaying this high definition thumbnail in the display panel while the actual skin downloads, Players can get a much faster response time when browsing skins online. Next week I am planning to fix some issues I have found with the skin lists themselves as there are some problems surrounding how skins are added as your scroll down. Then, hopefully after that has been fixed I am planning to begin work on actually allowing public and private skins to be played with online. Pending tasks are now

• Implement skinning server functionality
• Creating inventory system and skin database.
• Steam workshop for player skins.
• Complete network game lobby UI (make pretty and complete all network game modes).
• Complete network game restart UI (make pretty).
• Research different arenas and backgrounds.
• General bug fixing, tidy up and enhancement of look and feel..

Over the last week I have managed to make the skinning management UI complete with all buttons functional and tested. I have also now fixed reporting so people can't report the same skin over and over again and the server will now keep track of which skins each user has reported as well as a list of every person who has reported each skin. However, I may also have to address a problem surrounding notifications for the Skinning management UI as the code has become increasingly unwieldy. This was caused primarily because of the current notification system. Last week I thought that if users actions were made to send notifications instead of only skin status changes then a clean and efficient solution could be produced. However, it would seem that the entire system would be more simpler if it was rebuilt to just keep track of which skin versions are in which skin index, instead of also using statuses. Next week I will begin work on this fix as well as allowing for public skins to be viewed online. I will also work on sideloading which will allow for local skins to be seen online even if they arent publically available. This features content safety setting 'Anything Goes' can be adjusted within the new settings UI. Pending tasks are now

• Skin "Sideloading"
• Skinning UI optimisation and polish
• Complete network game lobby UI (make pretty and complete all network game modes).
• Complete network game restart UI (make pretty).
• Research different arenas and backgrounds.
• General bug fixing, tidy up and enhancement of look and feel..

This week more work was done on adding button functionality to the remaining buttons with every skin button now having its own button functionality implemented. Now the Unpublish, Report and Ban buttons have been given their corresponding functionality as well as the previously unconsidered buttons that arose from their completion such as Clear button (Which removes the reported skin from the reported list), Unban button (Which removes the banned skin from the banned list), and the Purge button (Which removes the skin from the Server completely). However, there are still a few issues that have not yet been addressed. For example there is nothing stopping the user from reporting a skin multiple times. Currently, In order for a skin to be placed in the reported list it must be reported a certain number of times until it reaches a limit where it will be added to the list. So this current issue allows anyone to push any skin they don't want past this threshold and therefore add it to the reported list. Another issue that persists is that the current notification system that is based entirely off skin statuses is lacking the required information to ensure that every client is aware of the current state of every skin. With the addition of the new Unpublish and Report button functionality it became apparent that if a skin was to be reported, as its state could not be changed (This is because a skin can be both online and reported at the same time) a notification would not be sent and no other clients would be aware of the skin being reported. I am planning to fix this all next week with by including the action along with the status change to add that extra bit of information so that clients can stay updated. Pending tasks are now

• Implement skinning server functionality
• Creating inventory system and skin database.
• Steam workshop for player skins.
• Complete network game lobby UI (make pretty and complete all network game modes).
• Complete network game restart UI (make pretty).
• Research different arenas and backgrounds.
• General bug fixing, tidy up and enhancement of look and feel..

This week, more work was done on the skin feature with the development of skin notifications which now allow clients to be alerted to changes in skin statuses. Previously, in order to see if skins had either been added or removed from the online skins list Rivalry had to be restarted. Also for new skin statuses to be updated the skin UI had to be exited and then re-entered. Now, when a skins status is changed it will alert the server which reacts by sending a notification to all players logged in. From these status change notifications it can then be assumed what has happened to the skin. For example, if a client received a notification that a skins status had been changed to public it could then be assumed that it has completed its publication process and now must be removed from the pending list and added to the public list. However, more work still has to be done on button functionality with the Ban, Report and Unpublish buttons all still lacking any function. As well as this more testing must be done using larger quantities of skins. This is test whether or not the developed notification and listing systems are built to handle hundreds of skins. Pending tasks are now

• Implement skinning server functionality
• Creating inventory system and skin database.
• Steam workshop for player skins.
• Complete network game lobby UI (make pretty and complete all network game modes).
• Complete network game restart UI (make pretty).
• Research different arenas and backgrounds.
• General bug fixing, tidy up and enhancement of look and feel..

This week was focused on the development of how button display states are controlled as well as their functionality. Now, published skins that can be viewed from the public list can be downloaded and used both locally and online. This development now renders the skinning feature functional end to end. These downloaded skins can now also be copied and edited to create new remixed skins. Other important buttons that have been implemented now include the withdraw button that allows for users to remove their skins from the publishing process, as well as the reload button which had had certain aspects fixed. Next week more button functionality will be added such as the unpublishing, reporting and banning buttons. More server notifications will be added as well that allow for skins to be added and updated continuously without having to restart the game for new skinning updates. Pending tasks are now

• Implement skinning server functionality
• Creating inventory system and skin database.
• Steam workshop for player skins.
• Complete network game lobby UI (make pretty and complete all network game modes).
• Complete network game restart UI (make pretty).
• Research different arenas and backgrounds.
• General bug fixing, tidy up and enhancement of look and feel..

This week more work was achieved on both versioning of skins we well as adding functionality to the buttons that control them. in order to know the current status of a skin it became necessary to have an icon attached to the skins entry that displays whether the skin is local, published, accepted, rejected or banned. However, as skins can have multiple of these statuses at once a system that could determine whether locally owned or downloaded skins were also available online or awaiting publication had to be created.
The reject button has also been implemented enabling skins that are in need of verification to either be accepted into the online list or rejected. However there are still some holes in how such buttons affect skin statuses, which will be the primary focus over the next week. It is finally starting to showing consistancy and can almost push a skin through its complete lifecycle Pending tasks are now

• Implement skinning server functionality
• Creating inventory system and skin database.
• Steam workshop for player skins.
• Complete network game lobby UI (make pretty and complete all network game modes).
• Complete network game restart UI (make pretty).
• Research different arenas and backgrounds.
• General bug fixing, tidy up and enhancement of look and feel..

This week I have worked on creating a system whereby different versions of skins that have been uploaded to lists such as the pending and public lists can now replace their older versions. Previously if a different version of a skin was uploaded to a list with another version already present. The two versions of the skins would both be displayed as different skins that could each be used. Now however, I am tracking what versions of each skin are located in each skin list, So if a new skin is uploaded to a list that already contains a version of that skin it will replace the old one. It also serves as a quick skin version lookup table as every version of a skin in each skin list can be identified in once place. My next step is to work more on the life cycle aspects of the skinning feature by giving the unpublish, reject, ban and download buttons proper functionality. Pending tasks are now

• Implement skinning server functionality
• Creating inventory system and skin database.
• Steam workshop for player skins.
• Complete network game lobby UI (make pretty and complete all network game modes).
• Complete network game restart UI (make pretty).
• Research different arenas and backgrounds.
• General bug fixing, tidy up and enhancement of look and feel..

Now that all my school assessments are over I have been given the chance to continue work on the skinning feature with advancements being made on both the publishing side of the network protocol as well as how information is loaded from the server and to clients
(Pending skins that are ready for approval. Note that the weird skins are merely for development purposes) Locally owned skins can now be “published” to the pending skins list where all their information and sprites can be loaded from the server and viewed by an administrator. The administrator can now also approve the skin which places it in the public skins list where anyone can then view them.
(Public skins that are ready to be downloaded) While all skin information such as the name, author and date created are sent to the client from the server, Instead of streaming the skins and their thumbnails directly from the server, a web link to the sprites on Amazon’s 'S3' service is created that can then load and stream the sprites much faster than what could be done through my own server. Future things that need to be added are the remaining pending and public button functionality such as rejecting, banning, downloading and reporting skins. But first of all, I must look into fixing an issue whereby different versions of the same skin are displayed as completely different skins. This means adding a system whereby different versions of skins can be overwritten and saved across different lists such as the pending and public lists. Pending tasks are now

• Implement skinning server functionality
• Creating inventory system and skin database.
• Steam workshop for player skins.
• Complete network game lobby UI (make pretty and complete all network game modes).
• Complete network game restart UI (make pretty).
• Research different arenas and backgrounds.
• General bug fixing, tidy up and enhancement of look and feel..

I have made no progress for the last few weeks because it was assignment season and now it is exam season for the next two weeks. I should be able to get back on to it late September. Pending tasks are now

• Handing in assignments
• Passing exams
• Implement skinning server functionality
• Creating inventory system and skin database.
• Steam workshop for player skins.
• Complete network game lobby UI (make pretty and complete all network game modes).
• Complete network game restart UI (make pretty).
• Research different arenas and backgrounds.
• General bug fixing, tidy up and enhancement of look and feel..

Over the past two weeks I have been working on allowing for skins to be uploaded to the server and sorted in a database. I have managed to create a skin uploading and storage system whereby the skin information is streamed up to the server and processed to ensure authenticity and then stored on an Amazon storage web service. Metadata such as the skin ID, skin name, author ID and other important information is stored on a Redis database, which can be quickly listed for when people scroll through online skins. http://thumbnails.rivalry.my64k.com/34a7c599-284d-44dd-a6e8-caecada97cf7/31572ac13914876fb165969d15a3adb25c2e0dde4374a2dd12b66bc5a238bbd1.png (link to stored skin thumbnail) Next week I am hoping to work on this online skin browsing and then the approval process for new skins. Pending tasks are now

• Implement skinning server functionality
• Creating inventory system and skin database.
• Steam workshop for player skins.
• Complete network game lobby UI (make pretty and complete all network game modes).
• Complete network game restart UI (make pretty).
• Research different arenas and backgrounds.
• General bug fixing, tidy up and enhancement of look and feel..

This week I worked primary on expanding the functionality for all the skinning features on the client side. I also began work on some of the server functionality but much of the interaction is still mocked on the client side untill I do more work on this.
(Note: Orange background is for development purposes) The client side now functions as if it were actually communicating with the server. So now it is possible to “publish” your custom skin, get it either approved, rejected or banned.
(Kim being approved for publication and public useage) If it's approved it will appear in the list of 'published' skins where it can then be downloaded. If the skin is banned the game will no longer display that skin in any of the skin selection lists.
(Kim being displayed as a public skin ready for download) However, for now, this interaction only happens on the client side as I now need to create the web services to support this on the server. I did get to make a good start on this today by adding the first real skin server command that sends all the skin IDs of the players downloaded skins to the server. This will be used to work out if any of the players downloaded skins require updates and what skins are available for download. Pending tasks are now

• Implement skinning server functionality
• Creating inventory system and skin database.
• Steam workshop for player skins.
• Complete network game lobby UI (make pretty and complete all network game modes).
• Complete network game restart UI (make pretty).
• Research different arenas and backgrounds.
• General bug fixing, tidy up and enhancement of look and feel..

This week I worked on the publishing side of things whereby the user can upload their own created skins to the server and have them be downloaded by others online. More specifically I started work on the uploading and downloading aspects so now it is possible to write all the skin objects and files into a stream that can then be read by the client and downloaded as a “.riv” skin file that will be displayed in the skinning UI. Next I will have to implement the actual server functionality like the verification process and the way skins are stored, aswell as the creation of a “downloads” tab that allows users to list, view and remove downloaded skins. Pending tasks are now

• Implement skinning UI and functionality
• Creating inventory system and skin database.
• Steam workshop for player skins.
• Complete network game lobby UI (make pretty and complete all network game modes).
• Complete network game restart UI (make pretty).
• Research different arenas and backgrounds.
• General bug fixing, tidy up and enhancement of look and feel..

This week I managed to create the right hand side of the Skinning UI which includes the skin model which displays the currently selected skin, as well as all the buttons that relate to the skin model. Also, the thumbnail for the listed skin entries are no longer just displayed as the skin head but now display an automatically generated thumnail of the entire skin.
The current skin model buttons include an “Open Folder” button which open the skins directory so it can be edited. A “Reload” button which reloads the skin so that skin creators can preview how their edits will look. A “Publish” button which will eventually begin the process of publication. An “Unpublish” button which will unpublish the skin and a “Republish” button which will update the skin if it has been edited. Next week I will be developing the publishing side of things some more and maybe even get started on the uploading of skins to the server. Pending tasks are now:

• Implement skinning UI and functionality
• Creating inventory system and skin database.
• Steam workshop for player skins.
• Complete network game lobby UI (make pretty and complete all network game modes).
• Complete network game restart UI (make pretty).
• Research different arenas and backgrounds.
• General bug fixing, tidy up and enhancement of look and feel..

This week I worked more on the Skinning feature and managed to get the create, copy and delete buttons working.
So you can now create brand new skins that come with limb templates that can be used, as well as copy and delete pre-existing skins. However the display player has yet to be created along with its button functionality which includes the ability to rename, reload, open and publish skins. Of these features reloading and opening should be easy to add as they have already had their functionality implemented but do not yet have their corresponding buttons. This will be the next thing that I will be working on with the ability to publish and store skins online being the next after that. Pending tasks are now

• Implement skinning UI and functionality
• Creating inventory system and skin database.
• Steam workshop for player skins.
• Complete network game lobby UI (make pretty and complete all network game modes).
• Complete network game restart UI (make pretty).
• Research different arenas and backgrounds.
• General bug fixing, tidy up and enhancement of look and feel..

This week I was able to work further on both the Skinning and Settings UI. The Settings UI has currently one option which allows the user to choose what type of skin content can be seen. There is the option of “None” which will only display skins you locally created. The option of “Safe" which will only display skins that are deemed safe for all ages and then “Anything Goes” which will display all types of skins including local skins from other people online.
(Basic Design of Settings UI with the content setting set to Anything Goes) I also managed to get some work done on the actual Skinning UI which currently includes a list of locally owned skins displaying their name, author, date of creation and head sprite. There is also a mode filter which will soon be used to either display locally owned or online skins.
(Current Design of Skinning UI) I have yet to add the functionality of this feature or add the buttons and filters that will be used to create, copy, delete, and download skins. I must also add the actual player that the skin will be displayed on or its corresponding buttons and functionality.
(Basic Design of Skinning UI) Once this has been complete I begin work on getting skins to be published to a server for download or have them streamed straight to another players client. Pending tasks are now

• Implement skinning UI and functionality
• Creating inventory system and skin database.
• Steam workshop for player skins.
• Complete network game lobby UI (make pretty and complete all network game modes).
• Complete network game restart UI (make pretty).
• Research different arenas and backgrounds.
• General bug fixing, tidy up and enhancement of look and feel..

I was unable to work on Rivalry because of an assessment week, but now that it is over I spent some time designing the UI that will enable people to both create, publish and download skins to be seen and used both locally and online. Although I haven’t yet created the actual UI within the Unity engine but have created some concept designs
(The options given for when viewing locally owned skins) As user generated content always comes with the possibility of people creating and publishing inappropriate skins I have decided to also create a option where you can control the quality of what kind of content you receive. Of which there will be the option to:

• View no skins at all.
• View and use skins that have been rated as 'safe' (the default).
• View and use all types of skins with very limited censorship including peoples locally created skins.

• Implement skinning UI and functionality
• Creating inventory system and skin database.
• Steam workshop for player skins.
• Complete network game lobby UI (make pretty and complete all network game modes).
• Complete network game restart UI (make pretty).
• Research different arenas and backgrounds.
• General bug fixing, tidy up and enhancement of look and feel..

Over the past week I have been able to work a lot on skinning getting most of the non-workshop implementation finished. Both local and network play both feature the same skinning functionality and skins can be seen in both the replay and in network games. However in network games only skins that both computers have downloaded will be displayed. I have also added some basic tools and templates to help people add their own skins to Rivalry locally on their client. To test it myself I had a go and made two timely skins :)
(Thank you Strong Fish for the idea and Trump image!) https://youtu.be/B9k2nDInRK8 The next step is investigating more into Steam Workshop as well as designing an inventory system and skin database to enable people create and upload custom skins as well as using skins other people have uploaded. Pending tasks are now

• Creating inventory system and skin database.
• Steam workshop for player skins.
• Complete network game lobby UI (make pretty and complete all network game modes).
• Complete network game restart UI (make pretty).
• Research different arenas and backgrounds.
• General bug fixing, tidy up and enhancement of look and feel..

This week wasn’t as productive as I had hoped as a lot of software had to be updated and my PC cleaned as it had been getting too slow to work with. However I did at least get some work done on refactoring both of the player setup UIs. I also redesigned some parts of the UI to make skin selection easier.
(New mode selection button is now above the weapon combination) Previously if you wanted to change the skin of the fist, it would instead change that hands weapon. This made it almost impossible to control either the weapon or skin of the player. So I have now decided to create a button that can be toggled between either a weapon selection mode and a skin selection mode. Pending tasks are now

• Implement Skinning into Network Play
• Steam workshop for player skins.
• Complete network game lobby UI (make pretty and complete all network game modes).
• Complete network game restart UI (make pretty).
• Research different arenas and backgrounds.
• General bug fixing, tidy up and enhancement of look and feel..

Sorry for not posting an update in over a month, I was stuck working on assessments for much of my free time, But now that they are over I can concentrate again on Rivalry! I have decided to move on from the chat feature to the skinning feature as I feel it is functional enough in its current state and any further work would just be polishing and more detail. So far I have managed to create a system whereby a player can choose a skin for each limb of their player which would be displayed in game. However this was only developed for local multiplayer games and not network multiplayer games. In order to continue developing the skin feature, I worked on refactoring both the local and network “player setup” UIs as both these UIs need to have a shared structure that the skinning feature needs to interact with. Once this structure has been created, I can work on actually implementing features of skinning like the ability to edit and display skins online as well as share them on the Steam Workshop. Pending tasks are now

• Implement skinning into network play
• Steam workshop for player skins.
• Complete network game lobby UI (make pretty and complete all network game modes).
• Complete network game restart UI (make pretty).
• Research different arenas and backgrounds.
• General bug fixing, tidy up and enhancement of look and feel..

A basic version of the chat feature has been released into the default version of the game allowing players to communicate with each other through physics based words which can be typed into and edited.
(example of text system) Currently each character typed is displayed on a created physics based word which can then be deleted or edited like a normal text editor. This creates a functional chat system which still fits with the games very physics oriented style. I will also continue to experiment with the physics properties of these words as well as possibly even making the characters themselves physics objects like what was shown in the last updates video.

(example of text system in game with other player) There are still some other things that could be improved upon such as the fact when the player begins to type off of the screen, instead of the words being created from the bottom of the previous word they appear from the cursor which can lead to clouds of indecipherable words. However this effect can also create quite interesting snakes of text which are fun to create and edit.
(example of text cloud) I encourage all to test out this new feature and try to find any issues present. Also now the leaderboard has been changed so any entries from before the updated leaderboard which tracks each users complete metrics instead of just kills will no longer be displayed as their metrics had incomplete information. Pending tasks are now

• Chat System (Experiment with physics properties and physics based characters).
• Steam workshop for player skins.
• Complete network game lobby UI (make pretty and complete all network game modes).
• Complete network game restart UI (make pretty).
• Research different arenas and backgrounds.
• General bug fixing, tidy up and enhancement of look and feel..

Over the past two weeks I have been working on the new Chat system for Rivalry which will allow players to communicate with each other both in the lobby and during fights. I have decided to add a physics based chat system into Rivalry that keeps in theme with the games very physics based feel. Each character you type will be created from your cursor and proceed to float around in the air. As you type more characters these physics based characters will string together to form words with each new word becoming a new line. I have a very simple version of this working in the video below. Note that I am still tweaking the physics values of the letters and the colourful blue, yellow and red backgrounds are only present for debugging purposes https://youtu.be/sKHTeUrMQdc I am still not sure if this system will work and be satisfying to use or merely become too convoluted and end up create sentences that become too hard to read, but I may as well try :). Currently the blue boxes are the characters that are being typed into the yellow boxes which are words. If you either press “enter” or “space” a new line and therefore word will be created. The red caret or “cursor” will be the visual indicator that will display where the user will be typing. Last week I worked on the network protocol and character commands that will send the typed characters to other players either in the lobby or in the game. As this chat system is based on stringing characters together it would make sense for the network commands be based on sending single unicode characters. These character commands will then be sent to all available players where they will be displayed locally. I am reusing the same structure that the mouse cursors use in terms of the visibility of the chat and who is allowed to see it. For example mouse cursors in games shouldn’t be seen in the lobby, likewise, conversations happening in games, shouldn’t be shared in the lobby. This Chat system will also feature normal operations such as backspace, delete, enter, home, end and left and right arrow keys which will allow the player to maneuver around their text to edit. Currently I am working on finishing the structure of the chat physics and working out how it can be easily edited through sending operations like backspace and the arrow keys. Then I will begin to wire up the network protocol to the display system. Pending tasks are now

• Chat System (Create chat physics structure).
• Steam workshop for player skins.
• Complete network game lobby UI (make pretty and complete all network game modes).
• Complete network game restart UI (make pretty).
• Research different arenas and backgrounds.
• General bug fixing, tidy up and enhancement of look and feel..

The Leaderboard feature is now released and available in game! This is the biggest change to the server since the launch of the game so please bear with me if there are any issues over the next few weeks. Over the past week I managed to fix some issues with how the leaderboard both requests and displays entries from the server. When the client requests entries from the database, It will now send them in larger chunks meaning the amount of data send with more message is higher increasing the efficiency of the server. When this data is sent to the client, the client will only display the data it knows exists. Meaning the effect when the player scrolls down past the end of the leaderboard and huge amounts of empty entries were being created and then destroyed now doesn’t happen. However I do wish I had more time to polish some small features and the overall visual style of the leaderboard, but in its current state it is most definitely functional and I invite all to give it a try and maybe find some bugs that need fixing. For the entries in the current leaderboard, I am still not sure If I will completely reset the leaderboard over the next few days, I am still deciding while I test. While they would still function with the current system it would technically give a huge boost to anyone who already has a leaderboard entry as their wins could be 80 while their losses 0, making their kill to death ratio unrealistically high. Pending tasks are now

• Chat System (Keeping in theme with the game).
• Steam workshop for player skins.
• Complete network game lobby UI (make pretty and complete all network game modes).
• Complete network game restart UI (make pretty).
• Research different arenas and backgrounds.
• General bug fixing, tidy up and enhancement of look and feel..

This week I have managed to get Leaderboards to a now almost finished state. Since last week I have added multiple leaderboards, a new scoring algorithm and the ability to jump to you or a selected players score on the leaderboard. Previously there was only one leaderboard that would rank players on their total kills. Now there are three new leaderboards that rank players on the total times they lost, their win ratio and a scoring system will hopefully combine these values into an accurate representation of score. This score uses a combination of the players win ratio and total games played to hopefully create a value that represents both skill and experience. Last week I added the ability for the user to view their or a selected players statistics. Now when you change the leaderboard it will also update these statistics appropriately to what the leaderboard ranks them by. This means you can easily view a players statistics over all the leaderboards.
I have also added a button that will jump a user to either their or a selected players entry in the leaderboard. This will hopefully allow a user to easily find their entry in a large leaderboard or find a selected players entries in different leaderboards for easy comparison. To jump to a players rank on a leaderboard all the user has to do is click on the rank statistic box, and if they wish to select themselves again after looking at another players statistics then they can click on the box that displays the players name. This however still needs to fine tuning as its doesn’t quite work 100% of the time and has a few issues if the user is jumping to a player that isn’t currently loaded in the leaderboard. I also have done some work on the server that allows for me to record and playback strings of commands for testing purposes. For example I could record the commands used for going online and creating a game and then play that back through a command prompt to simulate the process on the server more accurately. This recording also includes time in between commands so when the “recording” is played back the server doesn’t receive all the commands at once. The leaderboard feature now only needs to be polished and tested, and once that is done I can hopefully start work on the Chat system. Pending tasks are now

• Finish Leaderboard (Polish and Test).
• Chat System (Keeping in theme with the game).
• Steam workshop for player skins.
• Complete network game lobby UI (make pretty and complete all network game modes).
• Complete network game restart UI (make pretty).
• Research different arenas and backgrounds.
• General bug fixing, tidy up and enhancement of look and feel..

Just another quick update, I’ve currently been working on a lot of school assessments as well as working on the Rivalry server code. So not a lot of visible changes over the last month Some visible changes I have however been working on is the possibility for multiple leaderboards and tracking other player metrics such as games played, win percentages, games won and favorite weapons. The leaderboard starts by showing your statistics but you can explore those of other players by clicking on their entry in the leaderboard.
The other major change is mostly invisible and that has been an almost complete rewrite of the server code, to make it more modular and scalable in the long term. A lot of the changes have been to allow multiple server to cooperate together, which should allow me to host a large population of simultaneous players in the future :) The changes will also make deploying and more importantly testing updates on the server much easier. I’ve also been testing and building a list of current bugs in Network Play and game rematch. Which I am currently logging to be fixed once I have finished the leaderboard feature. I am also still working on skinning, where players can apply skins to their players to customise their appearance. The next step there is to integrate it with the Steam Workshop. Skinning is a larger long term task so I’ll probably have chat integrated and released before skinning. Pending tasks are now

• Finish Leaderboard (I need to think of an algorithm that can't be exploited).
• Chat System (Keeping in theme with the game).
• Complete network game lobby UI (make pretty and complete all network game modes).
• Complete network game restart UI (make pretty).
• Steam workshop for player skins.
• Research different arenas and backgrounds.
• General bug fixing, tidy up and enhancement of look and feel..

Just a quick update this weekend, I have managed to both optimise how the server manages commands and stores data, which then allowed me to quickly add different leaderboard metrics such as total wins, losses and a player’s favorite weapon. I’m using the wins and losses to create a leaderboard of win percentages which will help track the most “effective” players. I have also made it so the leaderboard updates dynamically when change to the leaderboard occurs, which means you no longer have to restart the game every time you want to check the leaderboard. I’m hoping to get these changes released into the game in the next week or so. Pending tasks are now

• Finish Leaderboard (I need to think of an algorithm that can't be exploited).
• Chat System (Keeping in theme with the game).
• Complete network game lobby UI (make pretty and complete all network game modes).
• Complete network game restart UI (make pretty).
• Steam workshop for player skins.
• Research different arenas and backgrounds.
• General bug fixing, tidy up and enhancement of look and feel..

It has been good to see so many results in the leaderboard. Currently Uno looks unbeatable with his current lead :) Over the last week I’ve been working on finishing the leaderboard feature so now as you scroll down the leaderboard it will load more results past the original 11 entry limit. To support this I created a utility that will insert fake users and results into the leaderboard that I can use for testing the leaderboard once it has gotten larger.
Unfortunately this enabled me to discover that the frame rate begins to drop as the leaderboard surpasses 300 entries. This is because the default Unity scroller I am currently using doesn’t hide entries when there not currently being displayed meaning it constantly has to manage 300 entries. When it gets to a 1000 it's very stuttery. To fix this I believe I will have to make a new scroller from scratch that hides undisplayed entries to minimise the processing performed by Unity to display the leaderboard. There is also currently an issue where once you scroll to the bottom of the leaderboard it will begin creating new entries to be populated with values. However because it is at the bottom of the leaderboard there are no new value to populate the entry with. So these empty entries are deleted. Sometimes the Unity scroller thinks it's passed the end of the leaderboard meaning it continues to create empty entries until stopped by the user. Most of the development went into the server which can now load arbitrary chunks of data from either a cache or the leaderboard database depending on whether the data is already in the cache. This currently has a problem that if I make lots of small requests when someone is scrolling slowly, the cache will end up containing many small blocks of cached leaderboard results. This can make it slow to return a larger range result as it needs to examine and build the result out of many small cache blocks. There are future optimisations that I can make to this to improve performance. This will be either ensuring that range requests happen with a predictable size and alignment, this will mean just cache results and not assemble results out of smaller cache blocks. Alternatively, possibly getting smaller cache blocks that are next to each other to merge, so there are less cache blocks to deal with when servicing a request.

Sorry for not making an update for a while, I instead focused on spending the last month creating two new features which are both almost complete. These are both the Skins feature which is around halfway complete and the Leaderboard feature which is already in the base game. Now when you look at the Ranking UI within the Networking feature it will rank every person who has a score into the leaderboard. This score is currently based on how many players you have killed, which I feel displays experience more than skill, as an experienced player with a low win rate could still have more kills than a newer player with a higher win rate. Also, there is currently an issue where if you wish to see the updated statistics on the leaderboard you have to restart the game.
Test players on local server I am still thinking of other ways to calculate this effect while also staying balanced. For example simply ranking the leaderboard based on the win rate would mean newer players could get a lucky first kill and never play again as they already have a 100% win rate. So I have done some simple testing of a few algorithms that may display skill over experience while still staying balanced. Some of which incorporate the other players score so beating a player with a higher score than you would increase your score more than beating someone with a lower score than you.
I am number one on the live server.. come at me :) Then there is also the issue whereby people can farm points by constantly killing another owned account which is one of the more difficult issues to address. For this issue the only real way of stopping it is by limiting how much score one can gain from killing the same player over and over again. I would encourage people to test it out and give some feedback on ways to improve it. The other feature I have been working on is the Skins feature which can currently display local skins that are built into the game.
Crazy test skins I'm using to debug skinning The selector at the top will change the entire player's skin while clicking on each limb with change its individual skin. This leaves room for some simple customisation as you can easily mix stains together.
Example of Skinning in Choose Weapons UI
Same Skin In Game However when you select the fists skin you will more often than not change your weapon combination which is quite irritating to deal with. I have considered having it so clicking on the fist changes its skin while clicking on the area around the fist changes its weapon. However this functionality may confuse first time users. My next step in finishing skins will be implementing Steam Workshop support which will allow for a wider variety of more interesting skin designs to be added to the game. I must then also allow for skins to be displayed online which would require an approval process which could then also lead to skins being implemented into the base game. The skins I've made to test and develop skinning are very primitive but this is what I am aiming for once Steam Workshop is integrated. http://steamcommunity.com/sharedfiles/filedetails/?id=624733305 In order to implement this feature I had to do a lot of work on polishing the player models as well as ensuring that both players are exactly the same. Previously both players had different sprites associated with them that meant player 2 had slightly higher resolution limbs than player 2. Not only that Player 2 actually had shorter arms and a slightly smaller further back head. When I noticed all these inconsistencies I began not only refurbishing Player 2’s limb sprites but also the shape and structure of Player 2. And to ensure that both players are identical Player 1 is now a direct copy of Player 2 just flipped the other way around. Pending tasks are now

• Chat System (Keeping in theme with the game).
• Finish Leaderboard (I need to think of an algorithm that can't be exploited).
• Complete network game lobby UI (make pretty and complete all network game modes).
• Complete network game restart UI (make pretty).
• Steam workshop for player skins.
• Research different arenas and backgrounds.
• General bug fixing, tidy up and enhancement of look and feel..

Over the past 2 weeks I have been working primarily on Leaderboards with some investigation into Skins. On the Rivalry Beta you will now notice that there is a new “Rank” UI that is a fairly barebones leaderboard containing a Scrollable list of player names and scores. (These players are merely there as an example to test the feature).
There have also been a few changes to the UI layout including an extra network menu option allowing you to choose between the networking and ranking feature. Some menu names have also been changed to aid in the consistency of the UI.
I have also added some new commands to the network protocol that can add and request scores from a set on a database. With this whenever someone wins a game their score can be incremented on the database and then retrieved by others when the ranks are displayed. However in its current state I have not yet wired up the client with the server. Currently peoples scores are simply judged on how many players they have killed. This can be gamed with people kill farming accounts they have control over. I have experimented with algorithms that scale against the player you are fighting and will discourage killing the same person over and over again. This I must put more thought into and would definitely welcome suggestions on improvements. I have also looked at how to effectively add skins into Rivalry and have started working on replacing the current player sprite in the choose weapons screen with an actual player. Pending tasks are now

• Chat System (Keeping in theme with the game).
• Leaderboard (I need to think of an algorithm that can't be exploited).
• 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 bug fixing, tidy up and enhancement of look and feel..

This week I managed to fix a critical bug that would cause all games to fail if people had some special characters in their Steam name. I have also doubled the network screen resolution which should make the mouse movement smoother. This resulted from a fix that solved an issue causing network mouse pointers to cluster in the bottom left of the screen when players were in a game. I have also changes to the network protocol so you will need to upgrade to the latest version on steam or it won’t allow you to play online. For now the game engine will keep trying to reconnect after being rejected by the server so it will be a bit messy for a few days until everyone has upgraded :( I have also added some warning text on the network button if the protocol is mismatched so that in the future these updates are a bit cleaner. When posting replay videos to Twitter it now lets you use the new 280 character limit. Fixed numerous other small bugs that had been nagging at me for the last few months and finally managed to work on some new functionality. I have added lobby sound effects to alert players waiting in the lobby when players are available to fight. I'm learning how the Unity sound system works and am using this as the basis for future gameplay sounds such as sword hits. Next week hoping to start working on an online chat which keeps within the style of the game :) Pending tasks are now

• Chat System (Keeping in theme with the game).
• Leaderboard (I need to think of an algorithm that can't be exploited).
• 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 bug fixing, tidy up and enhancement of look and feel..

School assignments are over and so I am now free to get back to work on Rivalry! However I wasn’t able to achieve as much as I had hoped for this week as I had to work on upgrading components of my local test server including my version of windows. I did manage to fix a bug which posed a major risk towards the server. If someone were to quit and rejoin after their network connection dropped out while they were in a game. Then that person's game would remain as a broken game that people could join but never destroy. Technically people could create as many of these games as they wanted creating a huge list of broken games. So far I believe that this effect can no longer be recreated as once you rejoin after quitting the server now deletes your previous game. Pending tasks are now

• Various networking bug fixes.
• Audio Notification that a game has started.
• Chat System (Keeping in theme with the game).
• Leaderboard (I need to think of an algorithm that can't be exploited).
• 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 bug fixing, tidy up and enhancement of look and feel..

For the next two weeks I won't have much time to work on Rivalry as I am in the middle of the main school assessments period for this year. I've been loving watching people play and enjoy the game. There have been some great suggestions which I am now adding to my list and prioritising. I have noticed that people using IPv6 have been having problems playing online games and is something I will be looking into but can't for a few weeks. Pending tasks are now

• Various networking bug fixes.
• Audio Notification that a game has started.
• Chat System (Keeping in theme with the game).
• Leaderboard (I need to think of an algorithm that can't be exploited).
• 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 bug fixing, tidy up and enhancement of look and feel..

Over the past week I have been playing a lot of games with a lot of different people, and I would just like to thank all who used the Network feature as you helped me find a lot of bugs and I have had a lot of fun playing with everyone. I spent most of the time just identifying bugs instead of fixing them but I did get to fix a few. For example: when someone left their game, their cursor would become globally visible even to people already playing games meaning that randomly player mouse cursors could just pop into games that were already in the middle of a match. This has now been fixed so that once you finish a game your cursor will only be visible to those who are in the lobby. I also spent some time to modify the networking lobby. I have changed the way filtering by Steam friends works so now instead of removing all games that aren’t from that friend, it will highlight the game your friend has created to a different colour. I have also added some text at the top of the screen to prompt players on what to do and have changed the colour and style of certain text boxes.
(Before)
(After) However I didn’t get much done when it comes to new game modes and instead spent most of the time playing with others :) Pending tasks are now

• 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 bug fixing, tidy up and enhancement of look and feel..

The Network Play feature is now available in Rivalry’s base game allowing you to now play a game with anyone, anywhere around the world. Over the past two weeks I worked on both getting peer to peer to an acceptable state, re-structured the server back to using containers, disabling and fixing broken network game modes and added a new Steam invite feature that allows you to invite your friends to an online game of Rivalry. Soooo.. Networking is going Live! Although now the client can restart its Peer to Peer connection, the success rate of this restart is currently very low. It will usually take 4 tries for a peer to peer connection to form taking around 30 seconds. However I feel that this success rate can be improved with further investigation. I have asked the developer of the NAT traversal plugin I’m using what could possibly be going wrong and methods of improving it. The server has also been restructured back into containers. This means that all the components of my server are now deployed as Docker containers. The game mode “Players” which allows for network games with more than 2 players has been disabled from the network play feature as there were still a lot of game breaking bugs. For example if more than one person were to drag a limb at once as their turn ended, the player would stay floppy allowing for players to fly around the map with ease. So because of this I have decided to remove it until I have managed to remove these game breaking edge cases. However, on another note I have re-added the “Weapon Choice” mode back into the network play feature as I now believe all game breaking bugs have been fixed. Previously if you were to choose the “Quick” mode, (which randomly selects a weapon combination that will be given to both players). While both sides did get the same weapon combinations, the combinations would be different on each player's screen. For example while the host may see both sides wielding a sword and a knife, the client would see both sides holding an axe and a shield. This always ended in chaos as players would be seen with certain weapons that they didn’t necessarily have. However, the mode has now been fixed and re-added into the network play feature. The final feature I added was the ability to invite friends to join network games. All you have to do is change the filter below the network games list to anyone of your Steam friends and click on their name. In its current state I do believe it is too easy to invite someone to a game and may prove to be irritating without a text prompt of some sort to ask whether you truly do want to invite someone to a game. If the person you invited accepts then they will be automatically sent to the network lobby. This could be improved by instead of taking you to the lobby, it then took you into the network game itself. If anything strange happens during a network game, don’t be afraid to tell me, as I would greatly appreciate bug reports and feedback to further improve the game!
This is a brilliant Review. Thank you very much :) Pending tasks are now

• 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 bug fixing, tidy up and enhancement of look and feel..

This week I worked primarily on strengthening the startup process of the Peer to Peer network connection method. Initially during the startup process if any of the ping messages sent failed to be received, especially if due to latency and a race condition I started listening after the message was sent, then the Peer to Peer connection would also fail as a result. However, now the machine that is sending the ping messages will not only retry sending, but will also retry the connection negotiation process as well. From what I have seen so far the machine sending the ping messages hasn't failed since the change. There was, however, an exception to this when the machine receiving the messages loses all communication from the machine attempting to send them. This only happened twice but that is still enough to warrant an investigation. I will likely need to add a timeout that re-attempts the connection end to end. Another problem I found was that when I tested peer to peer games with more than 2 players joining at once the whole Unity engine would crash. The obvious conclusion would be that the two people joining at once would be too much traffic for the NAT traversal plugin I am using to handle but even when I changed it so connections would be made synchronously, one after the other, the issue persisted. The final change made was refactoring the server from a massive block of Javascript into many smaller Typescript classes. This ensures that the server can be both easily understood and modified. It was getting a bit out of hand :) https://www.youtube.com/watch?v=pusoANI9FC4 Pending tasks are now

• Finish and Test Peer to Peer
• 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..

The Peer to Peer networking method now has a complete life cycle meaning you can play multiple Peer to Peer network games one after the other without trouble. Previously trying to start a new peer to peer game after already playing one would end in a mess of errors and jumbled network states. But now you can continue to play more peer to peer games after already completing one. However I have still found more issues relating to Peer to Peer that limit me from releasing it into the public version. Occasionally during the setup process of peer to peer, Something stops the client from punching through to the listener resulting in a failed peer to peer connection. This could be caused by the protection levels of the machines attempting to connect, players joining and starting games too quickly for the setup process to complete or UDP packets getting lost between machines. Once these issues are fixed and more testing is done then there is a real possibility of releasing networking (including Peer to Peer) into the public version. I also worked on getting the server to coordinate who it should relay packets too without causing the repetition of packets as well as ensuing everyone receives the information they require. Previously if you had a game of 4 people 3 using peer to peer and one using the relay method. Then everyone else who was using peer to peer would also receive the relayed packets from the server, resulting in double the amount of possibly outdated information being sent. However now the host sends client connection status information to the server, so the server can know which machines not to send relayed packets too. Pending tasks are now

• Finish and Test Peer to Peer
• 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..

This week I managed to get peer to peer network play functional! It is now possible to play a game of Rivalry with a friend anywhere around the world by using the peer to peer method which is considerably faster than using the server relay method. However, I still have to fix the peer to peer lifecycle and how it dismantles its connections once a game is finished. Currently you can only really have one game before things start to fall apart. There are also still some optimizations that can be made to the architecture of the code and how packets are unpacked and processed. But once this has been done, all the peer to peer related bugs are fixed and the networking UIs are polished I could say that the network feature has been completed and I can move onto the next feature, player skins. I also looked at how to optimise network speed times by controlling the rate of host frames being sent by the host to all the clients. I can change the network frame rate dynamically, so in theory I can have it scale with network performance. I could potentially also have it so if there is a large influx of players using the server relay method I could lower the host frame rate which would decrease the amount of information on the network allowing the server more time to process requests. Pending tasks are now

• Finish Peer to Peer
• 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..

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

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

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:

• 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..

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

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

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.

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.

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.

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.

Finally all of my school assessments for thus 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 who ch allows people to then vote to either leave or rematch. Currently it needs to be unanimous on either side to cause any change, and I still have to work out the logic that should happen 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.

It was difficult to get any work done during both last and this week as I am now in the middle of my assessment period. However I did manage to get some work done on networking with the development of rematching. I have created a new “Rematching UI” that will get triggered if anyone at the end of a game presses the rematch button.
This allows people to vote to either leave the game entirely or restart the existing game with the same players. People who vote to leave the game will still get the chance to see how other players are voting allowing them to change their vote. Or they can then click continue they will instantly leave the game. If a player votes to rematch and then presses continue they will jump to the player and weapon selection screen for the rematched game. If after this not enough people vote for a rematch the game will become public again allowing other new players to join.
I underestimated the complexity of the issue and found that it will be even more complicated than joining a game as it involves people who could be looking at different screens like the game over screen, share screen or they could be rendering a video. So then it needs to gather everyone up to vote on whether they want to prolong the game session or leave it. The Network protocol is still very slow and there is still lots of bugs that need to be fixed. My goal is to get things feature complete before I start tidying and optimising

This week I worked on getting blood and the replay/social media sharing feature working after a network battle. Previously the client machine could not see any blood while in a network fight while the host machine could. So now I have made blood information from the host’s machine get sent to and displayed by the clients machine. There were issues with blood emitter location translations and certain blood values were not being sent because of their type incompatibility with the network protocol. However it now seems to work perfectly so message me if you see anything strange while using networking in the Beta. I also managed to get the replay feature working after a network game. So now after a network game you can view and share a replay of the fight. However there are still a few edge cases and issues that haven’t been fixed. For example when you are in the replay UI and someone leaves the game it will kick you out of replay UI, but it’s still technically on in the background, meaning when you have another fight the replay UI will be overlayed over top of your current fight ending in utter chaos. There are also other edge cases, like when rendering a video the other players cursors are shown live moving around the screen instead of being played back. https://www.youtube.com/watch?v=fz2HwS9SXWk Also if someone cancels a game while you’re rendering a video, your replay will be rudely interrupted by the network game canceled warning. https://www.youtube.com/watch?v=VnneSNgpSu4 It is still pretty broken as there are many interactions between players and network games that shouldn’t be happening. Next I will work more on fixing edge cases just like these and will go on to work on the network logic behind rematching a network game.

Finally after many months of work you can play a game of Rivalry with someone else over a network! If you wish to test it out the feature is currently available on the Rivalry beta. The networking protocol is still very inefficient and there are many features still missing but you can now at last fight and complete a game This week I finally enabled multiple limbs to be selected and dragged at the same time in networking. I then changed the network protocol so clients can send mouse clicks and dragging information to the host, allowing the selected limb to move towards the client's mouse location. This process means clients can finally move limbs and respond to a host's movement. So it is now possible to have a complete fight. Another feature which is now functional is having multiple people’s cursors controlling the limbs of the same player at once. So far I have played a 2 vs 2 game which was functional but did suffer from slow response speeds. Currently the largest match you can have is a 4 vs 4, and although it should work in theory, I still have not yet tested it and am not sure how fast the response times will be with the added players and network traffic. I still welcome people to try it and see how they do. https://youtu.be/2GsJDiS3W4k However, there are still many network features that need to be completed. Currently, blood information from the host is not being sent to the client. Meaning the host can see the blood (because the host runs the game physics), but the client can not.
(Host side) The client can still see limbs being torn off or made floppy but that is about all the damage feedback they get.
(Client side) This early version of networking is also quite slow because of the format I am using to send information. I am planning to change it to a much simpler Binary format which will hopefully speed up response times. There are also various features like replay and rematches that don't yet work not to mention many bugs that still need to be fixed. During this week I also got to work further on weapon pushing. I experimented with how impacts should travel through the player's body using dividing factors that recursively travel through all limbs. This created some.. weird.. effects. For example the ability to flick and rotate players into the air (which I am still contemplating how I could possibly use this.) https://www.youtube.com/watch?v=6luGsXSEKl8 I was wondering if this should be a possible physics option when if I add customisable games, or if this effect could be exclusively for heavy weapons. I am also wondering if weapon impacting should be used exclusively by heavy weapons like the sledgehammer and battleaxe. It would be incredibly helpful to get If your thoughts on these ideas, so if you have any you can post them in the comments below. Currently I have disabled weapon pushing as there are too many bugs that need to fixed Next week I will be working on getting networking features like blood and game over options like replay and rematching working as well as fixing bugs and edge-cases throughout networking.

This week I worked on refactoring the code which controls information on highlighting and dragging. In order to continue work on network play, this code needed to be refactored. Previously my central limb base class controlled all the information about highlighting and selection, which meant it treated mouse highlighting and selection in a way which would only allow one highlight and selection to be made at any given time. This was also the case for my base movement class, which controlled everything about limb dragging. So in order to have multiple people controlling characters or limbs in parallel with one another, these systems must allow for limbs to be selected and dragged at the same time by multiple players I did this by splitting the information about what limbs that are currently being selected and dragged from the static classes and instead, moved them to smaller classes that can be instantiated depending on the number of players. This enables multiple selection and dragging values to controlled which will be incredibly beneficial to the development of network play. However, currently I only have the system working on single player games (which didn’t create much of an effect on the gameplay except for fixing a few selection bugs). Next week I am planning on adding this to network play as well. Some other good news is that school holidays have begun, meaning I can spend more time working on Rivalry. However I have also been given school assessments to finish over the holidays so I will have to spend some days working on those projects instead.

This weekend was mainly focused on updating all my machines with the latest software. This included updates to Unity, Visual Studio and even Windows 10. Sadly this meant i didn’t get a lot of time to working on networking or the network protocol and instead a lot of time watching progress bars.

Sorry for not posting an update in 2 weeks. On the first week I had to work solely on assessments and on the second I had a fever. But this week I was free to work on Rivalry! I worked further on the Networking by implementing rules on what limb a cursor is allowed to select and when that cursor is allowed to skip their turn. Previously a cursor controlling one player could highlight and drag (if they were the host) the other player. They could also skip their opponents turn for them. Now there are rules set in place that stop different players from controlling their opponents player and skipping their turn. I also managed to add some of the framework needed for client to host player movement. Next week I will start working on the actual implementation of this feature and may even finish it. This week I also fixed various bugs that have been recently plaguing Rivalry. There was an issue with weapon pushing where if a player is dragging their weapon and it get impacted by the opponents weapon, It would save the dragging weapons relaxed constraints. This means when the player's weapon stops being impacted then it would revert back to a state with relaxed constraints making it forever floppy until dragged again. I fixed this by having it so a weapon can not be impacted when already being dragged. This fixes the problem and still allows the weapon to be “impacted” by the opponents weapon because of its relaxed dragging constraints. Some people had noticed how rarely when a weapon strikes a limb the blood gush would come out at in an inverted angle. This creates a strange effect as the blood travels through the other side of the head.
I still do not completely know what is causing this bug, but I have implemented a temporary fix that greatly minimises the chance of it happening. Please notify me if it ever happens to you while you are using the beta.

Over the past week my time has been primarily taken up by working on assignments and homework. However I did get some time during the weekend to work on the Network Protocol for Network play and some work on fixing bugs in Weapon Pushing. Last week I managed to get highlight information from the client to be sent to the host and then displayed. However this would mean that only the host would be able to see other players mouse highlights. Now whenever the host receives highlighting information from a client machine, the host will integrate the client's highlight information (as well as the hosts highlight information) into the game information frame to then be sent to all the clients and displayed. This means all players will be able to see everyone else's selections which will hopefully increase teamwork between players controlling the same player. I have also added in the ability for clients to skip their turn by sending a skip turn command from the client to the host machine which will switch whose turn it is. Next week I will work on movement and dragging information to be sent from the client to the host. I have found a bug in weapons that allowed people to forcibly push their opponent’s weapons out of their hands and into a strange glitchy state. I assumed it was being caused by weapon pushing but found It was actually being caused by a material I was applying to the weapons that made them much more “bouncy”. I have now removed this “bounciness” which has stopped the glitch but changed the way all the weapons react to collisions with one another. This means I will have to rebalance all the weapon pushing fields that control weapon pushing. I am currently seeing an issue on the live server (which is somehow behaving differently to my local server) where transmission seems to be broken down.

Sorry for not releasing an update last week. School assignments and homework are back with a vengeance so I took some time to get them done. However in the time I did have to work on Rivalry I added in two noticeable features. I have now added in a client to host network protocol which currently only lets client cursors highlight limbs on the hosts side. So currently it’s a little bit incomplete but finally I have settled on a design that sends client information to the host. The way I have it working is that the host will perform all physics simulations and send frame information updates to all the clients. The clients will send their input to get processed and the results get incorporated into the frame information updates. I have started with just mouse-over limb highlights as it was the simplest method to test and prove this design. An outstanding issue is that the mouse interpolation now renders the mouse position lagging behind the mouse-over limb highlight.
I am hoping that next week I can incorporate mouse-over limb highlighting into the host frame information updates so all the clients will be able to see the host’s mouse selection. Then I will attempt client to host limb dragging and movement. Weapon pushing has also changed so now when weapons collide, the weapon with the largest velocity will push the other weapon away instead of it being based on who’s turn it is. I added this because it was creating weird effects when weapons would collide at high velocities. For example if someone flung themselves at their opponent with their weapon extended but it wasn’t their turn, then their weapon would just bend backwards against the opponents stationary weapon.
(player flings at opponent with longsword extended)
(opponent's weapon bends when it is impacted by the players extended longsword even when it is the opponent's turn) The next step for weapon pushing is having the impact stop gradually instead of having it suddenly locking into place.

I just got braces put in yesterday (yay?) :( and I’m in a lot of pain so didn’t get much done this weekend.
This release contains ‘Pushing’ of weapons and some minor bug fixes. I have also tweaked the stickiness of the Morning Star. I have held back the Spear until I add larger arenas. I spent this weekend fixing bugs in the server code, getting the code ready to add some of the new messages needed for remote clients to send their movement to the game host in network games.The main bug I fixed this weekend is collisions in the server objects when players in a game made quick changes to their status. Teeth willing, next week, onto revamping the server code to allow it to be extended to contain the new remote client movement gameplay commands. If you want to check the status of network gaming try the "beta" branch.

The latest Beta is out (0.33). I would really appreciate feedback on weapon pushing and the stickiness of the Morning Star. I have gotten many requests to add the ability to push weapons aside. but am not quite sure if this is really “Rivalry”. By this I mean, it seems that part of the appeal of the game is the weird physics. I am not sure yet, if making the physics realistic, makes the game more or less fun. I finally got Weapon pushing working successfully without any side effects on physics or gameplay. https://www.youtube.com/watch?v=9ymDlo1h9UA Previously I had attempted at getting Weapon Pushing working by affecting a weapon/limbs drag and angular drag. However this left over bugs like players freezing in mid air and static anti-gravity swords. I then changed it so it would affect a weapons mass. This didn’t have much effect on the bugs and just made things worse by creating static anti-gravity super swords that caused massive amounts of damage resulting in geysers of blood and body “liquefaction”. :) https://www.youtube.com/watch?v=uRxK8FhX21I These two methods of Weapon Pushing also resulted in many complex systems of saving and restoring physics values and artificial physics values, which would often get mixed up with each other resulting in broken physics. However I have now replaced these methods with a new third method of using “Friction-Joints”. These enabled me to add torque to the hinges connecting limbs and weapons when being pushed. This also preserves the physics dynamics and ensures that there are no side effects. Throughout the week I will continue to tweak weapon pushing to make it easier or harder to push limbs. https://www.youtube.com/watch?v=V85F1iqzCds I have also done some work on weapon stickiness by making the Morning Star the only sticky weapon and by making the shield the only weapon that the Morning Star can stick into. I did this because I sometimes found weapons sticking into other weapons unexpected and annoying. So I thought by doing this it would simplify the stickiness feature and gameplay. https://www.youtube.com/watch?v=vre9EUgPosY Next week I plan to work more on the Networking protocol and maybe even achieve client to host dragging and movement.

During this week I did some more work on Network play. I did some small touches on the Networking UI by resizing some button's box colliders, but mainly got some work done on the Networking Protocol. Now information like movement points, whose turn it is, who is allowed to move which player, who can select which player's limbs and who has the power to skip a turn can now all be sent from client to host or host to client. However currently player movement can only be sent from host to client. Getting this to work both ways will be the next big step in Networking. I have decided to have all calculations, physics and dragging to be done on the host machine. At the moment the host is the machine that started the game. This will mean that I will have to send data like the mouse scroll wheel input and dragging information across to the host machine. The benefit from doing this is so in the future I can get player turns happening simultaneously. I also managed to get some work done on Weapon (and limb) Pushing. Now when weapons collide with an opponent, the opponent's weapon or limb will be pushed. This works recursively, meaning if you hit the opponent's hand, then only his hand and weapon will move but if you hit the opponent's upper arm, the upper arm, lower arm, hand and weapon will move. This also means if you slam a sledgehammer into the torso of the opponent all his limbs will impact and crumple. I am still playing around with how limbs should be pushed and will also be working on making the effectiveness of the push be based on the impacting weapon's mass. For example pushing someone's arm with a knife should be harder to achieve than pushing it with a sledgehammer. It is still experimental so if you would like to test it yourself and give feedback the feature is available on the open Beta.

Today is a special day as it is Rivalry's first Early Access Steam Release Anniversary! It is good to see how far the game has progressed since last year with the replay feature being added, Social Media sharing and a complete UI makeover, and I am hoping for an even more productive 2017!.. if school work allows it... During this week I have changed the way stickiness works with different parts of weapons. I have changed how it affects both the part of your weapon you are hitting with, and which part of your opponent's weapon you are hitting. This means that individual parts of your weapon could be more sticky than other parts. For example, if you hit someone with the handle of a Morning Star then it will not stick into them. However if you hit them with one of the sharp points of the Morning Star than you will have a much greater chance of it sticking into them.
The Morning Star's handle was bashed into the arm of the opponent, failing to stick into the arm and instead bouncing back
But When the Morning Star's head was bashed into the arm of the opponent it stuck, enabling the opponent to be suspended into the air Also, different parts of your opponent's weapon are more susceptible to being stuck into. For example, if you hit your Morning Star into the head of a Spear it will bounce right off, but if you smash it into the wooden staff of a spear it will have a much greater chance of sticking. Both these details adds more strategy to disarming an opponent and claiming victory.
The Morning Star is bashed into the steel head of the spear causing it to bounce off without sticking
However this time the Morning Star is bashed into the wooden staff of the spear causing it to stick also enabling the opponent to be suspended into the air I have also done some more work on the Networking UI by changing the location of some of the components and information. For example the "Create Game/Join Game button" is now located in the top right instead of the bottom middle. I did this so it would correlate with other similar UI's in Rivalry like "Choose Weapons UI". I have also changed the location of the game's description to the top where it continues to be close to the "Create Game/Join Game button". The colour scheme has also changed to better fit other color standards found throughout the game. Some of these may change as I fine tune the colours to be more clearer or aesthetically pleasing.
This weekend I got the network protocol null issue resolved which was introduced by the optimisations to the telemetry recording I introduced over the last month. I'm now designing the extended protocol to allow the transmission of game state such as dragging. My first attempt is to have only one of the players be the 'host'. This means all the physics happens on one machine. I'm designing a protocol that allows this to be accurate and efficient, as well as fun :) I'm going to start by only transmitting mouse information but I suspect I may need to also transmit some of the game state as well. Today was spent going through all the old networking code written before PAX, getting it in good working order and deciding how to proceed next. If you play the beta you will notice that data only moves one way, from the host to all the clients. Next weekend the aim is to get data flowing the other way. If anyone wishes to experience these new features, they will be available on the public Beta. Next week I will be working on features like "Weapon Pushing" and more on the network protocol until hopefully I can actually have a fight over network.

Over the week I have added the spear as a new weapon! This is the first "polearm" to be implemented into Rivalry. It's main advantage over other weapons is its long range. It is twice as long as the Rapier (which was the longest weapon) but is also the second heaviest weapon. (Just before the shield). The spear is sharp on both ends because both it's spear-head and 'butt-cap' can do cut damage. It is also a winged spear meaning you can effectively block an opponent's weapon or pummel them. Currently it is also the second "stickiest weapon". It will be available on the beta branch in a few days.
Currently I have found that the spear sticks into other weapons to easily. To combat this I will be making sticking weapons into other weapons harder to achieve. I will do this by making some parts of the weapon (like metal blades or heads) have a higher tolerance against sticky weapons, while wooden staffs or handles will have a lower tolerance. https://youtu.be/J2LauxjT_0I This week I also managed to fix and refurbish the Networking UI. I have fixed resizing issues on displays with different resolutions or aspect ratios. This was a major blocker for a while but now seems to be under control. Some workarounds in Unity needed to be found to solve the scaling issues I was encountering. I also did some work on improving the layout of the UI.
Next week I will be working more on the spear, possibly adding the ability to adjust your hand's position on the spear pole allowing you to adjust its length. I will also be improving UI usability and investigate "weapon pushing" which will enable weapons to push other weapons away.

This weekend I investigated into the bug in network play where mouse positions wouldn't correlate across different machines with screens of different resolutions. However I found that the mouse positions were tracking accordingly and it was instead the things I used to test if they were tracking that had the bug. I would test mouse positions by aligning up the cursor on one screen with a letter in a piece of text. I would then look at the other screen to see where it had been drawn. I found that the mouse positions were being drawn in the correct places but the text was being scaled down or up depending on the resolution. This would create the illusion that the mouse's position was different. I found that some UI Canvases didn't have any Canvas Scalers which is needed to resize text objects depending on the screen resolution. I also found that some text objects had a resizing script which when also paired with the Canvas Scaler would apply the revised scale twice ending in abnormally small or large text objects.
I also re-added the expand method which adds a nice zoom effect when you first enter a menu option and modified the "oscillating/breathing text" method to scale the text object's transform instead of the font size which resulted in a smoother effect. The last change I made was to redo the design for some of the menu options to make things even clearer.

During the week I also modified the pause option during gameplay to actually pause the game. I did this because I was receiving feedback that people would kill each other when paused :).
Also had to spend considerable time fixing breaking changes from the Unity upgrade to Unity 5.5.0. The largest of the glitches was when a player stopped moving their body would explode which as you could imagine had a considerable effect on the gameplay :D. Some more good news is that school is over for this year, which means I get more time to work on Rivalry!

Just last night I managed to find the cause of the memory leak! I found that the way the movement point indicator was being rendered was that it was being constantly created over and over again each time creating a new Unity object that wouldn't be garbage collected.

This weekend I attempted to optimise the way frames are recorded during a fight. I did this by only having a limb's geometric transform recorded when it changed from frame to frame. I did this by having each limb return a value of null when it's transform hadn't changed. This would use less memory because now less information was being stored. On playback when displaying each limb's transform, It will now seek back previous frames until each limb found a value of itself that wasn't null. This is to ensure that each limb always has an accurate value and so it can pick up where it is supposed to be on the screen no matter where it has been placed on the timeline. However, when comparing this new optimisation with the current version it failed to make any impact on the memory usage. Even when I compared it to a version that didn't record any frames there was no change in memory usage. This has led me to believe that it is because of possibly a memory leak. I know that it's storing less frame information but I am unable to measure its effects until I have located the memory leak or have determined that it is not a memory leak and is a feature of Unity. On a more positive note, with these changes, I have managed to create a system that records down the minimum amount of information. This will greatly aid the network feature as now a substantially smaller amount of information has to be sent across the network.

This week I have made a few more small changes to various parts of the game that needed fixing and have released a new version that includes all the new features I have added over the past few weeks. This week I have added a "rendering percentage" when rendering. This is surprisingly a great improvement because now you can better judge how long the video will take to render. I feel a lot more paitent waiting for a render knowing that it's not going to take forever. :)
I have also made blood shoot out from a limbs surface at a perpendicular angle. Before blood would shoot out towards the center of the colliding weapon, which would result in blood gushes having some unrealistic trajectories. However now it shoots towards the limb surface's "normal", resulting in it shooting out from the limb at a realistic angle. https://www.youtube.com/watch?v=pHgjbdAh1A4
Started on getting network play working again. I did some research into the memory consumption during recording of games. This has an impact on network play as I am using the same format across the network that I use to save the game for replay, so if I get it optimised for replay, it should also be optimised for network play. At the moment I believe I am saving too much information about the game state for each frame. Eg. saving information for limbs that are not moving. If I can reduce this, it will allow for less memory consumption, longer games and lower ping times when being used in network play.

During this week I have worked on finishing the replay feature. I have implemented the VCR theme and added a new Death Marker that appears on the video position slider.
This is so you can easily find where the final blow was dealt. I often found myself struggling to find where the death blow occurred in the timeline to pick out the perfect few seconds of carnage. One other thing I worked on was getting every single weapon combination a name! Although some of them aren't that witty I am hoping that you can help improve the names by suggesting different names for different combinations! Currently this is marked by a simple white square but soon I will replace it with a skull symbol. I also will be adding a few more tweaks to make the VCR styled buttons a little more responsive. https://www.youtube.com/watch?v=I_kNRk6jSBc

I have been experimenting with different art styles to try and improve the usability of the replay and posting to social media UI. I have decided to go with a retro VCR theme because of it's simplicity and its use of basic colours and flashing as signifiers, which goes with the current simple style of the game. Currently the social media and write message buttons look ugly and out of place so I will be fixing those during the week.
I will also probably spend the next week trying to get replay UI completed. This involves the restructuring of how object transforms are saved in memory (This will also be used for in the network play feature) and adding a few more features like showing the point of death on the replay timeline. Almost school holidays, Yay! Homework, exams and assignments are pretty much over for the year, so I am finding myself with more time to work on the game.

During this week I developed a new feature which enables weapons to stick into other weapons and limbs. The harder you smash a weapon into a limb/weapon and which weapon you use (like the Morning Star) will determine whether your weapon will stick into the other person's limb. This enables people to drag the opponent towards them or lift them into the air. Here are some videos I shared using the new social media sharing feature i launched at PAX last week. https://twitter.com/qewbe/status/799121820234313728 Once stuck into the limb/weapon the opponent can thrash or pull on the limb to try and detach themselves. All this together adds a new level of strategy and another counter to people who like to push away their enemy. https://www.youtube.com/watch?v=wDwMHoCDE9w This feature will also be used in many other weapons that are designed to latch into the enemy.

Last weekend I was at PAX Australia in Melbourne showcasing Rivalry! It was great meeting all of you who got to play my game! It was also fun to see veterans from last PAX back to try the new features and challenge their friends.
PAX was also useful in testing new features. These features include the replay feature, the new damage system and the morning star. I found new issues with the fight replay UI, and which weapons were underpowered or TO overpowered, *Cough* Shield *Cough*.
One of the main complaints about the fight replay UI was that it looked too complicated, so currently I am working on fixing the design flaws in the fight replay UI and simplifying the overall design. I will also be changing some of the weapon’s damage levels and will be adding new weapons in the weeks to come.
The replay feature is now available in the new version that I released today. I will be refining the UI over the next few weeks.

Working as fast as I can on the networking UI. Managed to get game creation in the networking UI and started work on the network protocol for creating and joining games. Next step is getting players to join games. My school has decided that the week I have PAX, 5 assignments are due. :( This means I don't think I will be able to get everything i wanted to get done in networking, but I am going to try my best, even if it is just a semi-working demo. Here are some screenshots of my new developments.

This week I have been optimising the mouse movement network protocol. Given up on predictive vectoring for now, I may add this later on but it's a bit jittery the way I have it working now. I have settled on a simpler protocol and am moving on to actually getting network games playable. So, this weekend I have been adding a UI for network multiplayer games. It can currently create a game. Next step is being able to join existing games. I am hoping to get this feature done for PAX Melbourne in 3 weeks!

https://youtu.be/fuSjKi9bd3o Example of multiplayer lobby in Rivalry. You get to see each player's mouse cursor. This is only available in the closed beta if you know the secret handshake. :) This weekend I added a simple online lobby where players cursors show up on other people's screens over network. This cursor concept is how I am going to base all online user interactions. This will also work during the multiplayer fights as the whole game is driven by the mouse. I have also changed how damage is calculated and the balance of weapons. I am hoping that the weapons are still balanced and that the game is still fun. This is where you come in, if you want to help test the closed beta, just ask me for the secret handshake :) Before the axe and sledgehammer would do barely any damage, even when they were slammed down onto someone. But now weapon damage is raised to a power meaning that the axe and sledgehammer when lightly tapped against someone's arm will do nearly nothing, but when whacked against an arm it could easily tear it off. There are a few minor glitches that need to be sorted but so far I am preferring this method a lot more than the last method.
The last major thing I have added is the morning star! I would describe it as a lighter axe that has the power to latch onto weapons and players. This has inspired me to add a whole "stickiness" mechanic. Which enables players to be able to drag the opposing player towards them or to stop a weapon from easily moving. However if enough force is exerted onto the morning star the weapon or limb will detach from it.

Started on adding a new weapon. The Morning Star. It's very pointy and seems to get easily lodged in other weapons. I am guessing this is becuase of its complex polygon mesh. So I'll be simplifying it down to see if that fixes it.

I have also started on the UI for network play. I decided that I would have eveyones mouse pointer displayed in real time in the lobby, so your player avatar would be your mouse pointer :) It could be some crazy fun but I'm not sure if it would be practical, we will see...

Facebook have approved video posting for Rivalry so I have opened the beta to everyone! If you wish to test it out yourself, go to your Library, right click on "Rivalry", choose properties.....
.... then from the BETAS tab pick the "Open Beta" from the dropdown.
If you encounter any issues while running the beta please post details of what happened. HERE So this is two major features done, I'm starting today on network play. :)
Also this fan art has inspired me to think more about adding customs skin. What do you think?

Over the past month I have been working on cross platform integration of the replay feature over Windows, OSX and Linux. I have also been working on improving the server's security and other small details which should improve the user's experience. This proved to be quite difficult and it took a month more than expected. I only had to make one compromise and that's in order for OSX and Linux to successfully upload a video to any social media site you must install Mono onto your machine. If you do not have Mono installed Rivalry will detect this and give you a link to the download page. Because this has all taken longer than expected I only recently applied to Facebook to have permission to use their publishing actions. They should get back to me in a few more days, and when that's done (and if they approve it), I should be able to open the beta! I have also been commissioning and testing the servers. My dad has been helping me with getting the server application working on AWS using Docker. I am not sure if what we have written is entirely scalable under load but hopefully I will find out. :) While I have been testing social media posting and fixing those issues I have been working towards adding real time connectivity between the app and the servers which will form the basis of network play. From this experience I have learned a lot about the structure of servers and how components like Nginx, Redis and NodeJS works. I have also learned a lot about the networking between servers and how information is sent across the web. Currently you may be wondering why the game doesn't look that different from the last update. This is because I have really been focusing on the replay feature for the last 9 months, which was basically writing a video editor and solving the problem of getting videos out of unity and onto social media sites, It is for this reason that I haven't gotten much time to add any game changing new features. However once I have released the replay update I will work on adding new weapons, arenas and online multiplayer.

On Sunday I managed to get a sever installed. I learnt quite a lot about Docker container managment and AWS in general. This week I will be testing replay and posting to social media features on the new live sever. Wish me luck!

Over the past month I have managed to almost finish the replay feature! I have created a system that can correctly limit the video's specifications to each social media's platform limitations while keeping it (hopefully) seamless for the user to navigate through. I have also created a UI that enables you to write a message with your video and a pretty HTML page that will open when you have posted a video. I hope to have the replay feature in a closed beta by next week where I can test it on multiple operating systems. Once that is complete I can stand up a server and officially release it. In other news I'll be heading to PAX Melbourne early this November to showcase Rivalry. I am hoping to have a few more features and weapons implemented before then and looking forward to meeting some of you there!

Sorry about not posting any status updates over the past 3 weeks. I have currently been working on school assignments and am only now getting back into the habit of working on Rivalry. This weekend I have done some work on the replay feature and more specifically sharing. Both Twitter, Facebook and YouTube have certain limitations to what videos they can play. This means that if you wanted to upload a 60fps video to Twitter, and Twitter can only support a maximum of 40fps, then the upload will fail and things would fall apart. So to combat this issue Rivalry will now disable the button that lets you upload a video to that certain social media sites, if that video is above the limitations for upload. However I am now planning to change the buttons colour instead of disabling the button entirely. This is so the user can then chose to continue clicking the button causing a small text box to appear warning the user that the requirements of the video don't meet the needs for the certain social media site. It will also give the user the chance to cancel the upload or to have the computer automatically fix it for them. https://youtu.be/7dfrCvTO9qo

Spent most of today in "DLL Hell" but my dad managed to get me out of it with some Visual Studio tricks. Eventually I managed to get my sharing code intergrated with the game and was able to play a game, select a section and share it with Twitter, YouTube and Facebook all in one session.


A lot of the time, over the past month, I have been learning how to write client/server code. Luckly using node.js I can write server code in JavaScript which is the language I first learned.
Because Twitter has a lot of restrictions on video size, resolution, duration and frame rate I will have to create a UI that can inform the user and restrict some of the export options. For now I am just detecting when Twitter fails and activating a placeholder dialogue box that warns the user that the upload failed.
Its easy to upload to YouTube because YouTube will accept any video you give it. Facebook is limited to 30 fps, 45 minutes and 720p. Twitter is limited to 40 fps, 30 seconds and effectivly 720p. So when you want to export to all 3 at once I am going to have to find a way to limit duration, filesize, frame rate and resolution to the lowest common denominator. Facebook's policy is that the user needs to be able to write their own message and description and developers are not alowed to auto-populate any of the text. This is adding up to a complex UI that is going to take some thought. Apart from that I have been working on weapon balancing by creating a whole new damage system while still keeping the game fun. Some of the heavy weapons such as the BattleAxe and SledgeHammer are underpowered especialy when you get them up to speed. I kind of feel that the Knife is pretty perfect right now so I am trying to balance the other weapons around it. (Reach vs weight vs damage vs "swiftness")

Again sorry for having no video over the past few weeks. I've mostly been working on communications between the server and the client. This weekend I've been working on getting the client to send commands to the server and then handling the responses from the server. Next weekend I will be working on getting the server to coodinate multiple sessions. Also I'm going to change the way I intergrate with Twitter to make it more secure. My Dad has been helping me with the intergration process. We did Twitter first but after doing Facebook, Youtube, learning from that and talking to my Dad, he suggests we redo the Twitter intergration to make it more secure.

No video update this weekend however I have been working on posting to social media. If you've been monitoring the Rivalry Twitter acount you might have seen some test posts over the weekend. https://twitter.com/RivalryGame

Over the holidays I have been working on video interpolation and balancing weapons. There are still some other small features that need to be added like sharing and not to mention many bugs that need to be fixed. However the replay feature isn't that far away from being released. Once I get sharing the rendered video on social networks functional. https://youtu.be/FcTIiaXjT5o

More work on replay and video export. Fixed numerous small bugs in replay logic. Can now export selected video section at different speeds. School holidays at last, so I will hopefully make some good progress over the next two weeks.

1/4 Speed Export

4x Speed Export

More work on replay. Managed to add video selection tool. Replaced the inbuilt Unity scrub bar with my own custom one. Next week I hope to get video export working with exporting just the selected video. https://www.youtube.com/watch?v=cCpCq5g6TbU

More work on replay. Managed to add video selection tool. Replaced the inbuilt Unity scrub bar with my own custom one. Next week I hope to get video export working with exporting just the selected video. https://www.youtube.com/watch?v=cCpCq5g6TbU

This weekend I have been working on a speed multiplier for replay. I have also redone the UI so now it looks a little easier to understand. Also to speed up development I have made all weapons do an incredible amount of damage but don't worry it won't be implemented into the public version. I might however add it in as a game mode some time in the future. https://youtu.be/Rm0bWpJ0Qvc

Two members of the Yogscast, Kim and Duncan did a Let's Play of Rivalry!! I've been a fan of the Yogscast ever since I was 10 years old and into Minecraft. It's weird to see my game being played by them. It still really hasn't sunk in yet... https://www.youtube.com/watch?v=MtWLMYRl7Ks

This is a replay sample video of a quick match I had with my dad saved from the latest version of the Rivalry video editor. At the beginning it shows the new Intro and at the end it shows the new game over results. Over the past few weeks I have mainly been working on both fixing bugs and adding functions to the replay feature. https://youtu.be/NnPwD1X_f44

I've been working on options for the replay feature that can let you:

• Decide if you want the cursor displayed.
• Decide if you want the movement point indicator displayed.
• Let you choose the frame rate.
• Let you choose the resolution.

I've done more work this weekend on the replay feature and now have it so you can export a video in 1080p at 50fps with the correct playback speed. There are still a few bugs I have to fix but once I have fixed them I have gotten the core replay feature working and now have to work on sharing and video editing. Here is a sample of the saved from Rivalry. https://www.youtube.com/watch?v=Xpialmwmhcc

Got video saving working from replay. Trying to get frame rate to be constant. This video is 720p but I don't think I can generate that at the 25fps required to encode the frames and save it to disk without lag. I may have to generate the video at quarter screen resolution or stream the raw video to disk before processing it... which at this point looks like it's going to take many gigabytes per minute.. My dad has been helping me with the video processing. He has some ideas on how to get this working better. I will try them next weekend. This sample is at 25fps 720p. https://www.youtube.com/watch?v=XrNIgyc88yI

Making good progress on the replay feature I started after PAX. https://www.youtube.com/watch?v=60htphM7iUA Ultimately I want this to be able to post videos or animated gifs of sections of fights to social networks. The next priority will be familiarising myself with the Steam APIs to support matchmaking, network gaming and high score tables.

Rivalry - Early Access V0.17 is Live!!! Rivalry started as a level I made in Little Big Planet when I was 12 and I have spent the last two years learning how to program to get to here. It's been an amazing journey. The Kickstarter to get to PAX, exhibiting at PAX, the amazing response of attendees at our stand and the Greenlight campaign. And now into Steam on Early Access! Grab a friend and have a play. Please tell us what you think. This game can be made even more fun with your support! Thankyou Kew McParlane

• OS: Ubuntu 12.04. SteamOS
• Processor: 2.4 GHz Intel Pentium 4Memory: 2 GB RAM
• Memory: 2 GB RAM
• Graphics: 720p display. Any graphics card since 2004 should work.
• Storage: 300 MB available space

• OS: Ubuntu 12.04+. SteamOS+
• Processor: 3.4 GHz Intel i7Memory: 4 GB RAM
• Memory: 4 GB RAM
• Graphics: 720p+ Display. Intel HD Graphics 4000 and higher. ATI Radeon HD-Series 4650 and higher. Nvidia GeForce 2xx-Series and up
• Storage: 1 GB available space