Hexxing Hunt
Overview
Hexxing Hunt is a game I worked on with 3 of my classmates in our 2D Game Design class.
The game is free and open-source, and it has its own website and trailer! Check it out here!
Concept
The prompt for this project was to create a splitscreen game with a “hide-and-seek” vibe. The game is designed for two players, and the screen is split accordingly. Each player is either the witch or the witch hunter. The goals are simple: the witch needs to survive until the timer runs out, and avoid being burned alive and all that. The witch hunter needs to hunt down that witch!
Inspiration
Our group was heavily inspired by games like Screencheat and in particular, the popular Garry’s Mod gamemode Prop Hunt, for reasons that will probably be immediately obvious.
Development Process
I was the Lead Developer for this project. I also contributed to the art, and in particular did some quick work on some of the animations.
Gameplay
The witch hunter simply needs to touch the witch and press a button to end the hunt. The witch has one primary defense mechanism: they can shapeshift! They can transfigure themselves into different items to blend into the area.
Art
Notable Features
Camera System
The witch hunter has a pretty standard tracking camera, which leaves the character in the middle of their screen at all times.
The hunter can always look over at the witch’s screen, which was something we were expected to specifically design for. We realized early on that if we used the same tracking camera for the witch, it would be immediately obvious which object the witch was disguising themselves as.
So, we designed our camera system to have a second mode, where the camera only moves when the witch moves from one area to another. This makes it impossible to discern exactly where the witch is at any given time, or what object they are currently disguised as. Obviously, it is still possible to discern what room the witch may be in, but our map is designed with duplicate room designs to help mitigate this.
We’ve noticed during playtests that the fast pace of the game also means that screencheating is not as helpful as one might expect. You have to focus on your own screen to move and hunt effectively!
Here’s how we implemented the room lock camera system:
Initially, we were planning on manually finding the coordinate boundaries of each room, and inputting them into our code to make a very long chain of else if statements that would move the camera according to what coordinate bounds the player was currently in. This would require us to find the X/Y coordinates of 2 corners of every room, and the coordinates for the center of each room. Not only was this tedious, it was imprecise.
So instead, we implemented a system using 2D Box Colliders. Each room has a box collider to approximately represent its volume. I say approximately, but this method was much more precise and easier to adjust than our previous attempt with manual X/Y coordinate plotting.
We put our map together as one image, but we made a Prefab object for each room that only contained the BoxCollider2D component and our script, and then took 9 of those prefabs and nested them under our main map object. Note that the box colliders have “Is Trigger” checked, as they are going to act as triggers for a function in our camera script, and not affect or impede movement in any way.
Now for the actual script. Two nice things about having a box collider represent each room: for one, instead of writing a bunch of if statements, we can instead use the Unity physics engine’s built in OnTriggerStay2D function. And two, we can use boxCenter to quickly calculate the exact center of the room’s box collider on the fly.
// this function is called every frame where the gameobject has another gameobject inside its bounds (the gameobjects are set to behave as triggers in this case)
private void OnTriggerStay2D(Collider2D other)
{
// and when it's called, we check to see if the colliding object is the witch...
if (other.gameObject == witch)
{
// if it is, we move the camera to position (in this case, the center of the Collider volume)
activeCam.transform.position = new Vector3(boxCenter.x, boxCenter.y, -10f);
}
}
Each room prefab object has this script attached to it. The witch and activeCam variables are public attributes that can be accessed through the Unity editor. We could configure which player and which camera the script modifies, but there’s no need to here, since we are always checking to see if the witch player has entered the space, and we want to move the witch player’s camera.
In a nutshell: each room checks to see if the witch player is currently inside its bounds. If it is, move the camera to the center of those bounds. Otherwise, no movement.
Reflections
Challenges
Among other things, Unity Collab is…frustrating. There is a 3 person cap for the education version of Unity Collab, which was a problem because we have a team of 4! Definitely going with Git next time.
More specifically, engineering a solution for the room-based camera took a fair bit of time and a lot of googling. Some of the methods we found that initially looked promising turned out to have been deprecated or were only available to 3D box colliders.
Next Steps
This game won the class vote for best midterm game, and we will soon be installing it on the Interactive Arts arcade cabinet in the Decker Library lounge!
Source Code
Here’s the source code for this project!
