Zachary Faulkner:

Zachary focused his time on designing and programming all of the Menu Screens and In-Game UI. He was also responsible for certain effects related to changing between characters, such as camera filters and particle effects. Zachary also was one of the primary contributors to the project documentation.

---

Logan Lafauci:

Logan primarily worked on core mechanics such as camera controls and movement. Logan also focused on polishing the game by adding animations to the characters and updating abilities like the rogue's dash and climb. He created the moving floor puzzle for the rogue’s dash and the pressure plate puzzle for the knight’s boulder pickup and place mechanic. He also playtested, looked for bugs, and reported/helped to fix them. Logan worked with Gerald to create simple puzzles to show off the character mechanics for a basic demo and base game level.

---

Gerald Anthony:

Gerald was one of the primary contributors to game development. He spent his time developing the core gameplay of our game, Echos. This includes creating the functionality for the special abilities and movement of our characters and also setting up the environment itself. Gerald set up the project in Plastic SCM so that the project could be shared with all four of our game developers. He also made the second level of the game which provides the player with a more physically and mentally challenging puzzle to solve.

---

Dean Compton:

Dean focused on updating the website and documentation of the project. He was one of the primary contributors to the report documents as well as the project presentations and OPPM sheets. He helped set up GitHub and set up access for the team so that everyone had access to the website files and backup files for the Unity game. In addition, he helped polish the visual aspects of the game such as texturing the map with open source unity assets and reconfiguring the castle to look realistic and feel more immersive.

---

Shamar Thompkins:

Shamar spent his time working on Blender models for characters and the skeleton objects meant to be interacted with by the character. He made the skeleton models for the wizard, knight, and thief characters. Also, he made some prototype models and some finalized models for all of the characters, however, the player models could not be used yet due to animation difficulties (Further discussed in the trade-offs).

The player starts the game with a simple intro scene where it is explained to them that they are a thief looking for treasure deep in the castle. They are told they will encounter the dead along the way. From there the player will spawn into the castle where they will be forced to navigate, with trial and error, through the rooms of the castle. They must learn the mechanics of the game as they progress through the game. There are prompts that will help the user when they approach key items that will help them progress through the rooms. There are various skeletons scattered in the castle, some of which the player can interact with to “echo” to the past and control this person before they died. These characters from the past will help the player progress through the castle by granting them unique abilities to solve puzzles specific to each character.

Playable Characters:

There are four playable characters: the Knight, the Thief, the Mage, and the Adventurer. Each of these characters has their own unique abilities and mechanics. The Adventurer is the default, and all of the other characters use the Adventurer's base movement and mechanics. The player can press F as any character to interact with certain objects such as doors, buttons, and items. The Adventurer has one ability, Echo, and the other characters have two each, their Q abilities and their E abilities.

---

The Adventurer:

The Main Character, a hooded figure who is trying to find the treasure. Their ability is Echo. When the Adventurer is near the skeleton of one of the three playable characters, they can press 1 to take control of that character. Pressing 1 while controlling one of these characters returns the player back to controlling the Adventurer, leaving the skeleton in the location where the player was when they pressed 1.

---

The Knight:

A strong and powerful knight who died protecting the Castle. Abilities revolve around the Knight’s strength.

Q - Shield: When Shield is activated, the knight takes out their shield and defends themself with it, blocking fireballs. The Knight can still move and use other abilities while using shield.

E - Lift: When close to a boulder, the Knight can use Lift to pick up the boulder and carry it around with decreased movement speed. Using Lift while holding the boulder places the boulder down in front of the Knight

---

The Thief:

A nimble thief who died after being trapped in the castle when it was attacked. Abilities revolve around the Thief’s mobility.

Q - Climb: When close to a vine covered wall, the Thief can use Climb to climb the wall. If the Thief uses Climb while on a wall, they will let go of it, Falling to the floor if they aren’t on the ground.

E - Dash: When dash is activated, the Thief dashes forward a short distance. It then goes on cooldown for 2 seconds. Dash can also be used in the air.

---

The Mage:

An intelligent magic user who died while trying to cast a spell to save the castle. Abilities revolve around magical utility.

Q - Fireball: When Fireball is activated, a fireball is launched in whatever direction the mage is currently facing, and Fireball goes on cooldown for 2 seconds. The fireball travels in a straight line until it comes into contact with an object. If the fireball hits a box, the box is destroyed.

E - Rat: When the Rat is activated, the mage turns into a rat. As the Rat, the player has faster movement speed and a smaller collider, which allows them to enter areas with smaller openings. If Rat is activated while the player is a rat, the player turns back into the Mage.

---

Obstacles:

There are several obstacles the player must pass to complete the game. Some block the player’s progress.

---

Hazards:

There are two implemented hazards, fireballs and lava. When the player comes into contact with a hazard, they are brought back to the start of the current level.

Fireballs are shot from launchers and travel in a straight line until coming into contact with an object. They have the capability of breaking boxes, but there are no puzzles that currently use this.

Lava is stationary and placed at the bottom of pits which the player can fall into. It is used in conjunction with moving floors to make traversing it more difficult.

---

Locked Doors:

There are three types of locked doors, each being used primarily by a particular character: Button Doors, Key Doors, and Pressure Plate Doors

Button Doors require the player to locate and press one or more buttons, sometimes in a certain order. These doors are primarily used for the Mage.

Key Doors require the player to locate and pick up a key, and then bring it to the door to unlock it. These doors are primarily solved by the Thief.

Pressure Plate Doors require a pressure plate to be weighed down by a boulder. These doors are used for the Knight.

Story:

The original plan for the story was cut back heavily in favor of working on the core gameplay and mechanics. Originally, there would be a dialogue between characters, simple cutscenes, and a more nuanced story. Instead, we settled on a more straightforward story, told through an Intro Screen which quickly caught the player up to speed.

---

Player Models:

We intended on using the cohesive player models that Shamar made to make the game feel more fun and animated, however, when implementing them with the open-source animations that we wanted, the rig/armature of Shamar’s models would not cooperate with the animations. For this reason, we decided to just use some basic open-source player models for now so that the game would have a more complete look with working animations. It would be intended that later we could install the correct player models with working animations to make the game look exactly like how we wanted.

There were several takeaways we had from the playtests, and we used the feedback to focus on where we needed to work on the game moving forwards. One of the biggest takeaways was that our game had a lack of clarity with regard to what the player was supposed to be doing.

---

More Informative UI:

The Midterm Demo had practically no in-game UI, aside from a simple cooldown bar for the fireball ability. This lack of information led to the player not being aware of what they could do at any particular point in time. This was addressed by adding character portraits to show which character you were, adaptive ability icons to show what abilities you had as the current character, and a help tab in the Pause Menu to help the player figure out what their abilities do.

---

Simplifying Controls:

Another issue which was compounded by the lack of an informative UI was the confusing control scheme. In our demo, many of the abilities and mechanics were each bound to their own unique buttons which were only used for that particular mechanic, leading to far too many buttons. In conjunction with no UI to tell you what abilities you had, it became unclear what the player was supposed to do. This was fixed rather simply, by consolidating ability buttons together and organizing them in a more understandable layout. This was also helped by the UI, which showed buttons for each ability.

---

General Stylistic Improvement:

Our midterm demo was lacking in general when it came to overall style and appeal. This was caused by a multitude of factors, most of which were linked to a lack of assets and finished textures. We ended up remedying this by adding an array of assets for environmental textures, character models, object models, audio, etc.

Puzzle Finite State Machine:

Init: Enter/spawn in castle room
Switch: Find skeleton to switch to character in the past
Play: Use the character's abilities to explore room(s) and solve puzzles to progress through the castle
Solve: Solve puzzle and either (1) enter the next room, (2) go to the next level, or (3) enter the treasure room where you beat the game

---

Switch Animation:

The animation for the character switching was an imported particle system which plays when any of the switch character functions in SwitchCharacter are called. The particle system was attached to the prefab of all of the playable characters so that it always plays at their location.

---

Audio Effects:

Most of the audio effects were achieved by tying the sounds to certain in-game events. For instance, the door opening effect was tied to the interactions with the doors so that when a door is supposed to open, the event will also cue an audio player to play the correct sound effect. The dash, fireball, and boulder pick-up all work similarly to this. There is also an audio player in the background at all times so that the background music can be played and repeated throughout the game.

---

Open Source Visual Resources:

Characters Particle Effects Props Chest Crates Wall and Floor Textures Shield

---

Open Source Audio Resources:

Gameplay Music Main Menu Music Lift Rock Echo(Switch) Dash Fireball(Cast) Fireball(Impact) Mouse Walking Door

Echos is structured around the Global script SwitchCharacter, which is connected to an element called GameManager which keeps track of which character is currently being used, as well as which character is being switched to. Echos first loads the base player movement and controls and then uses SwitchCharacter to activate the correct character’s scripts, as well as set the camera to follow the correct character. Each character's attributes are set up in their own particular script, which is activated by SwitchCharacter. That character’s script then takes over, loading the correct movement, commands, abilities, etc.

In addition, there is a script for each character's ability, which is called by each character’s script when the ability is used. There are two scripts for movement: PlayerMovement and NewPlayerMovement. NewPlayerMovement is set up around the camera, PlayerMovement is simple tank controls. NewPlayerMovement is the primary movement control scheme used by most characters, though is less stable. PlayerMovement serves as a more stable base movement in case there are bugs with the regular movement. There are also scripts for various interactable objects.

---

User Interface:

Echos currently has a simple UI with placeholder particle effects in the background, with a ‘Play’ button, an ‘Options’ button, and an ‘Exit’ button, all with their features implemented. The options button brings you to the options menu, which has unimplemented settings that, in the finished game, the user will be able to interact with to change settings such as volume.

---

Setting/Map:

The map is divided into three sections, with a puzzle in each area. The Skeletons of the other three playable characters are laid out in their separate rooms. There is a weight and pressure plate puzzle for the knight, a transformation puzzle for the wizard, and a climbing puzzle for the thief. At the end of each puzzle, the player can find a key, which they can use to unlock doors.

Zachary Faulkner:

Zachary focused his time on designing and programming the Menu UI, as well as setting up all of the functionality for it. He also was in charge of the in-game UI, such as the cooldown UI for the mage. Zachary also was one of the primary contributors to the Progress Report Document.

---

Logan Lafauci:

Logan primarily worked on new camera controls and movement. He created a simple pressure plate puzzle for the knight’s boulder mechanic. He also playtested, looked for bugs, and reported/helped to fix them. Logan also worked with Gerald to create simple puzzles to show off the character mechanics.

---

Gerald Anthony:

Gerald was one of the primary contributors to game development. He spent his time developing the core gameplay of our game, Echos. This includes creating the functionality for the special ability and movement of our character and also setting up the environment itself. Gerald set up the project in Plastic SCM so that the project could be shared with all four of our game developers.

---

Dean Compton:

Dean focused on updating the website and documentation of the project. He was also one of the primary contributors to the progress report document as well as the project presentation and OPPM sheet. He helped set up GitHub and set up access for the team so that everyone had access to the website files and backup files for the Unity game.

---

Shamar Thompkins:

Shamar spent his time working on Blender models for characters and the skeleton objects meant to be interacted with by the character. He made the skeleton models for the wizard, knight, and thief characters. Also, he made some prototype models for the characters themselves which are still being conceptualized.

---

User Interface:

Additions to the UI will include more cooldown bars for new abilities as they are added, a portrait of the character which is currently being used by the player, more options, as well as functionality for those options, in the settings menu, as well as the ability to pause the game. Dialogue functionality would also be implemented so that an actual story can be told.

---

Echos is a top down 3D adventure/puzzle game which revolves around the player taking control of a thief who is attempting to steal a treasure from a ruined castle. The player will encounter skeletons of those who died in whatever conflict left the castle ruined. The player will gain the ability, “Echo.” This will allow them to interact with a skeleton to see the moments leading to their deaths, and they will then be able to take control of those characters and play as them in the past. The actions the player takes while controlling these characters of the past will affect the present. The player must utilize this ability to solve puzzles that will lead them further into the ruins, and in the process they will save the characters whom they possess.

Siege left the castle ruined and destroyed. The MC is an outlaw. They heard of a treasure which was lost in the ruins of the castle, and they are exploring the ruins in order to find it. They somehow discover the Echo ability, and use it to navigate the ruins. At the end of the game they will face a choice between taking the treasure or leaving it be.

Many people were killed in the siege. The player will be able to encounter three of the perished which they can then use Echo on: a Knight, a Mage, and a Thief.

Echos will have a somewhat cartoonish, yet serious art style. The general layout of the castle will remain the same between the past & present, but the aesthetic and design will change.

The Present will have a solemn air to it, being mostly quiet and empty. The castle is in ruins, any life that once inhabited it having long since absconded. The game will take place on a quiet and cloudy afternoon, and as such the lighting will be gray and moody. The general color palette will be a mix or dark grays and light blues/greens.

The Past will instead be energetic and chaotic, with distant fires and shouting in the background. As it is actively under siege, the castle will have sustained damage, but will still retain some of its glory as it has not yet been left abandoned. The scene will take place in the afternoon, the general color palette will be more shadowy oranges and yellows.

The main goal of the game is to reach the end while saving the characters along the way. The MC's main drive will most likely differ slightly from that of the player, as they will be driven more by the treasure than by saving the other characters.

Echo, the ability which the player will use to solve puzzles, will have several functional components.

• During gameplay, the user will encounter skeletons in the castle with a visual aura about them.
• To use Echo, the player must walk up to a skeleton with an aura and interact with it.
• A visual effect will take place, and the scene will change to the past.
• After a character is saved through Echo, a short cutscene will play showing them escaping their predicament, and their skeleton will disappear to signify that they have been saved.
• Each character will have different mechanics available to them which the Player can utilize.
• The first time the Player switches to a new character, instead of gaining control of that character, they will instead be shown a short scene of the character and their death, upon which the Echo will end and the player will take back control of the MC. This will serve to introduce the player to the Character, and the very first time the Player uses Echo it will reinforce that they are taking control of the character in the moments before their death. Any time the player uses Echo, the player will instead gain control over the character and can begin solving the puzzle.

Each Character has unique abilities which they can use to navigate and interact with the world. Some of the actions performed by these characters will have permanent consequences which affect the present.

• The knight can move large stones into specific positions to open up new areas/to complete a basic puzzle.
• Utilize enemy weapons to solve certain puzzles.
• Rogue can use a quick burst of speed to maneuver through certain areas on the map. (Maybe can reach areas unreachable without the speed boost).
• Simple matching/memorization minigame.
• Mage can either create or take over a small animals movement so that he can use it to reach unreachable areas.
• Have some items transfer from room to room that can be used to solve similar puzzles.