GameDev 2019 Week 14: Arcs

Fixes, Arcs, Tests

07.04.2019 - 18:40
Monday 01.04

Today I completely finished the game!

Oh, wait, it's April 1st, nevermind then... Instead I had to finish the blog post from last week, because I didn't yesterday. Then I experimented with a bunch of settings for my lightning beam creator and finally found one that looks decent in the game. And I also added a gold reward when completing a wave.



Tuesday 02.04

I started the day by creating a cattails model for future maps, because I felt like creating a model and because I didn't want to start with my actual task for today which was having another look at the network protocol and fix it. But finally, I forced myself to work on it and I realized that I never actually called the init() function of a class that was needed for the current version to work properly. It was still working, but not in the way I intended it to. However the code was messy anyway and some parts were unnecessary. At the moment the only server authority rule that is implemented is the trust client rule, which means the server will accept whatever each client tells them about their performance. This is very prone to cheating, but I can add additional rules where the server checks against it's own simulation results, and if you are playing with friends, you probably wouldn't want to cheat anyway. The main reason for the trust client rule is that from the clients point of view its own simulation will allways be correct. As mentioned, the server runs its own simulation, but if it is going to trust the client anyway, there's no point to simulating the whole game, so I added a switch so that the server doesn't simulate any entites or projectiles when using this game rule. And I also rewrote and cleaned up the implementation of the rule. I tested the new system with multiple local clients and it seemed to work better than before. However, I noticed that the path finding was messed up in multiplayer games, so another annoying task for tomorrow.

Wednesday 03.04

The messed up path finding kinda looked like a memory issue, overflow, reading from the wrong part, etc, because such bugs have had similar appearances in the past. So I spend a lot of time looking where I could have produced such a bug, but wasn't able to find one. After looking and thinking for a while I finally came close to the real problem though. I had changed the path finder to having one per player in its own thread. But my implementation of A* wasn't really threadsafe and was using the nav mesh nodes to store values and the pointers in its open and closed lists, which is very efficient because I don't have to allocate any memory, but if there are multiple threads writing to the nav mesh at the same time it's going to be bad. There wasn't really an elegant solution, so I changed the path finder back to a single, but unique thread, e.g. version 1 was the main thread was path finding, version 2 was one thread per player and version 3 is now one path finding thread which handles path finding for all players.

After the path finding worked correctly again, I could finally do something else, so I added two more projectile types to the game, a stone and a cannonball. I also added another rotation axis for projectile so they can now have backspins when flying to make it look more realistic. For a long time I wanted to add an arced projectile route, bascially a throw, to the game, so I started to work on that. And all the physics I ever had payed out, because I was still able to figure out the movement equations for throws and could make the towers throw a projectile to a specific point, where the entity would be in 1 second, so I also had to write an entity position predictor. It works pretty good, but if the entity unexpectedly gets stunned within that one second it won't reach the predicted point and the tower is going to miss. So this is basically a skill shot.



Thursday 04.04

Today I created an access code system, that can be used for all kinds of programs. The idea is that if I give out a test version of the game to some people I have a way to disable the versions remotely, because it wont be compatible with newer version anymore. On startup the game just asks a server whether its version token is still valid and if it isn't shows an error. Then I designed a background texture for the ESC menu, which can be brought up by either pressing the menu button or pressing ESC obviously. I also added a quit game and a main menu button to the ESC menu. However, the main menu button doesn't do anything yet.



Friday 05.04

I still had to upload the access code system and make sure it also works on the server and doesn't break anything. Then I added a projectile gravity value to change how high the arc of projectiles is. This got me very confused for a while though, because increasing the gravity caused the arc to be higher instead of lower. I finally figured out that because of the time constraint I am using when calculating the initial velocity that behavior would occur, it's a bit weird, but there is a way to change the arc height and that's what I wanted so I am fine with it for now. Then I did a release build of the game again and copied all the data that is actually needed to a folder and put the exe in there and it still worked, yay :)

Saturday 06.04

The second thing that needed to be done before trying the game with a friend was a linux build, so that the game server can run on a linux server. And even though in theory everything should be cross platform, in reality it rarely ever is. The build went quite good, only minor changes were needed until gcc accepted everything. But when trying to start a game on the server, the exe instantly got a segmentation fault when trying to open a file. After checking the function and reading over it and missing the mistake at least 50 times, I noticed that one value was read using fwrite, which doesn't make any sense at all ^.^ yet another copy paste mistake ^.^, I only wonder why it worked fine under windows? My assumption is that windows realizes the file is opened in "rb" ( read binary ) mode and when fwrite with 2 bytes is called it just advances the file curser and the rest is fine, while linux doesn't advance it or even ignores is and writes random bytes to the file. After fixing another "not implemented for linux" warning from my code, the server ran and I was able to connect and play a game.
Then I send the game to a friend to test it and try real multiplayer. The first version of the exe still had debug information linked ( I have no idea why, I didn't check it, but whatever ... ), so it didnt start, but after fixing that, it worked. However the game seems to run extremely slow on his system ( comparable in specs to mine, but an AMD card instead of my Nvidia ), and I mean extremely, 5ms+ per frame while mine never really got over 0.1ms, I have no idea what's causing that. And his game also crashed, and the last random crash I had when testing locally was weeks ago. This is going to be annoying to try and find out why.

---