GameDev 2019 Week 10: Shop
Network Improvements, Shop10.03.2019 - 12:11
When I originally added the tower button images into the game, I didn't have the tower upgrades in mind, so they were added in a suboptimally, so I changed the way they are loaded when the game start, so the tower button images can now also be used for tower upgrades. Then I implemented a new feature to my animation editor: it is now possible to replace colors in the editor to create variants of models, so now I can also add blue and red slime versions into the game. And of course yellow, orange, pink, black, white, purple, light magenta, tinted lime, stained brown, etc slimes ;) In all seriousness though, there is now way I am ever able to create completely different animated models for all waves, so having different version of a mob is a nice way to have some variation.
So far there was no way for the players in multiplayer games to interact so I added a console/chat into the game. However my engine console class was a bit outdated so I had to update and modernize it, but after a little while I was able to use it in the game. Luckily my networking library already had callback functions for chat messages so adding the chat functionality was fairly straight forward.
Today I introduced the concept of game rules, overarching rules for the game that can be configured before the game starts. The server will send the game rules to all clients in its first message. The first two game rules I added were a HP and a speed modifier. They can be used to change the hitpoints and speed of every mob to increase or decrease the difficulty, it will also help with the balancing of maps, if I notice that a map is way too easy or hard, I can globally change these stats without changing every single mobs hp and speed. Then I created a texture for the escape menu buttons and other more general buttons. And I started to design a ui for the shop. Normally I start by adding the functionality and then create the ui, but for the shop I did it the other way around, I dont know why :D
Today I worked on improving the multiplayer protocol, while every tower build and remove was synced the rest of the game was purely simulated on both the server and all clients. In 99%+ of situations this would be completely ok, because the simulation would yield the same results on all ends, but on rare occasions there could have been a RNG based difference, e.g. a mob with low HP is almost at the end, but one tower can get a shot in, on the clients side the tower crits and kills the mob and on the server side it doesn't. I don't want sync all projectiles, because there are going to be a lot of them. So instead I changed the protocol, at the end of every wave, every client will tell the server how it is done. And on the server there are going to be different server authority levels: The first option is trust the client and the server will trust each client with its own results, which means from the players view everything will be correct at all times. If the player wants to cheat, he theoretically could, but he would only affect his own gameplay, so if he wants to ruin it for himself, it's fine. The second and third option are not yet implemented, but they are going to be medium and full server trust, on full server trust, the server will force its simulation results onto all clients, regardless of how they have done eliminating all cheating possibilities, and on medium trust the server will compare the results and if they are within some margin of error, accept the clients results and otherwise use its own. Again: In 99% and more there won't be any difference between the methods.
As another feature to improve the sync I added a no RNG game rule, which will make the towers always dead their average damage on every hit, and they will crit in regular intervals based on their crit chance. If the game rule is turned on this would also eliminate a lot of desync issues resulting from different RNG results, the rule is not completely implemented yet though.
While working at the multiplayer protocols I also added the ability to recognize client disconnects and player deaths, at the moment a client disconnect is the same as death - I may need to add rejoining later. Dead player obviously won't spawn any more entities and cannot build, remove or upgrade towers. Unless the death was caused by disconnect the player may remain in the game though and spectate. When a player dies the player himself is shown a new Game Over UI and all other players get notified in the chat that the player died.
Continuing with some of the overall game logic improvements from yesterday, I had another look at the path finding. Up until today the path finding was its own game state between the building and wave phase, but I realized that this wasn't really necessary, the path finding could be done in the wave game state before the mobs start running. So I removed the path finding state and changed the entity spawning to wait a short amount to give the path finder time to finish. With the current map and the small number of towers I usually place for testing the path finding only takes a few milliseconds. However, when there are more towers and possibly even larger maps, the path finding could easily take over 16 milliseconds, resulting in a minor freeze, which obviously isn't desirable. Therefore I changed the path finder to be run in a thread.
Then I finally went ahead and implemented the game logic for the shop. The shop UI now displays the items that are in the game, and when purchasing an item it gets broadcast to the server and all clients and everyone calculates the effect of the item.
Just made another tower model and added it into the game:
by Christian - 10.03.2019 - 12:11