Shoot First, Ask Questions Later!
Shortly after the second round of playtesting, I was finally able to get my hands on the Light Gun from the school. Funnily enough, the Light gun was considered school equipment, so every week I would need to ask a student worker to “check out my gun again”. As soon as I got home, I got right to work setting up the Light Gun. (…And testing it out with a few rounds of Point Blank 2 and House of the Dead, of course. You would too!) I was up till about 2 AM making tweaks both in engine and with the Sinden software, and by the end I had gotten the game working with the Light Gun with a surprising amount of accuracy. I had been careful to do my research on how the gun works and write the code for the game in such a way that the existing scripts I had would work when the gun was in the mix without any issue.
The next round of testing provided a lot of valuable feedback. It seems that I had tuned the games to play well with a mouse, but the added physicality of the gun made some of the games a bit harder than intended. With this feedback in tow, I had what would become the whole game in an early prototype phase. For reasons we’ll dive into shortly, I made the difficult decision not too long after to cap the games at the three I had made and turned my focus onto polishing what I had and ending the development of the process at the end of the semester.
OVERVIEW
In contrast to the “guns-a-blazing” action of the first minigame, the second minigame “Sharpshooter” is one that demands steady aim and patience. In this minigame, the player has a limited number of bullets to shoot a fast moving fly as it zips across the screen before time runs out. Seeing as players have limited ammo here, they must be careful to take their time and make their shots count while still completing the task within the time limit. Easily the hardest minigame out of the three, yet one that many play testers seemed to enjoy for it’s challenge. I fear I made it a liiiiittle too hard the first week, but hey! That’s what playtesting is for! The week after, I added a third game: “Wanted!” Where the player has to pick out and shoot a target character, while being careful to NOT shoot any of the other bystanders. Similarly to “Sharpshooter”, the player has a single target to shoot, but now there are other “bystander” targets that get in the players way that will instantly end the game if shot instead of the target. The targets move across the screen more slowly than the fly, but they often weave between each other and overlap, leaving the player to find the right moment to strike! Feedback on this game was generally positive, but not as many people had something to say about it as they did the others.
While development was straightforward for the most part, I’d be lying if I said there weren’t several pain points and a myriad of issues that I had faced along the way. As fun as it was to work with, it was arguably the Sinden that gave me the most grief.
The Sinden uses a Camera to detect where the screen is, which caused some unique issues. For one, there would be instances in which the cursor would jitter like crazy between two points across the screen. This was because the Sinden would sometimes detect the wall behind the monitor as the screen if the wall was a light enough color, confusing the gun as to where exactly it is being aimed. Another issue would arise depending on the physical space. The gun functions best when it is being aimed about two times the length of the display away. For example, for a 24 inch monitor, the player must aim the gun 48 inches away from the screen. These issues were always solvable with some creative thinking and tinkering with both the Sinden software and with the physical space the gun was being used in. For the first issue, I had found that changing the color of the Sinden border from yellow to a darker color would help alleviate some of the jitter, but the wall would still sometimes get registered as the monitor for being so bright. The solution that I found helped the most was physically dimming the lights in the room. Dimming the lights in the room or turning off a set of lights would make the white light bouncing off the white walls a lot less harsh, allowing the Sinden to register the monitor properly.
This is but one Sinden related issue that I had to dedicate precious development time towards. If the gun wasn’t as close to 100% accurate as possible, the game would be unplayable.
Beyond the hardware side of things, scope was the other biggest sticking points for me not only in terms of design but asset creation as well. At the beginning of the semester, I had imagined SFAQL as a somewhat robust game with an arcade ladder, 10+ minigames, and even a “Skill analyzer” course that tested players on specific skills like reaction time, accuracy, and more. My idea going into this was that I’d recruit some students for help with art, and maybe a programmer or two… Unfortunately, by the time I had the ball rolling enough to consider recruiting any more people to the team, most of the artists and programmers had found other projects to work on and didn’t have the bandwidth to be able to work on both my project and the one they had begun to help with. I ended up having to ask other producers and team leaders to send artists my way if there was an off week where there wasn’t any work for them. I was able to get some great work from the artists that were able to help, and one graphic designer in particular was able to stay on the project for the long term which was a huge help. The process of describing the asset needed, the artist coming back with a sketch, giving feedback, and then finalizing the asset would often take several weeks which lead to things coming down to the wire in the art department.
Seeing as I was working by myself for the most part, I had to scale the idea back quite a bit. After a long talk with my Professor about the game, my plans for it, and what I wanted to get out of the project, I made the difficult decision to make a compact yet polished project that I could wrap up by the end of the semester and move onto something that would hone in on some more specific areas that I want to specialize in. As much as I would have loved to make a full blown spiritual sequel to Point Blank, I think I made the right choice in trimming the scope down a bit.
A group of play testers trying out the prototype. Even before the Light Gun was implimented, feedback was generally positive!
A video I took to show my friends and colleagues after I had gotten the gun working. I was pretty excited, If you couldn’t tell.
CHALLENGES
A snippet from the original Game Design Document, You can see remnants from the original (admittedly large) scope here. “Less is sometimes more” was a valuable lesson here.
FINAL THOUGHTS AND TAKEAWAYS
Although I wasn’t able to realize my initial vision in the exact way I was hoping I would, Shoot First, Ask Questions Later was still a project that I am incredibly proud of. I learned so much in such a short timeframe, many things that I carry into my future projects. The biggest takeaways for me were:
Playtest early, playtest often.
Self explanatory, but VITAL. It’s all too easy to design yourself into a corner by building atop a foundation that your players think is flawed or not fun. The more feedback you get as early as you can, the easier of a time you have formulating a plan of action.
Never give up, but don’t be afraid to take a step back.
There were plenty of weird and odd bugs that sprang up on account of the hardware used, many of which caused me to repeatedly bash my head into the metaphorical wall, getting nothing done, and getting upset. Learning to walk away for a moment to “reboot” your brain and come back to face the issue with a fresh set of eyes was a big deal for me. When you notice yourself getting frustrated at a coding or design problem, take a walk, drink some water, and come back!
Leave no stone unturned!
When it comes to working with physical hardware especially, there are so many factors that can cause errors. I would have never thought to try dimming the lights in the room to fix my jitter if I hadn’t been complaining about them because of the headache the bright lights were giving me. Try everything!
Don’t be afraid to kill your darlings
Sometimes, less is more. Don’t be afraid to have these conversations with yourself and your team. Getting married to any one idea can be dangerous, because it makes it that much harder to let it go in the event it isn’t working. It’s always hard in the moment to get rid of a feature that you really love, but I always find myself happy with my work at the end.
As we close out, I’d like to share one final experience I had regarding this project.
As the semester went along, I found myself comparing my game to others in the class. These were games with bigger teams that were progressing much faster than mine. I would find myself walking away from class each week proud, but still somewhat doubtful about my work and how it measured up to others.
Eventually, I had the opportunity to show SFAQL at the Chicago Toy and Game Fair, which I originally almost skipped over. Although, I noticed I wasn’t working late on Sunday as I normally do, which I took as a sign to sign up for a time slot to show my game.
Things began, and they were slow-going. We were positioned next to a “Jedi Academy” stand that taught kids how to use lightsabers. I figured no kid would want to play my game when they could learn to become a Jedi. But, to my surprise, kids kept funneling in. First a handful, then a few more would see it as they passed by and join in the line too. Eventually, I had a decent little line going, just to give my game a shot.
I wish I had the words to describe how it felt seeing kids line up to try my game. MY GAME! One pair of brothers found themselves wrestling over the controller after they each got a turn, both wanting so badly to try again. I’d be lying if I said I didn’t get a little emotional after that.
I didn’t get into game development because it was going to be easy. In fact, making a game is one of the hardest creative ventures out there. If I wanted easy money, I’d go into a different field. But it was that moment, with the two kids fighting over the Sinden Lightgun because they so badly wanted to try my game, that cemented in me once more that this is what I want to spend the rest of my life doing.
A photo of me at the Chicago Toy and Game Fair, showing off my game to young gamers! Playtesting pro tip: Offering candy is a surefire way to get people of all ages to try your game!
One of the most memorable parts of the entire experience, for me, is seeing my game in the yearly graduation video that contains snippets of the student projects that gets shown at graduation. If you couldn’t tell, I was a little excited.
Just a little.
The minute I found out that my school had a Sinden Light Gun available for use, I immediately began prototyping the game that would become Shoot First, Ask Questions Later. Inspired by arcade shooting classics like Point Blank, Ghoul panic, and Quick & Crash- Shoot First, Ask Questions Later tests the player’s accuracy, speed, and on-the-fly thinking through goofy, non violent minigames that are designed to be controlled with a Light Gun (or mouse!)
Despite many challenges both on the hardware and software end, Shoot First, Ask Questions later (Referred to herein as “Shoot First” or “SFAQL”) is a project that I can confidently say is one that I am incredibly proud of.
DEVELOPMENT PROCESS
Before I got my hands on the Sinden, The first week of development was focused on creating a prototype that would lay the groundwork for the game as you see it today.
The really neat thing about designing a game with a Light Gun in mind, is that the controller itself helps the player understand the game instantly. There’s only two things to worry about: aiming and shooting. Because the player’s only way to interact with the game is shooting, the challenge for me as a designer was to create mini games that felt fun and unique from each other through changing how the player approaches the act of shooting.
I got a little carried away and ended up making 2 mini games that first week, each requiring a different display of skill from the player. In the first game, “Rapid-Fire”, The player has unlimited ammo and a set time limit to destroy as many vases as they can before time is up. This one proved to be a fan favorite even without the Light Gun, as many testers enjoyed being able to go to town and dump as many bullets as possible in an attempt to not only hit the quota, but to also see how high of a score they could achieve!
Early footage of the “Rapid-Fire” Mini-Game. Just the bare basics are here at this point in time.
