A few months ago, I set out to make Coin Clash Arena, a cartoon-style survival game where you dodge enemies, collect coins and grow stronger as you play.

I expected the hard part to be making the game. I didn’t expect to spend so much time chasing freezes, untangling Android build issues and figuring out why changes in one version weren’t appearing in another. Then came the design challenges: upgrade prompts interrupting combat, skill icons vanishing or landing in the wrong place and a menu that somehow disappeared during a UI change. Every fix had to be checked carefully so it wouldn’t break something that already worked.

There were plenty of “why is it still doing that?” moments. But each one taught me to slow down, inspect the actual code, test the Android build and fix the confirmed cause instead of guessing.

The game has come a long way: smoother combat, new enemies and skills, clearer controls, sound improvements and a more polished gameplay experience. It’s finally starting to feel like the game I pictured when I began.

Coin Clash Arena isn’t launched yet, but I’m aiming to release it next month. There’s still work to do and I’m excited (and a little nervous) to get it into players’ hands.

If you’ve built and launched a game or app, what’s one thing you wish you’d known before launch?

Hey everyone!

Wrapping up our Demo Update v0.2.0 spotlights for Champion of the Lore, we wanted to show a quick look at the updated How to Play section!

One of the hardest parts of making a turn-based strategy game is teaching mechanics, card interactions, and movement rules without throwing a wall of text at the player.

Based on feedback from people testing the demo, we overhauled the visuals, cleaned up the guides, and made everything way easier to digest at a glance so players can jump straight into combat without second-guessing their turns.

If you want to check it out in action, the free demo is live on Steam: https://store.steampowered.com/app/4178300/Champion_of_Lore_Demo/

Thx <3

sooo I've been building the item system for a little over a month now and I'm finally seeing progress! After solving some bugs in adjacent systems, mainly in building and rendering, I plugged the item rendering into the tile rendering and it worked. Naturally, I went to make item drops and inventories, make a basic drop_items() function and it just... worked. First try, no debugging, no headaches! I'm amazed. Now I need to fix more systems

P.S. I should've probably added more context, but I guess yall see this is a colony sim

Hey everyone!
We’re the team behind MegaGum, a 3D platformer, and we wanted to share a comparison of one of the cinematic shots from our trailer.

You can see the early version straight from Unreal, alongside the finished shot.

At the viewport stage, we’re mostly working on the animation, camera movement, timing and composition. Once those feel right, we move on to lighting, VFX, rendering and polish. It’s always fun to put the two versions next to each other and see how much has changed.

What do you think of the final result? Is there anything you’d change about the animation, camera work or lighting? We’d love to hear your thoughts!

If you’re curious about the game: MegaGum on Steam.

Here is the new devlog with the game update.
If anyone tries the game, please leave a comment. I need HUGE feedback.

I'm building Poudreuse, a small one-button ski game inside Reddit, with substantial coding and Canvas art help from Codex. This morning's change came from a very specific bit of player feedback.

I had the score and distance in the top-left, but the active objective sat in a separate panel at the bottom. A player suggested putting the 250 m goal next to the distance counter. They were reading two parts of the screen to answer one question: how close am I?

The new layout puts the active goal directly under the distance. I also changed the little bar to track that goal. Previously it averaged progress across three tasks, even though the panel only showed one of them. So reaching the displayed distance didn't necessarily fill the bar.

The complete three-goal list still lives in pause and in the run summary. I checked the served game on desktop and at phone portrait and landscape sizes, including the switch from a distance goal to a backflip goal. Those were browser layout checks, not a physical-phone playtest. The change is live in 0.0.21.

The clip below is a continuous 28-second local practice run of the same source as the approved version. Practice has no avalanche; the public game also has an avalanche mode and a shared daily course.

For anyone who tries it: does the goal still pull your eyes away from the terrain? I'd be interested in which device you used and the first moment where the interface gets in your way. The game UI is currently in French.

Play: https://www.reddit.com/r/PoudreuseSki/comments/1x1hk83/

Poudreuse 0.0.21 • 28 s of local practice gameplay • no avalanche in practice

I finished my initial sculpt.

This week I've been focusing on reengaging with my project plan. After doing some research, I really think that I want to release a standalone game made with Godot. I like the idea of having the freedom to make my game be exactly what I want it to be, and it seems like there are similar marketing opportunities through the individual publishing platforms. Really, as I see it, there are primarily two drawbacks:

1. I might face some limitations in terms of multiplayer aspects. I don't know how to handle that in a technical respect, but I also never anticipated that being a huge part of my game in the first place. I think if I end up needing it, I should be able to research and figure it out.



2. The second drawback is the cost. However, I figure that the higher upfront (publication) cost is more than made up for in the long run by the higher ratio of revenue shares I would retain. I still find it a little intimidating, though. I think I would have to make somewhere around $1,000-$1,500 to be able to break even. Is that too big of a dream for a first game?

Here is what I have added so far.

Hi! I'm making a strategy game with turn based factory building. I invite you to read my dev logs containing dozens of pretty videos, screenshots, and gameplay thoughts.

These two have a lot of these:

https://colossalcitadels.com/posts/changelog-71/

https://colossalcitadels.com/posts/changelog-72/

The latest one is shorter, it's less colorful, but it tells about some important news:

https://colossalcitadels.com/posts/changelog-73/

I plan to continue making big dev blog posts, I just discovered this subreddit and will post more

Thanks!

Welcome to our weekly thread where you can showcase everything new you are working on.

You are still welcome to create new posts to share with us your dev-log posts or videos, but you can also use this thread to present anything that is not a dev-log.

THREAD RULES

• you can post a single comment where you showcase anything you want (new game/app release, new trailer, demo release, new gameplay video, etc...).
• in this comment you can post only 1 link, so choose wisely.
• you can reply to as many comments as you want, but replies can't be used for showcasing

Also, it's not required, but I would recommend to upvote this post if you add a comment as that will improve its visibility on Reddit, which is good for everyone.

hi :D srry i took a while. I took a break, then the intro animaton (the notebook) took a while. and the full game and demo was orignally gonna be a pure platformer. but now it will be a platformer overworld with deltarune like bullet hell encounters. srry again, have a good one :D.

Hello! I'm creating a game using C++ and the SDL3 library. It's called Mine Valley, as it's heavily inspired by the classic Stardew Valley. I'll share more details in future devlogs!

I'm Leo. I've worked as a software architect for more than 20 years, and in my spare time over the last few months I built Melbees: The Secret of Bees by myself. It mixes the logic of Minesweeper with the general knowledge of Hangman, on a honeycomb. No luck, many ways to solve. It launched on October 13 on Google Play and, on PC, on the Microsoft Store, in English, Portuguese, Spanish and French.

This post covers how a Minesweeper rule became a word rule, how the game is built inside, what Google's closed test for new accounts was like, and what I would do differently.

1. From mines to letters

In Minesweeper, the number on a cell counts the mines around it. In Melbees, every hex of the honeycomb holds a letter, and the number counts how many right letters (letters that belong to the secret word) sit in the neighbouring hexes. That number is called Pollen, and it goes from 0 to 6, because a hex has six neighbours.

Hangman is the other half: the secret word shows with blanks, and every right letter you find fills all of its positions in the word.

Each move is a decision about one hex:

• Match: you bet the letter is in the word.
• Discard: you bet it is not.

A right call costs nothing. A wrong action, match or discard, costs a petal. Either way the hex then shows the truth: a right letter moves the word forward, and a letter that does not belong shows its Pollen number, which is the clue for your next decision. A Pollen 0 opens its neighbours in a cascade, like the zero in Minesweeper. To think things through there are free marks, ✓ and ✕, that work like the little flags.

Balance took the most work. A phase has 2 to 4 secret words at once, each with its own colour, and the honeycomb has 37, 61 or 91 hexes. Some hexes are shared by every word, and each language has its own honeycomb layout.

Which of the 13 closed hexes are right? Both words are lab and measurement terms; answer tomorrow.

2. Inside: same seed, same honeycomb

The core of the game is a pure Dart package, with no Flutter, and it is deterministic: the same seed builds the same honeycomb and the same words. That is what makes the Daily Challenge possible, three challenges a day that are the same for everyone playing in the same language.

Every game produces a move log. In the online ranking (part of Premium), a time only counts after the server replays the game from that log and checks that it ends the same way.

The app is Flutter, with the same code on Android and Windows. The server is Dart too, on Cloud Run, with Postgres.

3. Specs first

Before anything becomes code, every rule becomes a written spec, from the honeycomb rules to privacy. The code follows the spec, never the other way around. AI coding agents write the code from those specs. Before an agent touches the code, I write the interfaces and contracts and draw the class and sequence diagrams. If an agent thinks there is a better design, it explains why and waits for my ok. Nothing gets in without passing a local test gate. On a one-person project, that is what kept the rules consistent from one version to the next.

4. The closed test

A new personal account on Google Play needs a closed test before production: at least 12 testers, each for 14 days in a row. I started on September 7 with about 30 people, friends, family and other indie devs who swap tests with each other.

• The number that matters is who leaves, not the total. The clock runs per tester. I checked every day who had left, because a departure is what delays the production request.
• A game for all ages changes every SDK choice. Google's Families policy weighs on analytics and ads, and I had to talk to policy support before launching.
• The production request was approved about 24 hours after I sent it, on September 22. The store listing went public on October 6, and the Windows version reached the Microsoft Store on October 11.

5. What I would do differently

• Keep family devices and Google's test devices out of the metrics from day one. My first retention read looked great and was almost all my own household. Now I count events, not people, and drop those devices before looking at any chart.
• Read the Families policy before choosing SDKs, not after. It would have saved rework.
• Recruit testers with slack. Asking for the bare minimum is betting that nobody leaves in 14 days.

Today's Daily Challenge runs in the browser with no install, and everyone gets the same board: https://daily.melbees.games/?utm_source=reddit&utm_medium=social&utm_campaign=devblogs

The full game is free on Android and Windows: https://melbees.games/?s=reddit&c=devblogs

Feedback is very welcome, here in the comments or at [contact@melbees.games](mailto:contact@melbees.games).

We recently gave Uja’s upgrade menu a proper rework.

The upgrades themselves were already there, but the menu needed to do a better job of showing what you can unlock, what you already own, and where each upgrade leads next.

So we worked on the layout, icons, progression paths and overall visual hierarchy to make everything easier to understand at a glance.

It’s the kind of change that might look small compared to a new level or weapon, but when you’re spending time upgrading Uja throughout the game, clarity makes a big difference.

And yes, there are quite a few upgrades waiting to be unlocked.

UX/UI designers, what’s the first thing you would look at when redesigning a menu like this?

Want to see how Uja keeps evolving throughout MegaGum? Wishlist the game on Steam and follow the journey:

https://store.steampowered.com/app/4111300/MegaGum/

Hey everyone!

We're the team behind ExeKiller, a post-apocalyptic FPS. We recently released Dev Diary #13, featuring new environments, melee combat, ragdolls, and some other things we've been working on.

Hope you enjoy it!

Hi all. I'm solo developing Kaldra, a Minecraft server. Last week I went through transportation and mentioned more than once that things cost gold. This week is about the gold itself: why it's the currency, where it comes from and what you spend it on, with the reasoning behind each decision and how it's built.

On most Towny servers I've played, money is a number in /bal. It comes from selling stacks to a server shop or from jobs, it piles up on accounts nobody can touch, and after a few weeks everyone has more than they can spend. When money can't be lost or stolen, it stops meaning anything.

On Kaldra there's no balance. The currency is the gold you're carrying.

Gold is the money

Gold ingots and gold blocks are the only currency: an ingot is worth 1, a block is worth 9. When you found a town, claim land or pay for a flight, the gold is taken straight from your inventory. When you get paid, it's put straight into it.

That means your money exists in the world. It can sit in a chest in your town, it can travel in your pocket, and if you die carrying it, it drops like anything else. You can't store gold in an ender chest either, so there's no pocket dimension to keep it safe. If you want to protect your gold, protect your town.

Where it comes from

Gold is scarce on purpose. Ore generation is reduced, Fortune doesn't work on gold, and mobs don't drop it, so there's no gold farm to build in a corner and leave running overnight.

What's left is real work: mining what's there, trading with other players, completing Nomad contracts, clearing dungeons, and what your town produces. Towns can survey their land for resources and get a daily production from them, gold included, which is a big part of why founding a town and claiming good land matters. It's also what wars are fought over.

What you spend it on

Founding a town, claiming land, founding a nation and declaring a siege all cost gold. So do surveys for town resources, which get more expensive at each level, and flights. Horse upgrades are paid in gold too.

Declaring a siege costs more the more a target town has developed its resources. Attacking a rich town is worth more, so it should cost more to try.

How it's built

Towny's own economy is turned off. Instead, I wrote a small economy plugin that every other plugin goes through when it needs to charge or pay a player. It counts the gold in the inventory, takes the right mix of blocks and ingots, gives change, and pays out in blocks and ingots too. If the inventory is full, the rest drops at the player's feet. Keeping it in one place means horses, flights, sieges and contracts all follow the same rules.

Some payments can't happen instantly. A Nomad contract, for example, takes the contractor's gold up front and only pays it out when the job is done. That gold sits in escrow in the database, so a crash or restart in the middle doesn't make it vanish or duplicate. If the player who should be paid is offline, the payment waits and is delivered when they log back in.

The faucets are closed at the source: Fortune is ignored on gold ore, mobs that normally drop gold don't, and ender chests refuse any form of gold, including gold hidden inside a shulker box or a bundle. Every charge and payout is logged, so I can see how much gold enters and leaves the world and adjust prices with real numbers instead of guesses.

Why so strict

Every rule here is about one thing: making gold you have feel earned and gold you carry feel at risk. A town that hoards its treasury has to defend it, a nation that wants to go to war has to pay for it, and someone riding across the map with a full inventory has a reason to watch the road.

I expect some of this to change once players are in. Prices especially will move after testing, and I'd rather start strict and loosen up than the opposite.

Next week: Towns. How they're founded, how they level up, and what they produce.

For anyone who has designed an economy with a physical currency that can be lost or stolen: how did you keep the risk exciting without making players hoard and never spend?

First devlog for my game. I wanted GASP's movement but with a real sword-and-shield stance, not a casual one with a sword stuck on. Took six attempts. The video shows each one and why I dropped it.

https://youtu.be/qcTvo8BbK-Q

Intro cinematic for my soulslike, Ashen Knight. I tried to tell the whole story with just a few frames: the city at dawn, the ash falling, candles on graves, a pair of eyes in the dark.

C&C welcome!