Team-built shooter game
A shooter built in Pygame with teammates who were new to programming. I set up the structure and made the music and visuals.
Goal
Build a playable shooter as a team. You move in four directions, shoot enemies and collect power-ups.
I also wanted a project structure that teammates who were new to programming could understand and add to.
Constraints
The assignment required Python and Pygame, a start screen, a game-over screen, score tracking and a high score on the start screen. We had to hand in a Git repository with a 1.0 release tag and install instructions.
My teammates were new to programming, so the structure needed to be approachable while we all worked toward the same deadline.
Process
I split the game into player and enemy classes, a shared config and separate modules, and built the foundations early so teammates had working examples to follow when they made their own features.
On the gameplay side I did player movement and animation, bullets (basic and homing) and the parallax scrolling, using third-party background assets. I also merged teammates' work together as it came in.
Outside the code, I designed the player character and menus, composed the music and hooked up the audio. For the interface I built scene switching, reusable buttons and text rendering with configurable font sizes.
A lot of it was explaining: how the pieces fit together, how an idea could be implemented, and making the structural calls that gave the team somewhere manageable to start. Before handing in I fixed integration bugs, player spawning after retry, naming and leftover code.
Result
A finished team shooter with keyboard movement, enemies, shooting and power-ups, including a nuke on N.
My part mixed code with original character and menu design, music and parallax. The structure and examples helped teammates build their own features, and the same team went on to do WP-2 together.
What I learned
I learned to communicate code and implementation ideas to people who had never programmed. That meant explaining the same work at different levels: what a feature should do, how it fits into the game, and what the code behind it looks like.
I also learned the value of working ahead to give people structure and concrete examples. Taking the early structural decisions added to my workload, but it made the project less overwhelming for my teammates and gave them a starting point.
The hard part was balancing a shared understanding against my own growth. I wanted us to build something everyone could follow, without my contribution being limited to more of the same. So I used simple game mechanics to experiment and see how far an idea could go, while trying to keep those experiments understandable to the team.