Code Red was a Capstone Project for Next Level Arcade from the Arts and Entertainment Technologies major at the University of Texas at Austin. Five others and I worked together to bring an experimental game to life in a single semester. For this project, I was the programmer and also assisted with the Mechanics design. This game used Projectors to bring a format that was not limited to a single screen, using the entire surface of an object to its fullest potential.
We used two Projectors to cast our game onto a rectangle. The projectors were cast onto all visible sides of the rectangle, so only five sides were used. The design challenge for this project was to use the projectors and the rectangle to make a game that utilised the space we had.
To go into further detail, the game we made is called Code Red, a two-player cooperative firefighting arcade game. Player one would control the firefighter putting out fires, and player two would control the person saving people from windows. The players will work together to put out all the fires and save as many people as they can within a set time. To utilise the rectangle, players would have to manage the fires and people on all the sides of the building, excluding the top. To do this, players are given two controllers, one in each of the opposite corners from where they are playing, and they have to switch between them to manage all the fires and people. To do this, the players had an object they had to place on a pad near their controller. This would indicate which controller they were using and which side the character should be on. Players would play until the timer ends, giving them a score and showing a high score.
Designing and programming for this game was challenging for a few reasons. As I programmed and tested, I was only able to test on a single screen, which prevented me from seeing exactly how it would work on the rectangle. This was due to the rectangle and projectors not being set up in time, and ultimately, the task fell to our group to make and set them up, which was initially supposed to be provided to us. The other challenging aspect was that, since I had to test on a single screen, it was sometimes hard to understand how the game would work in 3D space. Due to these hurdles, I used ChatGPT to help me write code I specifically asked it to generate. In other words, GPT was used not to generate ideas for new scripts, but to help me write out ideas I had as scripts. By using this method, I was able to quickly develop and test scripts and ideas without spending hours researching through forums and search results.
There were three challenging aspects of the mechanics that took the most time to get right. First was the method for getting a player from one edge of the screen to the other seamlessly. The second was how to bind a player to specific screens depending on which panel and controller were activated. Lastly, it was how the players would shoot up there with water and a ladder to put out fires or save people. These three mechanics worked together to create a fun game and to utilize the rectangle to its fullest potential.
To solve the first issue, I initially thought of having multiple players on and off-screen, so when the player would run off-screen, the pre-placed player would enter. The major flaw with this idea is that I would eventually run out of players if someone kept running in a circle. What I ended up doing was making it so a clone of the player would spawn after the initial player got close to the edge of the screen. It was timed so that once the player began to move off-screen, the clone moved on at the same time. After a point, to prevent the player from running off too far or walking back on screen too early, the initial player was despawned after a certain point, and a new clone would be made if the player went back to the edge.
The next issue was keeping the player bound to the correct side of the screen. With the way the game was set up, players could only see two sides of the screen at a time. To give extra tension to the game, instead of making it so the player could freely move anywhere they wanted, we used sensors and objects to tell the game which controller the player was using, and created a border that would affect each player differently. This border kept the player on the two sides of the screen that they could see. When they lifted their object off the sensor, the controls would lock and would only unlock when a player placed the object on one of their designated sensors again. The player's character would automatically move within the border of the two screens that the player would see, then control would be returned. This prevented players from moving off-screen unintentionally and also losing the character.
For the last issue of the water and the ladder, it was not so much of an issue with functionality, but the appearance was less than desired. The way I had made the water and ladder function was exactly the same, except one could put out fires and the other saved people. The problem came in when I executed that function, and what it did to textures. The water consisted of two cubes, one for the top of the water that would interact with the fire, and the other below it, that would stretch along the y-axis. While this method worked well, it would cause the texture of the stretching box to stretch along with it. I was hoping to solve these issues before showing it to a live audience, but in the end, I ran out of time and decided that while it looked odd, functionally it worked and was still fun.
other than those three things, the other features implemented where a timer, a system that handled the rounds, cutscenes that would play at the beginning and inbetween rounds, a system that spawned fire and people in random placed and at certan times, and a high score system. the fire and people spawner would spawn a certan ammont of each on all sides of the building, only spawing more if all of one type was put out or a round eneded. one big hit when people played was the high scores that where shown at the end of a game. The top 5 scores were displayed at the end of each game, and the participants' scores would be shown regardless of placement. It kept the competitive spirit of the game alive and drew in more people to participate.
The game is still very much in a prototype phase, with many bugs that greatly affect gameplay and outcomes still present. Despite that, the game did very well with players and was a great success. Hopefully, in the future, the existing bugs will be squashed, and new elements will be added. There were many ideas and features that we still wanted to add, but simply did not have the time to include.
The Link to our group documentation and game itself is here!
