CS315 Game Programming: Exercises

Exercise 0: An Unskippable Tutorial

Objectives

This project will introduce you to Godot Engine as well as the norms of the class.

1. Preliminaries

Complete the account registration form that is linked from Canvas. This will get you access to the class’ private GitHub organization, which is required to complete later steps of this project.

Install Microsoft Visual Studio Code (VSCode). We will be using VSCode as a robust Markdown editor. If you already know Markdown and have a preferred editor for it, use that. If not, use VSCode.

Make sure you can run git from the command line. Windows users will use Git Bash, which is part of the git installation for Windows.

Set up your identity following the setup instructions.

Configure git to use VSCode as your editor.

2. Tutorial

Work through the “Your first 2D game tutorial” using GDScript.

3. Version Control

You should have previous experience with distributed version control from the prerequisite courses. This semester’s work builds upon that experience with more professional techniques.

Set up a git repository for your project. For example, you can use the command line to navigate to your project folder and then issue the command git init.

When you make a new project, Godot Engine will create appropriate .gitignore and .gitattributes files that tell git what files to ignore and how to deal with different kinds of files, respectively. Take a look at the .gitignore file, opening it in a plain text editor such as VSCode. You should see that .gitignore is ignoring a folder called .godot, and that this folder contains all manner of gobbledygook. Godot Engine uses that folder to hold its generated content—the files it needs to edit and build your project. Since it is generated content, it should not be tracked in version control. Three cheers for Godot Engine’s helpful default git configuration files!

If you are using macOS, you need to edit your .gitignore to ignores the .DS_Store files created by your operating system. Once you are done, your .gitignore will look like this:

# Godot 4+ specific ignores
.godot/

# macOS ignores
.DS_Store

Use git status at any time to see what is currently being tracked by git. You will see me use this comment a lot to make sure my mental model matches the computer’s state.

From the project directory, you can add all the non-ignored files with the following command. That is, this tells git to stage these files for commit.

git add -A

This would be a good time to do git status and compare the previous results to these.

You should now be ready to commit. Tell git to commit all of the staged flags (the -a flag) and also that you will give the commit message on the command line (the -m flag, which is combined with the previous into the string -am). Notice that this commit message follows the style guide.

git commit -am "Complete the tutorial"

Once again, git status is informative here. This is also a good time to try git log. If you want to get fancy, try this expanded version of the command:

git log --abbrev --decorate --online --graph

With your local repository ready, it’s time to make a remote one. Create a repository in our course organization on GitHub, naming it E0-myname, where myname is your BSU username or your surname. This naming scheme identifies the repository as being yours and corresponding to Exercise 0. Make sure it is an empty, private repository.

When you create the repository, follow the instructions GitHub shows to set your remote origin and push your changes to GitHub. One of the steps renames the default branch from master to main, and this step is optional.

Reload your page on GitHub, and you should now see that your remote repository is an exact copy of your local one.

Confirm that you have handled these steps properly by cloning your remote repository to a new location on your workstation. Do this by clicking the “Code” button on GitHub to get the HTTPS URL to your repository. It should look something like https://github.com/bsu-cs315/E0-myname. From your terminal, go to any convenient location in your filesystem and clone the repository using the git clone command, like this:

git clone https://github.com/bsu-cs315/E0-myname

This will make an exact copy of what is on GitHub. You can open this project using Godot Engine and verify that everything is working properly.

4. The README.md File

Use VSCode to create a README.md file at the root of your project.

The README.md file is in Markdown, which is a plain text format. VSCode has built-in support for Markdown editing. A useful feature is that you can bring up an HTML render preview using Ctrl-K, V (that is, hit Control and k together, release both, then tap v). This can help you ensure that your Markdown is well-formed.

Here are the most important Markdown features you need to know to get started.

• Headings are given with # characters; the more of them, the deeper the heading level.
• Blank lines, not line breaks, separate paragraphs.
• Hyperlinks are given as [link text](url).

One of the most important parts of the README.md file is your self-evaluation. The evaluation criteria for this exercise are simple:

• If you complete all the steps of the exercise, you earn an A.
• If you miss part of one step, you earn a C.
• If you more than one part of one step, you earn a D.

A, C, and D grades correspond to 3, 2, and 1 points following the standards of triage grading.

When you’re done, keeping in mind the self-evaluation requirements, your README.md file will look something like this:

# Project 0: An Unskippable Tutorial
A tutorial implementation by (Your Name Here).

This project follows the
[Your First Game tutorial from
godotengine.org](https://docs.godotengine.org/en/stable/getting_started/first_2d_game/index.html).

## Self-Evaluation

I have completed the exercise and have therefore earned an A.

## Third-Party Assets

- "art/House In a Forest Loop.ogg" Copyright © 2012
[HorrorPen](https://opengameart.org/users/horrorpen), [CC-BY 3.0:
Attribution](http://creativecommons.org/licenses/by/3.0/). Source:
https://opengameart.org/content/loop-house-in-a-forest

- Images are from "Abstract Platformer". Created in 2016 by kenney.nl,
[CC0 1.0 Universal](http://creativecommons.org/publicdomain/zero/1.0/). Source:
https://www.kenney.nl/assets/abstract-platformer

- Font is "Xolonium". Copyright © 2011-2016 Severin Meyer
<sev.ch@web.de>, with Reserved Font Name Xolonium, SIL open font license
version 1.1. Details are in `fonts/LICENSE.txt`.

Once you have created the README.md file, remember to use git status to see that it is not yet tracked by git. Follow the steps above to add this file to git, commit your changes, and push the latest changes to GitHub. Make sure you follow the style guide requirements for your commit message as we did above.

5. Release

Once you are confident that your work is complete, use GitHub’s web interface to create a GitHub release in accordance with the style guide. This marks your work as complete and ready for instructor evaluation.

Exercise 1, Increment 1: 2D Physics-Based Gameplay

Overview

This is the first of a multi-part project in which you will build a 2D physics-based action game along the lines of Angry Birds. This first part focuses on core physics-based gameplay. Future parts will build upon this to improve the player experience.

You have creative freedom to choose a theme for your game. In my sample solution, I have been inspired by Kenney’s Physics Assets pack.

User stories review

User stories are a common method of articulating functional requirements, particularly on teams that employ agile approaches. We will write our user stories following Mike Cohn’s approach. Each story is expressed as a statement of user desire followed by the conditions of satisfaction that explain how to confirm that the desire is satisfied.

User stories

Evaluation

Name your repository E1-myname where myname is your BSU username or your surname. You will use the same repository for all three iterations of the project; use the release name and number to mark your submission for each iteration.

From this exercise until the end of the semester, you must follow our style guide to earn a C or better grade. Be sure to review that page regularly, ask about anything that is unclear, and use peer review to help catch errors.

Suggestions

Angry Birds uses a cleverly-designed touch interaction to launch birds from a slingshot. It is sufficient for us—and a lot simpler—to use keyboard controls. If you were pursuing this as a final project, you might aim a bit higher, but keyboard input is perfectly appropriate for now.

For this first iteration, you do not need any images at all: you could just have every visual node draw itself by overriding the _draw function. That said, it can be easier to bring in images as you did in the previous project. Either approach is fine for the first iteration.

The projectile should be a RigidBody2D since it will be controlled by the physics system. It will have a child which is a CollisionShape2D. If you are using sprite images, then it will also have a child which is a Sprite2D.

Use apply_impulse to give a one-time boost of force (“impulse”) to the projectile.

An easy way to make the ground is with a StaticBody2D. An alternative is to use a TileMap, although this requires many more steps. If you go this way, make sure you have collision boxes set up correctly.

In order to get notification of a physics collision, you need to set the contact_monitor property and non-zero contacts_reported property of a RigidBody2D, as explained in the Godot Engine physics introduction. Only then will the body_entered signal be emitted.

I recommend that you try to get as far as you can using the official documentation and your experience from the previous exercise. This will help you think about the extents of your current understanding. I have a video from Fall 2020 that shows the first few steps of the project, but again, I would treat that as a safety net rather than a tutorial. (Also, the video uses an older version of Godot Engine.) Keep in mind that there are always more than one way to approach game programming problems.

Helpful Links

• Physics introduction at GodotEngine.org
• Kenney.nl has a wealth of high-quality public domain assets

Exercise 1, Increment 2: Game Logic and Assets

Overview

Now that you have the core gameplay in place, it’s time to add some features to make it more playable. You will limit the number of projectiles that the player can fire, and you will incorporate appropriate graphics and sound effects.

User stories

Evaluation

Sound

Never underestimate the power of good audio to improve the player experience. At a minimum, we want to have some kind of sound when the player launches the projectile. You can make your own sound effects, and there are plenty of places on the Web where you can find public domain and attribution-licensed assets. Personally, I am fond of freesound, which makes it easy to filter by license. For homemade sounds, I like the old-school sounds generated through the sfxr plugin in to LMMS. There’s an online sfxr port called jsfxr. Chiptone is more modern, but I have not used it myself.

The AudioStreamPlayer node provides an easy way to play sound effects. You can specify the audio asset to play in the Inspector and then call play when you want it to play. Sound effects should be .wav files. If you want to incorporate music, those audio files should be Ogg Vorbis files (.ogg), and you will probably want to set them to looping in the import settings. (This happened by default in older version of Godot Engine.)

Limited ammunition

One of the goals for this iteration is to ensure the player is only launching one projectile at a time. A problem you may run into here is determining when a projectile stops rolling after hitting the ground. Depending on your implementation, one approach is to listen for the RigidBody’s sleeping_state_changed signal. A physics body “sleeps” when no forces are acting on it. This saves the engine the trouble of processing that object each frame. You listen for the sleeping_state_changed signal to determine when a physics body has gone to sleep and use this in your game logic.

What happens if your projectile falls off the end of your world? If it falls forever, it will never change its sleeping state. A common solution to this problem is to set a “kill” line: if any object falls below that line, it is destroyed. This can be done by checking the Y coordinate of the projectile in the _physics_process method. Another approach is to add something like an Area2D to the level that can watch for overlapping projectiles and handle them appropriately, but this can be error-prone if a projectile overshoots your area.

To successfully complete this iteration, you need to be able to spawn multiple projectiles, one at a time, in succession. Defining the projectile in its own scene is an important step here. Remember: a Godot Engine scene is like a class in object-oriented languages. Once you have a scene (class) defined, you can make as many instances (objects) as you need. Of course, if you create projectiles programmatically, you will also need to connect their signals programmatically; you can read more about this in the signals documentation.

You might consider a flow of logic like the following.

1. Specify a spawn point as a Marker2D. At the start of the game, the main level’s script instantiates projectile.tscn and places it at the spawn point.

2. When the projectile is fired, the main level script listens for its sleeping_state_changed signal or for tree_exited if it is killed by passing the kill line.

3. When either signal is received, as long as there are projectiles remaining in the inventory, instantiate a new one at the spawn point and decrement the inventory.

Keep in mind that there are two ways to listen for signals. One is to use the Node dock within the editor, and the other is via scripting. Read more about this in the signals documentation.

HUD

The Heads-Up Display (HUD) is a trope of video game design through which the internal state of the game is exposed to the player. You have already done some work with Godot’s UI system in the first exercise. I encourage you to read about sizes and anchors and containers so that you understand the fundamentals of Godot’s UI system.

For this project, your HUD does not have to be fancy: simple, static labels are sufficient. The main idea for now is to move anything that the player needs to know away from print statements and into the HUD. Your HUD should show how many projectiles the player has remaining. You might also use it to show a score, firing angle, or firing power.

Exercise 1, Increment 3: Titles and Animation

Overview

In this final iteration, you will pull all the pieces together to make something that feels like a finished game. We are also going to step up the quality of our implementations to match the richness of our understanding.

User stories

Evaluation

The evaluation covers only the stories for this iteration. It is more important to gain practice with this iteration’s goals than to revisit last week’s.

Advice

Notice that the title screen is the first thing the player sees, but it is among the last things we have implemented. It is a common novice mistake to try to create games in the order the player experiences them. Instead, we prioritize that which has the most value to the player.

Your title screen is best kept in a separate scene from the rest of the game. One easy way to move forward is to create a new scene with the logo as a Sprite2D. Give a prompt to the user about what button to press to start the game, write a script that listens for that, and then replace the title scene with the game scene.

There are two common ways to create animations within Godot Engine: using the AnimationPlayer node or by tweening. If your animation depends on the dynamic state of the game, then the latter is the best approach.

Exercise 2, Increment 1: 2D Platforming Basics

Overview

This project will introduce you to kinematic motion in Godot Engine by building a simple 2D platforming game. Whereas Exercise 1 used the physics engine to determine the position of game elements, the kinematic approach means that you will directly, programmatically control each element.

Name your repository E2-myname where myname is your BSU username or your surname. You will use the same repository for both iterations of the project; use the release name and number to mark your submission for each iteration.

User stories

Evaluation

Platforming

2D Platforming games are a staple of the industry, and recent years have seen them as a darling of the pixel art indie scene. You have a lot of creative freedom in determining what you want to build for this project. Follow your inspiration and keep track of the goals. Be sure to keep your scope under control, though: this is a short exercise, so aim for something modest that demonstrates understanding rather than something overly ambitious that will lead you into dead ends or require inordinate effort. There will be room to expand on these creative ideas in the final project.

You can find many tutorials and samples to help you in a pinch. A general word of caution is in order: a lot of tutorials are essentially cut-and-paste exercises. These can be a rewarding for novice developers, but don’t mistake cut-and-paste programming for the kind of understanding that we expect from an upper-level Computer Science elective. As always, you are responsible for understanding and being able to explain every line of code in your system. You are going to learn much more through struggle than you will by typing someone else’s ideas.

If you possess a niggling doubt about your understanding, try one of the following:

• Consider the tutorial code to be a proof of concept. Once you know that it can be done, remove all that code and implement it yourself. Wash, rinse, repeat.
• Write a tutorial yourself about how to solve this problem. If you can explain it, then you understand it. Indeed, this is a good way to learn pretty much anything: learn it to the point where you can teach it.

Either of those options would demonstrate satisfactory understanding. After all, it is demonstration of understanding that is fundamentally the point of these exercises. Satisfying a user story doesn’t just mean “it works” but rather that you understand how the thing is done. If your code looks too much like tutorial or example code, and you don’t take the steps to show that you understand it, then you cannot in good faith claim to have met the goal, even if the “feature” is in the game. To do so would be a violation of the Academic Integrity Policy.

A Sample Path Forward

If you are not sure where to start, here is a sequence you might consider.

1. Read the documentation about CharacterBody2D so that you can understand the context in which we will be working.
2. Download Kenney’s Abstract Platformer pack and import the PNG tilesheet into your assets folder. Use this to make a TileMapLayer in your level, and draw a simple floor for your character to stand on. Remember to add a physics layer so you can paint collision rectangles on your tiles, and of course, list the asset pack as a third-party asset in your README file.
3. Create a PlayerCharacter scene that is a CharacterBody2D. Give it an AnimatedSprite child with idle and walking animations using one of the characters from Kenney’s Platformer Pack Redux. Set up a CollisionShape2D around the sprite and instance the PlayerCharacter into your test level. The template code will give you character that is affected by gravity and that can move left or right in a conventional manner.
4. Create your own input mappings for character movement to replace the UI-related template ones. Even if you use the same input methods, it will be better to have clearly named, single-purpose input mappings for character controls. Feel free to add gamepad support, but make sure keyboard input is an option.
5. Set up the character so that it is facing the direction of its movement. Note that you can flip an AnimatedSprite2D using its flip_h property, which easily turns a right-facing walk cycle into a left-facing one.

Exercise 2, Increment 2: Juice and Polish

Overview

In this iteration, you will finish up the demo you built in the previous iteration, making it into a fully-playable—though small—game.

User stories

Evaluation

Gameplay

Draw from what you learned in the first exercise to complete the player experience loop: some kind of title or introduction; active, goal-directed gameplay; and some kind of ending. You have creative control over the gameplay. Choose a common, genre-appropriate condition for ending the game, such as gathering all the collectibles or running out of time. Keep in mind the level design constraints described in the previous iteration: don’t make the game too long or too abstruse for our goals.

When incorporating assets, make sure you follow all the steps documented in the style guide, and make sure you are following the requirements of the licenses you use. You do not have to concern yourself with distributing copies of the licenses when required (as required by common Open Source licenses such as the MIT License, for example) since we are not deploying these games.

Juice

What’s the difference between a great game and a mediocre one? One of the terms used in the industry is “juice.” Perhaps the most referenced source on the topic is Juice It or Lose It. An captioned version of the video is also available. If you have already seen that one, check out Juicing Your Camera with Math or Fast and Funky 1D Transformations. Watch one or more of these videos and incorporate some juice into your game. Be sure to document, in your project report, the source for your ideas and how you implemented them.

Exercise 3: The Third Dimension

Overview

Game scientists have recently discovered a third dimension. This project will acclimate you to 3D development in Godot Engine while also reinforcing other lessons from the semester.

Tutorial

The first part of this project is to complete the Your First 3D Game tutorial from the official Godot documentation. This tutorial will be accessible to people who have never done any 3D development before. It also provides a valuable review while also introducing other important new ideas such as visibility notifiers and cameras. You should set yourself up with version control of course, even though it is not in the tutorial. I estimate the tutorial will take less than two hours; please let me know if this is way off.

Aside: If I were creating this game, I would not spawn enemies in the way they describe. Spawning along a square means that you will have a higher concentration of enemies appearing in the corners. I would instead spawn on a circle, even though it means some creatures spawn a bit off screen. Feel free to try this adjustment if you’re feeling like veering from the step-by-step tutorial.

Creative Challenge

Once you have completed the tutorial, you will see that making a 3D game is a lot like making a 2D game except for that tricksy extra dimension. Your creative challenge is to recreate a game like Exercise 1 but in 3D. That is, make a physics-based projectile game in the spirit of Angry Birds in which the player flings a RigidBody3D at some kind of obstacle.

Given what we have accomplished already this semester, you should be able to make a small game in the allocated time, complete with a title experience, a core game loop, and an ending. You have a lot of creative freedom in terms of how you execute the project, but I suggest you keep it simple: this is just a one-off exploration of 3D, and you’ll have time to create larger things later.

You are allowed to use 3D models following our usual licensing restrictions. However, I recommend blocking out the level and actors using simple geometric primitives via CSGPrimitive and its subclasses. It is fine to use these for the entire game if you so desire. Importing 3D models is a crapshoot and only worth doing if necessary to support your designs.

User Stories

Evaluation

Your grade for the exercise will be based on the following table.

The Reflection consists of one or two paragraphs in the README.md. These paragraphs contrast your experiences working on Exercise 1 and Exercise 3. When writing your reflection, we can take it as a given that you know more about Godot Engine and game programming now than you did then; the reflection should focus on the experience of working in 2D vs 3D.

Midsemester Ex(j)am

Overview

As we hit the mid-semester point, it’s a good time to look back on what you have learned and look forward to what comes next. This is the spirit of well-functioning midterm exams: they provide an opportunity to reflect on how far you have come. In that spirit, we are setting aside this week to work on a one-week jam-style project.

One of the goals of this project is to gain a better understanding of how to scope a Godot Engine project. This will help you improve your planning skills for the final project.

Another, optional way to think about this is as a time to start thinking about what you would like to build for your final project. There is an excellent quotation from Alan Hazelden that is appropriate here:

I only work on games that I believe I can prototype very quickly. If a proof of concept would take longer than a weekend, I don’t make it.

To that end, you can think about the one-week jam as being a chance to explore something you have considered for the final project. You can deploy Hazelden’s wisdom here: if a proof of concept does not fit in the one-week midsemester jam, then you probably cannot build it as a final project.

Jamming

The idea of a “game jam” is lifted from music performance, where people who may have never played together bring their instruments to a “jam session” to see what they can make. Game jams are creative exercises where the risks are low.

The jam theme will be announced in our meeting on October 10. Your task is to make a small but complete game before the end of the week, inspired by the given theme. There are no objective rules about the extent to which the theme is incorporated, but the spirit of the jam is that the theme should clearly manifest.

Since you’re putting nine hours per week into the class, this means that you’re essentially doing a one-day jam. Indeed, if you can schedule your effort so that you can literally complete the project in one working day, that would be ideal. In that case, you would not have to pay the cognitive cost of context switching.

Make sure that you keep your scope small. Part of creating any good software—and an essential practice for game development in particular—is slicing the project into small pieces that add value. Keep in mind that you’re welcome to review my family’s one-day jam games to help you think about what “small” really means. Most Ludum Dare or Global Game Jam games, for example, are significantly larger than what one can do in nine hours.

User Stories

Critique

On the day the midsemester exercise is due, you will complete a formal critique with your classmates and then share your reflection on the process.

Each student will review at least three other students’ work. The reviewer carefully plays the game and reads its implementation. Consider the file structure, scene structure, decomposition, dependency management, and general readability. Each person records at least two takeaways from the discussion and code review. Common forms for this include, “I learned X,” and, “I am eager to try Y.”

Self-Evaluation

Complete a self-evaluation report that includes the following.

• For each person that reviewed your work or whose work you reviewed, record their name and your takeaways from the discussion as described above.

• Synthesize those notes into a specific next action you commit to taking to advance your understanding. Consider explicitly connecting this with the learning outcomes of the course or to your own personal goals.

The self-evaluation is to be submitted in hardcopy at the start of your next meeting after the Midsemester Ex(j)am deadline.

Assessment

Your grade for the midsemester ex(j)am will be based on the highest row for which you satisfy the constraints. The self-evaluation will be graded via triage grading as essentially correct (3/3 points), middling (2/3 points), essentially incorrect (1/3 points), or incomplete (0/3 points).