Taking a break from Wands for a day, I ended up watching an incredible talk on game design focused on 2D pixel style games (although a lot of the concepts can easily transfer across to other games!). It's called The Art of Screenshake by Jan Willem Nijman from Vlambeer. They've made some incredible games and each of them have the "Vlambeer Effect" which is a certain way the game "feels". It's incredibly interesting and I'd highly recommend anyone who is interesting in game design to watch.

Taking inspiration from Jan's example, I went and implemented some of the elements into DDD. Camera shake, explosions, faster projectiles, more projectiles. And it actually works. The game FEELS more fun to watch and to play, even though I'm just shooting projectiles at a wall. I'm hoping to add some more things like this into the game, such as enemy explosions, permanancy of corpses and projectiles, and a more horde-like enemy AI.

I've finally got back from holiday and started work on the game again. The first thing I wanted to do was implement some form of save state for the user, so they can save and load their progress and switch profiles if multiple players are using the game. I've currently implemented 3 save slots, which will save the state of the user. This uses binary save files with minor compression, and hopefully will extend to saving the state of the current scene the player was in, so they can back out at any time and return to the game as it was. The next step for this will be implementing some form of seed in the dungeon generation so that this process can be made simpler to debug.

I've been working on implementing a basic main menu and options menu this week. The work wasn't necessarily tricky, just slow to get working as it involved reading through a lot of Unity forum posts to figure out ways to grab user settings (which get stored in some very odd places). There is also some music that plays, which cannot be heard in the gif :( . It works well for what we have at the moment and will be updated at a later date as multiplayer options start becoming available. I have been dabbling into the Unity multiplayer API, which is quite intuitive for the most part. I'm unwilling to add too much more to the game before getting multiplayer working, as it seems to involve a lot of modification to current code. This will hopefully progress more after my thesis is finished at the end of August.

We finally have a reasonable UI to work with as well as a currency that will be dropped by monsters and used to buy upgrades. The player has 3 hearts, which split into halves (so technically they can survive 6 hits), as well as a dodge and special attack countdown timer to let them know when their abilities are back up. Fendarr is surprised to see that his Eldritch Missile seemed to have a cooldown time, which made him much more nervous about heading into the next room. As the player gains more abilities, these will be added to the list. There is a currency counter in the top right of the screen, which displays the total amount of global currency the player has collected.

The global currency in DDD is called "Dusk Shards" and they are based on the same items in my D&D universe. I will soon be implementing NPCs who will provide upgrades to the player, their arsenal and the dungeon. I expect Elyse, the guild blacksmith, to become the first NPC within the game to be accessible with further confirmed NPCs being Bradley, Penelope, Fidus, and Charlos.

This was one of the big challenges that I've faced so far in the development of this game. I knew that I wanted to have a set number of room types to spawn, which left me with figuring out how to place them and chain them all up. After a long few days of trial and error, reading and debugging there is finally a robust dungeon generation system that can be customized to any room types I give to it.

To simply describe how the system works: First it places the starting room for the dungeon and a connecting corridor. It will then search for any unconnected corridors (at this point, only 1) and will look for a valid room to attach. It will then join them up, and spawn corridors to the available exits of that room. Each room was created with the rule that it must have at least two points of entry for this purpose. It then continues the cycle until it reaches a maximum room count, or runs out of corridors to attach due to the placement of the rooms not allowing it to do so. It then removes any stray corridors that could not be attached to a room, plugs the holes in all the rooms that have open exits and checks that we have a minimum required number of rooms. If we do not, it scraps everything and tries again, and since the process is extremely quick, this doesn't take much time at all. After the rooms have been generated, their A* maps are then created and all other processes go ahead within the individual rooms.

A* pathfinding is not unfamiliar to me, having already implemented it into my Fractus project last year in a much more complex 3D environment. This time, however, I wanted to refine it slightly more and to fully understand what was happening and why, which I hadn't fully grasped in Fractus. I started off generating the nodes for my A* map, followed by the map itself. Each room in the dungeon shall be given its own map and pathfinding coroutine, which enemies in that room will follow. As enemies do not travel between rooms, they only need to know about their rooms pathfinding map, however, to move them to a new room would simply be a matter of retargetting their pathfinding manager.

After this was done, I looked into threading the process further using coroutines which handles multiple enemies at once, moving them along fragments of their path at a time within the same space. This path that they track through the room is then smoothed to seem more natural. In the image, the green dots indicate viable nodes within the map and the red dots indicate unwalkable nodes. There is still more I wish to do with the algorithm, however that will come later when I return to the creation of enemies and their logic systems.