 |
|---|
|
Assignment 4: Game State |
For this project, you will be exploring game state management as you create a basic RPG. The gameplay itself can be 3D or 2D, but you will be working with GameInstance and UMG functionality extensively as the main feature we will be evaluating.
Your game will contain the following features:
The exceptions are things where working in C++ actively ignores the tools provided by UE5 (rather than working with the tools provided). Things you should consider working with Blueprints directly are: Animation Blueprints and/or Paper2dSprites, use of Timelines and Sequencer for other animation sequences, and the visual design aspects of UMG widgets.
Name your project CS354p_A4. This project does not specify 2D or 3D graphics, nor does it specify grid-based versus free-moving, so you are welcome to set up your game as you'd like. You should have at least some conversation about this as these decisions greatly affect how you'll implement physics and collision detection and therefore how you set up your Actors and World.
If you would like to make a 2D game, you may want to look into the Paper2D plugin, which provides tilemap, sprite, and flipbook (sprite animation) support. There aren't a lot of tutorials for integrating it with C++, and while it's relatively straightforward (you can add a PaperFlipbookComponent and a PaperSpriteComponent to your Pawn to handle the sprite animations), you can also fix the camera along the Y-axis and make the camera Orthographic to create pseudo-2D (throw on a nice Post Process Material to make it look like pixel art as a bonus).
The world map should be some space where the player character and enemies are visible and can navigate. The world map should either stop the player from leaving it, or wrap around so the player can never leave it. You can also choose how the player navigates the map (e.g. WASD controls or point-and-click movement, etc). You should spawn enemies on the world map itself so the player can see them before starting an encounter. The enemies can either move randomly, along a path, or target the player as the player approaches (you don't need to worry about building out a Behavior Tree unless you want to). When an enemy overlaps with the player character, the character and enemies enter into a battle mode.
Combat will take place in a separate scene. Depending on the type of combat, this scene setup will vary wildly. For a more traditional turn-based RPG, you may be able to place everything in a UMG, which is used for UI elements. If you are making an action rpg, you will need something more top-down or isometric. If you making a tactical rpg, you will need some notion of a "board" in addition to player actions.
Regardless of which type you choose, your battle screen should have at least some UI system (clickable is okay, but I'd prefer hotkeys) with selectable actions and visual representations of the playable character's current status, as well as a way to display the enemy's actions and status. This does not need to be elaborate, or even particularly intuitive so long as you have good documentation. The exercise is about working with context-sensitive UI/using persistent data.
The playable character should be visible on both the world map and battle map at all times. When a battle occurs, they move from the world map to the battle screen, where they must either defeat the enemies or escape from combat without dying. Thus the playable character should have the following properties:
Their ability to attack is based on some function related to their strength. Their ability to Defend is based on some function related to their defense. Evasion affects how likely they are to dodge an attack by the enemy and also their ability to escape from battles. If the current hit points for all playable characters reach zero, the game ends. If the character(s) defeat enough enemies, they can gain levels, which raises their base stats. You can choose whether leveling replenishes health or not, or if you want some sort of item that regenerates health. That said, playable characters should not regenerate health after defeating an enemy and returning to the world map.
As a gentle reminder, we aren't here to make fun games -- just to understand how games are made. RPGs are incredibly challenging games to tune for "fun" so do your best creating these stat curves, but don't worry if your game isn't ready for release.
The enemies should be visible on both the world map (if they have not been defeated) and within the battle map. When a battle occurs, the enemy will be controlled by the computer and combat the playable characters. Thus enemies should have at least the following properties:
Note that extra credit points will only be available after completing the minimum requirements.
RPGs need a little more than the minimum requirements to be fun. Things like inventory systems, gearing systems, ability systems, party composition, narrative systems etc are where the fun really starts. Put in one (or more) of these systems to give your game a little flare. Note, you are capped at 5 points extra credit, so multiple system implementations will not stack for multiple extra credits.
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_A4. 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).
Note that if you do use the Paper2D plugin, you need to consider how to handle that within your git repo. You can either include the plugin within your project, or expect users to install the plugin on their working machine before starting. The latter option is more space efficient, but make sure your README specifies exact instructions so there's no confusion while grading.
Note that you should also specify who has done what at this point in the project. Since the milestone is now a substantial percentage of the project's grade, your milestone grade will be adjusted based on your contributions to the code base during this phase of the project.
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 should also include the following: