Devlog 1 - v0.15.0

Hello world!

Though im not sure how many people read devlogs on itch, i want to document some things i learned/did since i started developing Plunderground in Godot. So lets review each notable topic.

Performance

Since starting in september 2023, the biggest issue was performance. This was my fault as a dev just learning and experimenting with a new engine, having no regards for scalability and just trying to make things "work somehow". A lot of mechanisms were foolishly put in process functions that would fire every single frame, which is as stupid as it can get. Of course, when starting out one doesn't want to deal with all the necessary stuff right off the bat, like saving/loading games or persisting (procedural) levels in a smart way, so i also didn't delete any generated levels/creatures when changing scenes, everything stayed in memory. Horrific really.

So processes were converted into more reasonable signals that would only fire when necessary and a save system was implemented. However there were still issues. Some were (and still are to some lesser extent) caching problems of the engine. A minor freeze when the first arrow was shot or a new kind of item dropped is typical for Godot. This is now mostly remedied by just briefly instancing all kinds of game objects when entering relevant scenes. But there was still lag in some situations. Turned out it was two more dumb things that were buried a bit deeper in code: Firstly, nav agents for entities were relentlessy calculating safe paths, no matter what. That was also the case when someone just stood still and didn't even want to move. Secondly, the pla,yer input was suboptimal. To reflect a certain priority in interactions, there were 4 seperate raycasts to determine what would happen on a click. So for instance, if an enemy stands on top of some loot, the enemy gets priority. The same was supposed to happen when the enemy is covered by the hitbox of a door, so just picking the thing closest to the camera wouldn't work. The issue for the performance here was the unconditional execution of all 4 possible raycasts, which can get expensive quickly. A sane person would just cancel the rest of the raycasts if a higher priority one hits an object.

Other minor optimization things like removing non-visual nodes on characters when they are dead were also made. In total these changes made it possible for me to boot up the game and play it on a pretty weak Lenovo laptop that only has an Intel Iris Xe graphics card, at least in the dungeons. The starting area seems to run at a constant 50 fps or so, something to look at in the future. 

Graphics

Before starting this particular project, i was rather trying to do something in 2D using sprites. Now that i spent a lot of time doing 3D models in blender im probably never going back. Despite the additional dimension, 3D asset creation is just so much faster. Luckily i chose an art style that utilizes almost no textures, which also speeds it up a lot! Still i made some mistakes early on and just imported some models without regard for polygon numbers. That almost melted some laptops because there were a few million polys at the start for the mountain wall, which i made using some subdivision and displacement modifiers in blender. Oops! Anyway, going forward most assets will be pretty low on poly counts, with most characters maxing out at around 2k. The 2D art for UI things are still an experiment and a lot might change, but at least its not the default grey boxes anymore.

The levels themselves are pretty much procedually generated and all use a grid system to be put together. Even the unique locations like the starting town are built at runtime using a pre defined grid. This way its easier to standardize pathing and other stuff related to the ground. Unfortunately this will also have the effect of a more squared look. Procedural rooms in dungeon levels are populated with clutter and furniture objects based on their room designation. So a storage room will have a chance for chests, weapon racks etc. while a hallway will have less interactive objects and gets more braziers and decorative stuff. Of course, this system needs to be fed a lot of objects to make it really alive and there is just a few at this point. To increase the amount of decorations will be an ongoing endeavour for future updates (luckily a lot of things can be recycled for different contexts).

Mechanics and Gameplay

Starting out as a clone of Diablo1, a lot of diverging choices were made. Hit chance? No, i don't like that. Armor functions differently, hit recovery too. The latter was depending a lot on level difference and amount of damage received in Diablo and seemed a bit harsh and random when imitating. Instead theres a poise stat, that slowly refills on its own. Once at 0, the character is stuck in the hit recovery animation and the poise recovers fully to prevent a stun lock situation. It also scales from vitality, just like hit points. 

The big divergence however are the companions. Inspired by the mercenaries of Diablo2, companions with their own equipment slots were implemented. Up to 3 companions can be brought along (there is currently only 2 however). These companions can be toggled between being aggressive and defensive, which seems to be necessary to prevent them from doing stupid things and have a little bit more control without overtaking them completely (i didn't want to clone the Dungeon Siege system). Tied to these "stances", they can learn skills. To do so, each companion will get 2 unique skill trees (Diablo2 again!). Each skill node, both active and passive skills, will also boost base stats. This way the player wouldnt have to deal with allocating 5 points per character in the party and it makes those companions feel more unique. Want to max out strength on a sorceress? Well, good luck with that...

For even more uniqueness to them, the way to unlock them is borrowed from CRPG games. You will have to find them and maybe do specific tasks/quests to recruit them. Said sorceress for example is held hostage by the first boss like enemy. Once slain, she is freed and can join the party. Possible future updates may include banter between specific party members, spontaneous dialogue at specific locations and stuff like that.

Future plans

Balancing of course. Things are conceptually implemented right now, without much experience on how the pacing is for the average playthrough. Stat scaling has some question marks left, like what will magic do apart from increase max mana? One idea is to increase the possible summons of that character by 1 for every 15 points in magic or so.

Theres the idea to give each party member a pet. Im not sure yet how to do that in an elegant way. They cannot be full blown combat participants, as you will quickly become a warband too big for any enemy encounter. A party of 4, each possibly a summoner can already make it 8. Add 4 pets and it is 12. Scale up the number of summons and its growing almost out of control (which might also be fun if done right). So there should be something like a tradeoff for having a pet. And to add to that, what will distinguish each pet from another? A passive bonus? Different behavior? In a perfect world, there will be viable builds to go 100% solo, be the biggest summoner crowd possible or to do something sensible in between.