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!

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!

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.

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!

First devlog for a small side project: https://www.youtube.com/watch?v=SmswtobcASg

What's in it:

- How a run works: three procedurally generated valleys with random objectives, a pass through the cliff to the next one, then a boss.

- The sword: four cuts that chain like old fencing manuals, so each one ends where the next starts.

- The enemies: three types, plus a boss that telegraphs every attack with zones on the ground.

- The world: a height function, then a Townscaper-style grid for the cliff, where each cell picks a piece from its four corners. That grid came out of a whole day of trying to generate natural rocks in code that never looked right.

- Where it stands: what's still placeholder (most of the art) and why it's a roguelike for now.

The name is a working title, so ideas are welcome.

AI disclosure: I use an AI coding assistant (Claude Code) for part of the code. The video's narration is a synthetic voice, and the concept images shown for the future enemy designs are AI-generated references for modelling. The in-game models are CC0 (Quaternius) or placeholder shapes, and the music and sound effects are synthesized by code.

More than two months after uploading the web version of the game, today I’m finally releasing the Windows version of "Nightmare in San Vicente", in which I’ve incorporated some improvements, especially in terms of visuals, since in the executable I’ve been able to get around the 1,000-file limit that exists on itch.io for online projects.

With this, I consider the project’s development process complete. If I write another devlog, it will be to announce the Spanish version of the game, something I’m still considering.

For developers who have ever used RPG Maker, here's what the final project looks like:

• Just over 2,000 hours of development
• 147 maps
• 395 switches
• 148 variables
• 104 common events
• 81 objects
• 37 plugins

And for players, here’s what you should know:

• An exploration, horror, and mystery game with a 2D pixel art style
• A keyboard and mouse are required to play
• No combat, though there are MANY ways to die in the game
• A large amount of text and clues that you’ll need to read carefully (the game doesn’t hold your hand.)
• 10–14 hours of gameplay
• 1 main storyline + 5 side stories

As a final note, I’d like to mention that it started out as something much smaller, but little by little it grew until it became a game lasting over 10 hours. I’d like to thank the friends who contributed to the project with their music or art, as well as those who helped me test the game and encouraged me to keep going with it. It’s been a long and sometimes frustrating process, but if there’s one thing I can say, it’s that I'VE ENJOYED IT TO THE FULLEST.

A big hug and thank you very much to everyone for reading.

Hey there :)

I'm building a roguelite where you capture, train and battle mutants.
After designing and building the game's core systems like the gameplay loop, data models, system design and so on I am now working directly towards building a playable demo.

This week I added weather. My first idea was the obvious one:
Roll the weather for each room independently.
That felt wrong and generic to me immediately so I changed it to use a Markov Chain instead.

There is a propability that it starts a weather condition. Then a weather condition get's chosen by percentage values for the specific region.
A forest might have 60% chance of clear weather, a 20% chance of fog and a 20% chance to rain.
When it's already raining it has a 60% chance to keep raining, a 10% chance to worsen into a storm and a 30% chance to clear up.

There is no rule forbidding it to start a new weather condition immediately but some have a cooldown attached to them.

During battle rooms weather will have a chance to apply status effects to some or all mutants on the battlefield while in shop / event rooms it has an impact on which kind of shop appears and what events spawn in.

A player sent us what looked like a contradictory report: their runs were saved in local history, and the game showed a comparison rank during play, but their best run was missing from the leaderboard list.

This happened while working on Stunt Pals, our Android animal-launch game. We had three things that looked closely related: a record saved on the device, a rank estimated during a run, and a place confirmed by the online board. The screen needed to explain which one the player was seeing.

One board, with optional login

We moved from relying on the platform's public leaderboard to an app-owned board. Players enter a unique nickname and opt in; connecting Google is a separate, optional step for recovering their ranking identity. It isn't a full cloud save or purchase backup.

That added work: handling duplicate names, supporting Korean, English and Japanese input, and providing reporting, hiding and deletion controls. We also had to distinguish pending, confirmed and failed submissions. A successful button press alone doesn't tell the player whether the score was saved online.

Daily needs one shared clock

For a worldwide daily challenge, resetting at each phone's local midnight would put different people on different days under the same heading.

We gave that mode one reset time: midnight in Korea, UTC+9. Its map, conditions and leaderboard use the same day, with daily scores kept separate from all-time bests. Local daily missions can still follow the device's date.

We also added checks for late responses. A result from yesterday's board, or from the identity used before an account connection, should not replace today's list.

What we learned

Owning the board means more responsibility. For us, it helped to separate the player's local history, shared ranking identity and confirmed online result instead of presenting them as one thing.

If you've added online rankings to a small game, what helped you make pending versus confirmed scores clear without cluttering the result screen?

A short edited gameplay clip for context:

https://reddit.com/link/1x898dq/video/tw4e9cwnv0wh1/player

Stunt Pals is free on Android, with ads and optional in-app purchases.

Google Play: Stunt Pals – Animal Launch

This update brings a lot of new additions next week, including a whole new perspective for the engine!

I thought I was close to being done. I had added all the new features I wanted, and all that was left was to polish everything... until I saw the RPG Maker U2U trailer.

And I'm like, well, look at that... If my competition has upped their game, then so must I!

So, introducing MMO Studio 0.7.0: The Diorama Update!

I've been working day and night on this update, with the new 2.5D perspective taking center stage, along with a few other major additions to the engine.

The screenshots were taken while I was building out the system and trying to match what I saw in RPG Maker U2U. The update is still a work in progress, but I thought I'd share what I've got so far!

What's New

• Turn-Based Combat: Player battles in both PvE and PvP.
• Moves System: A new interface that l

a coworker of mine has been making single-request decode for Qwen3.6-35B-A3B faster on one H100 where I work, and the megakernel he set out to build kept coming out slower than plain kernel launches

the idea was one persistent kernel that streams weights across operations and layers instead of stopping at hundreds of kernel boundaries. part of it worked, a persistent dense chain was 4.4% faster than separate launches. but the full MoE block was still about 4% slower after multiple rounds, and a full layer was 9.5% slower

the reason was that one kernel config had to serve very different operations, and it lost more per-op efficiency than it got back from prefetching across them

the launch cost settled it. inside a CUDA graph a launch boundary costs about 1 microsecond, so paying it was cheaper than the barriers needed to avoid it. the failed versions still paid off, they exposed a race condition and 2 measurement bugs

so the tuned kernels stay as separate launches, and the next big gain has to come from speculative decoding. with MTP the stack is already 50% faster than stock SGLang on the same GPU

feels close to the draw call batching argument, merging work only pays while it removes more than it adds. anyone hit the same wall in their own projects?

he wrote up what worked and what lost on our blog, if you want the details: https://www.coralbricks.ai/blog/ai-latency-engineering

Check out the full video: https://youtu.be/CFkDQlB5kdk

In this devlog, I go over the differences between the disciplines of environment design - the look of a game level - and level design - the gameplay of a game level. Oft the two are conflated but environment design is much more visual (and so makes for better gifs and short videos) whereas level design exists in an abstract, conceptual space and concerns actions, consequences, emotions, and possibilities.

Hope you like it! 🌿

Hey everyone!

We just dropped Demo Update v0.2.0 for Champion of the Lore, and I wanted to share one of the changes I'm most excited about.

A lot of you pointed out that having to click a "Play Card" button every single time made combat feel clunky and slow. You were totally right. We listened, went back to Unity, and completely removed that extra step. Now you just select your card, click your target, and boom—faster turns, cleaner flow, and way less unnecessary clicking!

Honestly, seeing the game get smoother and more fun directly because of player feedback is one of the coolest parts of this whole indie dev journey.

If you want to give the new combat flow a spin (or check out the rest of the update, like our brand new Settings menu!), the free demo is live on Steam:https://store.steampowered.com/app/4178300/Champion_of_Lore_Demo/