CS354p - Assignment 2

Project Description

You will build on the concepts from Assignment 1 by building a more complex player package with more involved controls and states, as well as multiple levels. This player package will include animations as well to better explore the way UE5's C++ systems work with the various Blueprint systems. To do this, you will create a "Character" class, multiple types of interactable objects, and multiple levels. You will also include a report write-up describing the software architecture choices you made and why, as well as video footage of your game to show off its features.

Basic Requirements

Your demonstration will contain a minimum of the following objects:

One custom Character class the player controls
Three types of Interactable objects that are placed throughout the arena levels
Two levels the player can transition between using one of the Interactable objects.

Remember that while you can use Blueprints to handle tunable parameters and the composition of functionality, all functionality should be created directly in C++. For example, you can create a class that inherits from Character in C++ that has BlueprintCallable functions, and then create a child Blueprint class of this Character, which performs these functions in its Event Graph.

Getting Started

You will be working from a C++ Blank Template as always, and you do not need to include the Starter Content, but you are welcome to do so if you'd like to use it. Since this project requires animations, you can import assets from the Top Down Tutorial to simplify obtaining assets using the migrate functionality. To do this, you create the Top Down Tutorial, and from within the UE5 editor, select the Characters folder in Content, right-click it and select "Migrate" then choose your Assignement2 Content folder to save it to.

If you want to look over any of the tutorial (particularly the C++ versions) for some context and ideas for how to start on your project, that is totally fine. Please just make sure you 1) understand what and why they're doing rather than just copying-and-pasting what's there, and 2) reimplement their functionality in the way I request for this project. The point of this class is to learn how to use large systems like UE5 to become a more proficient game programmer. If you're just trying to get through the projects as quickly as possible taking as many shortcuts as possible, the only one you're hurting is yourself, so just keep that in mind as you decide how best to navigate the "looking at other examples" line.

Level Requirements

You must create at least two arena levels that enclose all Interactable and Character objects. These arenas should have multiple types of lighting, and at least two types of Materials. You should also create at least one "Kill-Z" Volume, which is placed such that the player will "die" and reset the level should their Character escape. The prevents annoying situations where the player is infinitely falling or unable to continue their progress should your levels have flaws in them (which your levels will).

Since the Character will have Jump and Crouch abilities, make sure the level has some geometric features that allow the player to test Jump and Crouch. If you want these testbed levels to be kind of fun, please leave some time for tuning object placement etc. Fun is certainly not required, but it's encouraged.

Character Requirements

You will create 1 (or optionally more) Character(s) that the player will control via a custom PlayerController for a third-person camera perspective. You can choose which buttons map to which features, but you must implement the following behaviors:

Idle: The character, when its velocity is (0, 0, 0) and no action is being performed, will be in the Idle state. This idle state should be reflected by an idle animation that plays at this time.
Movement: The character can Move in 4 directions relative to the Actor's forward (forward/backward/left/right). You can choose the Character's movement speed. A walking and running animation should play in this state depending on the Character's speed (you get to determine how to tune this). For distinguishing walking/running, I'd recommend mapping a controller in addition to keyboard, or have a button that toggles the walking/running state from the keyboard. Implement at least one of these solutions (both are encouraged).
Camera/Turn: The camera should be controlled via the mouse, and when right-click is pressed, the character should turn to match the camera's orientation around the Z-axis (e.g. up axis). For the sake of simplicity, you can have the camera pivot only around the Z-axis, but as you may discover, a camera that can move around multiple axes will look and feel better (and potentially help with debugging).
Jump: The character has the ability to Jump and Double Jump from either the Idle or Movement states. Please take some time to tune the jump parameters in the Bluprint so it feels kind of nice. You should use the Jump animation when the character is jumping, but you don't need to worry about the start and end animations if you don't want to.
Crouch: The character has the ability to Crouch. There is no crouch animation in the basic Mannequin pack, so an animation change is not required (but if you find one for free or create your own in Blender, please feel free to include it). That said, the character should have a reduced capsule size while in the Crouch state and should move slower. A crouching character cannot jump.
Pick up: The character has the ability to use "Pick Up" on "Pickupable" objects if that Pickupable object is detected by a ray cast along the Character's Forward. If the cast detects a Pickupable object, that object should elevate slightly along the Z axis (e.g. up axis) and then move with the player. The character can only start execution of Pick up while idling, or crouching, but the character can continue move while carrying a Pickupable object. Pick up will last for as long as the player is holding the Pick up button, and it will end when they release the Pick up button. If there is no Pickupable object detected when the player executes Pick up, the character will not enter the Pick up state. You can choose if holding the Pick up button while moving the camera allows the player to Pick up an object, or if they must aim then click again (the first is nicer feeling but a little more complex). You do not need to associate Pick up with an animation but you can create your own animation if you'd like.
Pull: The character has the ability to "pull" "Lever" objects in its hit volume. When the character pulls a lever, it in some way change the state of the world. This could be moving a wall, starting a moving platform, or spawning additional items throughout the level. You get to choose what it does, but make sure you document expected behavior. The character can only interact from the idle state. When the player successfully interacts with a Lever, the player will not respond to input for 2 or 3 seconds. You do not need to include a "lever pulling" animation, but as always you're welcome to create additional assets in Blender. After the 2 or 3 second "action" period, the objects associated with the Lever object will react and the character will return to the idle state. If no Lever object is within the playable character's hit volume, the character's state does not change.

Interactable Requirements

You will create 3 (arguably 4) types of Interactable objects that the player can interact with via the Character. There should be at least 3 instances of each Interactable type in the scene, but you can choose whether the level starts with all instances spawned or if you want to have them spawn in over time etc. As always, your choices should be documented.

Level Transitions: Level transition volumes allow the player character to change levels when they either enter the volume, or interact within the volume. You can choose which behavior to implement (or implement both). Please have some indication in the level where these level transitions are. This can be done explicitly with some visual feature to the volume, or implicitly (i.e. a maze that ends in a level transition volume, or a door that the player interacts to change levels.
Pickupables: Pickupable items require a visual representation, a collision mask to block the playable character, and physics (e.g. if you drop the object, it should have gravity applied to make it fall, and if you run into the object, it should bounce along the ground). These objects should also be "pickupable" in that the player can select them via a raycast and move them around the arena (the objects do not need to transition between levels with the player character). You can do this by attaching the item to the player character. You may need to disable gravity while the item is "picked up" depending on how you implement it.
Levers and their Responders: Lever items require a visual representation and a collision mask to block the playable character. These levers should also be "interactable" in that the player can interact with them via a hit volume, which causes them to modify the behavior of the lever's "Responder" objects. What the modification looks like is up to you, but you should use Multicast delegates to get the job done.

Extra Credit

The are several opportunities for extra credit in this assignment if you'd like to add the features below, but note that extra credit points will only be available after completing the minimum requirements.

Timelines

Use the Unreal Timeline feature (from Blueprint is fine) to create simple animations on the objects in the world. For example have the lever turn when the player pulls it, or have doors swing open when the player interacts with a level transition (as if they are opening and stepping through the door)

Advanced Camera

Have your player camera rotate around multiple axes based on the mouse position. Try to make it feel as smooth, responsive, and as intuitive as possible.

User Interaction and Interface

Add some sort of GUI that is displayed in your game. You can choose what this GUI will capture. For example, you can implement a scoring system based on what Pawn interacts with what Interactable, or create a game time limit where the player collects nodes that increase time remaining. This GUI system should be somewhat substantiative though, so we expect you to add on some "game-like" feature in addition to the GUI itself.

Getting Started

You will be working in UE5.2, so first ensure all team members have downloaded the exact same version of UE5. Create a C++ blank project from the templates and name it CS354p_A2. Please do not use the existing templates. They are good for learning, but it's always best to customize your project to your exact needs rather than trying to fit another project into meeting your approximate needs.

Once you have a project created, now is the time to get your project connected to a git repo. This means creating a .gitingore, and .gitattributes (via git-lfs).

Project Milestone

Documentation: You will turn in a document with the following information:

Overall design of your game. What game genre are you going to explore? What are the mechanics and features you need to implement? What other code and assets are required? Try not to be too ambitious. It's better to aim for a game prototype with one or two working features than half a dozen broken, or only sort of working, features.
Software architecture and plan. How are you going to structure your classes? What will be in C++ versus Blueprint? If it looks like you won't be able to meet your deadline, how can you scale back during the second week? Please include explanations of the code you've implemented and detailed breakdowns of how you will implement code that is not implemented.
Division of labor. n terms of the delivered capabilities, who is responsible for which parts of the code, and what is your plan for meeting up? My experience is that teams who meet up and code together on a regular basis create a more cohesive, functional project than teams where everyone works autonomously and tries to come together at the end. Keep this in mind during your planning stage.

Project Demo: You will also link an initial demo of your proposed game for the Milestone. This demo can be simple, but we need to see a rudimentary version of the game, so we can gauge whether or not you're on track. This demo can be some video footage showing your game, and you may want to include some subtitles explaining what is happening in the footage you are showing.

Final Submission

The only required submission for Canvas is a link to your project's repository on GitLab. The TA will be looking at the branch called a2-code-freeze, so make sure you have created and committed working code to this branch before the deadline. Any commits made after the deadline will result in that day being deducted from your late slip pool. Also include:

A README file that explains how to build and run your game. This may be the default instructions, but please let us know in case you're doing something different.

A User Manual which explains how to play your game along with the game's objectives. Include anything of interest we should now about in terms of game features, or where you're expected extra credit.

A Project Report, either linked from the README or as a separate file. This report should include screenshots of critical and interesting code segments you wrote, how these work, and why you implemented them this way, as well as how you implemented features, and how work was allocated between team members.It should also explain the places where you did better or worse than you expected and why those issues arose. Please be honest about unexpected issues in addition to the successes. This is similar to a "post mortem" you'd do in industry after a game's launch, and it's a way for teams to become more efficient and cohesive on future projects.

Video Footage (ideally via Youtube or some other easily accessible platform) of your game in action, demonstrating all basic features plus any extra credit features you implemented.

Individual Evaluations. Each member of the team will turn in this evaluation separately (not as part of the team's game package). Include assessment of: the performance of your team, personal strengths and weaknesses of yourself and teammates, what you'd do differently if you started again, and the main things you've learned. The evaluation should include specifics of your own performance and that of your team members (again both strengths and weaknesses). This will be kept confidential and will be taken into consideration during the assignment (and final) grading.

Grading

Grading will be handled in a holistic way. C quality work is implementing the features in a way that is mostly working, but may be buggy or not scalable. B quality work is implementing the features in a way that works but may have scaling issues, or lacks consideration for tuning and iterating. A quality work is implementing the features in robust, polished way that demonstrates consideration for tuning and scaling.