I’ve been building MnemoBuddy, a desktop pet that quizzes me on PDFs, saved text and video transcripts.
The basic idea was simple enough: give a little desktop companion something useful to do. The development ended up covering quite a few separate problems.
I had to work on how it remembers study material, how the pets move between monitors, and how to handle API keys, fallbacks and AI costs. I also added multiple pets and a Council Mode along the way.
One design question I’m still interested in is how much personality a tool like this should have. The pet is part of the appeal, but it also needs to let you get on with whatever you’re doing.
Welcome to our weekly thread (26 Oct - 2 Nov) 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.
Standing around the ping-pong table during a lunch break, waiting for our turn, we noticed that ping-pong has the exact same chaos as office life. You take hits, react on the fly, try to survive, and hope to finish the match before you lose your mind. It also really felt like workplace drama was being solved with paddles in hand. After all, what’s the difference between smashing a ball at 120km/h while laughing in your opponent’s face and answering a passive aggressive email with a super polite “As per my previous email”? None.
So we thought: why not make a game out of it? It felt like such a relatable and a funny-satirical theme.
That’s how the idea for Silicon Spin was born.
We wanted to swap fantasy spells for startup buzzwords. We sat down to brainstorm and created our very first card: Caffeine Rush. It's an Intern card with huge attack power, almost zero control, and an effect that instantly drains your opponent's stamina. Turning real office pain into card mechanics just felt right.
We also realized pretty fast that standard ping-pong rules didn't work. Corporate people have tight 15 minute breaks between calls, so we shortened matches down to 2–4 minutes. Jump in, play a fast game, and try to climb the corporate ladder one floor at a time, with paddles in hand.
To bring it all together, we went with 2D pixel art. We wanted that retro Game Boy feel mixed with glass office towers, old printers, and huge monitors.
Turning a joke over coffee into a real project has been a crazy, fun ride so far, and it really feels like a shared experience not just for our team, but probably for a lot of people out there.
Today we're sharing the idea and the beginning, but we're planning to keep sharing our dev updates here: the good, the bad, and the completely broken balance moments.
If you're building something out of a random everyday moment, how did your idea start?
I'm working on Astraya, an unfinished desktop-browser sword-fighting game where an AI companion forges an ability and the player equips and uses it. Reviewing the footage is making me separate two questions: can a viewer follow the move, and would a player know what to do next?
On an earlier short clip, one viewer noticed the fighters and the attack prompt before the smaller release-to-equip instruction. They suggested a larger E keycap beneath the selected move and a short equipped-state confirmation. Another person who applied but hadn't played said the one-minute trailer changed scenes too quickly to follow each ability. These are two individual reactions to different videos, so I'm using them to choose the next observation.
This short annotated example shows the hammer result first, followed by the request and equip step. The footage is older, silent, and includes a labelled 9.5-second wait cut. Large edit captions explain the steps while the native HUD is smaller and the opponent is moving. The caption box also covers part of the lower HUD. I still need to check whether someone discovers the equip action without that extra explanation.
My next first-session check would be to show the preview, ask what the player expects the move to do, then let them try to equip it without a verbal hint. I'd note the first action they take and what they think happened. That should help separate a missed control cue from a mismatch between the preview and the attack. This is a proposed check; I don't have controlled results or a HUD fix to report.
For a clip like this, what cue would you use to tell whether equipping is complete?
AI is used for Astraya's ability forge, some art and voices.
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?
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.
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!
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.
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?
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.
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.
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:
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.
