A cosmic seed of horror travels toward a distant sun, piercing its core and corrupting the star's energy and color until it the sun eventually explodes . This event sends more seeds into space, one of which collides with a Type 1 civilization's planet. Despite attempts to redirect it, the object strikes tangentially, sparing the planet from total destruction. Upon investigating the impact, scientists discover a massive, seemingly endless hole, ultimately realizing that the seed is corrupting their world. They plan to construct a ship to eliminate whatever the seed has spawned, which they believe resides at the planet's core. As they delve deeper, they encounter a landscape resembling an organism's immune system, where they find themselves perceived as the disease.
Web-playable version of your game.
Trailer
Press Kit
Proposal
This is a 3 player game best played with a split keyboard. There are three subsystems (Gun, Shield, Engine) to the capsule ship the players control. Each player is responsible for one subsystem. The gun is controlled with keys WAD. The shield is controlled with keys UHK. The engine is controlled with the arrow keys. The beginning of the game starts with a cutscene which you can skip by pressing space. The objective of the game is to reach the bottom of the map and kill the boss. In order to do so, you will venture through various chambers of an underground and underwater environment. There are 5 different types of enemies: boids, leeches, kamikaze, mines, and turrets. The boids are the most common and will flock towards the capsule and shoot projectiles at it. Leeches will grab onto the ship and deal periodic damage. Kamikaze enemies will fly towards the ship and blow up. Mines are stationary and will blow up if the ship gets close to it. Turrets are stationary but have a ranged projectile attack. The optimal strategy is to push past heavy boid areas as fast as possible since they continously spawn. Then grab the gun upgrade in the second large chamber in the map. This gun upgrade will significantly increase the damage and spread of the gun subsystem. Afterwards, get the hull upgrade at the top of the boss room so you are at full health before engaging the boss. To fight the boss optimally, first kill the turrets directly above the boss. Then shoot the boss until 2-3 flocks of boids spawn. Then fly away from the boss and kill off the boids. After that, go back to shooting the boss and repeat. This way, the players are not overwhelmed by the boids spawn in the boss fight.
If your project contains code that: 1) your team did not write, and 2) does not fit cleanly into a role, please document it in this section. Please include the author of the code, where to find the code, and note which scripts, folders, or other files that comprise the external contribution. Additionally, include the license for the external code that permits you to use it. You do not need to include the license for code provided by the instruction team.
If you used tutorials or other intellectual guidance to create aspects of your project, include reference to that information as well.
Jasper Fadden: During the pitching phase of the project, I brought up an alternate game concept that was a tactics game. It was focused on merging turn-based tactics gameplay with RTS style resource management, and it had a special “soul” mechanic where you could slot stat changes and abilities into built units (but were also limited to your number of souls forcing you to find them as optional objectives and save defeated units). This project didn’t pan out do to our limited schedule for the project, but you can read the 3,300 word pitch document here:
https://docs.google.com/document/d/1iJKUWykExy8CWv6Hy0oAy0d8o\_-HdtwqbNEFaQggOWA/edit?usp=sharing
https://www.youtube.com/watch?v=oFnIlNW_p10&t=975s - Godot Implementation that helped me get a baseline for how this has been implemented previously in the Godot game engine. This implementation was very barebones and did not serve our use case effectively so retrofits were made on top of this code and setup.
https://www.youtube.com/watch?v=bqtqltqcQhw - Sebastian Lague's video covering this topic was phenomenal.
https://www.red3d.com/cwr/boids/ - Literature on the algorithm by its creator Craig W. Reynolds
https://www.youtube.com/watch?v=mhjuuHl6qHM&t=127s - The Coding Train, love his content, explained the algorithm super well and made it easy to understand the finer details of the implementation.
Your goal is to relate the work of your role and sub-role in terms of the content of the course. Please look at the role sections below for specific instructions for each role.
Below is a template for you to highlight items of your work. These provide the evidence needed for your work to be evaluated. Try to have at least four such descriptions. They will be assessed on the quality of the underlying system and how they are linked to course content.
Short Description - Long description of your work item that includes how it is relevant to topics discussed in class. [link to evidence in your repository](https://github.com/dr-jam/ECS189L/edit/project-description/ProjectDocumentTemplate.md)
Here is an example:
Procedural Terrain - The game's background consists of procedurally generated terrain produced with Perlin noise. The game can modify this terrain at run-time via a call to its script methods. The intent is to allow the player to modify the terrain. This system is based on the component design pattern and the procedural content generation portions of the course. [The PCG terrain generation script](https://github.com/dr-jam/CameraControlExercise/blob/513b927e87fc686fe627bf7d4ff6ff841cf34e9f/Obscura/Assets/Scripts/TerrainGenerator.cs\#L6).
You should replace any **bold text** with your relevant information. Liberally use the template when necessary and appropriate.
As a producer I organized bi weekly meetings over Discord where we regularly assessed the progress of the project. As a result of using Discord for team communication I found it easier to leave the meeting notes as messages in the general chat where the team can always refer back to later for review. This makes it really difficult to show what the notes for each meeting where but they generally ranged from giving a summary of what each person on the team will be working on for this week, here are a few examples:
Objectives for today:
-
Player ship can receive damage from all damage dealing enemies
- Player ship can deal damage to all damageable enemies (boids, turrets, collapsable walls)
- Figure out what the final boss is going to be
- Remove Herobrine
-
12/9/24, 6:34 PM
Final Boss:- Some sort of cosmic entity corrupted a planet
- The more you shoot at the core the more difficult the surrounding enemies will get
- The lower the hp the harder the enemies
- There are more tougher enemies (elaborate more)
- Reuse the hitbox for the enemies
- A game_manger.gd script to manage the strength of the enemies
- Call a function to update the new spawning enemies health.
-
12/9/24, 6:42 PM
On player death:- play death animation
- wait 2-3 second
- stop music
- fade to black
- title screen
-
(edited)
-
[
-
6:46 PM
-
]
-
Make a new script attached to the rigidt body add private health variable add public setter player health function; substracts health by one add public getter player health function; gets the players health player setter function is called by an area_entered event? (edited)
-
12/9/24, 6:55 PM
Upgrade System The bottom Three will be effected by Bullet Damage Upgrades- bullet_damage - damage that the bullet does to the enemy
- pierce_cap - number of targets that the bullet can piece before getting deleted
- bullets_per_fire - number of bullets that are shot when the player shoots (bullets will fan out -of the gun)
-
The bottoim Three will be effected by Player Hull Upgrades
- player_max_hp - maximum allowable health by the player
- player_speed - speed that the player moves at
- module_rotation_speed - rotation speed of the modules that surround the ship
-
HUD Elements
-
Display Player Bullet Damage - Red 3 Notch Hud Bar Smaller (about 1/3th player health bar)
-
Display Player Hull Upgrade - Blue 3 Notch Hud Bar Smaller (about 1/3 player health bar)
Aside from group scheduling I also manage the Project GitHub Repository. As a producer I delegated specific tasks to the team in such a way to reduce the number of merge conflicts as possible. This often relied on allowing only 1 person at a time to work on the map scene as managing merge conflicts in Godot scenes was really difficult. Often, godot scenes created weird git issues with untracked files. It was a total mess, but I digress.
-
As the producer I also created the bi weekly roadmap detailing the deliverables due date. This roadmap served as the baseline goals that we needed to achieve each week helping stay on target throughout the project life cycle. This roadmap can be found in the progress report and initial plan document.
As a producer I also contributed to the development of the project by implementing the flocking behavior for the boid enemies. The boids script covers more than just the basic flocking behavior. It also incorporates aggro behavior and shooting behavior.
I also wrote the boid spawner code which was later retrofitted by Nico Medina to be able to spawn the other types of enemies as well. However the main function of the spawner having a spawn cap, spawn timer and spawn amount was originally written by be.
Other smaller notes for my programming task include incorporating the changes and suggestions that I received from my playtest sessions that I conducted. I made minor adjustments to the bullet velocity of the player, the boids, and tweaked the gun script to be able to shoot continuously when holding down the button. These changes are not very big but it's worth mentioning as it ties back to my sub role as gameplay tester.
For my User Interface (UI) approach, I aimed for a minimalist design that balances aesthetic appeal with functionality. By reducing unnecessary visual elements and focusing on essential information, I ensured easier navigation, minimal distraction, and a clear emphasis on core gameplay. In the main menu, players can smoothly transition into the action, review the credits to appreciate the team’s contributions, or exit the game entirely. The pause menu provides a crucial in-game utility, allowing players to momentarily suspend the action and either resume gameplay or quit the current session without disrupting their overall experience. Within the credits screen, I utilized a dynamic backdrop of the game’s map to create a more engaging and visually interesting presentation of the development team’s efforts.
Health indicators are streamlined to communicate critical information at a glance. At the bottom of the screen, a dedicated health bar tracks the player’s ship integrity, updating in real-time as it sustains or recovers from damage. Smaller, separate health bars hover near boids and turrets, helping players quickly assess enemy conditions without crowding the interface. The boss health bar appears only when the player enters the designated boss arena, ensuring that this crucial piece of information is contextually revealed and doesn’t clutter earlier segments of the game.
In terms of controls, my groupmates and I implemented a keyboard-driven scheme that complements the game’s fluid mechanics. To control the ENGINE, players use the arrow keys: the left arrow turns the engine counterclockwise, the right arrow turns it clockwise, and pressing the up arrow engages its power. For handling the GUN, pressing “A” swivels it counterclockwise, “D” rotates it clockwise, and “W” fires shots. The SHIELD system follows a similar logic, with “H” rotating it counterclockwise, “K” rotating it clockwise, and “U” toggling the shield on. Finally, pressing the “Esc” key pauses the game, granting players a quick and intuitive means to manage their play session.
All these UI and control choices were made to ensure that players feel both empowered and informed. The minimalistic design keeps focus on the core gameplay mechanics and the evolving challenges, while the intuitive keyboard layout creates a seamless interaction that aligns with the game’s pacing and strategic depth.
Describe the basics of movement and physics in your game. Is it the standard physics model? What did you change or modify? Did you make your movement scripts that do not use the physics system?
Movement/Physics for this game mainly entailed creating the core player controller for the ship, including the chassis, its movement based on engines, independent attachments to the ship that rotate about it, projectile movement, and most of all ensuring that player movement feels right.
The player controller Is encompassed within a rigidbody2D, which gave several useful tools in regards to physics implementation (making collision and such very easy). However, its force functions ended up not being suitable for the movement system we planned to make, something very weighty and focused on building/releasing momentum.
I thus implemented a partially original movement system: force is applied until the player speed hits a predefined cap (takes a second or so with current parameters), at which point speed is throttled. This speed is maintained as the button it held, but upon release the player starts to slow down quadratically, multiplied every physics frame by (1 - friction). With enough tuning, I was able to get this to feel fairly smooth such that you travel forward an acceptable distance event when you have to stop to rotate the engines and travel another direction.
Both other attachments were implemented after engines, using a similar locomotion system. All attachments are offset by a parent node and rotated about that pivot point between 0-360 degrees. This rotation is modified based on input, and the direction vector is used to determine things like movement angle or shot angle. Engines use the vector away from the shift to decide what direction force is applied. In the case of shields, it simply offsets the hitbox that deletes projectiles. In the case of the gun, the projectile is instantiated, has its rotation set to match the gun attachment, and is finally transposed to the pivot point at the gun’s barrel. All projectile movement is then handled by its own script.
The gun has a few pieces of polish: There’s a very slight bullet spread for realism. But my teammates ere able to help me quite a bit with adding onto the implementation for upgrade functionality. There’s a tuneable number of shots, with the shooting function dynamically adding spread for each one. There’s also a tuned lerp for the gun’s rotation, specific to this attachment to allow precise aiming by briefly using either rotation key (very helpful for distant enemies early in the game).
I also created the final boss, which acts essentially as a mob spawner that summons more enemies as you bring down its health. The more its damaged, it’ll start to boost the health of summoned boids (randomly selecting the location each hit).
Aside from physics, I helped as the main bugfixer during the presentation (making quite a few commits). The game received many balanced adjustments and progression fixes, becoming quite stable now.
All art was created with Aseprite. Files can be found here
Assets:
Ship and subsystems:
| Ship | Gun | Shield | Engines |
|---|---|---|---|
![]() |
![]() |
![]() |
![]() |
Ship Death
Enemies
| Boid | Leech | Kamikaze | Mine | Turret |
|---|---|---|---|---|
![]() |
![]() |
![]() |
![]() |
Enemy Projectiles
| Boid Projectile | Turret Projectile |
|---|---|
![]() |
![]() |
Upgrade Pickup Icons
| Hull Upgrade | Gun Upgrade | Shield Upgrade | Thruster Upgrade |
|---|---|---|---|
![]() |
![]() |
![]() |
![]() |
Map Obstacles
| Collapsable Wall | Spike Wall |
|---|---|
![]() |
![]() |
Map (Downscaled)
![]() |
|---|
Control Icons
| Gun | Shield | Engine |
|---|---|---|
![]() |
![]() |
![]() |
Cutscenes
| Intro Cutscene | Win Cutscene |
|---|
The art style I went with was dark and minimalistic pixel art. Some inspirations for the style were Rain World and Insanely Twisted Shadow Planet
I wanted to maintain an atmosphere of slight horror while mixing in sci-fi tech elements. I utilized a thematic color palette. Yellows and oranges for the ship and neon vibrant colors for the bioluminescent enemies. This intersects with the world building because it fits the theme that the ship is an industrial capsule heading into a planet infected with an alien biological virus. I made the terrain mostly black and the background would change colors depending on the depth that the player is located.
Besides making the assets, I also connected animations to scripts such as making the ship engine fire off the plume of energy when the thruster button is pressed along with the other modules and enemies and their respective animations. I also added hurt flashes to the enemies and the player. In addition, I integrated the 2 cutscenes into the game with their respective activation triggers and added a skip button functionality. I also implemented the player death mechanic and fade to black, as well as doing some work on the project settings such as changing the texture filtering settings and screen scaling.
Key Responsibilities:
- Collaborated with teammates to design the map layout and establish a system for scaling difficulty as players progressed through the game.
- Developed scripts for various player power-ups.
- Influenced lighting decisions to create an atmospheric environment that fits the theme of a dark, cavernous alien planet.
Note: Though that eerie atmosphere heavily relies on Richard's extraordinary assets!
Scheduled Meetings - Map Design
November 25, 2024:
- I held an initial meeting with Richard (Animations and Visuals) to discuss the narrative Design of the map.
- Focused on how the narrative elements would integrate with the gameplay mechanics and player experience.
November 27, 2024:
- Conducted a second meeting to review the prefab map and the design choices for the assets.
- Discussed the visual style, ensuring it aligned with the game's overall aesthetic and supported the player's journey through the map.
Map Development:
- Designed and created the map's collision mesh, ensuring it provided players with a functional and engaging environment.
- Implemented the initial version of the map, focusing on creating a foundation that could be built upon as additional assets and game logic developed. - As new game mechanics were introduced, tactical decisions were made to deliberately showcase these elements to help players become familiar with the core mechanics right from the beginning of gameplay.
Miscellaneous:
- Implemented all of the powerups for Engine, Gun, and Shield players.
- Implemented the lighting and atmosphere for all enemies and map.
Document the game states and game data you managed and the design patterns you used to complete your task.
Game Logic entailed making the enemies, player, projectiles, obstacles, and assets work cohesively. Nearly every member of the team worked on parts of this section (refer to the table on the Initial Plan). As I, Nico, had this as my primary role, I worked on all the components included on the table in the Initial Plan, and then I integrated a lot of the components together for the game. Since not all components of the game were made at the same time, a lot of them were made to work the same way, which created conflicts when we tried to combine it all together. I ensured that the enemies, projectiles, and player ship all interacted with each other properly.
Game states used:
- States for the enemies:
- Kamikaze enemies: idle, tracking, attached, exploding
- Leech enemies: idle, tracking, attached
- Turret enemies: idle, firing
- Mines: Idle, triggered, exploding
Game data used:
- Player:
- Health, direction, speed, hitboxes and hurtboxes, damage
- Enemies:
- Health, speed, aggro distance, damage hitboxes and hurtboxes, projectile accuracy
- Enemy Spawn nodes:
- Enemy capacity, trigger distance, spawn rate, spawn amount, despawn distance
- Obstacles:
- Spikey Walls:
- Damage, hitboxes
- Collapsible walls:
- Health, hurtboxes
- Spikey Walls:
List your assets, including their sources and licenses.
All audio in the game is self-made, with both the music and sound effects being made through JummBox (https://jummb.us). This DAW happens to have an FM and chip syntheizer that proved useful for creating simple sound effects, along with some mild editing with Audacity.
All audio for the game is contained in the Audio folder. Here you can hear the sound effects, and each version of the main theme (looped twice for a bit under 20 seconds each). You can also hear the trialer theme (unused in-game), which smoothly progresses through each part
The game has 4 sound effects:
- shot.wav
- damaged.wav
- engines.mp3
- shields.mp3
The game also has the following 6 music tracks, each of which are variations of a song that increase in intensity:
- Capsule1.mp3 (pure melody)
- Capsule2.mp3 (melody plus ambient harmony)
- Capsule3.mp3 (above with drums added)
- Capsule4.mp3 (above with more drums added and a modified melody
- Capsule5.mp3 (above with even more drums, a faint bass-line, and a modified harmony)
- Capsule6.mp3 (final boss song, with 2 more layers of drums, further modified harmony, and further changed melody)
Describe the implementation of your audio system.
Most audio work in the game is handled by audio_manager.gd. This script preloads all sound effects and has 2 main categories of public method that other facets of the game use to communicate with audio:
- There is a play_sfx() method that takes a keyword string. This string determines what type of sound to play, or in the case of certain sounds like for the engines, when to start/stop them.
- There are 6 signals that are fired by certain trigger zones throughout the map. These trigger zones are roughly spread out based on general progression, usually before larger rooms or after significant challenges, ensuring that the song gradually progresses over the map until the final boss-fight.
Crossfading is achieved through an animation player. This animation player has 5 important animations that increment the song playing, fading in/out two tracks over 2 seconds by modifying their decibel volume as node property keys.
Document the sound style.
The music was focused on having a short and concise melody surrounded by a complex rhythm, originally very mellow but increasingly fast as the hazards of the setting become more lethal. Bells and high-reverb are used for the underwater setting, mixed with digital pads considering the mix with technology and alien life. I placed special attention to atmosphere for this game's soundtrack, as I believe that was an important goal for all members of the team.
Sound effects use heavily modified chip-noises, which served well for not being too annoying when played often, fitting with the pixel art style, and being snappy / recognizeable.
Add a link to the full results of your gameplay tests.
Juan Alvarez: https://docs.google.com/document/d/13XSmKWV0__V0rTi8SQmApLZdsqkZGlIJtGzJFigo5NI/edit?tab=t.0
Nico Medina:
Observations and Playtester Comments
Summarize the key findings from your gameplay tests.
Juan Alvarez: Summary is at the bottom of the full results of my gameplay tests.
Document how the narrative is present in the game via assets, gameplay systems, and gameplay.
Documentation:
Narrative Design Document
Reference Used:
Lover in a Dangerous Spacetime Trailer
Insanely Twisted Shadow Planet Gameplay No Commentary
Gameplay and Narrative Integration
- The gameplay system directly influences the narrative structure.
- The design is heavily inspired by similar multiplayer games, particularly *Lovers in a Dangerous Spacetime* and *Insanely Twisted Shadow Planet*.
Asset and Map Design
- The assets in the game are closely linked to the narrative design choices.
- A document outlining asset decisions and map design was created.
Enemy Design
- Enemy behaviors were shaped by the narrative, resulting in different types of enemies: boids, turrets, leeches, mines, and kamikaze enemies.
Collaboration Process
- Communication between narrative and art/animation teams was essential for design decisions.
- Richard and I conducted two meetings to discuss and finalize the map and its regions, leading to the creation of a draft map with prefabs.
- The narrative served as a foundation for the art design and game logic teams.
I chose to use the intro cutscene at the start of the trailer to hook the viewer in rather than showing them gameplay immediately. I thought this would set the mood for the game that we are showcasing. I also cut the trailer in a way to match the beats of the music. I thought this would help keep the viewer engaged. For the actual gameplay that is shown in the trailer. I chose to show brief glimpses of combat but not too much to spoil every enemy and mechanic. This would help the viewer understand what the game is about and looks like without spoiling everything
I chose to make the presskit using the differently press kit maker because I was familiar with working with plain HTML. I chose the screenshots in a way so that every area could be shown. This would help the visitor discern the mood of the game and get a grasp of the variety of areas in the game.
For game feel and aesthetic cohesion, I decided to integrate the “Press Start 2P” Google Font consistently throughout the interface to match the game’s title screen and the visual style established in Richard’s introductory cutscene. This font choice helps maintain a unified retro-inspired atmosphere and ensures that menus, UI elements, and in-game text look intentional and thematic. Additionally, to streamline the user experience, I assigned the pause function to the ESC key and introduced a dedicated pause icon, making it easier and more intuitive for players to quickly halt the action at any time.
To enhance the tactile sense of gameplay, I implemented a dynamic camera shake system that responds to the player’s damage intake—when the player is hit, the intensity of the shake scales, conveying a sense of impact and heightening the drama of combat encounters. This subtle visual feedback ties the player’s suffering directly into the game’s presentation, making the action feel more visceral.
I also refined the boss encounter introduction by placing an Area2D node that triggers the display of the boss’s health bar only once the player enters the designated zone. By doing so, the presence of the boss health bar is no longer static; instead, it emerges naturally as a response to player progression and spatial context. This small adjustment increases immersion and prevents unnecessary information from cluttering the screen early on.
Finally, I integrated a WorldEnvironment node in the main menu, map, and credit scenes to achieve a soft glow and ambient lighting effect. This gives each scene a more polished, atmospheric look, and provides a cohesive visual identity that carries through the entire game experience. Collectively, these enhancements—from font choice and improved UI elements to dynamic camera effects and environmental lighting—work together to create a more engaging, immersive, and polished gameplay environment. (Paused Icon: https://www.flaticon.com/free-icon/pause_13077337?term=pause&page=1&position=54&origin=search&related_id=13077337)



















