Top down shooter prototype
Inspired by the WolverineSoft Studio project Dreamwiilow, I wanted to explore further how to create a high quality top down shooter character controller. There were three things I wanted to explore further that I feel we didn't have time for while developing DreamWillow:
Polish
Polish, also known as Juice, is one of the most important steps when creating gameplay and systems. It is what helps your game feel alive and engaging to play, and can even affect how powerful certain actions and weapons feel. I believe this is something we weren't able to spend enough time with on the character controller for DreamWillow, and I wanted to explore how other top down shooters approach this.
One of the best descriptions of Polish / Juice can be found in the book Game Feel by Steve Swink.
Polish effects add appeal and emphasize the physical nature of interactions, helping designers sell those objects to the player as real …
… If all polish were removed, the essential functionality of the game would be unaltered, but the player would find the experience less perceptually convincing and therefore less appealing. This is because [for players] simulation and polish are indistinguishable. Feel can be just as strongly influenced by polish effects as by a collision system.
Applications of Polish
Camera and weapon movement
The camera movement helps to not only increase the size of the visible space around the player, but it helps to add to that sense of looking around and taking in your environment.
Having the weapon rotate to face the aim direction gives a visual indication and acknowledgement that the firing direction of the weapon is changing.
When combined these work together to increase that sense that the character’s focus is in line with the players.
Player Area light
Beyond being a juicy visual, the area light helps to make the players position in the world more apparent and easy to parse.
Due to the area light also casting shadows it functions as a field of view and can help the player quickly determine if a shot will actually make it to its target.
Particle Effects
Particle effects present in the prototype
Walking and Dashing
Projectile Collisions with Enemies, the player, and Walls
Projectile wall bounce and time decay
Something to note is that the particle effects all serve a purpose and are not being used just for superfluous juice, they have a function. Anything present in a game needs to serve a purpose for existing, and these particles exist to help ground and acknowledge the players interactions with the world.
Player Damage Effect
An effect like this is important because it needs to be obvious when the player has taken damage. Without this signifier it would be a hindrance to creating fair and balanced gameplay.
The effect used in this prototype is nearly identical to the one used in Dreamwillow. A breakdown of this effect has already been written, so if you’re interested please read its blog post.
Weapon kickback and Screen-shake
One of the easiest ways to make a weapon feel more powerful is to make it feel powerful in the game world. This can easily be done with weapon kickback and screen-shake. Not only does this make your game look more visually interesting, but it shows that a weapon is so powerful that it pushes the character back and causes the game world to shake.
Enemy Knockback, Damage Flash, and Corpse Permanence
This directly ties into the argument that polish can and should be used to uphold gameplay. By having enemies knockback / stagger and indicate when they are damaged with a flash is less of a coat of polish, and more of a base level implementation of messaging; this should honestly be an early stage expectation when developing enemies.
Having enemies leave behind corpses is done to show the player that their actions are causing an effect on the game world. These corpses can also be used for land-marking while navigating the map.
Post-Processing
While it is very easy to go overboard with post-processing, you can use it as a tool to aid in gameplay. Effects such as the Panini Projection and a Vignette can be used to take focus away from the edges of the screen and guide the player’s eye towards the center point which is generally where most action will be occurring.
Level Generation
While developing DreamWillow I created a random map generation tool to aid in rapidly developing new level shells. This tool made use of two algorithms the Drunkards Walk and Cellular Automata, and due to the style of game Dreamwillow was we ended up primarily making use of the later algorithm. Becuase of this I didn’t have the opportunity at the time to research ways that can make the Drunkards Walk algorithm better.
Algorithm overview
I wont break down the algorithm here, that can be found in my blog post on the map generation tool. However, lets go over some reasons why you might want to use this algorithm:
It’s very quick and easy to implement the base algorithm
There are several easy tricks which can be done to improve generated map quality
It’s able to create a very wide range of map style
It can run quickly
While these sound like a dream there are some severe draw backs when it comes to the applications of the algorithm
It can be challenging to hone in on generation settings that consistently make “good” levels.
Levels will always look like rooms and corridors, dungeons, or a cave. That’s fine if it’s what you’re looking for, but will be a dead-end if you’re looking for more organic levels; look to Cellular Automata if you want that.
Algorithm improvements
While on its surface the Drunkards walk is quite simple there are some small alterations which can be done to improve it's ability to create interesting and unique maps.
Room placement
This is a random chance event where a room (a n x n sized space) will be placed where a single floor tile normally would.
This is important to help reduce / change the amount of corridors created during generation. If you want a larger open map then increase the chance of rooms being placed, or you could also decrease the chance of rooms being placed and increase their size to generate more of a connected room style map.
Walker Spawning and Decay
The way floors are placed is with entities called Walkers that roam randomly, placing floor tiles on every iteration of the algorithm. To improve the generations chance of creating branching paths or creating more open spaces a random chance event can be added to the Walker’s iteration step that attempts to spawn a new Walker or kill the respective Walker (with exception that at least 1 Walker must always exist).
Future improvements
This implementation isn’t perfect, and a few ways I could see pushing this even farther for a commercial game could include:
Map Generation Profiles
The Drunkards Walk is a very modifiable algorithm that can lead to a wide array of generated maps. Because of that, this system could be used to create maps that exude a certain feel or characteristics based on a zone configuration of the algorithm. This is done by games such as Nuclear Throne to create different level styles, and allows the algorithm really flex it’s ability to create extremely varying maps.
This could easily be done by creating a ScriptableObject profile system (similar to this prototype’s Weapon Architecture) which defines the generation settings for a zone. This profile could then be used by a Level Generator and quickly swapped out or modified.
Details and Pickups
Something important to take these generated maps to the next level would be to include details and pickup items for players to interact with. Be it ammo and weapon pickups, explosive barrels, or destructible terrain the player needs some form of world interaction beyond killing enemies.
Ammo and weapons / Chests gives the player a goal to encourage movement and exploration
Explosive Barrels give the player combat options and promotes strategy during a fight
Destructible terrain adds to the player’s sense of interaction with the game world. It shows that their actions have an effect on the space their playing in. Functionally this can also be used as land-marking in a similar vein to defeated enemy corpses.
Weapon Architecture
ScriptableObjects are an extremely powerful tool that Unity offers developers and I wanted to explore applications for them with this project. In the end I choose to create a player and weapon architecture that makes use of ScriptableObjects to define the behaviors of a weapon. To keep this post’s length within reason I have broken down the details of the architecture in a separate blog post.