Pickledtezcat Game Devblog

This week I've been slogging slowly through the code to integrate combat in to the game. It's different to the way I did it when the game was real-time, but also kind of similar. A command is sent from the turn manager (a sub process of the main environment which has different functions behavior depending on whether it's the player or enemy turn) to an agent to fire its weapon. That weapon then checks if the target is valid and if it is ready to fire, and then it sends a message to the target with some stats so that the target can process the hits. Of course, the messages aren't really sent, they are just dumped in to a list in the main environment, and then agents pull out those relevant to themselves using their unique id. Each stage is separate from each other. Each process can fail without collapsing the whole game loop. For example if you fired a burst of shots at a target and the very first shot killed the target, the others simply won't be processed. Th...

Yesterday was headache day, so no development. Today was coding day. Found a big BUG! I've been using a dictionary to contain my navigation data, that's to remove the need to recalculate the graph after every run of A*. I just made a deep copy of the original dictionary. I was deep copying the dictionary, then cropping the new dictionary to a bounding box around the start and finish points, by reducing the size of the graph it makes A* run faster. Unfortunately deep copy, or even dict.copy() are very slow operations. So while a long distance calculation of A* was taking 0.012 seconds, the deep copy operation was taking 0.12 seconds! 10 times slower than the A* function. A big drain on resources indeed. (nearly half a second for just six enemies!) So I started by rewriting the cropping function. Now it crops data out of the original dictionary, copying entries and appending them to a new dictionary. Because it only copies entries inside the bounding area this...

I've been working hard but only a few small improvements to show. First is a scene I'm going to use for the main menu: Still Life for game menu from Pickledtezcat on Sketchfab . And an update to some of the light and shadow mechanics for the game: I also worked on the map reveal, you can  see the sections of the map being revealed as the players move through the level. This revealing of the map is mirrored by the mini map, which only shows where you've already been. I had some concept ideas too; 1. multi turn spell casting. I'm going to come back to that later when I know how it's going to work. 2. Auto follow for team mates. That one's easier to do, and will probably be added soon. I found it rather tiring to move all the players around when there are no enemies nearby. I think though it'll turn off automatically when you get to a trap or combat situation.

I spent some time today optimizing and modularizing the script I've been using to prepare it for having more than one player character. I also moved the mini map to an overlay scene. Finally I started doing some tests on LOS. Originally I had thought of using raycasting LOS, as this is a 3d game, I may as well take advantage of the power of a modern PC right? But after some consideration I'll be using the Bresenham line drawing algorithm to check for line of sight in the game and I've also been thinking of how I can use it in path finding. It is rather a nice algorithm and the worst part about it I can see is that it sometimes draws rather ugly lines when they veer near to the vertical or horizontal. Here's an example of the LOS in game: It's just an illustration of course so in the final game there won't be any indicators, the slime will just not be visible to the player. the beauty of using this implementation is that I don't have to do any r...