Week 12 - Prototype End

Line of sight

I've coded in the line of sight mechanic for the enemy. All it does is if the enemy is chasing the player, and the player happens to break the line of sight, via raycast, then the enemy will move to the player's last known location using the pathfinding system I set up. If the enemy doesn't see the player after it arrives at the last known location, it will simply go back to it's normal patrol routine. This addresses the issue where enemies were getting stuck on walls, although it would still be considered kind of dumb for an AI to simply forget that the player is gone immediately after losing sight of them, so in the future I would revamp this system so that the AI searches around for a bit before going back to normal patrol.

Speed Balance

In the last blog, I stated that I would change the speed of the enemy to be faster, but actually its not fun and it doesn't feel too fair, even when the enemy is at the same speed as the player. I think that the problem with the last build was that I had the right idea of making the enemy slightly slower than the player, which gives the opportunity for the player to escape, however, the speed of the enemy wasn't cutting it close enough to provide a challenge, so my participants were just treating it like a joke. I've increased the speed of the enemy so that the enemy is still slower than the player, but faster than it was before, and it feels just about right, and running into enemies is now more of a risk, because I'm using rigid-body movement, it takes a slight amount of time to slow down and run in the opposite direction which means that if the player isn't careful, they will get caught if they run into an enemy.

View Cone Balance

In the last blog, I determined that the view cone was slightly too short and too narrow, so I increased the range and angle of the view cone by altering the scale values of the gameobject associated with it. I actually found that I needed to be careful with how much area the view cone would cover as I ran into a visual design issue that I did not expect. I'm using lights to represent the view cone so players know what the enemy can see. Increasing the view cone too much actually makes things look a lot uglier and becomes irritating to look at after a short amount of time. I played around with the values and I think I've managed to find the right values so it isn't as irritation. In the end, I think the view cones feel just about right now and its become harder to fool the enemy.

Project Conclusion

I think that I have now reached the conclusion to the project. I think the prototype shows that procedural generation can work in the context of a stealth game. I think that I managed to show that even with just 5 different level layouts, you can still be caught off guard by the unpredictability of procedural generation, and with more level layouts this would be the case even more. I believe I did a really good job on the creating the context in which to test this system. The AI works pretty well for my first time coding a proper AI with different states, especially for combining the kind of systems that an AI for a stealth game would use with procedural generation. Overall, I think this has been very successful and I might continue working on this and make a game based off of it.

Future Steps

The whole point of the prototype was to prove whether a procedurally generated level system would work for a stealth game in order to fix the issues of replay value, and if it didn't, to investigate what adjustments I could make if there were any so that it could, and I think I've proven that it can work in this prototype, however, there are so many more avenues that you could go down with procedural generation. Over the past week, I've thought about the exploration aspect that procedural generation can provide and I've thought about a new system that could be added on to this one, which I like to call "Heaven and Hell" (although its got nothing to do with religion). The idea is that you have these various layers that are accessed by travelling upwards to "heaven" or downwards to "hell" via stairs or an elevator. In the context of the wider game, the player motivation for using the mechanic would be that certain items that the player can collect can only be accessed in heaven and hell. This mechanic is inspired by the ore spawning mechanic in Minecraft, as certain ores will spawn at certain y values in the world. The way it differs from Minecraft however is that heaven and hell have different level makeups. I imagine heaven being a more platforming based and adds in new obstacles while hell is more avoiding enemies focused and adds in new enemy types.

I think a system like this would balance out the whole randomness part, as it might not be as fun to wonder around aimlessly whereas with this system, I could give something that the player can predictably control which would enhance the exploration aspect I didn't think about.