Skip to main content

Decision Justification

Highlighting Doors

I spent a while trying to decide the best way to communicate to the player which button opens which door, and if to do so at all. This complication was influenced by research into puzzle games I conducted throughout the time I was working on the project. I learned that there are multiple approaches a player can take to solving a puzzle, some would stop and analyse to try and work out a solution, while others prefer to start interacting with the level immediately to see what happens. The first group of players would benefit from being able to immediately see which doors are connected to which buttons upon loading into a level. This could be done by colour-coding the doors and buttons or having them share symbols. An approach that would better suit the second "brute-force" group of players is providing no indication at all of which door will open, forcing the player to press play and make their robots stand on buttons to learn their effects. The approach I decided to take was a middle-ground between the two. I made it so that the ghost standing on a button in the planning phases lights up the corresponding door(s) so the player can see the button's effect before pressing play. 

Game Theme

My game was originally going to be a dungeon delving game in which you control three adventurers, working together but also betraying each other with the goal of taking all the treasure for themself, like the opening scene to The Raiders of the Lost Ark film. They could betray each other by closing doors on them, dropping trapdoors etc. However, I decided to pivot to a game that revolves around bank robbers instead. The player controls three characters that betray each other to keep the stolen money for themself, like the opening scene to The Dark Knight film. The game being set in a bank makes more sense thematically because players were initially walking into doors and exploding, but now the levels contain laser doors which can more realistically explode robots. 

Player Turning Around

I made the decision to not allow robots to turn back on themselves in their paths. If the player moves to the point they were previously at when planning the route, their last move is simply erased. This is to add a level of complexity to the game in that the player must walk in a square if they want to wait rather than just back and forth between two points. I believe this approach adds an interesting edge to the game as the player sometimes has to find the space to complete a loop with a robot before moving to the desired location. 
Labels:

Comments

Post a Comment

Popular posts from this blog

Semester 2 Submission

Project Outline This project is an exploration into player feedback and player reward in game mechanics. I have explored this by creating mechanics in Unreal Engine, imagining how they might be used in a game, and how a player might feel when using them. This exploration progressed into player reward in puzzle scenarios, which links into my current area of research. I looked into how visuals can create a language that the player will learn to understand while playing the game, and will guide them through problem solving in the game.  Project Context My semester 1 project was a core puzzle game, meaning the game was centred on a central puzzle mechanic and expanded from that point. I wanted to explore a mechanic that was more of a peripheral puzzle that exists as side quests to the main gameplay. Many popular game series have main gameplay mechanics with puzzles along the way, such as Batman Arkham, Resident Evil, and Tomb Raider. As these types of games are extremely popular and (a...
Post a Comment
Read more

Design Inspiration Semester 2

First person adaptation I decided to switch the view of my game from third person to first person. I made this decision because movement around the levels would sometimes give the player a confusing perspective (if they had their back to a wall for example). I moved the camera to instead hover above a pair of arms, that would be used to show the hand movements from a first person perspective. The challenge now was to recreate every animation in first person instead. I looked into first person games that think have good first person hand animations. I think Dishonored (2012) is one of the best example, as it relies heavy on the tools and abilities that centre around the player character's hands. One of my favourite aspects of the design is the way the knife moves from a regular to a reversed grip when entering stealth. The knife is clearly visible and serves its purpose in both grips and it tells the player they are in stealth mode without the need for another visual prompt (there i...
Post a Comment
Read more

Semester 2 Project Progress

13th January 2025 To begin this project, I am experimenting with creating different game mechanics. This is to build up a repertoire of skills in Unreal Engine and also see if any mechanics seem as if they can be adapted or incorporated into a game. I began by using free assets to make a character that can run around and execute an attack pattern. This was just to experiment with the assets and create a character that I could test other mechanics with. The first mechanic I created was one that lets the player grab an object and pull it toward them. When within a defined range, the player's reticle changes shape to indicate to them the object they're looking at can be grabbed. Grabbing it moves the object on an arcing trajectory toward the player. This could be used to grab a weapon to use, to bring an enemy closer to be attacked, etc. 14th January 2025 I added functionality for the player to hold an object and attack with it. When an object is pulled toward the player and reach...
Post a Comment
Read more