Assignment 2: Physics and Player Package

---

Project Description

In this assignment you and your team will create a rudimentary 3D game by taking the graphics concepts you worked with in Assignment 1 and extending them with physics and a player package. Since you will be working with other students, it is important that you be in contact with your group. If you have trouble getting in touch with them, let me or the TA know as soon as possible.

This rudimentary game will include a playable character with an over the shoulder camera, and an environment with interactable objects, and physical forces. Your team can take these basic specifications to fit the game genre of your choosing.

Basic Requirements

• Player Package

  The player will control a character, which can be as simple as a rectangular box, or an actual 3D model with animations. The player package includes all features related to the player, but we will focus on player movement and actions in this assignment. This will involved using the Input singleton, which connects to the Input Map. This work will all be done in GDExtension, but if you look through the godot/godot-cpp source, you will notice the functions in GDScript/C# map pretty closely to that in GDExtension.

  Your character should be able to:

  • Move. The character should move based on the four inputs, typically WASD. The basic movement includes moving forward and backward (W and S) relative to the character's "forward", which is a normalized vector pointing in the direction the character is facing while A and D map to strafing. Your character should also support rotation independent of camera rotation. You can implement rotating the character left and right when A or D are pressed in "rotate mode", or use other keys, such as Q and E. The scheme itself isn't important. The important part is that the character moves relative to its own forward rather than the world axes or the camera forward (unless expressly in some form of camera orienting mode, which you are free to implement in addition to these system).
  • Jump. The basic jump will use a ballistic trajectory based on an initial impulse, gravity, and air resistance. You can include exposed, tunable parameters for these properties, as well as one for air control. Air control allows the player to effect on character's movement during the ballistic motion. It is usually implemented as a value between 0 (no air control) and 1 (complete air control).
  • Fall. If the character does not have geometry beneath them, they should fall. Note that you will likely be using a CharacterBody3D for your character, so you will need to implement gravity/other forces on the character yourself rather than relying on the physical simulation directly.
  • Walkable Angle. Your character should have a tunable parameter to set the slope angle they can walk along. If they are unable to walk up an angled slope, they should slide back when jumping onto this angle.
  • Ledge Fall/Ledge Stop/Ledge Hang. Your character should be able to interact with ledges in three different ways, and your game space should feature all three forms of interaction for testing purposes. Ledge Fall is when a character moves over a ledge and are affected by gravity (the default way if you've implemented the above features). Ledge Stop prevents the character from walking past a ledge and falling. You will probably want to implement some sort of ray cast to detect the edge of a platform and prevent movement past this point. Ledge Hang allows the character to move past the edge, but rather than fall, the character "grabs" the edge. You will need to disable gravity when in this state, and implement player controls to release the ledge and/or pull themselves up.
  • Gliding, Flying, or Swimming. Your character should have at least one of these alternate modes of movement. You can determine what the correct physical parameters are for these different modes, but you should expose your tuning parameters to the editor for testing purposes. You will also need to implement ways to switch between modes -- either via player controls or world triggers. You also need to ensure a player does not get stuck in one of these modes (e.g. if a character falls into swimmable water, there must be some way for them to get out of the water and return to walking mode).
  • Custom Movement. You will implement at least one custom movement of your choice. This can be climbing, air/ground dashing, rolling with invincibility frames, double or triple jumps, etc. Please make sure you expose any parameters required to tune this movement.
  • Object Interactions. Your character should interact with at least two types of objects in different ways. This could be obtaining a power up versus hitting an enemy, or collecting a gathering node versus crafting with a building node. What the interaction does is entirely up to you, but please document expected behavior, so we are better able to experiment with your game.

• Camera control

  The camera should mimic a 3rd person over the shoulder style, which means it should have some way to orbit around the player, generally based on mouse input. Typically this is controlled by connecting the camera to a "boom" or Spring Arm to help with smoothing these movements. You will need to determine how input should map to camera orientation, and include tuning parameters for camera movement speed, radius, etc. The player should be visible at all times, so you will not only think about camera position but camera "look at" as well. You will also need to ensure that geometry between the camera and the player is either hidden or dithered (made semi-transparent).

  You can do this with a raycast from your camera to your player to check for geometry intersections, and you can set the object's transparency either through material shaders or node visibility. Depending on how you do this, you'll have some visual artifacting, but that is okay. The camera should also be done primarily in GDExtension.

  You are welcome to add a "camera mode" where the player's orientation follows that of the camera's orientation, but this should be in addition to the basic player movements/rotations described above.

• Sound effects and Background music

  Sound effects are critical for fostering player immersion and helping with the response timing. The minimal number of unique sound effects required for Assignment 2 are: 1) The player interacting with no interactable object present, the player interacting with one type of object present, 3) the player interacting with the other type of object present. The player should be able to turn the sound effects on and off -- either through a GUI, keyboard commands or both. Which sound effects you use are your design decisions.

  Background music should have separate volume control and on/off control from the sound effects. You might want to play around with things like loading/buffering time, starting and stopping sounds when menus are open, and playing multiple tracks. Be careful about copyright violations!

  You can handle sounds either via GDExtension or C#, but if you do it through C#, you should do the initial handling in a GDExtension node then connect your C# script to another node via a signal. Remember that you cannot connect a C# script directly to a GDExtension node, since each node can have only one script active at any time.

• Physics and collision detection

  The player package requires you to use both physic simulation and collision detection and response. In terms of basic forces, you must have at least gravity, impulse force for jumping, and velocity or impulse for movement. I would encourage you to go beyond these basics, though, and think about other interactions and forces. For example, when objects hit static surfaces, you may want to control how they bounce off with restitution, or you may want to implement pendulums/springs. If you do implement these additional features, the parameters should be tunable from the editor. Also remember that while you do not need to perfectly implement Earth's gravity or realistic object masses, you should make them plausible (and consider realistic units) for best simulation results.

• GUI and Status Display

  Your game should have some form of in-game GUI that is displayed throughout the game. This can be a character health bar, stamina meter, point system, timer, etc. How this value changes during gameplay is a design decision, and you are welcome to incorporate more than one of these as fits the needs of your game.

  You can (and should) build the GUI display within the Godot editor through C#, but you will need to connect these frontend C# scripts with backend logic calculated through your GDExtension scripts. You can update these values using custom signals or by navigating through the scene using get_node.

  Extra Credit

  • 3D Animations and State Machine

    If you use a 3D character with animations, you will need a state machine to transition between animations based on player input and world stimulus. Godot provides the AnimationTree node to handle transitions and animation blending, and you may use this system to hook up your functionality. While this does not require any C++ scripting on your part, there is a lot of intricacies in setting up these systems, so leave plenty of time.

    Also, given the project timeline, you will probably want to look for pre-rigged models on sites with free assets such as TurboSquid. Some of these include animations, but if they do not, you may be able to generate animations on it using Mixamo (but note that Mixamo will only work on bipedal rigs).

  • End Condition

    In addition to the basic scoring/status system your game requires, add an end condition so the player will either win or lose at some point. After this end condition is met, the player should be able to see how they did before starting a new game. If you get really excited, you can keep track of all games via a scoreboard in a separate play screen (player interfaces extra credit).

  • Particle Effects

    Particles make everything better! Hook in particle effects using the shader system's ParticleMaterials to add exciting, shiny things!

  • Player Interfaces

    Add a main menu screen and a pause menu. The pause menu should stop the physics simulation (and possibly the sound) and present the player with a "Continue" and "Quit" option. Continue will restart the game's physics simulation, while Quit will return to the main menu.

  Milestone 1

  You have two weeks for this project. To help you stay on track, you'll have a milestone in the first week to meet. This will be submitted via Canvas.

  1. Documentation: You will turn in a document with the following information:
     • Overall design of your game. What are the scoring rules? How will it look? What will the GUI control display/control and what will this look like? What is your plan for sound? Are there any additional aspects of the game play?
     • Software architecture and plan. At a high level, how are you structuring scenes/classes? How will you keep your code modular? How will you keep track of game state? Estimate how much work it'll take to incorporate each of the required capabilities. If it looks like you won't be able to meet your deadline, how can you scale back during the second week?
     • Division of labor. In terms of the delivered capabilities and software architecture, 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.

  2. Project Demo: You will also submit a link in the milestone report containing any initial demo code of your proposed game for Milestone 1 (this can be a branch in your git repo).

     This demo can be simple, but we need to see rudimentary versions of the expected capabilities, so we can gauge whether or not you're on track.

     This demo should compile and run, and you will provide instructions on controls and how the pieces of the demo in some way address your proposed creation (see final game deliverables). These pieces do not need to be at 100%, but at least parts of the game need to exist. For example, your GUI doesn't have to tied into the scoring system for this draft. You might have sounds hooked in, but you don't have player controls over them. The basic camera controls might be in place, but they are be glitchy or only partially working.

  Final Submission

  You should turn in link to your GitLab like you did in the previous assignment. The git repo should have a branch a2-code-freeze, and add both me and the TA to your repo before submission. Make sure you have your file structure and SCons files set up correctly, along with your .gitignore and .gitattributes, to minimize build pains. Please also make sure you included all relevant files, including those related to the Godot project, and your own source/library files. 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 that details and explains the places where you did better or worse than you expected and why those cases 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.

  Getting started

  Start. Now.

  Contact your team members and start planning. There's a lot of tutorial information to look at, so be thinking about the assignment and familiarizing yourself with the capabilities you'll need to use. The best code comes from people who spend most of their time thinking about the design of the system, not those who spend all their time coding. So just because you're not ready to start writing code doesn't mean you aren't in the middle of the most important part of your work, which is figuring out what to do.

  Grading

  You'll be graded on how well you met the requirements of the assignment. C quality work is implementing the features but 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.

  You will also be evaluated on your ability to meet deadlines. If the deadline is hopeless to meet without sacrificing capability, then you need to start making that case as early as you can, and propose plans to scale back.

  As a corollary, if you have grandiose plans to make a really fancy game that goes way beyond the requirements, be careful! Make sure you implement the required parts first. You can always enhance things later, but you won't be able to make up for points lost, because you didn't finish what was required. Pointing to all the stuff you did that wasn't required isn't an excuse in the real world, and it isn't one here. Extra credit is only possible once you complete the basic credit.

  Also note that we take quality of gameplay into consideration only as a secondary criterion. The most important thing is that the player should be able to navigate around and interact with the world, showing your basic domain knowledge of game "features" such as physics, sound systems, GUIs etc. That said, remember that a fancy game, which doesn't work or isn't playable is worth much much less than a simple game, which is fun to play. Frustrating mechanics will sour our enjoyment -- the TA and I are only human after all!

  ---

  Last modified: 10/01/24 by Sarah Abraham theshark@cs.utexas.edu