Hello, dear friend, you can consult us at any time if you have any questions, add WeChat: daixieit

Homework #3 : Game Loops & Text Adventures

The story of most game engines begins with a game

Estimated Time Investment                       Typical Time Allotment               Team Size

            10 hours                                           7 days (check schedule)                       1

A genre long gone (but-not-forgotten), Text Adventures– games played entirely via text / terminal–  enjoyed their heyday in the 1970s. Developers created vivid worlds and adventures with little but the written word (play one of the early ones, Colossal Cave Adventure (left), here). This genre will provide a gentle environment in which to experiment with core game engine concepts before the introduction of realtime 2D rendering in a couple weeks. (Left image by andiwm2003)

Pitch

Homework #3 : Game Loops & Text Adventures is the fi rst core, programming-intensive assignment in the course. It marks the beginning of our C++ game engine code bases – code that will be upgraded and iterated on for theremainder of the semester. Students will practice low-level basics of game development in the context of a storied (and programmer-friendly) genre. Future weeks and assignments will bring dramatic improvements to flexibil ity, expressiveness, aesthetics, and performance.

Purpose

Most game engines begin as a single, one-off game. The famous Unreal Engine, for instance, began as the     code base for Unreal – a 1998 fi rst person shooter game to rival id software’s Quake. When Epic MegaGames  (their name at the time) began to re-use Unreal’s technology for future projects, and even license it to external developers for usage, their code base transformed from that of a game to a reusable engine. Succinctly put –

“Make a game, then make a second game. The stuffyou re-used is the game engine.”

This assignment will--

●    Mark the beginning of students’ custom game engine code bases (via a simple text adventure game)

●    Introduce the classic (Input -> Update -> Render) game loop .

●    Introduce the concept of Actors.

●    Introduce the course autograder and multiplatform build process (Visual Studio, XCode, Make)

●    Introduce “Test Driven Development” (TDD) as a means for iterative (step-by-step) software development.

Tasks

Study the Autograder and Assignment Submission Process

● Autograder General Guide

○ Windows / Visual Studio Guide

○ OSX / XCode Guide

○ Make Guide

Acquire Assignment Dependencies

New : GLM 0.9.9.8 (“GL Math”)

● A header-only library that provides useful mathematical structures and functions, such as glm::ivec2 (an integer vector-2 useful for representing 2D integer coordinates). You will need to tell your compilers / IDEs where to look for these header files. Begin using it via #include "glm/glm.hpp"

○ Note : In C++ "vector" typically means std::vector (AKA, “dynamic array”). Here we refer to the mathematical / tuple meaning of “vector” (“2d vector”, “3d vector”, etc).

○ Trivia : GLM data types / functions are also used in the GLSL shading language, which may prove useful for writing shaders in the future (though OpenGL may deprecate… eventually).

New : MapHelper.h

● An assignment-specific helper file that includes a struct definition for Actors, a hardcoded scene (map), an array of hardcoded Actors, intro / outro message strings, etc.

NOTE : Do not use absolute file paths when configuring location of include / header directories.

● These will break on other machines / other filesystems. Use $(ProjectDir) / $(PROJECT_DIR) / other macros to establish relative paths instead.

Recommended .gitignore

Test-Driven Development

Each of the following test suites has a particular focus, and requires the implementation of particular features. You are recommended to clear all test cases in a given suite before proceeding to the next. If you break an older feature or introduce a bug, you may rely on older test suites to warn you of such regressions

(You may read about test-driven development, and why it features heavily in industry, here).

Test Suite #0 : Initial Render

This suite contains basic tests exercising your text engine’s render / input loop with a non-moving camera and one input command– “quit”.

1. When the engine launches, it must print the game_start_message from MapHelper.h

a. All output in this program must be via the standard output stream (std::cout)

2. Next Line : Print the initial render of the world (scene)

a. The camera’s initial position is (19,15) (the player’s position) and is 13x9 in size.

b. This is what the first render of the scene will be.

i. “p” = “player”, “s” = “spartan”, “f” = “friend”, and “b” = “blocking wall”

ii. You’ll make a real render later. For now, print initial_render in MapHelper.h

3. Next Line : The engine must then print health : x, score : y

a. x = the current health of the player, which starts at 3.

b. Y = the current score of the player, which starts at 0.

4. Next Line : The engine prompts the user by printing Please make a decision...

5. Next Line : The engine explains Your options are "n", "e", "s", "w", "quit"

6. If the player types quit the engine must print the game_over_bad_message from MapHelper.h

a. After doing so, conclude the program. Don’t print a newline after the ending message.

7. If the player enters any command besides quit (even if it isn’t a valid command) go to step #2.

Test Suite #1 : Basic Player Movement

This suite contains basic tests exercising your text engine’s player movement (and thus camera movement) functionality, introducing the “n”, “e”, “s”, and “w” commands. You’ll need to leave initial_render behind.

1. If the player inputs one of the cardinal directions (n, e, s, w) they must move one cell in that direction.

a. The player is represented by the character p and is always in the camera’s center.

b. The full scene layout is described in the hardcoded_map of MapHelper.h

i. Note : You won’t be drawing the entire map– just the camera area near the player actor.

c. Actor locations are defined in hardcoded_actors of MapHelper.h

i. Acquire the glm library to use glm::ivec2 data types (integer 2-tuples)

d. Example : the player inputs e as their very first move.

Test Suite #2 : Wall Collisions

This suite contains basic tests exercising your text engine’s concept of collision detection on blocking walls.

1. When the player actor chooses to move onto a cell marked b, do not move the player actor.

a. You may check hardcoded_map for b (blocking) cells.

Test Suite #3 : NPC Dialogue

This suite contains basic tests exercising your text engine’s concept of NPC dialogue.

1. If a non-player actor is in a cell adjacent to the player actor, its nearby_dialogue string is printed.

a. The message should print on its own line immediately after the render and before health.

b. “Adjacent” means the 8 cells surrounding the player cell.

2. If a non-player actor is on the same cell as the player actor, its contact_dialogue string is printed.

a. The message should print on its own line immediately after the render and before health.

b. When multiple actors share a cell, display the one ordered last in hardcoded_actors

3. Message ordering

a. If multiple messages occur in one turn, they are displayed in the order the actor was loaded. (ie, the order of the actors in the hardcoded_actors array)

4. Special Case

a. If an npc’s nearby or contact dialogue is the empty string “”, don’t print.

Test Suite #4 : NPC Collisions

This suite contains basic tests exercising your text engine’s concept of collision detection on blocking actors.

1. When the player actor chooses to move onto a cell that contains a blocking actor, don’t move.

Test Suite #5 : NPC Movement

This suite contains basic tests exercising your text engine’s concept of npc movement / velocity.

1. After receiving the user’s input on a turn, update the positions of all actors in the order they are loaded.

a. If an actor is the player actor, update it in the manner described in Test Suite #1

b. Non-player actors (NPC) alter their position in the amount of their velocity property.

i. If NPC cannot move to a cell (blocking wall or npc), invert / reverse their velocity. The Actor does not move after reversing velocity, but may begin moving again next turn.

Test Suite #6 : Dialogue Commands

This suite contains basic tests exercising your text engine’s implementation of special gameplay commands affecting health, scoring, winning, and losing.

1. If a nearby or contact dialogue contains health down the player’s health decreases by 1

a. If health reaches or drops below 0…

i. Print all the dialogue, then health and score, then game_over_bad_message

2. If a nearby or contact dialogue contains score up the player’s score increases by 1

a. A given NPC actor may only trigger a score increase once.

3. If a nearby or contact dialogue contains you win then end the game in victory.

a. Print all the dialogue, then health and score, then game_over_good_message

b. game_over_good_message may be found in MapHelper.h

4. If a nearby or contact dialogue contains game over then end the game in defeat.

a. Print all the dialogue, then health and score, then game_over_bad_message

b. Do not adjust health in response to a game over command.

5. Note : You may assume no piece of actor dialogue contains more than one command.

6. Note : This is also the first test suite that will take you to the edges of the map.

a. Having weird issues? Be sure you aren’t rendering nulls past the end of the map.

Test Suite #7 : Integration and Performance Tests

This suite contains large, advanced tests that stress your text engine’s correctness and performance.

Notes on Performance

● The staff solution answers “Is there a blocking actor / wall at location (x, y)” in O(1) time.

● The staff solution uses std::stringstream to minimize usage of std::cout.

● The staff solution avoids making copies when passing variables to functions.

● In general during this course, you are encouraged to trade memory for runtime performance.

Reflections

While you wait for the autograder to check your work and post your results, consider the following ideas –

●    Imagine we do some real-world playtesting. How long would a game like this entertain players?

○ What features / mechanics would you add?

●    If a player really enjoyed the game and wanted to create their own map …

○ What would they need to do?

○ What would they need to know?

○ What would they need access to?

●   The contents of MapHelper.h makes it somewhat easy for us (the engine developers) to add and tweak the map, actors, etc. Would this be possible for a normal player?

●    How would our work as engine developers be complicated if our engine was not turn-based, but real-time (60 “ updates” per second, rather than waiting for the player’s input)?