Task Description

Play the educational game GameDevDojo. The game is designed to guide users through key principles of game development by interacting with predefined game objects, adding components, and adjusting settings to solve challenges. This process offers a hands-on experience with real-time feedback to enhance your understanding of game development mechanics.

The GameDevDojo-Application can be found and downloaded here.

Instructions:

1. Start the Game
   • Launch GameDevDojo and enter your matriculation number to begin.
   • You must complete the lower levels to unlock the higher ones progressively.
2. Level Progression
   • For each level, manipulate the predefined game objects by adding components or adjusting settings according to the level objectives.
   • Upon completing a level, you will receive an individual code that you must submit as proof of completion.
3. Game Components and Interactions
   • The game provides a separate view for selecting new components to add to game objects.
   • Access component descriptions by clicking the help icon (?) next to each option.
   • To add a component:
     • Click on a game object to open its settings in the component view.
     • Select a component from the dropdown and press the “add” button to attach it to the object.
   • Modify settings by selecting/unselecting or enabling/disabling components in the component list.
4. Feedback and Subtasks
   • If you correctly configure a component, the game will provide visual feedback (a confetti effect near the help button) to indicate that you’ve completed part of the task.
5. Help and Guidance
   • Click on the “help” button in the lower-left corner to open a help view that provides additional guidance.
   • The help view displays the accomplishment status of each game object and its required components:
     • A green indicator shows a fully configured object.
     • A red indicator means components are missing or misconfigured.
   • Use the help feature to check for missing components, incorrect configurations, or to get more information about specific components.
6. Level Completion
   • Ensure that all necessary components are added and configured accurately to complete the level and receive your unique completion code.

Submission

In TeachCenter, submit the code you received upon completing the highest level you solved (e.g., level 5). This is required in order to receive the assignment points.

Task Description

For this task, you have to create a Pokémon-like game in Unity. Using the provided framework (available in TeachCenter), you must extend the project by implementing the features listed below. This will give you a better understanding of working with an already existing project and how to expand it.

As a sidenote, to progress the dialogue or confirm a selection, press ‘Z’ or ‘Y’, depending on your keyboard settings. The framework can be found on the TeachCenter.

Before you start…

Note that it is mandatory to list credits in your game! Even if you made all (or some) assets yourself, put yourself on the list. We should be able to locate all the assets you used online through the credits you provide (do not just reference a website). You may bind a key to open a separate canvas listing all credits.

Before you start, create a private repository on gitlab.tugraz.at and add both tutors as maintainers: Maximilian Wlasak (@7D0A13A51BCEBD14) and Ivan Jurinić (@2CB5598FFD28F44A).

Game Design and Development is a Master’s course within the field of computer science, so we expect everyone to be proficient with Git. Please be aware that points will be deducted if the following criteria are not met:

• ) Meaningful commits: The repo should show multiple commits, which also indicate the progress that was made along the way. A minimum of five commits is expected.

• ) Invalid project: Furthermore, we expect the repo to be a functional Unity project at all times.

• ) Maintainer assignment: Make sure to set an appropriate duration for the role of maintainers. For the entire course, we (the tutors) need to be able to access your repository.

Game Implementation (30%)

The following three features must be implemented (12% in total):

• ) New Pokémon and Moves (4%): Choose your favorite Pokémon and the most interesting attacks you know and bring them into the game. The Pokémon, as well as the moves, can be taken from newer or older game generations (- you can find all the sprites here). You can also come up with your own ideas. Make sure to create two new Pokémon and two new moves.

• ) Additional Pokéball (3%): Some Pokémon require a special Pokéball to catch them more easily. Implement three new Pokéball. For an overview, here is a list of all known Pokéball in the games. In this task, you may also use your creativity and come up with your own designs and purposes. However, please ensure that each creation delivers a meaningful input to the game. We cannot give you points for this task if we cannot determine the Pokéball’s purpose or test it. Every Pokéball must be in the inventory and ready to use from the very beginning.

• ) New Area (5%): Adding new areas will introduce an explorative aspect to the game, making it more distinctive and therefore more fun. With this task, you have to implement one unique area of your liking. This can be a desert, a new city, a snow area, or whatever you can come up with. Here, it is important to use a different tileset (different textures). The Pokémon spawning must also differ. Different region – different Pokémon encounter. You can either use the ones you created or opt for existing ones. It is also very important that the new area is not too small. It should be at least as large as a full screen. Furthermore, the user should be able to switch between the two regions at any time and must not be stuck in one region.

Additionally, you need to choose three of the following features to implement (18% in total):

• ) Gym and badge (6%): To make your game more challenging, implement one gym. Like in the original games, you must also be able to earn a badge once the gym leader is defeated. Thus, an implementation of a showcase of the user’s badge is needed and should be available at all times (out-of-combat only). The gym leader can be defeated only once, and you only earn the badge if you win. The gym itself must be an indoor area. There’s no requirement to include a labyrinth, puzzle, trainers, etc., before the gym leader battle, but you’re welcome to add them if you’d like.

• ) Mini-Map (6%): The bigger the map, the more confusing orientation can become. To help the player, you can implement a map showing the player’s current position in a top-down view. The player should be indicated in some form, e.g., sprites. The map should also display the names of the routes and different areas. Create a static map that is always shown in the corner of the game. Make sure the map is the appropriate size and zoomed in enough on the player (do not just show the entire map). However, don’t zoom in on the player too much, as that would defeat the purpose of the map. There is also no need to show the map during combat or indoor regions – so don’t.

• ) Weather (6%): Add one dynamic weather condition (e.g., rain, snow) that affects the battle mechanics. Some Pokémon perform better in specific conditions (like Water-type Pokémon in rain), while certain moves might be stronger or weaker. Implement region-specific weather conditions that change over time – sometimes sunny, sometimes rainy, sometimes nothing special is happening. The weather should not affect the entire map, but rather a single region or parts of it. Furthermore, there must be full-screen visuals (like in the original games), both out of combat and in combat. You may want to consider particles. Weather in-combat should only show when the text message stating its effect is displayed (like in the original games). If you are unfamiliar with the original weather design of Pokémon, you may want to check out this video. Especially the first few minutes can be very helpful to get a grasp of the idea. It is not required to implement a move that changes the weather during a fight, but you are welcome to do so nevertheless.
  
  DEBUG MODE: Implement the possibility to toggle this feature (e.g., via button click). The tutors should be able to test the functionality without waiting. This debug mode must only be available in the debug build. You can take the already implemented debug mode as a reference.

• ) Day/Night Cycle (6%): Add a day/night cycle with additional features. You are required to introduce special events at specific times. Some trainer battles, as well as the spawning of certain Pokémon, must only be available during the night. The map should also visually indicate whether it is night or not by making every outdoor region slightly darker. Lastly, also add a clock that shows the current in-game time (which may differ from real time). Based on that, set the day/night cycle accordingly. The clock may be visible at all times (except in combat) or be viewable via a button press, similar to the map. If you want some inspiration, check out the clock from Stardew Valley. Note that for this task, it is only required that the clock shows the time (not the current weather or such).
  
  DEBUG MODE: Implement the possibility to toggle this feature (e.g., via button click). The tutors should be able to test the functionality without having to wait. This debug mode must only be available in the debug build. You can take the already implemented debug mode as a reference.

• ) Following Pokémon (6%): Some of you may know that there are some generations out there, where the first Pokémon in the team used to follow the user. Now this will be your task to implement. The sprite of the very first Pokémon is supposed to follow the steps of the player. The Pokémon must have some kind of running animation (use of animation / different sprites) and must follow the steps of the player. It is NOT sufficient if it simply floats behind the player or even moves diagonally. The player can’t do this, so their Pokémon can’t either. The Pokémon is also supposed to stop behind the user and not run into them. This follow-procedure must be done with every in-game available Pokémon (also self-added ones). So, any Pokémon that is first in the team and has more than zero HP must be able to follow the player.

Important: Assembly definition files are part of the framework to organize scripts. These must not be deleted, and the use of assembly definition files is mandatory!

Report (5%)

In addition to two Windows builds, you must also submit a report of the game. This report should cover all the features you implemented, including some pictures for each one. Also, give a short description of the implementations. Only features mentioned and described in this report will be counted as completed (e.g., special features of Pokéball). This report doesn’t need to be done exceptionally well. However, it should be logically structured, well-organized, and easy to understand.

Submission

Once you have implemented your game, create two Windows builds. One release version, one debug version, and upload two independent zip files containing the builds and the report on TeachCenter within the deadline in the schedule.

The zip files should be called i02-pokemon-release-########.zip and i02-pokemon-debug-########.zip. The report shall be named i02-pokemon-report-########.pdf.

######## is your matriculation number, for example i02-pokemon-release-12345678.zip, i02-pokemon-debug-12345678.zip and i02-pokemon-report-12345678.pdf.

Task description

Form a group of four people and decide on a game idea that satisfies the topics and guidelines. If you don’t have a group already, you can find group members on Discord.

Create a repository on gitlab.tugraz.at and add both tutors as maintainers: Maximilian Wlasak (@7D0A13A51BCEBD14) and Ivan Jurinić (@2CB5598FFD28F44A). Consider the criteria that were mentioned before (also in terms of listing credits).

Describe your idea in a few sentences, you can add a small sketch if you want to. Also, decide on a fancy name for your group. The description should provide a general overview of your game, offering enough detail to give readers a clear sense of its core concept, gameplay mechanics, and overall theme. Please don’t forget to state your topic in the report as well.

Topics & Inspiration

This year, the main topic is Shift of Perspective. Your game should include this topic in some way. You are free to interpret it to your liking. However, if you are unsure whether your idea fits the narrative, don’t hesitate to ask the Tutors for confirmation.

Besides the main topic, you must also choose one of the topics listed below. The game should be based on your selected topic. If any questions arise regarding the topics, feel free to ask during lectures or directly on Discord. This semester’s topics are:

• ) Science
• ) Nature
• ) Mental Health
• ) Astronomy

Note: Only a certain number of groups can select each topic. Here counts – First Come, First Served. The selected group on TeachCenter determines the chosen topic.

Guidelines

Your game must cover the following topics in some way:

• ) Diversity: Keep important aspects such as race, gender, culture, etc., in mind.

• ) Accessibility: Motor (e.g., more than one type of input device), Cognitive (e.g., contextual in-game help), Vision (e.g., color blindness safe colors), Hearing (e.g., subtitles), General (e.g., difficulty levels). You can draw inspiration from here.

Submission

Create a PDF with the naming convention:
game-idea-##.pdf

## is your group number, hence group 5 sends the file game-idea-05.pdf.

First, join your group on TechCenter, then upload the file and enter your group name within the deadline in the schedule.

Task Description

Use the Game Design Document Template to create the first draft of your game design document. Keep the topics and guidelines listed above in mind. Don’t forget to update the title page and add a short abstract. This document should be updated as you progress through the project, e.g., to reflect the use of new tools. Doing so during development will significantly reduce the effort required at the end of the project. The Game Design Document must represent the game’s final state at the end of the course (see [G-05] Full Game for more information).

It is also mandatory to track your time. You must be able to compare the estimated time with the actual needed time at the end of the course.

Submission

Create a PDF with the naming convention:
game-design-doc-draft-##.pdf

## is your group number, hence group 5 sends the file game-design-doc-draft-05.pdf.

Upload the file to TeachCenter within the deadline in the schedule.

Task Description

Create a prototype according to the topics and guidelines. The prototype should show what your game will look like (e.g., blockouts of levels), and it should demonstrate the core mechanics of your game.

We don’t expect a fully fletched game, however, we do expect that every prototype shows the core mechanics in the form of a playable level. You may want to focus more on the mechanics than on textures for this prototype.

Create a page for your game on itch.io, and add a short description and screenshots that promote your game. If you want to make it private, make sure to submit a link that allows viewing of the game.

Submission

Upload a Windows build to TeachCenter and add a link to your itch.io page within the deadline in the schedule. The zip folder of the build should be called prototype-##.zip.

## is your group number, hence group 5 sends the file prototype-05.zip.

Task Description

Test a game from another group. The QA Strategy section below outlines what to look for during testing. You should test the player experience, usability, and QA (alias bugs).

Provide a small report (.pdf) with a list of issues you’ve found:
[ID / Type of issue (1-3) / Description of issue / Severity of this issue (A extremely bad – C nice to have) / Tips for improvement]

You should list at least 10 findings.

Example:
#4 / 1 / The game controls are not clear / B / Explain the controls on the start screen
#5 / 3 / Driving into a tree for 100 times crashes game / C / Find root cause for the crash

Your group will be assigned to another group. This will be announced on Discord. Once you know your partner group, it is your duty to contact them and trade games. You may use the corresponding GDD channel directly on Discord. If your partner group should not respond, please contact the tutors.

QA Strategy

Type 1: Player Experience (Game Design)

• Fun?
• Confused/bored/frustrated?
• Design good?
• Idea clear?
• Mechanics?
• Level too long/short?
• Do you understand the game?

Type 2: Usability

• Interface intuitive?
• Easy to use?
• Controls understandable?

Type 3: Quality Assurance (Severe Bugs)

• Test intensively
• Find bugs

Submission

Create a PDF with the naming convention:
qa-##.pdf

## is your group number, hence group 5 sends the file qa-05.pdf.

Upload the report to TeachCenter and send it to the other group via e-mail or Discord within the deadline in the schedule.

Task Description

Fully implement your game and create a presentation for the final exhibition. There are (almost) no concrete requirements of what the final game must include, since every game varies.

HOWEVER, every game must include sounds (SFX) and music. All in all, the game should be well-rounded. If, during development, you realise that time is becoming short, you must leave features behind. Logically, core mechanics MUST remain.

Presentation
Short “pitch” (max. 4-5 minutes!) – try to “sell” your game/game idea. The presentation should include 4-6 screenshots and a gameplay video. The video should only show the most crucial parts of the game (max 1 minute). For the submission on TeachCenter, the video should be 2-3 minutes long, showing a short gameplay section (also including the crucial parts).

Exhibition
Please bring your own equipment for the exhibition. In case you are missing hardware, contact the tutors in advance. If the exhibition cannot be held at the university, there will be an online exhibition.

Deliverables

• Final Game Design Document as PDF
  • It must represent the final state of the game
    • Actual implemented UI
    • Used tools and needed hardware
    • Active Controls
    • …
  • No future tense, ala “It will have X” but rather “X was implemented“
  • Comparison of estimated time and actual needed time
• Your group presentation
  • 4-6 screenshots
  • a small video of the gameplay (ca 2-3 minutes)
• Windows build and source code (full Unity project) of your game

Submission

Upload all deliverables to TeachCenter within the deadline in the schedule. The build and source code should be submitted in zip files called full-game-##.zip and full-game-source-##.zip, and the group presentation must be named presentation-##.[pptx, pdf, ...].

## is your group number, hence group 5 sends the file full-game-05.zip, full-game-source-05.zip and presentation-05.pptx.

Update the details about your game on your itch.io page and – if you want to – join this year’s game jam. We encourage you to upload the video and a build of your game to itch.io to make it available to a broader audience.

If you want to develop your game further and publish it beyond the scope of this lecture, we are happy to help and answer any remaining questions.

For the first time, we also have an additional (optional) way to show off your games! In cooperation with the Game Dev Students, we provide the opportunity to port your games onto their arcade machine. Such a port comes with limitations, the biggest being the available control scheme. The arcade machine is equipped with one joystick, six main buttons, and two menu buttons (start and exit), with all of these elements duplicated to support two-player games.

Please keep in mind that this is completely optional and does not affect grading in any way (does not award any points). This is just an opportunity we want to provide you to enrich your portfolio and also gain some reach for your projects!

If you are interested, contact either Maximilian Wlasak or Ivan Jurinić for further information.

The second chance assignment can be used by everyone who received a negative grade on the individual assignment (achieved points < 50% of the total points). Upon completion of this assignment, the course may still be graded positively if enough points are earned.

The general task is to develop a classic 2D side-scrolling Shmup (“Shoot’em up”, think R-Type, Gradius, etc.) game in Unity. Every feature that needs to be implemented has already been selected and described in more detail below. You may want to check out this tutorial: https://pixelnest.io/tutorials/2d-game-unity/.

Note that at least 50% of points must be reached in order to receive a positive grade.

The following characteristics of a Shmup must be included:

• Side-Scrolling manner: The player character must move through the level from left to right.
• Boundaries: It should be possible for the player to move freely on the entire space (Arrow keys or WASD) and not be affected by gravity. Furthermore, it must not be possible to exceed the screen borders.
• Projectiles: The player must be able to shoot projectiles from their current location.
• Enemies: Enemies must enter the screen from the right-hand side. In some way, they must damage the player over time (either with projectiles or by collision). However, by firing projectiles at the enemies, they also take damage / get destroyed.
• Lose condition: Once the player reaches 0 hp, there must be some indication that the game is lost, e.g,. Game Over-Screen. Once the lose indication is shown, the player must be given the option to replay the game with no changes to the previous run (different amount of hp, different sprite, different lose/win condition, …).
• Win condition: The longer the player survives and/or the more enemies they kill, the higher their score will be. The score must be shown at all times during the run and must be part of a high-score-based system. During the session, the high score must be displayed and used to motivate the user; e.g., if a new run beats the high score, it should say something like “New high score: XXXX”. The high score system may reset when the entire application is restarted.

Additionally, the following features must be implemented. Note that those are not optional and must be included just like the features listed above:

• Enemies dodging projectiles: This feature adds the ability to the enemies to dodge incoming projectiles. Dodging needs to be a reaction to player projectiles, moving the enemy out of the way. Teleportations are also allowed if they are visually distinguishable as a mechanic and do not create other problems, like enemies teleporting into the player or out of bounds. Random movement does not count as dodging.
• Ship selection: Add a simple player character selection screen with two choices before starting the game. The two selectable player characters should differ in visuals, movement speed, projectile damage, and health points.
• Special projectile: Add a special projectile the player can shoot, e.g., a homing projectile, which automatically targets the nearest player, … .
• Collectibles: Implement collectibles, such as coins, that the player can gather to improve their score. Collectibles must spawn over time, as the user progresses in the game.
• Main Menu: There must be a main menu before the actual game starts. This menu must contain the following information: your name, matriculation number, and how the controls in your game work. There should also be a button for starting the game, showing the credits, and quitting the game.

The visual assets and sounds can be created by yourself however you like, or you can use freely available asset packs (if the license allows it and you credit the creator correctly). If you made assets yourself, give yourself some credit. Either way, as with the Pokémon game, credits are mandatory!

In addition to the build and source code, you must also submit a report of the game. This report should cover all the features you implemented, including pictures for each one. Also, give a short description of the implementations. Only features mentioned and described in this report will be counted as completed. It is not necessary for this report to be done exceptionally well. However, it should be logically structured, well-organized, and easy to understand.

Upload a Windows build and source code to TeachCenter within the deadline in the schedule. They should be submitted in zip files called shmup-build-########.zip and shmup-source-########.zip. The report shall be named shmup-report-########.pdf.

######## is your matriculation number, for example shmup-build-12345678.zip, shmup-source-12345678.zip and shmup-report-12345678.pdf.

You must also create an itch.io page to release the game. To do this, you must create a WebGL build. Make sure that the tutors can access the game at the end of the deadline, either directly via a link or via an additional password. The itch.io information must also be submitted on TeachCenter within time.

An extension of the deadline for the second chance assignment is not possible!

Overview

Game Design and Development is a lecture with integrated exercises (VU, continual assessment). You will be deregistered from the lecture if you do not submit any assignments (partial course requirements, Teilleistungen). The examination is considered to have started when the assignment [I-01] GameDevDojo or any following assignment has been submitted.

You need to submit all assignments to receive a passing grade.

Each assignment will be graded based on how accurately you fulfill the tasks of the assignment description. For game assignments, the game design document, game elements, game design guidelines, usability, polishing, balancing, and presentation can also be considered. Readability, formatting, and how precisely the topic is addressed in written assignments can be additional decisive factors. For some assignments, you can earn bonus points; this is designated in the assignment description. The assignments are weighted according to the weighting table.

A total of 100% (excluding bonus points) can be achieved. Upon receiving 50% or more, the student receives a passing grade. The grading key denotes which percentage corresponds to which grade.

Note: Individual part and group assignment must both be completed positively (>= 50%)!

Late submissions are not considered by default. Contact the tutors (before the deadline) if you cannot submit an assignment in time, we might be able to find a solution.

Partial course requirements are corrected after all partial course requirements have been completed.

If you decide not to finish the course after submitting the first assignment considered in the examination, contact the tutors so that the grouping can be updated. If there are any open questions, feel free to contact us.

Plagiarism

If unauthorized aids are used or cases of plagiarism occur (e.g. a written assignment contains parts copied from another source or referencing is not done properly, or a game contains 3rd-party assets without proper attribution) a grade of “U (Ungültig/Täuschung)”, meaning that the grade is invalid, is given for the course (§5 TU Graz Statute Part Plagiarism). The student is then requested to attend a hearing at which they are confronted with the incident.

Weighting

Grading Key

A collection of games created in previous GameLabGraz lectures.
2022/23 GDD1 Games
2021/22 GDD1 Games
2020/21 GDD1 Games
2020 GDD2 Games
2019 GDD1 Games
2018 GDD2 Games
2017 GDD1 Games

Johanna’s personal book recommendations and books that the lecture draws inspiration from.

Jane McGonigal – Reality is Broken (+++)
One of my favorite books. Jane McGonigal offers inspiration and ideas for using games in different contexts. Reads like a novel and avoids theoretical aspects.

Jesse Schell – The Art of Game Design (+++)
This is the book I am using a lot for my lecture. Very good summary of the most important design aspects from different perspectives (technical, player psychology, and other design considerations).

Scott Rogers – Level Up (2nd Edition) (+++)
Also, an excellent book on game design. I’ve especially enjoyed the bonus chapters with inspirational lists for environments, game mechanics, and different templates as an inspirational resource for your games.

Jeremy Gibson – Introduction to Game Design, Prototyping, and Development (++)
This book also gives a very nice introduction to game design techniques, but in a more practical manner. The main part of this book is a unity and C# tutorial.

Raph Koster – A Theory of Fun (++)
I simply love the style of this book. It has comics and sketches?

Flow – Mihaly Csikszentmihalyi (+)
Wonderful book (THE book) about the flow experience, with neat examples from all kinds of fields.

Katie Salen & Eric Zimmerman – Rules of Play (+)
Very interesting book on game design, with many practical examples.

[I-00] Photo by Tim Mossholder on Unsplash
[I-01] Photo by Aidan Granberry on Unsplash
[I-02] Drawing by former Tutor Emma Stettner