Major Project 1
Major Project I/Bachelor of Design in Creative Media
Project Development
Week 1 - Week 9 Define and Ideation
Week 10 — Building the First Playable Foundation
The main focus was creating the first playable Godot 4 prototype and testing the original platformer direction.
Development Progress
- Built Aster’s basic movement system, including walking, running, jumping and double jumping.
- Added early combat mechanics such as shooting, player health, damage, recovery and scene reset after defeat.
- Created reusable systems for the player, bullets, enemies, bosses, damage zones, spawning and game flow.
- Developed the first test level with platforms, toxic areas, environmental obstacles and enemy testing spaces.
- Added an early HUD containing health, abilities, difficulty, objectives, notifications, dialogue and pause functions.
- Started the original Chapter 1 concept, Fallen from the Sky, which introduced toxic air, Corp X waste, village rejection and a chase sequence.
- Improved camera limits, level boundaries and fall protection so the player remained visible during gameplay.
Problems and Improvements
Some scripts produced errors because Godot warnings were treated as serious errors. I learned to use explicit GDScript types and read compiler messages more carefully.
The Chapter 1 scene also failed to load because of missing script references. Instead of rebuilding the entire project, I repaired the broken dependencies and restored the scene structure.
Camera framing was another issue because the player could move too close to the screen edge or become surrounded by empty space. Camera limits, smoothing and reset zones were added to improve visibility.
Week 11 — Changing the Game Direction
After proposal presentation, we consult with Ron, he said that our game mechanic is way too generic just a general 2d platformer combat game, but did not show any of Waste colonialism through the mechanic,
So after our consideration and discussion, we changes the story direction from sealing up the portal, to build a rocket to revenge back the planet, as a potential solution to stop waste colonialism
The project shifted from a combat-focused platformer towards waste collection, recycling and base progression.
Development Progress
- Kept the original combat prototype as a backup.
- Created a separate BaseLoopPrototype scene to test the new gameplay direction safely.
- Defined the new gameplay loop:
Collect waste → Return to base → Recycle materials → Process components → Repair the rocket → Explore further
-
Created reusable systems for:
- Waste collection
- Vacuum interaction
- Resources and scrap
- Recycling and processing stations
- Rocket progression
- Portal stones
- NPC rescue and assignment
- Dialogue and notifications
- Added random scrap rewards from waste piles.
- Added weighted recycling results that could produce Plastic, Metal, E-Waste and Chemical Waste.
- Changed the economy so Aster carries scrap back to the base instead of immediately converting it in the exploration area.
- Planned NPC automation so a rescued character could later work at the Recycling Station.
- Set the prototype resolution to 640 × 360 to support the pixel-art visual direction.
Problems and Improvements
Rocket progress originally felt too directly connected to collecting waste. The system was separated into several stages:
- Waste becomes scrap.
- Scrap is recycled into materials.
- Materials are processed into Rocket Components.
- Only Rocket Components increase rocket progress.
Camera smoothing was also tested, but too much smoothing created visible jitter in the pixel-art presentation. Different follow offsets and camera settings were compared to balance smooth movement with pixel stability.
Reflection
Week 11 established the clearest identity for SCRAPS!.
Waste became the central resource, progression system and reason for exploration. The player was no longer collecting objects without purpose; every collected resource contributed towards repairing the rocket and escaping the damaged world.
Week 12 - 13— Replacing Placeholders with Pixel Art
The focus shifted towards visual production, animation setup and reusable world systems.
Development Progress
-
Imported the supplied pixel-art assets for:
- Aster
- Kiri
- NPCs
- Waste
- Buildings
- Stations
- The rocket
- Replaced primitive placeholder shapes with the project’s actual visual assets.
- Set up AnimatedSprite2D and SpriteFrames for Aster.
-
Prepared animation states such as:
- Idle
- Walk
- Run
- Clean
- Attack
- Added TileMap-based terrain and collisions.
- Built follower behaviour for Kiri and the rescued NPC.
- Made Kiri follow behind Aster during exploration.
- Made the rescued NPC follow Aster until being assigned to the Recycling Station.
- Improved Recycling Station feedback, NPC placement and worker assignment.
- Started developing a reusable slime-bounce mechanic for platforming challenges.
Problems and Improvements
Some sprites initially floated above the ground or overlapped with older placeholder graphics. Sprite positions, collision shapes and visual layers were adjusted separately so the character’s feet could align correctly with the terrain.
The NPC also appeared with unwanted background graphics and leftover placeholder visuals. These were fixed by separating visual sprites from collision and debugging shapes.
The slime-bounce script caused errors when attached to incompatible node types. This demonstrated that reusable scripts must match the node type and physics behaviour of the scene where they are used.
Week 14 — Playtesting, UI Refinement and Gameplay Clarity
The final week focused on making the game easier to understand, reducing interface obstruction and improving feedback based on playtesting.
1. HUD and Interface Improvements
The original purple pixel-art HUD had a strong visual identity but contained several usability issues:
- Duplicated information
- Overlapping rocket progress values
- Missing icons
- Non-editable text
- Oversized panels
- Notifications overflowing their borders
- Important information covering the gameplay area
The UI controller was renamed and reorganised so it represented the full gameplay interface rather than only controlling resources.
Important information was rebuilt using editable Godot Label nodes, panels and icon containers. This made the HUD easier to adjust directly in the editor.
The updated HUD included:
- Compact health and bag information
- Separate resource values
- Rocket progress
- Current objective
- Notifications
- Contextual interaction prompts
- Hold-to-vacuum progress
The rocket panel was simplified to show one clear progress value, while notifications were given text wrapping and vertical expansion.
2. Bag and Inventory System
The original resource drawer permanently covered part of the screen.
It was replaced with a bag system:
- Press B to open the bag.
- The bag appears in the centre of the screen.
- The environment becomes slightly darker.
- Unrelated HUD elements are hidden.
- Clicking outside closes the bag.
- The compact HUD displays the total number of collected resources.
This allows the player to check resources when necessary without losing permanent gameplay space.
3. Dialogue Focus
When dialogue appears:
- Gameplay pauses.
- Other HUD elements disappear.
- Notifications are hidden.
- The background becomes darker.
- Left click progresses the dialogue instead of firing Aster’s weapon.
This prevents gameplay controls and UI information from competing with the dialogue.
4. Teaching Controls Through the World
The first tutorial design used one large instruction overlay. Playtesting showed that it:
- Covered the character
- Blocked gameplay
- Hid the bag interaction
- Presented too much information at once
The tutorial was replaced with editable signboards placed along the gameplay route.
Each sign teaches one control:
- Movement: A/D or WASD
- Jump: Space
- Attack: Left click
- Interact: E
- Open bag: B
- Pause: Esc
This allows beginners to learn controls gradually while continuing to explore.
5. Waste Progression and Platforming Challenges
Waste placement was made more irregular so it felt like environmental pollution instead of a row of identical objects.
Different waste types were introduced:
- Normal waste: Can be collected normally.
- Purple waste: Cannot immediately be vacuumed and introduces a new gameplay obstacle.
- Golden waste: Rewards the player with a Rocket Component.
Purple and golden waste trigger dialogue from Kiri, allowing story and gameplay explanation to happen at the moment of discovery.
A high platform was also added as a movement challenge. The player must combine a slime bounce with a double jump to reach a golden waste pile.
This gives the movement mechanics a clear purpose and rewards players for learning the controls.
6. Camera Improvements
The camera was given a delayed follow effect to make movement feel smoother.
A safe framing area was also maintained so Aster would not drift too far towards the edge of the screen or disappear from view.
7. Audio and Atmosphere
A sound cue plan was created so each sound supports a specific action.
Planned and implemented sound categories included:
- Background music
- Environmental ambience
- Normal jump
- Slime bounce
- Landing impact
- Vacuum interaction
- Blaster attack
- Waste collection
- Recycling
- Portal activity
- Dialogue
- UI interaction
- Progression events
The slime bounce uses a separate cartoon-style sound to distinguish it from a normal jump.
The day-to-night cycle was shortened from approximately five minutes to one minute for faster testing and a more noticeable atmosphere change.
During the first night transition, Kiri reacts through dialogue, connecting the environmental system to the story.
8. Dialogue as Gameplay Feedback
Dialogue became more than story text. It was used to explain unusual gameplay events when they occurred.
Examples include:
- Kiri explaining why purple waste cannot be collected normally.
- Kiri reacting when golden waste is discovered.
- Golden waste being identified as a Rocket Component.
- Kiri reacting when the environment becomes dark for the first time.
This is more natural than placing all instructions inside a separate manual or tutorial screen.
9. Combat and Input Testing
Several shooting speeds and animation timings were tested.
The tests showed that attack animation, projectile timing, sound and player input must happen together.
Rapid shooting felt responsive but did not match Aster’s full attack animation. The final direction kept the clearer complete-animation shooting rhythm because it communicated the action more effectively.
Input conflicts were also corrected so:
- Dialogue clicks do not trigger attacks.
- Respawning does not trigger the damage animation.
- Modal UI states prevent unintended combat actions.
10. Technical Problems Solved
Several late prototype issues were repaired:
- Missing and duplicated UI nodes
- Runtime UI values overriding editor changes
- Objective markers targeting deleted waste piles
- Text escaping notification panels
- Interaction prompts covering Aster
- Dialogue clicks triggering attacks
- Fall resets incorrectly triggering hit feedback
Instance-validity checks were added before the objective system accessed waste piles that had already been removed.
Comments
Post a Comment