CS315 Game Programming: Final Project

Contents

• Schedule
• Overview
• Pitch
• Plan
• Development

Schedule

Overview

The final project will be our primary focus for the last several weeks of the semester. It is the primary mechanism by which you will demonstrate what you have learned.

Getting ready for the final project requires us to spend a week on the Pitch and the Plan. These two steps need to completed in that order: you can begin the Plan only after having completed the Pitch.

Your final project must be built with Godot Engine. There are neither genre nor format restrictions, although the content and form must abide by the style guide.

Be careful and think clearly about scope. By the time you start the final project, you will have developed a sense of what you can accomplish in a week. A clean, complete small game is preferable to a sprawling, buggy, unfinished one. Keep in mind that under normal circumstances, n people can accomplish less than n times what one person can accomplish because of communication costs. This is in part what Fred Brooks recognized when he famously commented that adding people to a late project makes it later.

Beware of asset-heavy projects or projects that require sophisticated level design to be enjoyable. Creating assets is not within the learning objectives of the course and so do not “count” as productive time on task.

The best strategy for the final project is to recreate the gameplay from a classic arcade game. I would not even try to innovate here: it is a worthwhile exercise to recreate a classic, successful design. Of course, we do need to obey relevant intellectual property restrictions, so you cannot use original assets, marketing material, or otherwise copyrighted work from the arcade era. However, it is the expression that is copyrighted, not the idea of the game. For example, you are free to make a modern implementation of Missile Command as long as you don’t use that game’s copyrighted materials.

Pitch

Project pitches and team formation will take place in class according to the schedule. For this meeting, each student will prepare and present a Pitch Poster. These are physical posters on at least letter-sized paper that will be posted around the room. All text must be at least 24pt with 36pt or larger preferred. Handcrafted posters are welcome; they do not have to be digitally produced. AI-generated posters will be subject to severe mockery.

The goal of the Pitch Poster is to express a game idea to our learning community. Ideally, you will use the Pitch Poster to help form a team around your idea, potentially merging it with others’. Everyone is expected to complete a Pitch Poster as an academic exercise even if you do not have a particular game concept you wish to pursue.

You will have two minutes in class to give a brief oral summary of your concept.

A satisfactory Pitch Poster will contain the following:

• Working Title: A memorable name to reference this idea.
• Concept: a sentence or phrase that describes what the player does and toward what goal.
• Key features: Technical and/or gameplay features
• Visual direction: The poster design should clearly express the intended visual direction and aesthetic for the game.

David Osario’s One-Page format might provide some inspiration.

The poster will be evaluated following triage grading. A full-credit submission will:

• Contain all the formal elements described above
• Meet the minimum paper and font size requirements
• Demonstrate an appropriate level of compositional care
• Present a concept that clearly ties into the final project requirements and would meet the style guide content restrictions

Immediately after the poster presentations, we will form teams for the final project. Each team will consist of one to four students from the same section. The project you choose to pursue does not have to be strictly one of of the pitches that was presented: it can be something new or an amalgam of those presented—but keep it simple!

If extenuating circumstances require you to miss the meeting, contact the professor as usual. Include a copy of your poster, a written description akin to an oral presentation, and whether you want to join with another team or pursue your project individually.

Plan

Once your team has agreed upon your direction, you can move on to the planning phase. As Benjamin Franklin said, “If you fail to plan, you are planning to fail.”

We are following an iterative and incremental approach that is characteristic of agile software development. This means that we will work in defined timeboxes (iterations), and the software will be built up in coherent pieces (increments) that add value to the player.

The Final Project Methodology documentation in our GitHub organization explains how to complete your project plan.

Each team will present their iteration plans according to the schedule. Your first iteration plan presentation must include a digital slide that meets the Pitch Poster requirements for your project. If you are pursuing a project exactly as it was pitched earlier, you can simply reuse the Pitch Poster and remind the audience of the concept.

Development

Following an agile approach, each iteration produces a small game. There should be nothing half-done in the first increment: every exposed feature is fully implemented, although some assets may be placeholders.

Each increment will be showcased in class following the schedule. If extenuating circumstances prevent you from presenting, contact the instructor as soon as practicable to coordinate an alternative.

Personal Progress Reports

Personal progress reports are designed to hold you accountable to making steady progress throughout the increment. They are to be submitted in hardcopy at the start of the meeting on the corresponding deadline.

The report addresses the following questions:

• What did you commit to working on this week?
• What did you accomplish this week?
• Who helped you this week, and whom did you help?
• What tutorials and resources did you use this week, and how were they helpful?

Answer each question separately, clearly, and explicitly. Don’t make the reader go hunting for the details in a paragraph of prose.

A personal progress report is worth full credit as long as it matches the required format, is clearly written, and clearly represents an appropriate weekly effort.

Keep in mind that, as a three credit-hour class, you are expected to invest nine hours of effort per week. This counts time pursuing course goals, and those course goals deal with technical aspects of game programming. If you choose to spend time creating assets or designing levels, that is your choice, but don’t confuse this effort with that spent pursuing our learning objectives.

Increment Assessment

Meeting the following criterion earns a D or better grade, and failing to meet it earns an F grade.

• The repository is in the course organization. It contains a README.md file in its top-level directory on the default branch. This file lists the names of all team members and includes a self-assessment—a clear and explicit indication of what grade you expect based on these criteria.

Meeting all previous criteria as well as the following earns a C or better grade.

• You have followed our style guide.
• There is a core loop: the game begins, the player takes action toward some goal, there is some source of conflict, and the game ends. The player can play again without restarting the application.

Meeting all previous criteria as well as the following earns a B or better grade.

• The game features appropriate music, sound effects, and graphics.
• Gameplay instructions are included in the game.
• The game’s goals are explicit or inferred from the theme.

Meeting all previous criteria as well as one or more of the following earns an A.

• Use the state design pattern, derkork’s State Charts library, or another approved approach to manage an object with three or more states.
• Incorporate custom shaders to accomplish aesthetic goals. Document your shader’s intent and operation clearly in your EVALUATION.md file. Note that simply copying shaders from a repository like GodotShaders or generating one with an AI is not sufficient to satisfy this criterion.
• Manage agent behavior with a behavior tree using bitbrain’s beehave library or another approved package.
• The game is publicly released on GitHub Pages or itch.io. Do not host the game directly from our course organization because these repositories will be removed after the end of the semester.