---

Project Description

You will familiarize yourself with Unreal Engine 5 and the underlying systems by creating a physics-based arena. You will create multiple "Pawn" classes, through which the player can interact with the world, as well as multiple "Interactable" objects, with which the players can perform various physical interactions. You will also include a report write-up describing the software architecture choices you made and why.

Basic Requirements

Your demonstration will contain a minimum of the following objects:

1. Two Pawns the player can launch in any direction
2. Three types of Interactable objects that are placed throughout the arena
3. An arena the player can navigate to interact with the Interactables via the Pawns

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 Pawn in C++ that has BlueprintCallable functions, and then create a child Blueprint class of this Pawn, which performs these functions in its Event Graph.

Arena Requirements

You must create an arena that encloses all Interactable and Pawn objects. This arena should have multipel 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 any of their Pawns 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).

Pawn Requirements

You will create exactly 2 Pawns that the player can Possess/Unpossess at any time. You can choose how players should Possess/Unpossess Pawns, but be sure to include that information in the documentation. You can also choose how to architect these Pawns, but again, be sure to include that information in your documentation. Each Pawn will have one shared behavior, and one unique behavior, but any other functionality can be implemented (either for both of them or just one of them).

1. Shared Behavior: Movement. All Pawns can be launched in a direction based on the direction the Pawn is "facing". The distance and way the Pawn is launched is up to you (i.e. each pawn has a different launch distance, whether to have the launch apply in the Z axis or wholly on the XY plane, etc), but all of this information should be documented.
2. Unique Behavior 1: Destructive. Only one of the Pawns will have this behavior. When this Pawn comes into contact with an Interactable object, the Interactable object will be destroyed. Pawns should never destroy other Pawns. You can decide the way in which an Interactable is visually destroyed.
3. Unique Behavior 2: Force Application. Only one of the Pawns will have this behavior. When this Pawn comes into contact with an Interactable object, it will collide with the Interactable object and send the Interactable object bouncing in a physically correct way. Pawns should never collide with other Pawns.

Interactable Requirements

You will create 3 types of Interactable objects, each with one or more of these features, that the player can interact with via the Pawns. 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. All features should be implemented even if Interactables have more than one feature.

1. Feature 1: Movement. Interactables with this feature will move throughout the world. You can choose to put them on a fixed path (and will then have to handle the case of when a Force Application Pawn moves them), or have them freely move but not get stuck on walls (one way to do this is have them reflect off of walls when they collide).
2. Feature 2: Pendulums/Springs. Iteractables with this feature will either swing like a pendulum or behave like a spring. Note that pendulums are a kind of spring, so you will implement both ways in a similar manner. The swinging/springing should be continuous. You will need to decide how this will work during Force Application Pawn interactions.
3. Feature 3: Teleportation. Interactables with this feature will teleport throughout the world. After a teleport, there should be at least 7 seconds of "cooldown" where the object does not teleport. The teleport should always send the object to a valid place within the arena. You will probably want to place teleport locations throughout the arena to achieve this.

Note that both Movement and Teleportation can be simplified by using what is called a "NavMesh" and while we will be discussing those later in the class, do not use them for now. The focus of this assignment is designing classes and components that work in a modular way, so it is okay if you hit design limitations for now.

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.

Camera Controls

Attach the camera to the currently possessed Pawn. Include basic controls for this camera: either rotate around the Pawn, zoom in and out based on the Pawn location, or both.

Sound Effects

Add sound effects that are synchronized with interactions in the world. You can choose how to differentiate sound effects (e.g. different Pawns have different interaction sounds, or different interactions trigger different sounds) but please make a note of what you did in your report.

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, 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_A1. 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).

After you confirm all team members can successfully pull and push, begin development on the arena and the game objects themselves. You may want to take at least a little time to architect your code. UE4 is quite nice to work in if you have a plan and some system knowledge, but will actively fight you if you freestyle it. Also remember that you should not work in the level file itself at the same time someone else is modifying it. Only one of your changes can be preserved.

Project Submissions

The only required submission for Canvas is a link to your project's repository. The TA will be looking at the branch called codefreeze, 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. You project's repository can have the report included as the README or as a separate file, and any video footage of your game can be linked from this report (or included in the repository). Remember that your report should include at least a couple screenshots of critical or interesting code segments you wrote. Please make sure, however you decide to structure your repository, that you inform the TA of the setup in the README so they can quickly figure out how to look over your assignment.

Grading

You'll be graded on how well you met the requirements of the assignment. D quality work is project compiles but features are not working. C quality work is features have been implemented in a way that is mostly working, but the project may be buggy or not scalable. B quality work is features are working, but the project may have scaling issues, or lack consideration for tuning and iterating, include difficult to read code. A quality work is features have been implemented in a robust, polished way that demonstrates consideration for tuning and scaling, including well-written code.

---