Giles Penfold

Dungeons, Dawns & Deviants: Progression Page

Any updates on the progress of the game will be added here.

Game "Feel"

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.

Ilith Joins The Party

While I've been working on my other project, Ross has been steaming ahead with the character art. Fendarr has had his attack animations updated to fit in the up and coming combat system, and his best friend: Ilith, has joined him in the dungeon. We've based her pixel form from the design documents of her D&D character and Ross has done a wonderful job of matching the style with Fendarr and the rest of the game. We'll soon have a full animation set for Ilith within the coming weeks, which I'll update here.

While my attention has been directed towards my research and self improvement project the past few months, I have been working on adjusting the dungeon generation and AI to be more efficient and adaptable to what I need. The dungeon rooms originally would be completely randomized, however, I know I always want a shop room and maybe some secret rooms thrown in there, so adding elements of art direction in there is incredibly important. I'll be updating more in the coming months with any significant work on the game, mostly art assets being added on Ross' end.

Save States

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.

Idle Animations & Destructible Objects

Just a small update while I have some free time before my thesis hand in. Fendarr has been taking out his frustration on the local barrel population of the dungeon, by rolling into them and seeing whats inside. Usually Dusk Shards, which he can at least use to buy something nice back at the camp.

I've been focusing my attention on populating the environment with fun objects to destroy, as I noticed myself just running into these things in Enter The Gungeon for the sake of seeing them fall apart and the satisfaction that it gave. These are just a working prototype that drops objects randomly from a loot table, but I'm hoping to get rigid body collisions working with the debris soon too.

Ross has completed another set of sprites, this time: idle animations. We have Fendarr being able to look sassily around the room and yawn at the lack of enemies that are currently there. I made a randomizer that will select a random idle trigger from a table and run it with an acceptable distance between triggers so that he's not looking like a narcoleptic. I've also implemented a system of tracking his activity in the dungeon, where he'll breathe heavier after running or attacking for longer periods of time before slowly returning to his natural state.

Main Menu

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.

Minimap & Map UI

Fendarr has been having trouble figuring out where he's travelled in this dungeon. It's almost like it was built by a madman! Good thing he has his trusty map with him to mark down where he is going and what to do next. Hopefully he'll get that moisturiser soon.

The map is made by placing an additional camera above Fendarr that follows him around, with additional meshes beneath each of the maps holding the same material (in this case, a golden unlit material). A sprite of Fendarr's head is also placed above him so that he can be tracked on the map. All these objects are set to a "Map" layer and rendered by the camera to a texture. The minimap will display in the bottom corner, with the big map displaying when the tab button is held down.

There has also been work done on scaling the UI to different resolutions as I noticed it would stay in the defined pixel space when going into fullscreen mode. It should now correctly scale to all(most) resolutions.

UI Updates & Items

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.

Special Attacks

Each playable character will have a special attack that can be upgraded in some way. Fendarr's special is "Eldritch Missile", which will spawn a number of missiles that will seek in on the nearest targets. He will eventually be able to upgrade the number of bolts he has, the damage they deal and a number of other additions to keep him alive whilst trapped in the dungeon. He's at least slightly glad that the enemies haven't figured out how to get into the spawn room (yet).

Dungeon Creation

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.

Ross Joins The Development

One part of this project that has been incredibly tough for me was the creation of the pixel art. The tilesets I have purchased in, from an artist called Elisha Ramos, have been incredibly useful in helping me attain the atmosphere I need in the game. For the character art, however, it is a very custom thing, with the characters being based on my players characters from my D&D universe. I have very basic knowledge of pixel art creation but that could only take me so far.

After talking to some friends and mentioning that I was looking for a Pixel Artist, I stumbled upon Ross by accident through a mutual friend. Excited to help out with the project, Ross worked hard to get some initial concepts done for Fendarr to preview what style we might like to use. After deciding on the style (highlighted in red on the image), Ross has started work on the character assets for the game. You can find his Artstation page here to check out his other cool work.

A* Pathfinding

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.

Attacking and Dodging

The Dark Souls universe, alongside Witcher lore, has been a major influencer in my D&D universe, allowing me to create a gritty, mysterious and believable world for my players to enjoy. The games are good fun, but what really intices me to them is the lore of the worlds. Good stories have good lore, which is a philosophy I strongly follow. The story for DDD is yet to be written, though I do have some ideas already based off of villians in my universe already. One that I'm sure my players would hate to see return is currently taking the leading role in my mind for the tale to be told. But that is a digression.

Looking back at the two games, they have many things in common, but the one I am looking at is the combat. It is fast, it is visceral and it is deadly. Even in the differing medium of 2D pixel games, I feel that can be encompassed, which is my ultimate goal with the combat in DDD. The first steps have been made towards that combat with some basic attacks and dodging for the player character, though I plan to give them both more depth as time goes on with the project. Rome wasn't built in a day, and a game wasn't built in one either.