I wanted to have a save system for the game when I started and I got a very basic one working using a binary formatter. I wanted more complex save data though and that obviously required more complex setup, which I didn’t end up doing, leaving save data partially developed. A binary formatter can be used to save simple data such as int, string, float variables.
Magic
Another combat mechanic I wanted to implement was magic. I didn’t figure out how I wanted it to work exactly, but I did create some custom particle effects that would be triggered when casting.
Procedural Room Generation
The random generation of the game was meant to include the spawning of random rooms, but I didn’t spend the time to figure out checking where the door ways were in a room prefab. The base random generation is already in place due to the random enemy generation, but random rooms requires a lot more complexity than I could be burdened with at the time.
Potions
Another combat mechanic I was originally wanting was potions and grenades. Simple enough to implement, and they would use the same generation as the weapon spawning, but I didn’t have the time to complete this mechanic.
I wanted to have an AI for the enemies to make combat that much more interesting on top of the sword mechanics. I followed the below playlist create an AI but quickly found out the videos leave out a lot of scripts and lines in shown scripts tat make the rest of the code useless without.
I got very frustrated with this and spent countless hours trying to find any clues in every video, even the ones I wasn’t planning on using in the first place. I spent way too long on this and gave up many times before coming back a few days later to try again. I eventually started making progress and filled in some blanks but theyy wwerentenough to get everything working properly. So, time for the not-so-good-looking option.
The videos show capsule colliders on most of the bones, but I simplified it so there are only two box colliders, left and right, to detect when you hit the enemy. The detection triggers an animation depending on where they got hit. The video version would blend the animations based on how close to the centre of the character the collision occured, whereas my version doesn’t blend at all.
Through a lot of trial and error, I figured out a way to make sure an instantiated prefab could detect a collision on itself and not other copies, and activate animations in it’s version of an animator without triggering those of another copy. I ended up using four scripts for this; one on each collider, and two on the parent gameobject. One script on the parent will look for, detect, and chase the player. The other script on the parent is used for storing variables to be accessed by the scripts on the collider gameobjects. Each collider script will detect when their respective collider has been hit, will play their respective hit animations, and will disable both colliders until they are ready to be hit again. The videos below show player detection, hit reaction, and enemy behaviours.
The white circle and yellow lines are done in an editor script in the editor folder so they won’t be used in a built version. This is useful for when you need to see something in the scene view but not in the built game, such as a detection radius.
Before I actually got this to work, the player detection and enemy behaviour was quite different. One version is the player would always be detected and looked at but would only be chased when within a certain range. The other is the player would only be detected within a certain range, but there was no way to hide whilst in that range and you would always be chased. Below are videos to show these.
As you can see with the first video, for some reason the enemy would lean over as the player gets closer, leading to some interesting results.
For me to want to repeatedly play a game I like to have different experiences each time. You can have the same basic story but with different encounters/mechanics, or the same encounters/mechanics with different stories. Customisation in games really helps with this as you can change your play style and enjoy a game that way too. One way to change the experience every time is to have procedural/random generation – terrain, enemies, items, or just about anything you can think of. Using a computer doesn’t make generation random exactly – everything is determined by calculations – but it’s pretty close and gives the feel of randomness, which is more important. I used the video below to create a script for generating random coordinates within an area of my designation and for prefabs to spawn at those coordinates.
You can see it working in the video below. The white cubes are to show the corners of the spawn area. The script is setup so each element in the Enemy Types list will correspond to the same element number in the Enemy Spawn Counts list and will use the number in the spawn counts list to spawn the prefab in the types list that many times. The spawning coordinates are all random between the parameters set, and even the rotation can be changed.
I made a modified version of this so you can choose the points you want an object to spawn in, and it will choose an object randomly from the list given to it. I used this to spawn in weapons for the player to choose from to vary their experience more.
I really dislike the current popular method of melee combat/interactions; most objects don’t feel like they have any weight and they can move as easily and as quickly as the controller can. They also pass through most objects in an environment instead of receiving force based on object size and weight. This would be solved with force feedback if it were widely available and safe, as that much force to stop a sword could easily break an arm if done wrong.
Evan Fletcher devises a way to create a more realistic feeling of feedback from an object with the current limitations of VR. He doesn’t show any of the set up he did except for the settings on a configurable joint. The rest he vaguely mentions as bullet points for what needs to be done, leaving me to figure out what he means and recreate to the best of my ability. Weeks later after ignoring this for some time trying to find an alternative, I finally sat down and had a think. First I tried to interpret the referencing of his Unity scene setup, before then creating a C# script to crudely run through the bullet points presented by Mr. Fletcher. These are what I came up with:
The wrist prefab has the configurable joint on it and is instantiated by the script when you pick up a weapon. The wrist object becomes a parent to the weapon object and a child to your xr rig hand/controller. When you drop the weapon the wrist prefab is destroyed, but the weapon stays.
This worked, somewhat surprisingly, but I know there’s things I haven’t thought of when deciphering Mr. Fletcher’s notes.
For this project I wanted to create a VR game as I am more interested in video games than virtual experiences. I am highly fond of the fantasy genre, in particular medieval fantasy, and so I made that the theme of my project. A historical fantasy version of medieval Europe. I then needed to think about what type of game I wanted to make and roguelike kind of just kept coming back to me. I have played many roguelike games and I enjoy them very much, so I just went with it. I haven’t played any VR roguelike games but I have played Hades, The Binding of Isaac, even Pixel Dungeon on mobile, and many others so I already had a pretty good idea of some things I wanted to include.
To justify making this game and why it would benefit from being in VR compared to on a computer is spatial awareness. Roguelikes are usually played from a third-person or top-down view, meaning you can see things the character you’re playing shouldn’t be able to and react differently because of that. A roguelike in VR would restrict your spatial awareness incredibly in comparison as you can only see from the first-person perspective. You would have no idea if anything were behind you or around the corner unless you turn around or hear a noise. It adds that extra fear and suspense.
I was planning to make my own assets and characters at the start of the project, however I quickly got busy with other work and put this project on the backfoot, thereby running out of time to make any and have enough time left to make the game. I did come across the UMA Character Unity asset pack and tested it out a little, but I quickly forgot about it amongst all the other things I needed to do and I ended up just using a bunch of pre-made assets from the Unity Asset Store and Mixamo.
For weapons I used the following:
LOWPOLY – Weapon Pack Demo by IV team (Unity Asset Store)
Low Poly Weapons by SICS Games (Unity Asset Store)
For characters I used the following:
Dragon for Boss Monster : PBR by Dungeon Mason (Unity Asset Store)
erika_archer_bow_arrow (Mixamo Character)
Nightshade J Friedrich (Mixamo Character)
skeletonzombie_t_avelange (Mixamo Character)
Vampire A Lusth (Mixamo Character)
Paladin WProp J Nordstrom (Mixamo Character)
For the environment I used Ultimate Low Poly Dungeon by Broken Vector (Unity Asset Store).
With these assets I came up with a list of rooms I could construct and fill with items and then drew a floor plan. It’s a rough floor plan but it let me start the project.
That rough floor plan was good enough to get by but my indecisiveness meant I actually needed to flesh out the plan before building any more of the project. This next floor plan is the most accurate version that I used to make the layout.
And below is what it looks like top down in Unity. Looking through the ceilings of course.
The original concept for this game was to make a tower for the player to conquer but I took too long with making the mechanics that I ended up with only one level. The name was meant to be “Tower Dungeon”, it is now called “Castle Dungeon”. The setting changed from “Tower Dungeon is a roguelike dungeon crawler set in a historical fantasy version of medieval Europe. The player takes on the role of the Undesirable One trying to make their way to the top floor of Fortitude Tower – a tower safeguarding the power of the gods, said to be conquered only by those chosen by the gods.” to “Castle Dungeon is a roguelike dungeon crawler set in a historical fantasy version of medieval Europe. The player’s task is to defeat the occupants of the castle along with the evil Dragon Lord who reigns over them.” As the setting describes, the objective of the game is to clear out the occupants of the castle along with their evil overlord. You can clear room by room or you could go straight to the big guy.
I came across a lot of issues and challenges when creating this game. The main challenges were to do with the enemy AI and sword mechanics, as described in their respective posts. Those took up a lot of my time trying to figure them out and get them working that I ended up not having the time or even forgetting about getting doors to work properly, or triggers to spawn things in rather than everything at once, and even sounds and menus. I also ran out of time to set all of the objects with interactable events, mainly just to pick up and move them around.
Annoyingly there are some pretty serious issues that have remained in the build upon submission. The player moves around just fine when not holding anything but when they pick up a weapon all of a sudden they can only move in the direction roughly 120 degrees counter-clockwise from where they are facing and at a stupidly fast speed. My guess is something in the custom weapon pickup script or configurable joint is affecting the player incorrectly. The sword wrist either works fine and I didn’t test it against an immovable object, or it looks like it’s working the opposite way of how it should and is moving the object it is touching around a pivot rather than itself. The player detection on the enemies has also stopped working in the build but it works in the Unity project file when you play the scene, so I have no clue what is up with that. You can find videos showing these problems here: https://artslondon.padlet.org/whobbs0120191/i1gut10jra6z46ao.
I would like to develop this game more and bring it closer to the original plan that I had but I’m not sure if I will as I might start a new project and use what I have learnt from this one to make that one better. If I do develop this game more, here’s a list of things I would want to improve/add besides the issues mentioned before:
Add more levels to make it a tower, not a castle
Add more progress attributes (upgrades, lore, difficulties, etc.)
Add friendly/neutral NPCs (e.g. shopkeepers)
Add/finish more combat mechanics (magic, ranged weaponry, weapon stats, character stats, etc.)
