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 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.)
Planning. I feel I didn’t do enough in the beginning of this unit. I didn’t really have an idea of what exactly I was going to be producing to be graded. This in turn meant I was having to come up with plans and ideas later into the unit when I was supposed to be producing said things.
Design. I think I left the designs a little later than I probably should’ve, despite having them in time for the modelling. I feel I should’ve started them sooner as that would’ve given me time to be more creative with the designs. In the future I will be drawing designs before writing up their character profile because writing a profile puts a certain image in my head that I then find hard to deviate from when designing.
Modelling. I definitely needed to spend more time modelling than I did, especially if I want to have a more detailed model next time. I also need to practice modelling more as I’m alright once I get into the groove, or if I’ve modelled something similar before, but I struggle to know where and how to start something new. This struggle is probably why I don’t realise things such as putting the faces of a cube onto a cylinder instead of rounding out a cube until after I have finished modelling it. I also need to learn to be ok with things not being absolutely perfect to begin with as I think that contributes to the starting struggle. I made one model for a blend shape but I should make more next time as I feel that would incite me to actually try to use blend shapes in the final render.
Rigging. Setting up the skeleton went well. I had no problems with that. Weight painting was annoying as I would finish painting all of the joints and then would find they had repainted where they shouldn’t when moving joints around. This was frustrating as it meant I had to spend so much longer than anticipated trying to fix this. I can see how inverse kinematics are useful and I will definitely use them in the future, they just didn’t work with this particular model.
Animation. Having a plan for the animation before I reach the animation stage would be a good idea. This would allow me to use a mocap studio effectively. Even if I have a model that isn’t humanoid, I could still use the studio to get motions for specific parts of the model instead of forgoing motion capture and keyframing everything. I could also use the studio to film actions and use those as references for keyframing to get more fluid and lifelike animations.
Overview. All in all the finished render isn’t too bad, in my opinion. The main improvements look to be about planning early on and extra time management for more detailed areas.
I have found the Inverse Kinematic handles to be counterproductive for this specific model as they stop me from moving the tentacles any way other than how the IK handle is set up. This meant I couldn’t move any joints inside the IK handle without completely screwing up the tentacle. So I removed them and have had to key frame each joint individually.
I made a plan for what I wanted to happen in ~15 seconds for the animation.
I was able to animate the entire sequence by keyframing the most important parts first to give me a solid base to then keyframe everything else around them. I didn’t end up adding blend shapes or blinking eyelids, so you do have a wide-eyed squid staring you down. The eyes don’t move separate from the head either in the animation, which Icompletely forgot about until now. Altogether the animation is 460 frames at 24 fps, making it just over 19 seconds long, which ain’t too bad.
Keyframing without the Inverse Kinematic handles wasn’t actually that bad once I got the hang of keyframing. Just getting the first 3 seconds done probably took me longer than the last 16 seconds due to trying to figure out how to get it all to work how I wanted. However, I think I actually did a pretty good job keyframing. I particularly like watching Mr Squid tilt and scratch his head, purely because that is the first part that I thought I did a really good job at animating.
