Game Summary

Neon City Panic is a bullet hell style shooter in the vein of 16-bit classics with modern, sharp, 3D visuals. Players engage in high-speed combat as they fly through the streets of Neon City against swarms of drones. But they’re not the only challenge to the player. Each level ends with a unique boss fight, testing the player’s skills. Choose your loadout and lay waste to your enemies.

Featured in UCF Celebrates the Arts 2018

Responsibilities

• Design, prototype, and implement 9 different enemies. I began with simple, classic bullet hell enemies that fly straight down from the top of the screen as a base for the light or “fodder” class of enemies. From there I expanded to enemies that served more specialized roles like high-speed fighters that swerved from one side to another firing bursts at the player. Medium enemies that took a bigger beating and had more specialized roles like firing missiles and blocking off areas of the playfield with beam attacks. Finally, my pride and joy, heavy enemies acted as battleships or mini-bosses the player encountered on levels. These enormous ships sported turrets, beam cannons, and one even acted as an aircraft carrier. To add extra juice to these heavy enemies I made sure they went down in flames, crashing to the landscape below.
• Design 3 bosses. No good bullet hell is complete without good bosses. I expanded upon the heavy enemy class for bosses and created large enemies with individually destructible areas which, if destroyed, made fights much easier.
  • The first boss was a simple supercarrier bristling with guns and constantly spawning enemies. Players could destroy the hangars on the left and right, its turrets, or destroy the core of the ship at the center to end the boss fight. In order to get the enemies to spawn, I simplified the code used for spawning enemies in levels and applied it to this boss which was then applied and modified to the carrier enemies.
  • For the second boss, I wanted to learn how to create a multi-stage boss, and also troll the player while I was at it. The fight begins with a single, easily dispatched enemy that moves across the battlefield. Nothing fancy. Upon destruction, it fades in a much larger vessel that spins like mad around the level trying to destroy the player by either crashing into their ship or any of the flak it sprays in a circular pattern around it. After the player destroys all of these turrets it shifts to its third and final form, a larger vessel that swerves from side to side-firing from four different guns. These guns fire beam cannons or torpedoes. If a player is caught by a beam it’s a good chance they’re done for, but if they’re in front of a torpedo they can try to destroy it or dodge out of the way with the ship’s movement.
  • The final boss went through several iterations of overkill before being toned down to its final form. Originally it contained a blackhole gun to try and mess with the player’s controls, sweeping beam cannons, and a “time dilation field” which slowed incoming projectiles. But this proved to be technically challenging and made the boss far too difficult for our target audience, so it was toned down to a heavy ship bristling with guns. Players had to dance around barrages of missiles and flak fire in order to line up their shots on the boss while simultaneously being very careful not to get caught in either of its beam cannon batteries. While drastically toned down from its original vision, this boss still provided a final, exhilarating experience to players of Neon City Panic.
• Design, prototype, and implement encounters for 3 levels. The first step in developing these encounters was creating the spawn system. This was done with 5 spawn points out of sight at the top of the map where player shots could not reach enemies. Behind these spawns and at the center of the screen sat the boss spawn which had to sit way further behind due to the scale of these bosses. Afterward, it was a simple matter of writing a coroutine that ran for the currently designated level. Combined with the way some enemies moved this spawn system created some fun and deadly flight patterns for players to deal with.
• Design, prototype, and implement the scrolling 3D background. We basically created giant tiles that scrolled across the screen beneath the player. At a certain point in their movement, the next tile was called up and “joined” to the currently visible one so when players saw the next tile it would be a seamless transition. There are about ten different tiles used in the game for the city set. Originally the plan was for three unique environments but that was going over our scope, so we opted for a change in lighting instead.
• Design, prototype and implement 6 different primary and secondary weapons and their five levels of upgrade. These ranged from classics such as a machinegun that fanned out its shots as it upgraded and a spread of seeking missiles to flak cannons, and plasma guns that would explode on impact and randomly send shrapnel scattered across the air.
• Design, prototype, and implement 3 different superweapons. The first was a classic mega bomb that covered a great deal of the play space. The second was to give the players their own beam cannon. While its damage was not as quick to deliver as the bomb, it operates for a much longer time and ultimately deals more damage if focused on a target. The final superweapon was an over shield that protects players from all damage and can be used offensively to destroy enemy ships.
• Design and prototype scoring and economy system. As part of our game’s progression, we added in a currency that was tied to the player’s score. Players could then take this currency and spend it on upgrades for their ship if they lost them in battle, extra lives, superweapons, or they could even change their ship and weapons loadout.
• Design and prototype local coop. Up to two players can play Neon City Panic on keyboard, arcade cabinet, or while one player uses a Limbitless flex controller and the other the keyboard.
• Collaborate with another programmer to implement all of the game’s UI, menus, shop, and couch coop. This programmer joined late in the development process, but he was a welcome relief from all the solo coding I had done up to this point. I caught him up on all the code implemented so far and then worked with him to implement things like managing player loadouts and tracking which of the two potential players had which ship, weapons, score, and upgrades.
• Implement Limbitless Flex Controller and Arcade cabinet support. To do this we had to use the Limbitless API which was completely new to all of us. It was a controller that operates on electric impulses from a player’s body used to train them to use their prosthetic limbs in the future. To make matters worse we only had one controller to test with across twelve different teams. After much research, trial and error, this feature was successfully implemented ahead of schedule. Arcade cabinet support was simple by comparison, just a quick rebind of the keyboard controls.
• Strong multi-tasking between designer, producer, and tech lead roles. I was the king of multitasking in this project. Thankfully I was so passionate about the project that the initial planning was done in the first few days of our project launch. But even so, things needed adjusting whether it be mechanics, timelines, or keeping up with all the different artists on the team and their tasks. Until about 60%-75% of the project’s completion, I was the only programmer on our team as well. Thankfully the rest of our studio had several other great programmers I could turn to for help and bounce ideas off of to maintain our deadlines and keep me sane.
• Coordinate with 12 team members and our studio to create and complete tasks. As mentioned above my team was comprised entirely of artists up until we had a programmer join late in the development cycle. I delegated tasks between all of them involving concept art, UI, environmental work and all the different ships in the game. Because we were part of a studio could also reach out to other teams for help with any tasks we were struggling with or help them with their own.
• Provide thorough design documentation in the form of our GDD, ASG, and spreadsheets to balance all of our weapons, enemies, and player ships.

Skills Gained or Improved

• Understanding of the Unity 5 Engine. This was my first deep dive into Unity. Prior to this, I had experimented with different tutorials but never made a full project from beginning to end. After this project, I can confidently develop any games I need to in the Unity Engine.
• C# Scripting. I learned how to write C# code for unity and further expanded my knowledge of it. One of my bigger challenges was developing homing missiles that didn’t crash the game. Another fun challenge was ensuring the beam cannon players fired did not actually tilt with them as they swerved from one side to another.
• Project Management. Being the sole person responsible for whether or not things were done properly and on schedule I learned a lot here. HackNPlan was my go-to software to create and track tickets whether they be tasks or bugs. I learned to communicate daily with my team to make sure everything was running smoothly and if it wasn’t, I could act accordingly to correct any issues.
• Conflict Resolution Skills. This was primarily between me and our creative director. He had a much cuter vision for all of our studio projects to follow as our projects were for kids that Limbitless was helping. I argued that the kids already had cute covered and needed variety in their games. We came to a compromise where our game’s characters maintained the cuter aspects desired by our creative director while the rest of the game was able to be the neon fueled chaos you can see and play today.

Challenges Overcome

• Original Tech Lead abandoned the project the week before prototype deliverable. This was a tough one because the deadline was so close when he came out and said he was leaving. Thankfully, I had a suspicion that this might happen after they avoided communication and started development on my own prototype and was able to pull that off successfully.
• The technical team of one was overwhelmed by the number of tasks. I was it for most of the project and I had to learn a lot along the way too so there was a lot of crunch while I got my bearings but I refused to let this project fail and it was for the best at the end of it.
• Lackluster performance from two team members on crucial tasks. There were two team members who weren’t performing to the level needed. The first was not delivering assets on time or to the agreed-upon quality and designs. They received warnings and did not correct their behavior, so they had to be let go. The second corrected their behavior quickly after a discussion about what was going on and a change of production practice to be more hands-on or attentive to them.