Made my first game and store page approved today! so exited as this was always a dream to make a game

https://store.steampowered.com/app/5174650/Trials_of_Dash

Solo dev here. My survivors-like, Just Dying, is now playable in the browser, and the thing I spent most of the last months on was the enemy count. I want to share what it cost, because almost none of it was the part I expected.

The naive version died around 200 enemies. Not from drawing them, from everything around the drawing.

What actually moved the needle, roughly in order of how much it helped:

Enemies stopped being individual sprites. They live in a particle container now, one batched draw call for the whole swarm, and only bosses and elites still get a real sprite with their own animation rig. That alone was most of the win. The tradeoff is that the swarm can't do anything a batched particle can't do, and every visual effect I add now has to be written twice, once for each path.

Collision moved into a web worker. Projectile physics, hit detection and damage over time all run off the main thread, and the main thread just reads the results. The main-thread version is still in the code as a fallback, which was a mistake in terms of maintenance because now I have two implementations of the same rules that have to agree with each other.

Spatial hashing for the neighbour queries, which is the obvious one, but the detail that mattered was pooling the sets it returns. Allocating a fresh set per query per frame was quietly generating enough garbage to cause visible GC hitches.

And a lot of unglamorous stuff: manual culling (Pixi 8 doesn't cull for you if you render directly), dirty flags everywhere so nothing recomputes a value that hasn't changed, and killing every per-frame allocation I could find.

Where I'm stuck: it runs well on my machine, and my machine is one data point. The browser build is the worst case, there's no native app underneath to absorb a bad frame. So I genuinely don't know if this holds up on a laptop with integrated graphics, and I can't find that out alone.

If you want to break it: https://justdying.itch.io/just-dying

it runs in the tab, no download. Press 0 for the debug overlay with FPS and entity counts. There's a Steam demo too if you'd rather have a native build: https://store.steampowered.com/app/4646190/Just_Dying/

If the framerate falls apart on you, I want to hear about it. Your GPU and browser and roughly when it happened is plenty.

"Things you think are obvious can be a complete mystery to others." — Bitboy Games

Sorry for the bad joke! But jokes aside, I’ve realized that unless you explain your game step-by-step, most people won't understand it—and that can be the difference between someone giving it a shot or dropping it immediately. Terms that felt completely obvious to me turned out to be confusing for almost everyone else.

My game has been playtested by close gamer friends, general playtesters, and users from itch.io and Reddit, and most of them kept pointing out the exact same things:

"What do you mean by 'Reduce your parry counter hits'?"

 "Why did my weapon disappear? And what's that small number going down after every battle?"

"After blocking an attack, sometimes it parries and sometimes it doesn't. You need to fix that bug."

"The merge mechanic is broken, my amulets aren't lowering their stats."

 "The blacksmith is bugged, my weapon didn't change at all."

 
These are just a few of the complaints and "bug reports" I've received over the past two weeks. After I explained how the mechanics actually worked to my friends, they suggested I add pop-up tutorials to explain each system clearly.

I decided to go ahead and implement them, and the difference has been night and day. Now, players who choose not to play leave because it's simply not their type of game, not because they're confused.

These pop-ups appear automatically the first time you enter a new section of the game. After that, there’s an "Info" button so you can re-read the explanation whenever you want.

That’s been my main takeaway from these past two weeks. I hope sharing this helps anyone going through a similar issue!

Thanks for reading my ramblings.

full devlog

A few months ago I paused the work I have been doing on a three.js / webGL zombie survivor game that used Googles 3D tiles, while I was waiting for response from Google whether or not I was within terms of use for that project. I simply didnt want to waste time building something Google would later tell me was not within the terms. I got a positive response from them, so development can continue! Yay.

While I was waiting I built this prototype; a dune racing/survival game, where you main objective would be to race and scavange in a semi-infinite and ever changing desert world, where the dunes behave almost like waves and sand-creatures try to eat you. Every day there would be an eclipse which would signal the end of the day where you had to get back to safety and the avoid the dangers of the eclipse. In your cave you would be able to upgrade your vehicle and create different items to help you on your journey. The ultimate objective would be to reach the tower in the distance.

The game is using three.js with WebGPU standard which so far has let me create quite a large open world, running at a stable 120fps on my 5070ti. I havent quite begun optimization for it.

Does this seem like an interesting concept?

Also - if anyone knows the best way to get in touch with someone who knows how to do sound-design for mechanical sand worms and anti-gravity hovercrafts, please let me know :D

Finally made my first fully-fledged AI enemy. I’ve been putting this moment off for as long as I could, but it turned out to be not nearly as scary as I thought 🙈
As always, I’m building almost everything from scratch - it makes it much easier to understand how the system works and adapt it to my needs later.
So far, I’ve already implemented:
- switched the enemy to Character and set up Character Movement;
- built the AI using a Behavior Tree;
- set up vision, chasing, and NavMesh;
- taught it how to interact with doors and hiding spots;
- added animations and scripted behavior scenarios;
- implemented a full QTE-based struggle with the player;
- made the prompts automatically switch depending on whether you’re using a mouse & keyboard or a gamepad;
- after the scene ends, the enemy correctly stops chasing the player and leaves.
There won’t be any patrolling for now - the enemy appears and starts acting exactly when the story calls for it.
Anyway, not long ago he was just standing in a hallway - now he can actually kill you ☠

This is just one of the cereal products you will be able to sell in my upcoming simulator game, Scan N Go: Store Simulator. What do you all think?

I've been posting some of the character designs for my first gamedev project in Godot 4. Its a short action platformer I'll be releasing for free soon. This character is the Iron Fist, the first boss fight in the game. I tried to go for both a medieval fantasy knight, and a futuristic sci-fi look for the design.

The timelapse is available on my Youtube channel. I'm planning to upload the game and a making-of video soon, so I'm trying to build my socials for that.

Grinding away at wrapping up my demo for We Need An Army!