#bitcrash

{Week 13}

As development on Bit Crash wraps up, I wanted to reflect on the full process: what worked, what didn’t, and how far the game has come from concept to final submission. Creating a full arcade-style experience in GDevelop pushed my systems thinking, UI design, and debugging skills in ways that felt both challenging and rewarding.

What Worked?

From the start, our goal was clear: build a glitch-themed arcade shooter that feels fast, chaotic, and replayable. The asteroid destruction, knockback mechanic, and respawning hazards created a gameplay rhythm that kept players moving and thinking on their feet. Watching testers dodge enemies, upgrade mid-run, and chase scores was proof the design loop landed. The XP-based upgrade system added real replay value. Players could invest in fire rate or health, making each run feel slightly different. This tied perfectly into the arcade feel we were aiming for and gave players short-term goals. Bit Crash had a visual identity that clicked. The CRT overlays, VHS distortion, glitch FX, and chiptune audio helped sell the simulation-gone-wrong vibe.

What Didn’t Work?

While the DataFragments were effective hazards, they didn’t evolve much over time. In a longer development cycle, I’d introduce enemy types with different behaviors; some that shoot, others that orbit the player, etc. That variety would help the game scale in complexity and keep the player learning. The game was too easy. Enemies didn’t spawn fast enough to pressure the player, and bullets were slow. Through playtesting, we increased difficulty and fixed pacing; but it reminded me how important regular feedback is.

What I Learned

Playcentric Design Works: Getting feedback early helped shape the final product more than any single mechanic I added. As Fullerton says, “You aren’t designing unless you’re testing.”

Modular Logic is Powerful: Breaking up systems (enemy respawn timers, score tracking, upgrades) into small parts helped me debug and iterate faster.

Polish Comes Last, But Matters: Little touches like sound cues, UI transitions, and knockback had an outsized impact on the feel of the game.

Bit Crash started as a weird glitch-core spin on Asteroids, and turned into one of the most complete games I’ve made to date. I’m proud of what the team produced and what I contributed. If I had more time, I’d expand the progression and enemy types, maybe even explore online leaderboards or an endless survival mode.

{Week 11}

This week we conducted our first round of structured playtesting for Bit Crash, gathering direct feedback through surveys and observation. Our goal was to evaluate core mechanics like movement, shooting, and enemy behavior, while also identifying any usability issues or balance concerns before final polish.

Testers & Demographics

We had two participants:

Alex – Regular arcade/puzzle player, 20+ hours of gaming per week

Jamie – Action RPG / roguelike fan, 25+ hours of gaming per week

Both fit our core audience: experienced players who enjoy reflex-based and score-driven arcade games.

Key Findings

Controls & Gameplay Both testers agreed the controls were intuitive and the game was easy to pick up. Shooting, movement, and feedback were all clear. However, Alex suggested increasing bullet speed to improve responsiveness.

“I felt like I was sometimes faster than my bullets. Faster projectiles would make the combat more snappy.”

Challenge Balance Neither player found the game frustratingly difficult or boringly easy — a good sign for current balance. Jamie did mention that more enemies would add to the intensity:

“There weren’t enough enemies for it to feel like a real challenge yet. I’d like to see a denser wave pattern.”

Visuals & Feedback Visual style and atmosphere were well received. CRT effects, sound design, and UI were all praised for reinforcing the glitch-core aesthetic. Players ranked visuals and audio as top aspects.

Replayability & Progression Both players said they would play the game again and were curious to see how the upgrade system evolves. This validates our decision to make upgrades a mid-run mechanic for replay value.

What We’ll Improve Next

🔺 Increase bullet speed slightly for better combat flow

🔁 Increase enemy spawn rate to create more tension

⚠️ Consider adding a “warning” flash or indicator for respawning DataFragments

📈 Explore scaling enemy difficulty over time or based on score

Playtest Report Progress

We’ve now compiled our results into the official Playtesting Report and are planning a second round of testing next week to validate our changes.

{Week 10}

This week, our team continued development on our Assignment 3 game, Bit Crash; a fast-paced glitch-themed arcade shooter where you play as a rogue AI trapped in a collapsing simulation. We’ve made solid progress on the core systems and officially recorded our gameplay video for submission.

Gameplay Video Recorded

We’ve now exported a full prototype build and recorded a short gameplay video showing:

Core player movement, shooting, and knockback

Asteroid destruction with visual feedback

XP gain system and fully functional upgrade menu

Glitch-themed CRT visuals and audio FX

Homing Data Fragments that respawn and target the player

The video is under 3 minutes and demonstrates all the required mechanics and UI systems in action. We used OBS to capture footage and made sure it stayed under the file size limit.

Upgrade System Working

Our upgrade system is now fully operational. As the player earns XP by destroying asteroids, they can spend that XP mid-run to upgrade:

Fire rate (shoot faster)

Health points (survive more hits)

The UI is built using a mouse-hover system; players simply hover over each upgrade button to apply it. It’s responsive and gives immediate feedback with sound and visual cues.

Team Workflow

We’ve been staying on track with our team task list from Part A. Everyone’s been working on specific areas.

What’s Next

Begin structured internal playtesting (Week 11)

Finalize questionnaire and feedback script

Polish balance values for upgrades and enemies

Start compiling the Playtesting Report Document

Record any remaining footage if needed

The game is in a really solid state right now. Most of the core loop is in place, and upgrades are already making gameplay feel more engaging. Next week we’ll see how new players respond and what we can improve from there.

{Week 7}

Now that the core gameplay loop for Bit Crash is functional, I wanted to reflect on the development process so far. Building this game has been a great way to push beyond a simple Asteroids clone into something more experimental and reactive.

What Worked Well The biggest success this week was getting all the core systems to talk to each other. Player movement, shooting, enemy behavior, and scoring now form a satisfying loop that feeds into itself.

Adding enemy respawn behavior after they leave the screen gave the game a much more dynamic feel; fragments that drift out of sight come back for revenge. Combined with knockback when shooting, the player’s own actions constantly shift their position, which adds an element of chaos I really enjoy.

The scoring system is simple but satisfying, and I’ve already seen opportunities to expand it into something more replayable, like Endless Mode or unlockable content.

Playtesting Feedback I had two peers playtest the current build during a workshop session. Neither had seen Bit Crash before, which gave me a chance to observe how a new player reacts without any prior knowledge.

Player 1:

Noted that the movement felt responsive and fluid

Liked the recoil from the blaster, said it added “flavour” to the shooting mechanic

Took several hits before realizing that DataFragments were invincible

Suggested a small red outline or glow around threats to better distinguish them

Player 2:

Said the glitch aesthetic looked cool, but asked whether the visual noise would ramp up too fast over time

Said the respawning enemies were “spooky in a fun way”

Recommended adding a small warning indicator when an enemy re-enters the screen

Enjoyed the asteroid destruction loop, but asked if larger asteroids could break into smaller ones (might explore that later)

From this, I learned that the visual clarity of the game needs tuning - especially as effects stack over time. I also noticed how both players appreciated any mechanic that gave them more feedback or control in a chaotic environment.

What Didn’t Work (Yet) Enemy behavior is still too simple. While DataFragments feel threatening, they don’t provide much interaction beyond being something to avoid. Since they’re indestructible, the player’s only option is to dodge. Over time, this can become repetitive.

Right now, only one object type (the asteroids) contributes to score. This limits the player’s ability to make meaningful choices. Adding more enemy types or making enemies destructible would open up more strategic variety.

Another challenge was making sure everything stayed readable. The glitch aesthetic can very easily become overwhelming. I’ve had to start pulling back some of the visual effects to keep things playable.

One Thing I’d Change About My Process Early on, I jumped into building systems without prototyping them in isolation. If I had sketched out or paper-tested the respawn logic before coding it, I probably would’ve avoided some frustrating bugs and timer issues. Fullerton emphasizes iterative prototyping as a core principle of play-centric design, and this experience really hammered that home.

“It is tempting to keep building features, but without testing, you're not designing — you're guessing.” – Fullerton, Game Design Workshop (2018)

One Thing I’d Change in the Design I’d like to give the player more agency when interacting with enemies. Right now, there’s no way to fight back against DataFragments. I think adding a charge shot or timed “debug pulse” mechanic could allow the player to clear space or protect themselves in a tight moment, adding some needed variety to the loop.

{Week 6}

Game Preview

This week in Bit Crash, I focused on transforming the basic enemy mechanic into something more intentional and reactive. Not just floating obstacles, but rogue data fragments that hunt you down after vanishing into the void. Alongside this, I implemented the game’s scoring system tied to asteroid destruction, officially kicking off the arcade loop.

Enemy System: Immovable Hazards That Return I created a set of immovable hazards (DataFragments) that drift across the screen and damage the player on contact. But instead of deleting them when they exit the screen, I wanted to reinforce the glitch-core theme, so now they disappear, wait between 3 to 6 seconds, and then respawn from a random screen edge, launching directly toward the player’s position.

This gave the game a more sinister rhythm, and the unpredictability of where they’ll come from adds tension. I even added spinning to each fragment as they drift, making them feel more like destabilized chunks of corrupted memory.

This system taught me a lot about using object variables to manage internal state (such as ShouldRespawn and RespawnTimer) and reinforced how small, modular logic chunks can build emergent behavior.

Player Movement and Bullet Feedback I also made big improvements to the player movement system this week. The player now rotates toward the mouse cursor and fires with the left mouse button. To add more weight and feedback to firing, I added a slight knockback that pushes the player backwards when shooting.

This gave shooting a much more satisfying feel. It not only helps sell the impact of the bullet visually, but also introduces a skill-based mechanic where players can tactically reposition using their own firepower. It fits perfectly into the glitchy aesthetic and adds some interesting risk to spamming shots.

Point Scoring: Asteroids Asteroids are currently the only source of score in the game. Destroying one adds 1 point to a global score variable, which is displayed in real-time using a UI text object. The destruction is paired with feedback like screen shake, visual effects, and sound cues to reinforce the moment.

Eventually, score will tie into leaderboards, unlockables, and Endless Mode, but for now, this system helped me lock in the core arcade loop: aim, destroy, reward.

This was the first real implementation of the reward loop. Fullerton talks about creating clear, compelling outcomes for player actions, and this felt like the first time that started happening naturally in my game.

Done This Week:

Main menu with ambient glitch-core soundtrack

Player movement and bullet recoil system

DataFragments now respawn with delay and track the player

Asteroids can be destroyed for score

Score system with UI feedback

Visual and sound effects for damage and point gain

Random spawn system with directional targeting for enemies

This week was the most rewarding yet. The mechanics are starting to talk to each other. Enemy behavior is feeding into movement design, movement is influencing combat, and combat now ties directly into the scoring loop.

{Week 5}

Game Title: Bit Crash Tagline: “Reality is broken. Can you debug your way out?”

In Bit Crash, you play as a rogue AI fragment trapped inside a corrupted simulation. Instead of floating rocks, you’re dodging memory leaks, fighting off virus swarms, and navigating glitch-ridden environments that are breaking down in real time. Your mission: survive, debug, and escape before total system collapse.

The game draws inspiration from Asteroids, but pushes beyond it with reactive environments and layered visual feedback. The longer you play, the more corrupted the simulation becomes—introducing unpredictable behaviors, heavier screen distortion, and chaotic enemy patterns.

Key Mechanics:

Corruption Meter: Increases over time, affecting visuals, audio, and enemy AI.

Power-Ups: Tactical tools like Debugger Pulse (shockwave), Patch Protocol (invincibility), and Stack Overflow (risk/reward high-speed fire).

Progressive Zones: From the clean Boot Sector to the terrifying Black Box, each level introduces new glitches, hazards, and boss-like memory structures.

Look & Feel:

Aesthetic: CRT fuzz, VHS overlays, neon colors, scanlines, and RGB-splitting. Audio: Glitch-hop and distorted chiptunes, broken system sounds, and error messages voiced in deadpan robotic tones.

Bit Crash channels the arcade DNA of Asteroids but injects it with modern chaos and a narrative-embedded glitch aesthetic.

Concept Art:

(Made using HTML, CSS & JS)

Shockwave:

Inspired by concepts from Fullerton's Game Design Workshop (2018) and lecture discussions on avoiding scope creep, this pitch is intentionally focused and achievable within GDevelop. I’ll be applying lessons learned from Max Power; like scene transitions, damage feedback, and event timing; to ensure this game feels more polished from day one.