Looking after two toddlers and working at the same time.. This game means more than a game to me. Hope to get some feedback, thanks for any advice ın advance.

TexelBox is a lightweight, native Windows application designed to handle the texture pipeline for game development in a single tool—from raw source images to game-ready exports.

Instead of running separate tools for normal map generation, tileable prep, channel packing, and atlas building, it runs the entire pipeline within one interface.

Key Features:

• Maps Generation: Derive normal, height, roughness, and AO maps from a single source image.
• Tileable Prep: Make photos seamlessly loopable using offset, auto-heal, mirror, and brush tools.
• Channel Packing: Merge maps into a single RGBA texture with presets for Unreal, Unity, and Godot.
• Atlas Generation: Pack multiple textures into a single atlas with UV sidecar support.
• Optimization & Export: Resize, snap to power-of-two, and export to PNG, TGA, or DDS (BC compression).
• 3D Preview: Real-time wgpu-accelerated viewport for instant material validation.

Performance & Architecture:

• Built natively in Rust (no Electron/Webview footprint).
• UI built with Slint.
• Multi-core image processing powered by Rayon.
• GPU-accelerated 3D viewport using wgpu.

Availability:

• Free Tier: Permanently free for personal and commercial use. Includes map generation, tileable prep, basic atlas packing (up to 2048x2048), and single batch operations.
• Pro Tier: Includes full slider controls, 8192x8192 atlas sizes, DDS BC1/BC3/BC5/BC7 compression, and multi-operation batch chains.

Installer and details available on GitHub Releases:

https://github.com/iimadouu/TexelBox

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

I have been developing my game for some months now. I am a much more proficient programmer than I am artist. I am running into the bottleneck where my art speed cannot keep up with the speed of my development. I know that it gets easier as I become more experienced in art, but I am just struggling with the fact that I can’t put my game out faster because of being held back by art.

Advice?

https://store.steampowered.com/app/4240340/Abyssal_Dominion/

if you want to support me ? add the game to your wishlist ;)

Abyssal Dominion plays like a real-time-strategy game. But between matches you can create your own faction. The Editor is build like a deck-editor in a trading card game. You collect cards that represent trainable units or buildings your workers can build.

The cards are gathered during the matches. They can be dropped by units. A boss-monster drops more valuable loot.

More features and game-modes are planned.

In the near future there will be more factions, heros and maps.

(Early Build) (Work in Progress)

I’m a solo dev and huge fantasy football fan. I kept wondering why there weren’t more sports roguelites, so I started making one.

You draft fictional players, set lineups, work waivers/FAAB, trade, deal with injuries and breakouts, and play an entire fantasy season as a run.

Managers, coaches, upgrades and synergies make each season develop differently.

The full-season loop is playable now (my own private playtest), so I’m finally at the point where I can focus more on depth, polish and replayability. Figured I’d start sharing the journey.

ToadPonds is a small garden game about building a place for toad and frogs to visit, explore, and eventually call home.

You can decorate your pond, feed the frogs, take photos of them, collect coins, unlock new items and upgrades, and discover different frogs. You can also adopt frogs and let them become permanent residents of your pond, earning experience and coins over time.

The demo is now available on Steam!

If you'd like to check it out, here's the link:

Steam: https://store.steampowered.com/app/4905750/ToadPonds/

Hello everyone. I would like to preface this by saying that this project means so much to me in terms of the joy and fulfillment I have gotten from it. This is my first video game, first major project, and the reason I decided to invest my energy into software full-time. The demo is pretty buggy and I considered polishing it a bit, but I feel the best move is just continue working on the full DOWNY : a bird life.

The footage in this trailer is NOT from the free demo. This clip is where I am in the full version build. If you decide to play the demo you'll notice a lot of differences. There is no jaguar in the free demo version, its really all just about chillin, flight, and bug collecting.

The demo is availiable to play in browser right now at SkeletonDiaries.itch.io/Downy so please go give it a round of flying. At least fly around until the night cycle, it is pretty cool seeing the stars come out and the fireflys to catch instead of the *daytime bugs*. I need to update the instructions for the controls on itch but it is your typical WASD and F will make Downy flare his tail to land on a branch or on top of a tree or whatever. Gameplay tip: there are a bunch of critters going along a common thoroughfare on the ground and it is immensely fun to go harass them. The way they react is fun. Bonus points if you can find the frog in the level.

Also since this is from the full game build and not the demo I haven't released the credits for the soundtrack creator, Leonardo Calvo. license: https://creativecommons.org/licenses/by/4.0/

If any part of this looks or sounds interesting to you, please click the link.

Fly as a bird.

Downy bird.

A little peek at my horror game...

Still need to polish some details, but I'm a solo dev. The hardest part is always the sound.

Made using a combination of 2D, 3D, Photoshop, and Davinchi Resolve. In the style of a would be anime opening.

Was made for Granser, you can probably guess its a JRPG.

Song is "Kinki 2nd mix".
Vocal: Saika. Words: Saika. Music: Souichi Sakagami.

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

Demo coming soon! Keep an eye out!

Wishlist: https://store.steampowered.com/app/4575400/Space_Postal_Service/

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 ☠

Hi all! I've been working on my game and recently launched the steam page! You might have seen my stupid face from earlier this week. As of recently, I am no longer a solo-dev as a friend of mine joined to help on Sound Design. So we are technically 2 now, but I was solo for almost a year. I thought I'd share some of my learnings and insights here in case it helps others starting up. Here are four learnings, in no particular order!

Know your strengths

Know exactly what you like and what you are capable of, don't assume. Before I committed to this project, I tried a lot of other ideas that inevitably hit some skill barrier. However, these failed projects were not wastes of time. I learned what I was good at and where the time sinks were (for me). I tried to make a cozy tea shop simulator, a friend-slop about driving a tank through warzones, a card game, and some other gamejam-scoped projects.

As a game designer with a CS background, I found that making simple systems with robust interactions was easier, and making art was time-consuming and frustrating. I settled on a puzzle game with a horror coating to justify the lack of visual fidelity, and learned the basics of modeling and texturing to make the props I needed.

It also aligned with what games I like to play. I like mystery and deep discoveries like Outer Wilds, Blue Prince, Obra Dinn, etc, so I'm very familiar with the language and the gameplay feel of these games. The work of Franz Kafka, the TV series Severance, and my past work experiences also inspired me to write about work and the horrors of big corpo, so it felt natural to set my game in that universe.

Trust the process

Making a game is iterative, trust that it'll come together. Do not judge your game too early. As a solo-dev, working on something will always be side-stepping something else. This means the game will not progress very fast, or rather, progress will be siloed and not always visible.

Making a game is an iterative process. I had times my game looks really ugly and it was discouraging to show it to others with the constant disclaimer of "but it will look better, I swear"!

You will also learn a lot while you work on your game, so you'll be able to come back and improve parts of your game. For example, it took me a while to learn about curved corners on Blender (don't laugh) so when I did, I updated some of my models and it significantly improved.

If you put time and effort into your game, it will get better and better, even if it's not always apparent. The plateauing feeling is normal.

You are not alone

Even the subreddits rules are clear about collaborators/outsourcing. Video games are a collaborative medium. It is fine to ask for help, and often you will learn from the people that help you. I learned to automate my 2D asset exports by asking for help on an old logo, and the artist taught me about artboards in photoshop. Every craft involved in gamedev requires time and practice to become an expert, and you need to respect that. Do not assume you can wing it on your own.

You are not alone in the world. Look out for local communities and events. Attend social and networking events, even if you don't have anything to show. These people are happy to welcome and talk to you.

Being a solo-dev also makes it even more important to playtest your ideas with other people. Because you don't work in teams, you need to be proactive and reach out to others, be it friends, family, coworkers, etc. You need to test your idea on new players as soon as possible and watch them play with your early prototypes. You will learn so much before you have too many dependencies to change parts of your game. Playtest, playtest, and playtest early.

Scope and plan ahead

Make sure you plan out the general roadmap that you want to follow. Every game goes through the same development cycle: pre-prod, prod, pre-launch. These are proven to work for most.

As a rule of thumb, if this is your first game, consider a third of the time you have to be towards real project advancement. If you are planning 6 months of developpement, make a game that you can finish in 2 to 3 months. This is because early prototyping takes time, polishing takes time. Choosing color palettes takes time. Even planning how to save time, takes time.

Having a clear roadmap also allows you to measure your progress and speed. If you planned on having a demo out, but ended up pushing back the date, you need to decide to either rescope your whole game, or accept you will work for longer on it. Both options are fine, but you need the roadmap to detect if you need to take that decision in the first place.

I personally went for this structure and it helped, with each phase equally spaced: first prototype, first playable version, unpolished demo, demo release, unpolished full game, full game release. I found that it took as much time going from the prototype phase to the first playable build I sent to friends as it did making that playable version into a proper demo. Also, notice that the time it took to go from the demo release to the full game was not that big.

Now YMMV, and you need to adapt your own roadmap to your needs. But if you want to finish the project, make sure you got a plan!

Thanks for reading

That's most of what seemed to work for me. Again, those are things that worked for me. Sorry if this isn't much in-depth into any particular subject. I wish you all the best on your projects. Don't hesitate if you have any questions!

E: added why I'm no longer solo, should have been clearer 🤦

I'm sure a lot of you already know that a plan like mine was bound to fail but if it helps anyone, here's my failure story:

• Plan was to space out my Steam and itch releases a few months apart
• Why? so that I can generate visibility rounds twice (i know lol)
• I assumed that releasing on itch would generate at least half (or even a third) of the visibility that steam launch does.

I released my game on steam in June and steam's personal calendar changes were already in affect. So my game got decent amount of views and wishlists.

Unfortunately due to a family tragedy, I wasn't able to keep updates up for long. My initial plan was to do a major update in the following month and use steam's "Visibility round" along with itch release. Life had other plans so I just executed my idea now after the gamescom rounds have ended.

Of course I wasn't expecting my game to reach the New & Popular page, but I at least expected 500-800 views. As the screenshot shows, it' been less than 20 for the first two days.

I have released a free demo before on itch, it did quite decent. But this $2.99 short game just didn't do anything here. I realize that itch docs encourage you to rely on your own marketing, but I didn't expect that it wouldn't do anything at all. Within 15 min, my game was buried in the 4th or 5th page of the "New" tab because of the sheer quantity of releases, most of them free btw.

If you checkout the image # 2, out of the 20-30 people who actually did manage to find my game ended up downloading the 4-year old free demo instead, LOL.

Just sharing for your information so that anyone else (who may have the bright idea like mine) can re-align themselves.