Still working with the level editor, since we underestimated just how time consuming the process could be.
Another problem became apparent at the play-testing session last Monday. There was no way to test the actual levels. The lead programmer wasn't able to generate the levels via the TXT's until a few hours before the session. And so, testers would see weirdly placed furniture, empty rooms and run into invisible walls. Another problem was that if an object would be set so that the light wouldn't affect it, it would turn invisible.
The misplaced objects was an easy fix, but testers also complained about lacking level design. Saying that the levels were too void and that they entered the game not feeling motivated enough. The goal wasn't obvious and the NPC's weren't threatening enough.
It's true that there really isn't much that motivates the player to hide from the NPC's and get to the exit safely. After testing the game personally, I noticed that it was too easy to outsmart(-run) the NPC's. This might encourage players to just rush through the levels, rather than staying hidden.
How do we fix these other problems?
One suggestion might be the use of a time limit. The player has a certain amount time to complete the objective and find the exit. This might motivate the player a little more to reach the game's goal. This however might not motivate them to make use of stealth, but rather give even more reason to rush through the level.
The NPC's needs to pose more of a threat. In order for the guards to shoot, the player needs to stay within the guards line of sight (flashlight) for a certain amount of time. This is usually enough time for the player to escape and get out of their line of sight. If succeeded, the guard will simply spin around and later continue with his usual patrol pattern.
A suggestion to fix this, is to apply a permanent consequence for being spotted. This was suggested early in the development. The guard will report to the others on the level and every other guard will start to look for and chase the player.
The problem with this solution, is that the stealth gameplay would come to an abrupt stop. There would be no room for mistakes and the difficulty would be raised immensely.
If the player was able to hide from the guards and there would be a cooldown for the alarm raised, it would be less of an issue. However considering the difficulties of programming AI and the amount time left on the project, it's not likely this will make it into the final version of the game.
There's a lot of problems, many not even mentioned that needs to be fixed. Many of these problems weren't even noticed by us, until the play-testing session. Which proves even further the importance of proper outside play-testing.
Hello Gustav,
SvaraRaderaIt seems like you hit some roadblocks with your games core gameplay? May I ask what your key features? Since it seems like you have stealth as a key feature, but still there is a suggestion for a time limit? Surely it is a suggestion, but considering that stealth seem like your key feature I have a hard time imagining why that would even be a suggestion. Also, how long is the delay for the guards? Because with such an unspecific expression as “a certain amount”, the amount can literally be any time frame. If you leave the reader in the dark with such information it is easy to underestimate or overestimate how long the delay is, since I first thought it to be several seconds. Which seems like a bad idea to begin with. Another thing with the guard NPC, why would it spin? It just seem so random when you read it.
Something that I was confused with was whether you created the level editor or just worked in it? A quick recap of previous post that are related to the level editor, would be helpful, so that I do not have to guess which of these you were doing.
I hope you can manage to fix the NPC and I am looking forward to see what becomes of our game.
May I ask what your key features are*
Radera