DEV Community: Katana Works

Run a Game Studio for $0/Month: My Complete Free Tool Stack (Engine, Art, Video, Marketing)

Katana Works — Fri, 06 Nov 2026 14:03:49 +0000

Quick math for you: engine license, art software, video editing suite, hosting. The "standard" indie stack costs somewhere between $50 and $100 every month before you've sold a single copy of anything.

I built my entire studio workflow on a stack that costs exactly zero. Not free trials. Not crippled versions. Five tools that take you from blank screen to published game — and marketed. Here they are.

1. GDevelop — The No-Code Engine That Doesn't Fight You
GDevelop is an open-source, no-code game engine that runs in your browser or as a desktop app. No C#, no C++, no missing-semicolon debugging sessions at 2 AM.

The event system reads like plain English: "If the player presses the right arrow key, move the player to the right." You spend your brain cycles on game design, not syntax.

The underrated killer feature: one-click exporting. Android, HTML5 web, Windows/Mac/Linux desktop — same project. When you're a solo dev, removing porting friction is the difference between shipping on three platforms and shipping on none.

2. Inkscape — Vector Art Without the Adobe Tax
Free, open-source vector editor. The important word is vector: unlike raster images, vector art scales infinitely. Your character sprites, icons, and UI stay razor-sharp on a phone screen and on a 4K monitor alike — same asset, zero pixelation.

For 2D game assets specifically, this beats paying a monthly Illustrator subscription for functionality that Inkscape covers.

3. OBS Studio — The Recording Standard
Modern game dev means building a brand alongside the game: devlogs, tutorials, trailers. OBS Studio is open-source, rock-solid, and the de facto industry standard for capture and streaming.

Set your resolution and frame rate once, then forget it exists. One-button recording when you want simple; multi-scene, multi-track audio setups when you don't.

DaVinci Resolve — Hollywood-Grade Editing, Free Tier Most free video editors are clunky watermarked junk. DaVinci Resolve is the actual software used in Hollywood film pipelines — and the free version gives you cutting, titling, color correction, and clean high-quality exports.

The long-game detail I love: if you ever pay for the Studio version, your project timelines transfer perfectly. No relearning, no lost work. The tool grows with your studio instead of trapping you.

5. Dev.to — Your Zero-Maintenance Traffic Engine
Not software — a platform. Building and maintaining your own site costs time and money; posting your devlogs and tutorials on dev.to gets you in front of an enormous existing developer audience for free.

Embed your YouTube videos directly into posts, pick good tags, and let dev.to's internal traffic and SEO do the discovery work for you. Free backlinks, organic growth, zero servers to manage.

The Stack at a Glance
Engine GDevelop $0
2D art Inkscape $0
Screen capture OBS Studio $0
Video editing DaVinci Resolve $0
Marketing/audience dev.to $0
Total $0/month

The barrier to entry for game development has never been lower. The most important variable isn't your tool budget — it's your consistency. This stack removes every excuse except sitting down and building.

What's in your free stack? Anything I'm missing? Drop it in the comments 👇

Build a Snappy Horizontal Dash in GDevelop in 5 Steps (No Code Required)

Katana Works — Thu, 05 Nov 2026 12:51:13 +0000

A dash mechanic is the difference between a platformer that feels like homework and one that feels like butter. Players love it, it solves level design problems (long gaps, dodge attacks, speedrun routes), and — here's the kicker — in GDevelop it takes about ten minutes to wire up properly.

In this post I'll break down the exact setup: the behavior, the event logic that most beginners get wrong, and the animation polish that makes it feel finished.

Step 1: Add the Horizontal Dash Behavior
Don't hand-code a dash from scratch. GDevelop ships a dedicated behavior that handles velocity, duration, and cooldown logic for you.

Double-click your player sprite to open its properties.
Go to the Behaviors tab → Add a behavior.
Search "dash" and pick Horizontal Dash.
Tune the speed/distance values, then hit Apply.
Skip the temptation to accept the defaults here — dash distance and speed are what make or break the "game feel." Iterate until it clicks for your character's movement scale.

Step 2: Define the Trigger Key
Create a new event in the Event Sheet. Add a condition: key X is pressed. This becomes the gate for everything else.

Step 3: Get the Hierarchy Right (Where Most People Mess Up)
This is the gotcha that causes "my dash randomly doesn't work" forum posts. GDevelop evaluates events top-to-bottom, and indented events behave like if-then branches.

If you place your left/right directional checks on the same level as the X key press, your logic runs in the wrong order and controls get glitchy or unresponsive.

The correct structure:

Top-level condition: X key is pressed
Indented under it: directional check via an OR block
Right key is pressed
OR Left key is pressed
The OR condition lives in the Advanced section of the conditions list. This nesting guarantees the dash fires only when a direction is held while X is tapped.

Step 4: Simulate the Dash
On the action side, add Simulate dash key press for the player object. That's the handshake between your event logic and the behavior from Step 1. Press X while holding a direction — zip. Player rockets across the screen.

Step 5: Animation Polish
A dash without a dedicated animation feels stiff. Fixes:

Add a "Dash" animation to your player object.
New event: condition Is dashing → action Change the animation by name → "Dash".
When the dash ends, your existing idle/run animation events take back over naturally.

TL;DR
Step What Why
1 Horizontal Dash behavior Handles velocity/cooldown for free
2 X key condition Input gate
3 Indent direction checks under X (OR block) Correct logical flow
4 Simulate dash key press Fires the behavior
5 "Is dashing" → Dash animation Visual feedback
Whether you're building a Metroidvania or a precision platformer, this gives players real control and juice in minutes.

🎥 I recorded the full walkthrough step-by-step — watch it here:

What game are you building with it? Drop a comment below 👇

How to Add Professional Screen Transitions in GDevelop (Step-by-Step)

Katana Works — Fri, 30 Oct 2026 02:53:36 +0000

Ever notice how amateur games have that jarring "snap" between scenes? One frame you're on the menu, the next you're mid-level with no warning. Professional games use screen transitions — fades, wipes, iris effects — to bridge scenes smoothly. Here's exactly how to set them up in GDevelop.

What You Need

GDevelop (free)
The Flash and Transition Painter extension (free, built-in)

Step 1: Install the Extension

Open your Extensions tab → Create or Add Extensions → search for Flash and Transition Painter. Double-click to install. This extension handles drawing and animating transition shapes across your screen without manual opacity math.

Step 2: Create a Dedicated Transition Layer

This is where most beginners fail. Your transition effect must live on its own layer, above everything else.

Open the Layers Panel
Add a new layer → name it Transition
Drag it to the top of the layer stack

If the transition layer sits below your UI or game layer, the effect renders behind your interface elements and looks broken.

Step 3: Add the Shape Painter Object

In Scene Objects, add a new Shape Painter object
Name it ShapePainterTransition
Drag it into your scene
In the Properties Panel, change the Base Layer to your Transition layer

This is the second place beginners get stuck. If the Shape Painter stays on the base layer, it's subject to camera movement — your transition will drift off-screen when the player moves.

Step 4: Add the Behavior

Select your Shape Painter object → Behaviors tab → add the Flash Transition Painter behavior. This links the extension's logic to this specific object. Without it, the event sheet actions have nothing to target.

Step 5: Configure the Event Sheet

Add an action wherever you want the transition to fire (level start, goal collision, button press).

In Add Action, search for Paint Effect → select the Flash Transition Painter option.

Settings that look professional:

Parameter	Value	Why
Object	`ShapePainterTransition`	Your transition object
Color	`0;0;0` (black)	Clean, neutral bridge between scenes
Duration	`1` second	Long enough to register, short enough to not drag
Effect Type	`Circular` or `Flash`	Circular = cinematic iris effect. Flash = simple fade.
Direction	`Backwards`	Smoother "closing" animation for iris effects
Opacity	`255`	Fully opaque — hides the scene completely

The #1 Mistake

Everything works — extension installed, object placed, events configured — but the Shape Painter is still on the base layer. The transition animates but drifts with the camera. Always move it to a dedicated top-level layer.

Key Takeaways

Dedicated layer, top of the stack. Non-negotiable.
1-second duration. The sweet spot for pacing.
Circular iris effect adds immediate polish with zero extra effort.
Stay consistent. Use the same transition style throughout your game.

This takes about 5 minutes to set up and immediately makes your game feel more polished. The full video walkthrough with live demonstration is here:

Why I Quit Teaching English Abroad and Started Building Games Instead

Katana Works — Fri, 23 Oct 2026 16:31:26 +0000

If you’ve ever considered living abroad, you’ve probably heard the usual advice: get a TEFL cert, teach English, live cheap.

I did that. I also did government contracting. Both paths had the same fatal flaw — you’re trading hours for dollars with zero residual value.

The problem with every “traditional” path
Teaching English: Supply goes up every year. New teachers arrive willing to work for less. Pay stays flat or drops. You’re literally training your own competition.

Government/embassy work: High pay, impressive title, zero control. They choose where you go. And when you leave the system, you have nothing — no products, no IP, no assets. Just a resume.

What actually works: asset stacking
Solo game development flips the model.

Every game you finish is a permanent digital asset. Put it on a storefront and it earns while you sleep. Stack 12 games in a year and you have 12 income streams running simultaneously.

The math is simple:
Month 1: 1 game earning
Month 6: 6 games earning
Month 12: 12 games earning

Nobody can undercut your portfolio. Nobody can reassign you. Nobody can fire you.

Why game dev specifically?
No certification required — start tonight
No employer visa dependency — you own the business
No “all-in” gamble — build on evenings and weekends while keeping your current income
Tools are free — engines like GDevelop cost nothing to start with
The full breakdown

I made a video covering exactly why the traditional paths fail, how asset stacking works in practice, and the three steps to go from zero to a working game on your phone in one weekend.

🎥 Watch it here: https://youtu.be/otJsCFpbdxI

If you’re a dev already, you’re closer to this than you think. Game dev is just software with a storefront attached.

Dynamic Multi-Level Loading in GDevelop (Without Duplicating Scenes)

Katana Works — Wed, 21 Oct 2026 17:42:56 +0000

If you’re building a multi-level game in GDevelop, you do not need a separate scene for every stage. There’s a pattern using global variables and external layouts that keeps your entire game running on a single reusable scene.

Here’s how it works at a high level.

One global variable drives everything. Create a number variable called current_level in your project’s global variables. Initialize it to 1. This is your level pointer.

External layouts hold level geometry. Instead of new scenes, you create external layouts named with a consistent pattern — Level1, Level2, Level3, etc. Each layout uses your main game scene as its base, so it has access to all existing objects.

Dynamic loading at scene start. In your main scene’s event sheet, add a “Beginning of scene” event with the action “Create objects from external layout.” The layout name is an expression:

"Level" + GlobalVariableString(current_level)

Set X, Y, Z origin to 0. Add a Trigger Once condition so it doesn’t fire every frame.

Level transitions. When the player collides with a door and presses the interact key, increment current_level by 1 and change to the same scene. The scene reloads, the beginning-of-scene event fires, and the next layout gets pulled in automatically.

Don’t forget camera boundaries. If your levels are different sizes, you need per-level camera boundary logic. Check the value of current_level and set boundaries accordingly, or your camera will float off into empty space.

This pattern scales well — I’ve used it on projects with 20+ levels and the project file stays manageable. No duplicated event sheets, no object sprawl across scenes.

I made a video walkthrough that covers the full implementation if you prefer to see it built step by step:
https://youtu.be/KBtNvKsRlwk

3 GDevelop Mistakes That Silently Break Your Game (And How to Fix Them)

Katana Works — Fri, 16 Oct 2026 02:27:28 +0000

GDevelop’s no-code event system makes it easy to start building immediately — which is also why beginners hit specific walls that are almost invisible when you’re inside them. These aren’t “I forgot a condition” bugs. They’re workflow-level mistakes that send you debugging in the wrong direction for hours.

Here are three I’ve run into firsthand, with the fixes that actually work.

1. The Sprite Scaling Trap
GDevelop lets you resize any object in the editor. Take a 1024×1024 image, scale it to 64×64, looks fine — ship it. Except under certain conditions (scene transitions, event triggers, preview refreshes), the sprite can revert to its original dimensions at runtime.

Why this wrecks your game:
Say you have a checkpoint object scaled down to fit a single tile. Your event says “Create player at the center of Checkpoint.” Logic is correct. But if the checkpoint reverts to its native size for even one frame, the center point shifts — and your player spawns three tiles away, inside a wall, or off-screen entirely.

Why it’s hard to debug:
You’ll instinctively look at your event sheet for a logic error. You’ll rewrite conditions, add debug text, question your sanity. The bug isn’t in your events — it’s in your assets folder.

The fix: Size your sprites to their in-game pixel dimensions in an external editor (Piskel, Aseprite, Photoshop) before importing. Don’t rely on GDevelop’s scaling for core gameplay objects. This keeps collision masks, center points, and spawn positions consistent.

2. Following Experts Instead of Beginner-Plus Creators
Counterintuitive, but important. GDevelop experts show you the cleanest, most elegant implementations — and they skip the “obvious” steps that trip beginners up because they’ve forgotten those steps exist. Curse of knowledge.

A creator who’s only a few months ahead of you is still navigating the same walls you’re about to hit. Their solutions might not be the most optimized, but their process of identifying and solving beginner-level traps is far more useful when you’re starting out.

How to balance it:
Experts → technique. Learn how to structure a project, use advanced features, understand best practices.
Beginner-plus creators → traps. Watch for the mistakes they make and how they recover. That’s where your actual learning happens.
Always focus on “why.” If a tutorial says click a button, understand why that button matters before moving on. Copying events you don’t understand means you can’t fix them when they break.

The Grand Vision vs. The Micro-Project

Everyone starts GDevelop because they have a dream game — a sprawling RPG with an inventory system, skill tree, and 20-hour story. Trying to build that as your first project is a fast track to burnout.

How scope creep kills you:
You start with a simple platformer. Then it needs a double jump. Then a wall slide. Then a shop system. Suddenly you’re managing a project a 50-person studio would struggle to ship. When something breaks, you can’t fix it because you didn’t build the system — you copied it from a 45-minute tutorial you half-followed.

The “one mechanic” rule:
Treat every mechanic as its own micro-project:

Build it — Create a square that jumps when you press a key.
Break it — Change gravity, tweak jump sustain, see what happens.
Fix it — Prevent infinite mid-air jumps.
Move on — Next mechanic: coin pickup, respawn trigger, enemy patrol.

By keeping scope tiny, you understand every single event in your project. The build-break-fix cycle is where real learning happens. Those micro-projects eventually combine into a full game — except now you actually understand every piece of it.

TL;DR Mistake & Fix
Scaling sprites inside GDevelop / Size them in an external editor before importing
Only following expert tutorials / Add beginner-plus creators who still hit the same walls you do
Starting with your dream game / Build one mechanic at a time — build, break, fix, repeat

Every expert was a beginner who kept building. Keep your projects small, your sprites sized correctly, and your learning focused on the “why.”

How to Set Up a Smooth, Bounded Camera in GDevelop (2 Steps)

Katana Works — Tue, 13 Oct 2026 14:59:40 +0000

Ever previewed your platformer and watched the camera drift past your background into grey nothingness? That’s the fastest way to make a finished game look like a prototype. GDevelop makes fixing this surprisingly painless — two steps, no code, no math.

This guide covers the exact setup: a smooth-follow camera behavior plus boundary enforcement tied to your background’s bounding box.

What You’re Building
A camera that:

Follows your player with a slight interpolated delay (no jerky snapping)
Stops hard at the edges of your background image (no void)
Adapts automatically if you resize or reposition your level
Step 1: Add the Smooth Platformer Camera Behavior

Stop using the basic “Center camera on object” action. It works for prototypes but the instant snapping looks cheap. GDevelop has a dedicated behavior that handles interpolation for you.

Setup:
Double-click your player character in the object list to open its properties.
Go to the Behaviors tab.
Click Add a behavior to the object.
Search for “camera” and select Smooth Platformer Camera.

When you apply it, GDevelop actually installs two components: Smooth Camera and Smooth Platformer Camera. Together they give the camera a weighted delay that smooths out jumps, falls, and direction changes.

Preview your game now — the camera follows nicely, but it’ll sail right past the edges of your background. That’s what Step 2 fixes.

Step 2: Enforce Camera Boundaries in the Event Sheet
Boundaries aren’t a behavior — they’re an action you add to your event sheet. The key move is linking the boundary values to your background object’s bounding box instead of hard-coding pixel coordinates.

Event Sheet Setup:
Add a new action (no condition needed — this runs every frame).
Search for Enforce camera boundary.
Fill the four fields using the Object Selection tool:

Field Expression Path Object
Left Object Position → Bounding Box → Left Position Your background object
Top Object Position → Bounding Box → Top Position Your background object
Right Object Position → Bounding Box → Right Position Your background object
Bottom Object Position → Bounding Box → Bottom Position Your background object

Using bounding box expressions instead of raw numbers means the boundaries update automatically if you scale or move your background in the editor. No maintenance.

Common Mistake: Wrong Boundary Object
If your scene has multiple layers (parallax clouds, decorative props, mid-ground platforms), make sure you’re selecting the primary background object that defines the playable area. Binding the camera to a small cloud sprite or a decorative prop will cause jittering or a stuck camera because the boundaries are too small. Double-check your object names in the event sheet.

Why This Matters
Smooth Camera behavior handles interpolation math — no manual lerping.
BoundingBox expressions adapt to level changes — no hard-coded coordinates to maintain.
Layer awareness — apply boundaries to the layer your gameplay lives on (usually Base Layer), not your UI layer.
No void — players never see outside your level, which is one of the cheapest ways to make a game feel finished.

Two steps. No plugins, no extensions, no subscriptions. Your camera now glides with the player and stops exactly where your world ends.

Why I Chose GDevelop Over Unity, Godot, and Construct (5 Reasons, 1 Dealbreaker)

Katana Works — Thu, 08 Oct 2026 21:34:06 +0000

I ship one small 2D game to Google Play and web portals every month. I don’t do 3D and I don’t need fancy rendering. I need an engine that gets a finished game out the door without a fight.

After months of testing, I put my time into GDevelop instead of Godot, Unity, or Construct 3. Here are the five reasons, the one thing it can’t do, and who should skip it.

1. Event sheets beat dense code
Event sheets are visual logic: Conditions and Actions. If this is true, do that. It’s color-coded, spaced out, and readable at a glance.

I’m dyslexic, so walls of symbols and syntax are where I lose hours. In a text editor I’m hunting for a typo. In an event sheet I’m reading my game logic. I can work for hours without the mental fatigue.

2. Behaviors you drop on objects
Solo dev means you’re the programmer, artist, sound designer, and tester. I don’t have time to rebuild a platformer controller every month.

Drop the Platformer Object behavior on a sprite and you have a running, jumping character in about a minute. The behaviors are tested and compatible, so I skip the boilerplate and start on what makes the game mine.

3. Export that doesn’t eat my week
When you ship monthly, every extra hurdle is a chance to miss your deadline. In some engines, the Android SDK, certificates, and build paths can swallow an afternoon. In GDevelop, exporting to Android or web is a few steps inside the editor. That’s the real reason I can ship on a schedule.

4. Everything lives in one place
Asset store: sprites, sounds, and music without leaving the app
Extensions: community extensions in the editor when built-ins aren’t enough
Tutorials: built in, so I’m not trusting a three-year-old video

Less context switching means more flow state, and flow is what keeps a solo project moving.

5. Open source means nobody can reprice me
In 2023 Unity announced a fee structure that would have hit games already released. They walked much of it back in 2024, but the lesson stuck: don’t build your income on one company’s pricing decisions. With open source, the rules can’t change under me mid-project.

The one thing GDevelop can’t do
It’s not built for heavy 3D or AAA-scale projects. If you’re building a 3D open-world RPG, pick something else. And if your goal is a job at a big studio, learn Unity, Unreal, or Godot, because that’s what they hire for.

Takeaways

Pick the tool that helps you finish games, not the one with the longest feature list
Event sheets are legitimate, and “real coders” don’t get a vote on your productivity
If syntax drains you, a visual engine is an accessibility win
Shipping is a skill, and easy export makes you practice it more

Want to see this in action? I post a new GDevelop mechanic every few days: https://youtu.be/zwBISSibep4

Your turn: What engine are you using, and what’s the one thing that slows you down? Drop it in the comments. If you’re on the fence about GDevelop, ask me anything and I’ll answer.

Follow me here for more solo dev workflows.

GDevelop Death Animation in Minutes:

Katana Works — Wed, 07 Oct 2026 09:40:43 +0000

You don't need keyframes or a state machine for a good death animation. I swap the player for a particle effect, wait a beat, then respawn. Three events, about five minutes of work.

What you need first
A player that moves and collides
Something that kills you (spike ball, enemy, hazard)
A respawn or checkpoint system (this one only handles the animation, not where you come back)

Step 1: Group your hazards
Put every deadly object into one group called Enemies. Spikes, enemies, lava, whatever. One event covers all of them, and new hazards later cost you nothing.

Step 2: The death event
Conditions:

Player is in collision with Enemies
Trigger once while true

Trigger once matters. Without it the collision fires every frame and you stack a pile of effects that tanks performance.

Step 3: Spawn the effect, then delete the player
Actions, in this order:

Create object DeathEffect at X: Player.CenterX(), Y: Player.CenterY()
Delete Player

Create first, delete second, so the position is still readable. Deleting the player also kills movement and stray collisions during the animation.

Step 4: Wait, clean up, respawn
Add these actions after the delete:

Wait 0.5 to 1 second (needs the Advanced Wait extension, install it from the extensions list if you don't have it)
Delete DeathEffect
Run your respawn logic

Too short and the player never sees the effect. Too long and people get annoyed waiting. Half a second to a second works for sparks and flames.

Swapping the look
The logic doesn't care what the effect is. Change the object in the Create action and you're done. Electric spark for sci-fi, blue flame or smoke for fantasy, pixel explosion for retro. Keep it centered on the player and nothing else needs touching.

Recap

Group hazards so one event covers everything
Trigger once while true on the death event
Create the effect at CenterX() / CenterY(), then delete the player
Wait, delete the effect, respawn

Questions or a different setup? Drop a comment. Next up I'm tying this into the checkpoint system.

How to Flip Your Character Sprite in GDevelop (And the Beginner Mistake That Breaks It)

Katana Works — Wed, 30 Sep 2026 17:00:00 +0000

A character that slides backward instead of turning around kills immersion instantly. In GDevelop, fixing this takes two events in the Event Sheet and about three minutes. But there's one beginner mistake that makes the sprite flicker or refuse to flip at all — and almost everyone hits it the first time.

Setup Assumptions

You already have:

A character sprite imported into your scene
A platform/ground sprite in your scene
Both scaled to a size where you can clearly see which direction the character faces

If your character is tiny on screen, scale it up in the editor before testing. You need to see the flip to debug the flip.

Assign Platformer Behaviors
GDevelop handles physics through its Behavior system. Two behaviors make a basic platformer work:

For the character:
Double-click the sprite → Behaviors tab → Add a Behavior → Platform Character. Keep the defaults and apply.

For the ground/platforms:
Double-click the platform sprite → Behaviors tab → Add a Behavior → Platform. Apply.

Run a preview. Your character should move with arrow keys and jump. But you'll notice the problem — the sprite faces the same direction no matter which way you move. That's what we're fixing.

The Flip Logic: Two Separate Events

Open your Event Sheet. You need exactly two events.

Event 1 — Moving Right (reset to default orientation):

Condition: Key Pressed → Right
Action: Flip the object horizontally → select your character → Activate flipping: No

Event 2 — Moving Left (mirror the sprite):

Condition: Key Pressed → Left
Action: Flip the object horizontally → select your character → Activate flipping: Yes

That's it. The flip action mirrors the entire sprite so you don't need separate left-facing and right-facing animation frames.

The Mistake Everyone Makes

Putting both actions in the same event block. If you group the right-key flip and left-key flip under one event or nest them together without proper separation, the engine processes both instructions on the same frame and the sprite either flickers or doesn't flip at all.

GDevelop executes events top to bottom every frame. Conflicting flip instructions in the same block means the last one always wins, or worse, they fight each other. Two separate top-level events eliminates the conflict entirely. The engine checks each condition independently and only fires the matching action.

This is the single most common reason beginners can't get sprite flipping to work. If your flip looks broken, check your Event Sheet structure before anything else.

Quick Reference
Platform Character behavior on the player, Platform behavior on the ground
Flip Horizontally is a toggle: Yes = mirrored, No = default
Right key → flip No, Left key → flip Yes
Separate events, not one combined event
Preview often — the flip should feel instant at any movement speed
From Here

Once your character faces the right direction, you've got the foundation for everything else — run animations, attack directions, wall interactions, and enemy AI that reacts to which way the player is facing. It's a small detail that touches every system you'll build on top of it.

How to Build a Pro Death Animation in GDevelop Using the Particle Emitter

Katana Works — Tue, 29 Sep 2026 17:00:00 +0000

A character that just vanishes when it hits a spike feels unfinished. A character that bursts into particles feels like a real game. The difference is about ten minutes of setup in GDevelop using the Particle Emitter.

This approach gives you a dynamic burst effect that varies slightly each time it triggers, so the player never sees the exact same death twice. No sprite sheets, no pre-rendered videos — just one emitter object and a few events.

Prerequisites

You need a working scene with:

A player with the Platformer Object behavior attached
Input handling events (movement, sprite flipping)
A hazard object (spikes, enemy, whatever kills the player)

If your player can move and your spike exists, you're ready.

Create the Particle Emitter Object
Add a new object to your scene → select Particles Emitter from the list. This is your death effect — the "soul" or debris burst that plays when the player dies.

The default settings are a mess for this use case. Here's what to change:

Delete when out of particles → ON. If you skip this, the emitter object persists invisibly after the animation finishes. That means wasted processing and potential visual glitches on respawn.

Number of particles in tank → 1. This is the one most people get wrong. The default is -1, which means infinite particles — great for fire or rain, terrible for a death burst. You want a single controlled pop, not a fountain. Set it to 1.

Gravity on Y-axis → ~800. This gives the particles weight so they arc up and fall back down instead of floating off screen.

Particle start/end size → 50%–100% of your character's size. Too small and the death feels insignificant. Too large and it looks disconnected from the player sprite.

Min/max variation values (e.g., -640 to 640): This randomizes the burst angle slightly each time, so every death looks a little different. That's where the "pro" feel comes from.

Event Sheet Logic

Three actions on one event. That's the whole system.

Condition: Player is in collision with Spike

Action 1: Create object → your Death Particle Emitter, positioned at:

X: Player.CenterX()
Y: Player.CenterY()

This spawns the burst at the center of the player, not at some arbitrary origin point. The effect looks like it's coming from the character.

Action 2: Rotate towards angle → apply to the Death Particle Emitter

Angle: -90 (straight up)
Angular speed: 0

This is what gives you the upward burst instead of particles spraying sideways or downward.

⚠️ Watch out here. GDevelop has several similar-looking rotation actions — "Rotate towards position," "Rotate towards object," etc. If the action asks you to select another object, you picked the wrong one. The correct action only asks for two numbers: angle and speed.

Action 3: Add the Trigger Once condition to this event.

Without Trigger Once, GDevelop creates a new emitter every frame the player overlaps the spike. That's dozens of particle bursts stacking on top of each other per second. Your game will lag, the effect will look horrible, and you'll spend an hour debugging something that's just a missing condition.

Details That Matter

Hide or delete the player sprite immediately. Once the death triggers, the player shouldn't be standing on the spike while particles burst out of them. Delete the player object or set it to invisible in the same event so the particle effect is the only thing on screen.

Match particle size to sprite size. If you rescale your character later, update the emitter settings too. Mismatched sizes break the illusion instantly.

Tweak gravity and velocity for different feels. High gravity + high velocity = heavy dramatic death. Low gravity + low velocity = floaty cartoony pop. Small changes to these two values completely shift the tone.

The Quick Reference
Particle tank: 1 (not -1)
Delete when out of particles: ON
Y gravity: ~800
Spawn position: Player.CenterX(), Player.CenterY()
Rotation angle: -90 degrees, speed 0
Always use Trigger Once on the collision event
Hide/delete the player sprite on death

One emitter, one event, and your deaths go from "programmer placeholder" to something that actually feels like a game. Experiment with the values from here — the particle emitter has a lot of range once the foundation is right.

Stop Watching GDevelop Tutorials. Start Building Instead.

Katana Works — Mon, 28 Sep 2026 17:00:00 +0000

Tutorial hell is real. You're three hours into a GDevelop course, eyes glazing over, and you haven't built anything that feels like your game. The course is fine. The problem is the method.

Following step-by-step tutorials is furniture assembly without seeing the finished product. You learn how to move a character. You learn how to spawn a coin. But these mechanics sit in your brain as isolated fragments, not parts of a game you're actually making. If that sounds familiar, the fix isn't a better tutorial — it's a different approach entirely.

"Just-in-Case" Learning Is Why You're Bored
Traditional tutorials teach everything you might need. Every logic block, every edge case, every possible scenario. Sounds responsible. In practice, it's information overload.

When you learn a complex inventory system but aren't building a game that needs one, that knowledge evaporates before you ever use it. You're not learning — you're mimicking. That's passive education, and it's why you lose focus and stop making progress.

Switch to Just-in-Time Learning

Start with a goal, not a tutorial. You want to build a 2D platformer? Don't search "complete platformer course." Work backward from your vision and solve one problem at a time:

How do I get a character to stand on a platform?
How do I make them move left and right?
How do I flip the sprite when they change direction?
How do I trigger a death animation on enemy collision?

Each solved problem is a win that feeds the next one. You're not following a script — you're debugging your own game. The motivation difference is massive.

Learn from Advanced Beginners, Not Experts
Your instinct is to find the best developer with the most subscribers. Resist that. Experts suffer from the curse of knowledge — they've forgotten what it feels like to not understand the basics. They skip steps they consider obvious. They use workflows they perfected years ago that might be outdated.

Advanced beginners — creators one or two steps ahead of you — are better teachers for three reasons:
They remember the struggle. They still recall the character getting stuck in the wall, the variable not updating, the collision event doing nothing. When they teach, they show the mistakes. That's where the actual learning lives.

Their info is current. Someone who figured something out yesterday is using the latest version of GDevelop and the most relevant techniques. An expert might be teaching a method from three versions ago.

They don't skip "obvious" steps. They speak your language. They explain the keyboard shortcut. They show which menu to open. You don't get stuck because the instructor assumed you already knew something.

The Fastest Way to Lock It In: Teach It
Once you've implemented a mechanic — a double jump, a parallax background, a checkpoint system — explain it to someone else. Blog post, short video, even a written note to yourself. Format doesn't matter.

Teaching does two things:
It forces organization. Verbalizing your process moves knowledge from short-term recall into durable understanding. If you can walk someone through it, you own it.

It exposes gaps. If you can't explain a specific part of your logic in simple terms, you don't fully understand it yet. That's not a failure — it's a free diagnostic. Go back, relearn that piece, and try explaining it again.

You don't need an audience. You need the act of articulating what you did and why it worked.

The Playbook

If you're stuck in tutorial hell right now, here's the shift:

Stop watching tutorials like movies. Have GDevelop open. Only search for answers to the specific problem in front of you.
Pick one game idea. Break it into the smallest possible tasks. Solve them in order.

Seek out creators who show their bugs. The fix is more instructive than the finished product.

Try the "Explain It to a Five-Year-Old" test. If you get tripped up explaining your game's logic out loud, that's your gap.

Build → Learn → Teach. That cycle is the fastest path from beginner to confident developer.
The Point

This isn't about abandoning tutorials. It's about stopping the passive consumption loop and replacing it with targeted problem-solving on a real project. Just-in-time learning, advanced-beginner mentors, and teaching what you build — that combination kills tutorial hell faster than any course will.

Pick a game. Break it down. Build the first piece. Search only when you're stuck. Explain what you did when it works. Repeat.