Team Postmortem

What Did We Change from the Initial Plan?

The initial plan was to make two-parter levels. The first part of a level would involve plugging up portals with pushable blocks that continuously spawn enemies. You would have a weak weapon capable of stunning and slowing enemy advances as you worked to plug in all of the portals. The second part of the level involved going into a separate dimension to kill all of the invading enemies with an upgraded weapon for an extra juicy experience. 

With the time constraints involved, we had to make several compromises. The game became restricted to just the two parts as two separate levels, and both levels would involve plugging up enemy spawning portals. The stun gun worked out, but its power was not weak: just normal. The stunning and slowing effect mostly became obsolete or problematic when it came to dealing with the tanky boss enemies. Additionally, we did not have enough time to implement all of the unique assets we had hoped for, so we had to scour online for free assets to use. The player model turned into a legless sentry robot (essentially a roomba with a gun), and the portal plugging blocks turned into TVs that came with their own breaking animation. 

What Went Right with the Final Project?

Despite the challenges, we managed to achieve the basic game loop. Portals spawned various enemies with their own unique traits and the player had a gun to fend them off which evolved after plugging in all portals with pushable TV blocks. Unexpectedly, the warrior roomba player model became a fan favorite. Even with the use of asset stores or online free materials, the unique assets that we were able to produce in time contributed to a distinctive technological aesthetic, aligning with our initial vision.

What Went Wrong with the Final Project?

The project faced setbacks during Thanksgiving Break and the onslaught of finals and responsibilities, leading to downscaled art and programming goals. The art team struggled with completing 3D assets, and communication delays occurred due to external factors such as COVID-19, job interviews, and other finals. Having to downscale to only two levels with a rushed level layout also hurt. Several bugs persisted in the final build, from collision issues to problematic enemy AI and spawn logic and loud audio.

What Would We Do Differently Next Time?

Reflecting on our experience, we could definitely approach this better. Our progress during this project was very disjointed, as we just assigned tasks, waited for them to finish, and then assigned more when necessary. Better time management, consistent communication, and a more structured work schedule would keep steady progress for our project. Calling once or twice a week is essential to keep everyone’s mind in the game. Instead of assigning tasks when they were needed, laying out all tasks for the project would help us realize the actual scale and what our progress was at any time. Much of our progress on the game came just a day before the presentation. That’s definitely not good. If we must cram, it would be best to cram as soon as possible, as just a single extra day of cramming would make for a much more polished game. 

If we could have one more week of development, what would we add?

One extra week of development would help us get more unique assets, such as an official player character model, as well as providing texturing, rigging, and animation to the enemies, which move very stiffly in the final build. On the programming side, adding distinct behaviors to the enemy AI would be great. They currently just follow the player if the player happens to exist, at all times. To expand on this, introducing more unique attacks tailored to each kind of enemy, as well as more elaborate boss battles, would give our game a lot more depth to its combat. We would also hope to expand the game with additional levels and incorporate health pickups to balance the heavy combat.

Conclusion

The ideas we had for our project were really grand and exciting, but as it turns out, achieving such ideas is really difficult if you don’t plan properly. When time flew by and the deadline was right next door, our whole group went through the depths of hell to get a completed product in the seconds we had to spare. It was a valuable experience and a learning lesson for future projects. While we wish we could’ve done more and achieved our visions, we are still proud of our “Portal Gun Game” that we were able to present and release.

Individual Contributions

Hung Nguyen (Programmer)

• Player Controller
  • Movement (sprinting), sensitivity, shooting, HP / damage / death logic, etc
• Third-Person Camera
• Combat Mechanics
• Enemy Status (HP, damage handling, death, stunned/slowed states)
• Enemy/Bullet Object Pooling
  • Updated enemy portal spawn logic to generate a random type of enemy each time
• Enemy Variations (Virus, Bug, Trojan)
  • Each has different speeds and HP, different actions (Virus is the only one that can fire bullets)
  • Boss Enemy Variation
• Player/Enemy bullet programming
  • 4 different bullet types (normal, evolved, charged, evolved charged)
  • Different logic for player vs enemy bullets (enemy bullets move slower and last longer, and pass through objects)
• Player Gun 
  • Animations (fire, evolution, charge shot)
  • Programming (fire rate/cooldown, aiming calculations, charge shot, evolution/upgrade)
• Audio Manager
• Game Manager
• UI (Menus: Main Menu, Pause Menu, Game Over Menu)
• Misc visual effects (sprint particles, player trail, objects play a shrink animation before being disabled/destroyed) and materials
• Imported assets from asset store/online
  • Player model, TV model, skybox, menu art, all sfx and music

Gabriel Li (Programmer)

• Portal Mechanic 
  • Enemy Spawning Logic (enemies rise from the portal on a set interval)
• End Portal Creation
  • Used to transition to 2nd level after the 1st portal is plugged up
• Enemy AI: 
  • Enemy Nav Mesh (assigns player target for enemies to follow)
•  Enemy & Player UI: 
  • Health UI (World Space, Green for player, Red for enemies)

Miles Anderson (3D Character Artist / Game Designer)

• Created 3D enemy meshes for Virus, Trojan, and Bug enemies.
• Conceptualized block puzzle mechanic

Noah Eichler (3D Artist / Level Designer)

• Created environment assets using Aseprite/Blender
  • Designed both levels
  • Designed boxes, signs, portal holes, and other retro-style assets such as TV/Screen character-like sprites.
• Helped coordinate implementation of said assets into Unity