Project Gaslight was created as the FYP for my Bachelors in Computer Science degree. The name comes from the frequent occurrence of the three playtesters jokingly accusing each other of gaslighting, as all three experienced different enemy placements in the same level.

That occurrence sums up what the project set out to do, namely:

• Take player data
• Figure out most encountered patterns
• Shake up the patterns to keep the players on their toes
• Players will figure out new patterns
• Repeat from Step 1

The Game

Initially planned to be a full turn-based RPG with multiple levels, Project Gaslight The Game was scoped down to just one small level and a simple Attack/Defend system in favor of Project Gaslight The Tool. The players take control of multiple pawns and try to get to an objective while avoiding/defeating enemies.

The Tool

When a player completes the level, their patterns of movement are noted and passed off to a server and converted to a heatmap. A remix event is triggered, which takes all the player activities since the last time this event was triggered and combines them into one heatmap like so:

The server has been given the information of the levels through an automated process during design time.

As such it knows certain safeguards such as:

• Do not put enemies into walls
• Do not move an enemy if it obstructs them from a path
• Do not move this enemy, they are static
• Do not make all enemies converge on this location (difficulty setting)

It then takes the enemy placements (uploaded automatically during design time) and converges them slightly towards the player paths:

With that done, the tool stores these new placements for The Game to receive whenever a level is started, reverting to the original level in case of errors:

Additional Tools

Hosting

For hosting, I initially used Azure with .NET ASP, but switched to Flask and MongoDB for flexibility, speed and better OpenCV support. Since the project already had a JSON parser, it was quite easy to translate.

Testing

As the presentation requirement of the project shifted to technical implementation, I had to get a lot of data in a short time. Playtesting would not cut it; For testing purposes, I created a Krita-based pipeline to create test data.

The absurdity did not go unnoticed by the advisors. To make testing levels without a dedicated level editor, I created a workflow where you'd make the level in a photo editor like so:

And it would be imported into a level in-engine, with support for further modifications.

Blade Wolf from Metal Gear Rising said it best.

Pathfinder

I had the idea for Project Gaslight in an earlier semester. During my Artificial Intelligence course, I had the idea almost fully planned out. But I knew as much that I would need a custom pathfinder for this project. My requirements were:

• Traversal costs defined by the character, circumstantial information ("a player character was last seen here!"), the level, as well as other characters of the opposing faction.
• S P E E D

I implemented the pathfinder using the Job system in Unity for extremely fast performance.

Future work

Initially I planned on using the FYP as the base for some future games. I wanted to complete the game I initially pitched, and create new games in the same setting such as Metalborn (entry upcoming).

However, because of the runtime fee incident I felt it was an insecure base to have the project in Unity. Before I could create anything based on it, I believe I must port it to another engine (Godot or Unreal for example). Even after the runtime fee was drawn back by a ton, I would not feel secure with having Unity as the base for a personal project.

Extras

"Why didn't you use a server version of the game?"

A server version would have reduced a lot of effort of keeping the levels consistent. But, as a CS FYP, the project is a technical work. So, as my advisor Dr. Safdar Abbas told me, as much of it that can be used independent of the underlying system should be made that way. The same server can be used with any other engine.

This was an amazing decision made shortly before the Unity runtime fee debacle.

Reception

The initial project was very popular among my peers as a very rare video-game type project. I had no trouble finding playtesters for the initial prototypes. However, after the scope down, the reception became much more mild as the project became more and more abstract and technical. Up until the mid-defense, the project was very much game focused.

Then the focus was shifted onto the technical side. By creating more tools to assist the developers in designing levels.

Final word

This project was my first attempt at creating a game with a novel concept. While it did not pan out as I'd hoped, I gained a lot of insights into the process itself. I also learnt my dream job would be to make outlandish programs.