Assignment 4: The Pivot

Philosophy

For assignment 4 you will make a “drastic” change to your project and also add some minor polishing. The “drastic” change should be significant in its appearance, but not actually be that drastic in terms of what you have to change in the code itself. Of course, you may discover that your implementation is not quite as flexible as you thought/it should be.

Codebase

The first step for assignment 4 will be to find a team: Team sizes should be 4-5 students, and the easiest/preferred way to form these teams is to merge two of the existing teams from assignment 3. Since both teams will have their own code base, you should spend some time discussing what each team has implemented, and to see which code you want to continue with. You can, and may want to, also take individual pieces from each of the two code bases.

Overview

The assignment itself has to be submitted in two parts: Assignment 4a is just the group formation and merging of the games. You do not have to literally merge the code, but you have to make sure to support everything the individual projects contained. For the “main” part of assignment 4, there are two tasks: The major pivot, for which you have to choose one of four options, and adding polish, for which you have to choose two out of several options. You can also add more of the polish options for bonus points.

Task 1: Merging (5 points, deadline: May 27, AoE)

Before you start coding something new, you will need to find your team and figure out the shared codebase you will be working with. For the first task you will have to combine all base projects into one (you do not necessarily have to copy any code between them; the requirement is only about functionality). Concretely, your shared code base has to support:

  • All enemies defined by all group members (this should not require much more than copying together the definitions from all json files)
  • All spells defined by all group members (this will likely require adapting some spell code)
  • All relics defined by all group members (this may require adding/adapting different events, and merging the relevant relic code)

Please submit your code together with a pdf with all group members and a list of all enemies, spells and relics in the combined project.

Task 2: Major Pivot (15 points)

Choose one:

  • Change the game to be a sequential exploration of rooms with at least 10 levels

  • Add a crafting system for spells and relics

  • Change the game to 3D FPS controls

  • (Not recommended) Change the game to be a competitive multiplayer game (split screen)

Sequential Exploration

The current game play loop for the game involves enemies spawning in waves in one large(ish) map. When the player has defeated all enemies, the next wave starts. A different game play experience could be for the player to start in a starting room and exploring a sequence of rooms until they find a staircase (or teleporter, or some other goal), which leads them to the next map. Your task, if you choose this pivot, will be to implement this sequential game play structure.

What you will have to change:

  • The map itself: There should be multiple rooms (an example map is shown below; it is just meant as guidance; please create your own and don’t just replicate this one), connected by corridors, or some other.
  • Enemy spawning: Since the player now traverses the map, enemies should no longer spawn in random/fixed positions all across the map. One good approach would be to have each room come with its own enemies (you will want to limit how far enemies pursue the player and prevent them from leaving their room)
  • The reward system: The player should still unlock new spells and relics, but since there are no waves anymore, you will have to change when the player obtains rewards. One option is to just give them the reward when they reach the end of the level. Another option would be to have certain rooms give the player a reward for entering them/interacting with an object/defeating all enemies within (could be a boss?). Instead of having 10 separate “levels” you could also have one very large map with different sections, and the player receives a reward at the end of each section.
  • The difficulty levels: Right now our difficulty levels change how many waves the player encounters when playing the game, which does not really translate well to our new progression system. The scaling of enemy stats may still be useful, but with individual rooms, even scaling the number of enemies in the same way may not be feasible anymore.

Choose this if:

  • You want to do some level design
  • You want to mess with the spawning code again
  • You are unsure what to choose

Crafting System

Currently, the player gets one spell after every wave, and a relic after every third wave. Spells are randomly generated, and relics consist of triggers and effects, which are (hopefully) reusable components in your code. If you choose this option, instead of giving the player randomly generated spells, you would give them “pieces” of spells (more than one per wave would be good; maybe each enemy has a chance to drop a component?), and players can then assemble the pieces into an overall spell. In the simplest case, instead of a reward screen, you would show a craft screen, where players see all the pieces they have on one side of the screen, and then can select and combine arbitrary pieces into a full spell. For example, the “doubler” modifier would be one piece, the “homing” modifier another piece, and base spells would also be pieces. The player could then selectively assemble a doubled, homing arcane bolt and add it to their spell bar. Relics, similarly can be assembled from different triggers and effects. For relics, it might make sense to assign a “energy” value to each trigger, and only activate the effect when the overall energy value has reached a threshold defined by the effect. For example, the effect “gain 5 mana” could have a energy requirement of 16, and the trigger “take damage” produces 8 energy, while the trigger “kill an enemy” produces 32 energy. If the player crafts “take damage: gain 5 mana” and equips it, they will get 8 energy every time they are dealt damage. Once they have accumulated 16 (i.e. after every second hit they take), the effect is activated. On the other hand if they craft “kill an enemy: gain 5 mana”, killing an enemy will produce 32 energy, and activate the effect twice. This energy is specific to each relic, and just a way to balance how easy it is to achieve each trigger. Note that this is similar to how the runeword system works in Diablo IV.

Note that there are some details you will need to work out, such as how to show the player what each component does, and how to represent it on the screen (icon?), as well as how the crafting UI should work in general. You can also allow the player to disassemble existing spells and relics to get the components back, if you want to give them maximum flexibility. It’s fine if the inventory has a (reasonable) maximum size, but in that case you should allow players to drop components if necessary.

Choose this if:

  • You want to (or at least don’t mind to) do some more UI work
  • You want to make full use of the flexibility of our spell system

3D FPS Controls

Our existing game is played from a top-down 2D perspective. However, nothing in our spell system really requires us to be limited to two dimensions. If you choose this option, you should change the game so that is played from a first person perspective in a 3D environment. This may seem like a drastic change, but by keeping our game mechanics (mostly) separated from the visual representation, it is really not. There are two main parts you will need to work on for this option: First, while most of our mechanics are dimensionality-agnostic, vectors show up in several places, even in the spell system. The spell interface itself only talks about an origin and a direction, but for example your arcane blast will create other projectiles in the xy plane. Unfortunately, Unity does not like having the z-axis defined as “up”, so you will need to modify the locations where directions were determined. The movement code is another place you need to change, as it uses 2D vectors and 2D raycasts. The second part of the assignment will have to do with the sourcing of art assets. You can find free 3D models on opengameart.org (e.g. goblin, forest monster, chicken) or the Unity asset store (e.g. orcs; you can also use particle systems to create nice projectiles (see e.g. this tutorial).

You can either create a new Unity project starting with the 3D template, which will come with the right settings (but you’ll have to recreate/copy-paste the entire scene), or you can change the existing project (easier, but you will want to compare your settings with a newly created 3D project to make sure you get the rendering setup right). You will need to do (at least):

  • Change the camera mode to projection
  • Change renderer to 3D
  • Change scene view to 3D
  • Recreate the level in 3D
  • Replace prefabs for enemy and projectiles
  • Change vectors (for movement, projectiles, etc.) to use x and z instead of x and y
  • Implement the new control scheme

Choose this if:

  • You want a very drastic change for surprisingly little effort
  • You feel comfortable enough with the project structure to touch the entity instantiation parts
  • You want to/don’t mind to look for more art assets

Competitive Multiplayer

Another way to change our game would be to allow more than one player to play it at the same time. Sticking with the same overall mechanics, we could have two players compete on a single map, with the monsters being on one of the two teams. Just as it is now, the monsters spawn periodically, but instead of simply moving towards the player, they have a target in mind: The other team’s base. If they encounter an enemy on the way, they will attack, otherwise they will just proceed towards their destination. The goal of the game is to get a certain number of monsters from your own team to the other team’s base. The players can attack the monsters on the other team as well as the other player. When a player dies, they respawn after a certain (but increasing) amount of time. Essentially: Turn the game into a simple MOBA. You will need to figure out how spell and relic rewards work (after player kills perhaps? You could incorporate a currency system, but that can get complex pretty quickly). Also, note that you will want to make this playable via split screen (with the second player using a controller perhaps), as adding online game play adds a whole other layer of complexity.

Choose this if:

  • Actually, don’t choose this

Task 3: Polish (5 points)

Choose two of these options:

  • Status effects for the player and enemies
  • Damage and Armor types
  • Items for the player (simple stat boost)
  • Item inventory for the player (requires items)
  • Better AI behavior
  • Animations and GFX
  • Colorblind modes
  • (Recommended) Main menu, credits, settings, etc.
  • Sound effects and background music
  • Suggest your own

Note that the description of each of these items is very open-ended, and you are encouraged to take the basic ideas and implement them in whichever way you think makes for the best gameplay experience.

Status Effects

Some of your spells already slow enemies, which is great. Maybe we want more varied status effects that can be applied to enemies (and the player), like damage-over-time effects, vulnerability, a chance to miss on attacks, a stun, etc. You could add a generic system, where spells/attacks can add such a status effect, which then modifies how the affected entity can act. Then you can add spells that e.g. apply a burning effect, or have enemies that can stun the player.

Damage and Armor Types

So far, all our spells only deal arcane damage, and even if we changed this to, say, “fire damage”, there would not be any gameplay difference. You could add spells with different damage types (with different icons, and perhaps even projectile colors), and then give the different enemies resistances against certain damage types, like warlocks taking less damage from arcane spells, or zombies taking more damage from fire spells. The player could also have different resistances

More Enemy Variety

So far, our enemies only differ in speed, hp, and damage, but they are all simple melee attackers. You could add the ability for enemies to cast spells, buff their allies, heal them (or themselves), etc.

Items

Players have several properties, including speed, hp, spellpower, mana and mana regeneration. You could add a system where enemies may drop items that the player can collect. For this first version, each item type should just have a fixed attribute it improves, and the player would only pick up a new item if it improves the stat. For example, if you say that all hats (only) increase mana, and the player finds a hat that gives +10 mana, any subsequent hat would only be picked up (and replace the one the player already has) if it gives more than +10 mana. It would be helpful if there was a display of which stats the player gets from their different items (could just be text).

Item Inventory

If we want more complex items (maybe a hat that gives +10 mana and +5 hp, and another one that gives +5 mana and +10 hp), we will want to let the player choose which item they want to commit. For this option, you will also need the “Items” option, and adding the inventory would count as your second choice. When the player picks up an item, it now goes into an inventory, and the player can equip items in different slots. You can decide if that is possible at any point during gameplay, or perhaps only between waves (or levels, as the case may be).

Better AI Behavior

Right now, all enemies just move towards the player in a straight line, and get stuck if there is a wall in the way. Perhaps it would be good to give them at least some basic pathfinding capabilities? (It does not have to be complete navigation, some predefined waypoints would already greatly improve the experience) Additionally, if different enemy types behave differently, that would also distinguish them better. Maybe zombies run at the player, while skeletons group up and attack in a team.

Animations and GFX

Since the focus of the project has been on the development side, the game is not very pretty right now. We could greatly improve the aesthetics and experience by providing additional feedback to the player as to what is happening. When enemies move, their sprites change to indicate walking, when they attack the player there is a small effect (in addition to the damage numbers, which are really more like debug output anyway), etc. More advanced improvements could include making good use of lighting

Colorblind Modes

Our game communicates the hp of each unity with a green bar on a red background, which is not accessible to players that cannot distinguish these two colors well. Deuteranomaly, which is a form of red-green colorblindness, is one of the most common color vision deficiencies in humans, and it would be great if we could make our game more accessible. You should include an option that makes the game more accessible to people with different types of colorblindness. Part of this task is to investigate how to do this in a reasonable manner (hint: do not change the look of the actual game world).

A full game does not just start with the game scene itself. There is a splash screen and a main menu, there are settings, credits (that’s you!), etc. You should add those things to your game.

Sound effects and background music

Our game is very quiet. Too quiet. You should liven it up a bit by adding sound effects for relevant events, and perhaps a fitting piece of background music can also further enhance the gameplay experience.

Game State Saving/Loading

One somewhat annoying aspect of our game is that once you start playing you either have to finish or abandon your run. You could implement a feature that allows players to save their progress (at any time, or just between waves), and then load that saved progress later. Make sure to preserve all aspects of the game state.

Achievements

Beyond saving progress of a single game state, we could add a meta progression system, that keeps track of actions performed by the player, e.g. how many zombies they killed through all of their playthroughs, and award them with an achievement when they reach a certain threshold. You should come up with your own goals and achievements!

Suggest your own

From the list above you should get a good sense for what we are looking for in “polish”. Since the list is limited by my creativity, there are certainly aspects of the game where I have not considered how they could be improved. You are more than welcome to come up with your own suggestions. If you are unclear on what “counts”, just ask.

Requirements and Deliverables

To reiterate, you are required to:

  • Merge all base versions into one that supports all enemies, spells, and relics defined by all group members (due 5/27)
  • Choose and implement one of the major pivots listed above
  • Choose and implement two of the polish options listed above
  • Optionally add more polish options for bonus points

Deliverables:

  • Submit the entire Unity project, without (at least) the .git, Library and Logs directories (please also remove any __MACOSX directories if you are using a Mac); preferable: exclude everything that’s excluded by the .gitignore file. You may submit this in the form of a link to your github repository (a specific commit is best!), if you add the instructor and the TA to it.
  • Additionally, include a pdf file with the names of the team members, a list of all enemies, spells and relics, which major pivot and which polish options you implemented and a short (1-2 paragraph) reflection by each team member on what their contributions were and what they learned.

Deadline for the assignment is 6/10 AoE.