Project Title: Flashlight
Development: C# / XNA
My Role: Gameplay Programmer, Designer
Designer: Evan Schipellite
Artist: Paul Kubik
Programmers: Jake Ellenberg, Paul Kubik, Evan Schipellite
Flashlight was a 5 week project created with the collaboration of Jake Ellenberg, Paul Kubik, and myself. The gameplay is centered on a combination of AI state machines and online-multiplayer features.
In the game, 8 players compete for treasure in a haunted mansion. Players can host a lobby where Treasure Goals and time limits can be adjusted per-game. If the Treasure Goal is not reached by the end of the time limit, the player with the highest treasure value wins the round.
Players all begin in the area known as the Lobby, and from there can explore outwards into the depths of the mansion. Along the way they'll come into contact with a number of objects that can be searched for treasure. However, the player's vision is limited by the range of their flashlight, forcing them to navigate through rooms and search for objects with a relatively restricted field of view.
The field of view also prevents them from easily avoiding threats, such as Ghosts that wander the rooms. When in range, Ghosts will chase players, and if they collide, the player will lose some of their treasure and be forced to flee back to the Lobby before continuing their adventure.
As the game progresses, the earlier rooms will likely become devoid of treasures, thus forcing players to risk exploring the farthest parts of the map where greater threats and treasures are scattered.
During the design process, it was evident that the Ghosts needed to be smart enough to pose a threat, but not so much as to completely discourage the player. We wanted to ensure that, when caught by a Ghost, the reasoning would seldom relate to the player's inability to avoid the Ghost. Instead, it would typically be the result of a player failing to check their surroundings and safety before continuing to loot a room.
Ghosts have a spawn point, which also serves as their 'base' for wandering. During their Wander state, they will pathfind to a random location within a small area surrounding their spawn point. Each Ghost has a very small sight radius, and when they detect a player within this sight radius, they will attempt to pursue the player by moving toward their location. If they cannot locate the player for a certain amount of time, they attempt to wait a moment and then move to the Search state.
Furthermore, when chasing, if another player enters their vision, they will not attempt to chase that player unless their previous target has gone missing for too long. In other words, they will begin a chase by detecting a random nearby player in their sight, and then will attempt to chase that particular player for the duration, without acknowledging other entities.
In the Search state, the Ghost essentially just moves about the room for a certain duration, largely looking to chase and find a player again. However, in the event that no targets are found, the Ghost will revert to the Wander state.
When any object is opened, nearby Ghosts are notified of the room in which the Object was opened, thus enabling the Investigation State to examine the area. Once in the room, they will search it as normal in an attempt to locate the player.
The Investigate state is probably one of the most important states, simply because it enables the Ghosts to become an eventual threat that will punish careless players. After opening the first object in a room, nearby Ghosts will be alerted of the event and attempt to move toward the room. Although this may take some time, if the player continues to try and loot the entirety of the room, it is highly likely that they player will find themselves in a situation where they might encounter 1-2 Ghosts in the process.
Therefore, the act of searching encourages two basic strategies. The player can either play in a risky fashion and attempt to quickly gather all the treasure and escape around the Ghosts searching the area, or they can play in a cautious fashion by looting 1-2 items before retreating from the area before the Ghosts arrive.
The goal for the Player AI was to allow for them to convey the basic gameplay mechanics that human players would have available, while also playing in a smart enough manner as to not draw attention. Therefore, the Player AI needed to be knowledgeable enough to play the game with the ability of an average human player.
The Player AI begins by enacting the Move state, allowing it to consider its current room and nearby connections to rooms. When taking this matter into account, the Player AI also has access to knowledge concerning which rooms it has already been to. When choosing a connection, it will randomly choose from connections that it has yet to utilize. If all connections have already been visited, it will simply choose a random connection and continue from there.
After reaching the next room, the Player AI enacts the Search Room state, grabbing all available room positions to allow it to navigate around. The Player AI will search the room for a set amount of time. After the time limit, it will enact the Move state again and continue to the next room.
However, if the Player AI notices an Object in their sight, they will move to the Search Object state and move to the target. The Player AI will attempt to open the Object. Once the Object is opened, or if the Object becomes unavailable, the Player AI will return to the Search state, thus resetting the time allotted to search the area. So, for every object the Player AI finds, it becomes more likely to continue searching to find more Objects in the room.
There is another important feature relating to the Player AI states. Once it finishes searching a room, the Player AI will make a note of the room before moving on the next connection. Every time a Player AI begins searching a room, if that rooms is already on the list, it will continue to the Move state. This allows the Player AI to remember which rooms it has already completed searching, thus allowing it to quickly move through the map to new areas.
The last state is the Ghost state, which ended up being relatively simple and avoids complex checks. In the event of coming into range of a Ghost, the Player AI will attempt to map to a random adjacent room in order to avoid the Ghost.
This unfortunately means that sometimes the Player will run through the Ghost in the process, but due to the limited vision, it is not blatantly noticeable. The majority of the time, the Player AI appears to effectively find the Ghost within their vision, thus allowing them to quickly retreat to an adjacent room.
By approaching Objects and maintaining line-of-sight with the Object, players can attempt to loot Objects in order to search for treasure. If only one player was ever involved in this process, the system created would be very simple.
However, since the game is designed to be playable online, adjustments had to be made to ensure that 'claims' could be made on Objects. When a player goes to begin opening an object, they check the availability on the Object. Each Object has an ID, and as long as the ID slot is occupied, the Object is available and can be opened. After the availability is assessed, the player sends information over the network to confirm the claim of the Object, thus notifying all other network players that the Object is no longer accessible.
If, during the process, the Object becomes unavailable, the player then immediately withdraws any attempts at claiming the Object, as it is highly likely that the change occurred from a recent packet arrival. Due to the time between packets, it becomes evident that a network player likely began claim of the Object earlier, and although immediate information may not have been available, after receiving the packet the player must account for the fact that another player acquired claim before them. This process works similar for the AI Players, although all their data is merely managed by the Host.
When a player leaves the game, the current Host takes note of that player and creates an AI Player based on their information. This AI Player is then added to the list, and the Host manages updates and pack sending as it normally would. Upon Host change, the game is designed to allow easy transitions, as the new Host can effectively take control of the current AI and continue gameplay as normal.
As far as Clients are concerned, Ghosts and Player AI are essentially additional networked players that require prediction and smoothing. The Host maintains all AI decisions, while the Clients receive simple information regarding positions, animation states, and status updates.
Flashlight was not only a fun game to design and playtest, but the process of challenging our team to tackle AI development in an online environment was also rewarding. Given the specified time limit, we were effectively able to generate level creation, AI functionality, 2D lighting, and game networking to build a enjoyable multiplayer treasure hunt game.