Jump to content
  • Advertisement

Recommended Posts

As part of my environment design module, I have been tinkering with simple trap and puzzle ideas and have tested out some ideas in Unreal Engine 4. These traps and puzzles will hopefully be applicable in my dungeon crawler level designs.


For my first trap, I have decided to create a version of a classic trap: the dart launcher. This is the first trap encountered in the original Tomb Raider that is not an enemy. This trap is usually intended to damage the player a certain amount per hit without outright killing the player. Darts can also be modified to apply different effects on the player such as poison, stun and sleep; just like real darts!

For my own darts, I have created a dart launcher that can be edited by designers to fire standard darts or poison darts. The darts can also be given different life spans so they do not enter areas they shouldn't. The rate at which darts are fired can also be modified as well as how much damage the dart can do in one attack or over different lengths of time.

Players know if they have been struck by a dart via sound effects. For poison darts, the player hears the dart hit them, then another sound effect combined with a particle system to show that the player is taking damage over time. The poison will eventually run out and the effects will disappear.

The variables in the dart and the dart launcher could have been placed in structures to make the blueprints tidier. I could have also added the ability to edit the velocity of darts to add a new dimension to trap layouts. As for hinting to the player that these flying objects are dangerous, I could have indicated the danger beforehand by having a dart strike an unwitting NPC and kill them. This would alert the player about the potential danger before being put in a position to be hit by one. Currently, the only hint of the presence of darts is the sound of the cannon (standing in for a crossbow or some other dart throwing weapon) firing.


The puzzle is a simple pressure plate that controls the lowering of a door. To make the puzzle more interesting I have added functionality that requires the player to lock the door in the lowered position. This must be done by remaining on the pressure plate to keep the door lowered and firing a dart at the switch beyond the door. The switch cannot be hit without lowering the door.

To hint that the switch, represented by a statue with a torch on it, is interactable, I have added a lone version of the switch to the start of the level. This allows the player to observe the switch being struck by a dart and causing an effect. On reflection, it would have been more useful for the switch to be linked to a door or some other object in the wold to show that these can be connected to moveable objects. The switch’s presence is also not immediately obvious to the player on approaching the door and requires the player to advance right up to the door to see it. This may make it less obvious as the solution.

I would appreciate any feedback on parts I could improve or have missed.

Share this post

Link to post
Share on other sites

What kind of dungeon crawler? Poe/Diablo style or more similar to gauntlet?  Will the traps be a core part of the game or just a flavor?

Edited by AceofSpadesqt

Share this post

Link to post
Share on other sites

During the last two weeks, I have been attempting to rectify bugs and design errors within my level. I have overhauled the layout of the level to give it a greater sense of depth. I was unhappy with my previous layout as it seemed to be a long, linear path that occasionally ascended a little. The new level allows the player to gain and lose altitude and travel into corridors, rooms and larger open areas. The players can now make use of a lift as well as the stairs in the level, to give them a little variety. While the BSP is laid out in a manner that prevents the player from falling through the world and the characters are set to not be able to walk off ledges, some refinement of the BSP is required as players can avoid the door puzzle by walking along the edge of the path and bypassing the wall. The enemies are unable to follow them. It has been suggested to me that I use blocking volumes to stop the player walking off edges as they Can Walk Off Ledge Boolean cause them to hover in mid-air. The sense of depth in the level has been well-received during testing. Testers liked the feel of the world and complimented the ‘clear, concise level design’. Although the level is fairly short, the depth makes it seem bigger than it is. Of course, the depth is not without its problems. In certain spots, the player character was lost behind a wall or floor as the camera’s spring arm does not allow for collisions with objects. When this option is turned however, the camera snaps towards the player every time he walks through a door. This could break the player’s immersion as it is being pervasive.

" rel="external">

When interacting with the world, players feel that the world objects could use some more variety. I currently only have one trap (the dart launcher) that doesn’t involve ambushing the player by spawning enemies. This can be especially punishing to the player for no reason. I added sound effects to spawning enemies but since some of the spawns are happening off camera, the player does not know he is in peril until it is too late. I have begun to adjust spawn points for enemies but some still require optimising. The dart launchers are also inconsistent with the number of darts they fire. I did this to present the player with varying scenarios using the same mechanic to stave off repetitiveness. However, some of the players found the inconsistency to be annoying rather than challenging. This may be an apt position as the idea of this level is to be an early, or the beginning, level of the game. Doors also presented an issue, as I have yet to add features that would allow a player to distinguish between a locked, unlocked or switch-dependent door. The most obvious switch doors are those with flame statues next to them. Even so, players would still be puzzled (this is bad as not all the doors are supposed to be puzzling as they are unlocked) and this was not helped by the first encounter with a switch door being ruined when the player is hit by the trap that is supposed to open the door. Instead of witnessing a projectile hit the switch, the player is hit by the dart and then stands around not knowing what to do about the door. Frustrating. Also, being able to use switches universally for different actors in the world seemed like a good idea. But, using floor switches for both traps and doors often left players unable to progress because they did not want to stand on the switch that up until that point had tried to smite them.

Interactions between the player and enemies are also of concern. Initially, the combat between the player and the enemies looked like a ‘Benny Hill sketch’ as the player could not fire the weapon fast enough (projectiles were also very slow) to kill more than one of the enemies before their position was overrun. In some cases, players retraced nearly the whole level to avoid enemies. Enemies would also spawn and become a large group quickly. Since this is the starting level, I am going to reduce the number of enemies in the ambush encounters and delay their spawning more significantly. The player should not be overwhelmed right away as it might put them off. I am still going to try it this way even though I have changed the rate of fire for the player. The response to combat after this change was very positive. Players enjoyed mowing down enemies as they did not have to keep running away to avoid being swarmed. The enemies were dispatched at a quicker rate, but not so quick as to be non-threatening. One or two enemies might make it to the player’s location and make them think about having to avoid the threat.

The boss, while challenging and not frustrating, is easily exploited with some Dark Souls tactics by standing as close to his behind as possible. The boss is also prone to losing track of the player, even if he is looking directly at them. He can also continue to attack while he is stunned. However, players ignorant of these exploits will engage the boss as I planned and are kept on their toes by having to avoid the ranged attacks and then being chased down after doing so much damage. Players would figure out that the traps at the edge of the area could be used to harm the boss but each cannon has one shot. These shots were often all wasted as the player discovered he could in fact set them off. I will change this so that the cannons may be fired again after a period. Until this is changed, the reward for the player is immediately removed and it removes the experience they should have had of blasting the boss in the face with some big guns.

When tested by my peers, the controls were generally liked. The Resident Evil vibe seemed to be a hit. Having to stand still while firing added a little extra challenge to combat situations that was received well. The inputs for the controls were not an issue. However, testing outside my peer group showed how the controls could be unintuitive to the average player. One player (Dad), could not grasp having to manipulate the left trigger, right thumbstick and right trigger for firing for some time and paid a lot of health for it. He also suggested that the camera should be at a greater angle to make the game more top down. Currently it is at its default setting. He would also have preferred a lock-on system to having to aim manually. All players, including myself, have trouble aiming even when the particle systems on the projectiles give an indication of where the rounds are travelling.

This sounds extremely negative; however, my level was generally liked and the ability to shoot axe-wielding vampires was also somewhat satisfying to everyone. The remaining criticisms I am going to address soon when I begin to polish areas of my level. This includes elements such as: particle effects, sounds, visual clues and meshes. This will certainly help the player receive feedback from the world as they venture through it. I will also have to adjust the positions and activation of existing systems so that the players are not afraid of every door, and can actually observe a flame statue being activated by a projectile so they do not get stumped straight away.

Share this post

Link to post
Share on other sites




Level Design


The texts I analyzed for my literature review offered useful insight into design principles that I have attempted to follow. Ultimately, level design should enhance the existing core gameplay to prevent it becoming stale. However, this requires attention being given to several different elements that must be balanced. One of these elements is pacing. One of the more obvious methods of controlling pace in levels is through enemies. Positions, number type should be considered to control the pace. This is noticeable in dungeon crawlers such as Lara Croft, Diablo 3 and Gauntlet. Typically, the player will only face one or two enemies in his first few encounters. These enemies will also be terrible and of little threat. Thus, I have made the first few encounters in my own game against one or two enemies that only have melee attacks. Throughout the level, the player is subject to more difficult situations. I have achieved this by spawning increasing number of enemies in encounters. I also vary the scenarios by having the player be attacked from the front, behind and from multiple direction.


Of course, the level should be fun to play. The enemy encounters throughout the level, despite the variety in circumstances regarding positioning and numbers, still can be quite repetitive as the standard enemies in the level do not change. No variants of this enemy or other type of grunt is introduced to force players to possibly avoid multiple attack types. The boss at the end of the level is the only change in enemy type and makes for a much more rewarding finish to the level, rather than simply fighting even more enemies with axes.


Attention should be paid to ergonomics as well. The design should avoid presenting the players with scenarios or bugs that they will find frustrating. One of the problems that was identified in my level, by players inside and outside of the peer group, is that the environment itself lacks clarity or hints. Almost every player required direction from myself as it became unclear where to go. One such actor that cause this problem was the lift to the room before the boss fight. The lift platform was at the bottom, out of camera shot, so it was easily missed. Therefore, I changed the way lift worked by changing it from a pressure pad activation to simply overlapping the actor when stepping onto it. Other switches were also moved to be easier to spot as some were hidden at the camera’s edge. Originally, I put in a scenario to demonstrate that flaming statues could be ignited using projectiles as a hint for the door puzzle. Unfortunately, this could be broken and the hint lost if the player accidentally ran into the dart before it struck the statue. Again, this happened to almost every player and then the players would run around looking for a key that doesn’t exist. I removed this scenario and now an NPC appears to give the player helpful tips and sometimes state explicitly what to do. This explicitness is okay as the level design is supposed to be the game’s first level, where such direction can be expected. Another hint I intended the player to act upon was the use of pressure pads to activate the dart launchers. As well as identifying traps, the player can see dart launchers positioned in the boss arena to assist them with the fight. These launchers act just like the rest of the launchers in the level and as such can only be used once when activated. This caused problems for about half of the players as they discovered their usefulness and then set all of them off before the boss could be hit by them. The pressure pad system presented its own problem as players thought the pressure pad for the door puzzle, and the lift before I changed it, also activated traps and so initially avoided them.


Overall, players found the layout of the level to be quite good. They appreciated the changes in altitude and direction that give the world depth as this is better than running along a flat, repetitive level. Trap placement was also like, as the traps offered opportunities to do extra damage to enemies, as well as offering risk versus reward scenarios, such as picking up the key on the pressure pad. The general concerns were the need for more clarity and a bit more variety in traps and enemies.




Players responded well to the combat mechanics as they find it fun shooting hordes of enemies that have inferior weapons. However, my concern is that the limited abilities of the player character will destroy and replay-ability as the combat gameplay will get old quickly. Suggestions for improvements included secondary weapons and some kind of special ability like throwing grenades. Combat has been improved though. The fire rate of the gun has been tripled, letting the player dispatch enemies quicker, and preventing them from being overrun by just a couple of enemies. It even makes the larger horde encounter much more fun as they can mow down enemies rather than run around like Benny Hill. The bullets also have nice, bright golf-ball-sized tracers to clearly show the player where they are firing. This is helped further by the player character having an idle aiming animation.


Whilst there is more clarity, particularly in the level itself, than there was in previous versions, there is still room to improve when it comes to gameplay. I have used sounds and some particles to indicate to the player when something has happened, however some of these sounds are ambiguous and even fail to play properly. One example is when enemies spawn in. The sound only seems to play half of the time and there is no visual cue for the player to show that an enemy is about to spawn. More particle effects and visual cues would therefore not be amiss. This lack of visual and audio feedback makes it more difficult for players to keep track of new enemies, especially if more enemies spawn off camera.


I have improved the AI. The boss can now switch to melee attack if the player tries to hide between his legs. The boss’s weapon ranges have also been adjusted to stop him from continuously swinging his sword at the air when the player has moved away from him. However, there is still a problem when the boss is stunned as he seems incapable of reacquiring the player as a target after the stun wears off. The player must run around the boss over and over until he realizes there’s a target. Obviously, no one does this as it’s easier to just shoot him and so take advantage of the exploit. There is also no particle effect to show he has been stunned and then the stun wearing off.


Standard enemies are also more likely to connect with their axe swings now and be somewhat of a threat. Although this can be done in some encounters where their spawning positions means that they will quickly form a queue to be slaughtered. Adding an offset to their target location has helped but they can still be lured into queueing for death. These enemies, by design, are not supposed to be particularly threatening but this does make them completely ineffective.


The gamepad controls were also received well. While the aiming system is a little complex as the player has to aim first, then change direction and then pull the trigger, the controls are simple enough and much more suited to casually running around shooting pathetic enemies. Some UI prompts would probably have been better for showing the controls to the player, instead of simply telling the player the buttons in the dialogue which is what I currently have. The player can also see what is going on a lot better as the camera is now at a higher angle above the world and the player moves and aims in the direction relative to the player’s perspective, rather than the world.


Despite these improvements, the level (and game as a whole) still has a number of bugs and issues that could prevent it from being playable as players will no doubt find them by exploring. It is possible to skip past objectives, meaning the UI is not updated and so the player will be at a loss for what they are supposed to be doing. Players can also run around on the rocks in they run in certain places. There are also problems aesthetically that makes the game unclear and not particularly pretty to look at. But ultimately, the real problem is a lack of gameplay mechanics combined with a lack of variety in the manner in which they are implemented in the level. This is certainly a long way from being a playable game and more time and effort put into it would have been apt.

 Playable Build:




Share this post

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!