THIS CASE IS A WORK IN PROGRESS!!!
Overview
Witchy Blast is a small arcade shooter developed in GameMaker as one of my first hands-on programming and gameplay logic studies. Inspired by the structure of Asteroids, the project began as a template exercise and gradually evolved into a custom reskin with original visuals, UI polish, audio feedback, and multiple small systems created to improve fairness, readability, and game feel.
The goal of this project was not to build a large-scale game, but to use a contained prototype as a practical way to learn how gameplay systems interact inside an engine: player movement, projectile behavior, enemy spawning, collision logic, lives, pause states, menus, HUD, audio, and basic visual feedback.
Goal
My main objective with Witchy Blast was to learn GameMaker through implementation rather than theory alone. I wanted to understand how to move from “following a template” to actually making decisions as a designer and beginner programmer:
1. Adapting an existing structure into a custom concept
2. Understanding the logic behind each gameplay system
3. Identifying problems during playtests
4. Improving the player experience through small but meaningful iterations
This project also became an exercise in translating technical learning into something presentable, readable, and visually cohesive.
My  as a Solo Developer
I was responsible for:
1. game design decisions
2. Implementation in GameMaker
3. gameplay tuning
4. UI and menu structure
5. visual reskin and asset replacement
6. audio implementation
7. iteration and playtesting
8. Documentation of the learning process
Core Concept
Witchy Blast is a witchy reinterpretation of the classic arcade loop of Asteroids. The player controls a drifting witch, shoots incoming skull-shaped rocks, avoids collisions, and survives for as long as possible while accumulating points.
What started as a simple movement and shooting exercise gradually became a more complete prototype with:
inertia-based movement
projectile system
destructible large and small enemies
score and lives
pause state
menu and credits screen
game over feedback
music and sound effects
visual polish and custom presentation
Design & Implementation Focus
1. Learning through system breakdown
One of the most valuable parts of this project was breaking down the game into small, understandable blocks. Instead of trying to solve everything at once, I approached the prototype system by system:
player movement
shooting
bullet behavior
collision logic
enemy splitting
score tracking
menu flow
game over feedback
spawn fairness
player survivability
This helped me better understand not only how to implement something, but also why a system works the way it does.
2. Movement and control readability
The player movement was one of the first systems I studied. Because the project was based on an Asteroids-style structure, movement was not simple 4-direction movement, but rotation + thrust + inertia.
That meant understanding:
angle-based movement
how player orientation affects direction
how to rotate instead of strafing
how momentum changes the feeling of control
After that, I expanded input support beyond arrow keys and added WASD controls to make the game feel more familiar and comfortable for modern players.
3. Shooting as a connected system
The shooting mechanic became an important study in how objects relate to one another in-engine.
The system required:
creating a projectile instance from player input
spawning it at the player’s position
assigning direction based on player angle
setting speed and behavior on creation
removing the projectile when it leaves the playable space
This was a useful lesson in separating responsibilities:
the player creates the projectile
the projectile defines its own movement behavior
the collision event determines what happens on impact
4. Early balancing issue: unfair failure states
One of the first major gameplay problems I encountered was unfair spawning.
Because large rocks were being created with random positioning, it was possible for one to spawn directly on top of the player, immediately causing a loss. Technically, the system worked, but from a player experience perspective, it felt frustrating and unreadable.
To solve this, I reworked the spawn logic by:
creating a dedicated spawner object
forcing rocks to spawn from the edges of the room
defining a minimum distance from the player
limiting the maximum number of rocks active at once
This was an important design lesson: a system can be functional and still feel bad. Fixing fairness often comes from rethinking when and where something happens, not just whether it technically works.
5. Enemy behavior and logic cleanup
Another challenge came from the enemy collision logic.
Initially, the rock split/destruction behavior included conditions tied to the total number of rocks active in the room. While this seemed useful at first, it created unpredictable behavior because rock collision outcomes depended not only on the current enemy state, but also on what else existed globally in the room.
I simplified the logic into something much clearer:
large rock → splits into two smaller ones
small rock → gets destroyed
Then I moved room-wide spawn control into the spawner system instead of keeping it inside the collision event.
This made the system:
easier to understand
easier to debug
more consistent in play
6. Player survivability and feedback
Originally, a direct hit triggered immediate game over. Later, I changed that into a 3-life system to create a more forgiving and readable gameplay loop.
That led to implementing:
a life counter
visual HUD feedback
temporary invulnerability after damage
a flashing effect while invulnerable
delayed game over only when lives reached zero
This change significantly improved the overall feel of the prototype. It gave the player room to recover, reduced frustration, and created a clearer sense of progression during a run.
7. Menu, pause, and presentation
Once the gameplay loop became stable, I focused on adding more structure around it through interface and presentation systems.
I implemented:
a main menu
controls screen
credits screen
pause system
game over overlay
score and life display
menu and gameplay music
simple menu sound feedback
The menu itself evolved from plain text into a more stylized presentation with:
a custom logo image
background art
animated pulse effect on the logo
better spacing and visual hierarchy
This stage was less about raw functionality and more about learning how polish affects perception. Even a small prototype feels much more intentional when feedback, pacing, and interface are thoughtfully presented.
Key Challenges
Understanding where logic belongs
A recurring challenge in the project was learning where each responsibility should live.
For example:
Spawn logic should not live in the rock collision
Game state should be controlled by a manager object
Object creation and object behavior are separate concerns
Visual feedback often belongs in Draw, not Step
Understanding this separation helped me build cleaner logic and avoid compounding bugs.
Debugging syntax vs. design problems
During development, I faced two different kinds of problems:
syntax/implementation issues, such as incorrect operators or invalid conditional structure
design / feel issues, such as unfair spawning or unclear feedback
This project helped me practice distinguishing between:
“The code is broken.”
and
“The code works, but the player experience is poor.”
That distinction is essential in game development.
What I Learned
Witchy Blast taught me a lot about the relationship between design intent and implementation details.
Some of the biggest takeaways were:
Small prototypes are excellent spaces for learning real production logic
Fairness is one of the most important parts of the moment-to-moment gameplay feel
System clarity improves both design quality and debugging speed
Polish does not need to be large-scale to be effective
Feedback systems (sound, UI, blinking states, overlays, menus) dramatically improve how a prototype is perceived
Building something playable from a template still involves a large number of original design decisions
Most importantly, this project helped me feel more confident navigating GameMaker not just as a tool, but as a space for iteration, experimentation, and structured learning.
Tools
Engine: GameMaker
Art: Procreate
Distribution: itch.io
Development focus: gameplay logic, systems implementation, UI, iteration
Final Notes
Witchy Blast was developed as a contained learning project, but it became much more than a simple tutorial exercise. By the end of the process, it had turned into a fully playable prototype that reflects both my early technical learning and my design instincts around player experience, feedback, and polish.
It also established a strong foundation for the next GameMaker projects I want to build, now with a much clearer understanding of how small gameplay systems connect and evolve through iteration.
↑Back to Top