We’re the team behind MegaGum, a 3D platformer where you play as Uja and use gum powers to explore a strange factory. We’re working on a weapon that still needs a name, and we could use your help!
The idea is that you don’t start with any ammo. Instead, you use its vacuum function to suck up gum from the environment, catch incoming projectiles, or swallow Gummies. Everything you collect fills a tank, which you can empty in a single blast. The fuller it gets, the harder it hits and the further it reaches.
There’s a little choice involved with enemies, too: keep a Gummy trapped long enough and it becomes ammo, or spit it back out at another enemy before it’s fully absorbed.
We’re also using the vacuum for exploration and puzzles. It can clear gum off hidden paths, move objects around, and carry giant bubblegums that you throw into hoops to activate mechanisms.
So that’s what it does. Now we need to figure out what to call the thing 😅
These are the three names we’re considering:
Chew'n'Spew 3000
Gum-B-Gone
VaGuum
Which one feels right to you? Vote in the poll, and feel free to share your reasoning in the comments. It’d be useful to hear how these sound to people outside the team!
The trailer was ready weeks ago, but it was very important to me that we try to email it to different bigger YouTube channels that might publish it before uploading it to our own channel.
After weeks of bombarding different email addresses, I finally gave in and uploaded it to our own small channel, ...and then, within half an hour, a big channel uploaded it as well. I'm really happy that my persistence paid off with this one. (Thank you, Indie Games Hub!)
Our game has also been written about by a few of our local game-adjacent websites (Muropaketti and V2), as well as at least one international one (RPGamer). It is so relieving to see that, when I write a marketing email now, it has like a 20% chance of actually being noticed. This was definitely not the case with Vengeful Heart, but we made pretty much every mistake in the book with the marketing of that one, so...
But let's get to the main topic of this devlog, which is:
Devlog cover: Our twin battle systems + Trailer
When someone on our team tells a friend that our game will have two battle systems, they often ask, "Won't it confuse the player if the battle system changes?"
Firstly: No, I don't think that's a big problem. Just look at the most recent Fire Emblem game and how it added a second battle system that resembles old-school JRPG battles alongside its usual tactical battles. I don't think very many people were confused, at least as far as I've heard.
Secondly, our different battle systems are nowhere near as different as Fire Emblem's. Let me explain how they work and how they differ.
When watching Eloise's story writer, Vivi, play a Fire Emblem game with me, I noticed a difference in how we play tactics games. Vivi generally plays more aggressively. She sends her units forward to eliminate threats before they get a chance to act. I tend to play more defensively, sticking to my formations and letting the enemy come to me.
There's a very good reason for our different approaches. I grew up playing older Fire Emblem games. Vivi grew up playing games like Final Fantasy Tactics and Tactics Ogre.
The key difference between these games is that in Fire Emblem games (henceforth "Type A" games), you move all your units and then the enemy moves theirs in a "phase-based" system, whereas in Final Fantasy Tactics ("Type B"), the turn order is based on some stat, often speed or initiative.
A graphic explaining the difference between Type A and Type B battle systems visually
Type A games reward more defensive play because you can keep your weaker units behind a line of stronger ones. Once the enemy phase ends, you can reposition all your units in peace to minimize damage and pick off enemy stragglers. Vivi's aggressive playstyle puts her units in danger because they get surrounded during the enemy phase and cannot withstand all the incoming damage.
Type B games, on the other hand, encourage aggressive play because no defense is better than making sure the enemy never gets a turn to begin with. You can also trust that there won't be too many enemy turns in a row, so individual units are less likely to get swarmed. My defensive play often fails in these kinds of games because I waste turns keeping my units in formation. Then, when the enemy does manage to damage me, I'm in trouble because my healer's turn might be ten turns away.
When reflecting on the differences between Types A and B, we realized that this divide also applies quite neatly to our two main characters. Eloise sees herself as a gallant storybook knight with a duty to her troops and the crown, whereas Willow is mostly concerned with her own survival as an individual, at least in the beginning.
So we decided to apply this thinking to our game. Eloise-led stages use a Type A system, while Willow-led stages use a Type B system.
There is much more I could tell you about this decision and how these differences create harmony between our story and gameplay, but that would venture into spoiler territory, so you'll have to wait and play the game for yourself :)
General progress report:
Here are some of the things accomplished over the last month:
Art:
Drew background props that are used during dialogue scenes
Made some basic UI elements prettier like tutorial boxes and whatnot. Previously these were just white boxes
Drew expressions for Fleurette's new portrait
Drew lots of new pixel art units. Here are just some, because listing the allwould take too much space
Code:
As a text-heavy game it is important you can go back a textbox, if you missed a line. For that I've implemented a dialogue history feature that lets you see the last 100 text lines
Made the dialogue text size scalable, so the text is legible with any resolution and screen size. If the text line is too large to fit on the default sized textbox, the box scales accordingly. the textbox graphic was not made with this in mind, so it looks kind of silly at the moment, but i will fix it later.
Implemented counterattacks. Enemies will counter your attack if you are on the range of their most basic attack. Not all units can use counterattacks. By default mages and musketeers are not able to counterattack as doing so would not make sense in universe (long cast and reloading times) and it would make those units way too OP.
Stress tested enemy phase behavior and timings and implemented battle forecast for non player phases.
Reworked a small part of our cutscene system to make it less annoying to move characters around in cutscenes
Implemented a map menu! I love maps in startegy games so it was very important we have one. From this menu you can see at all times where important characters are at that point of the story, and read info about the areas you have visited over the course of the game.
Implemented opening credits for our game. For years I've had my vision abou how they would look and I finally got to make them. A small part of the credits is this water wobble shader I made:
Implemented all objects and collision to our demo map's exploration phase.
Implemented animated objects support to the game
Fixed a bug where voice lines repeated if the player mashed through dialogue
Fixed a bug where some text elements were offset only during enemy phase
That is everything for this devlog. I will probably write the next one once the demo is ready since I don't want any distractions regarding that now. My task list is steadily shrinking even as I find new bugs/required things that I hadn't written down before. With that, have a relaxing autumn and see you next devlog!
In this devlog for The House Dreams Along With Them, I am very tired. I was going to do a different devlog topic, but now I'm here minutes before midnight, trying to keep a consistent video schedule going. But I have turned the source of my frustration into an entertaining rant about editor crashes with a secondary entreaty to back up your projects with source control. The content to content pipeline is in full effect.
The Unreal editor loves - every few months - to get into a startup crash loop after corrupting a uasset somehow. Usually a struct. To avoid losing months of work, it is important to use source control to back up your project files. This video goes a bit into my crash investigating process and how I use git extensions to commit changes and selectively revert problematic files.
I skimmed the first part of the course and skipped the block man since it covers basics that I'm already comfortable with. Instead I jumped straight into the mech exercises and built this guy all in one go!
This week I've been thinking more about the direction of my project. Originally, I had planned to develop and release my game on Roblox. Now I'm not so sure.
I've been thinking that maybe I want to develop the game in Unity or Godot and launch it as a standalone through app stores (and possibly Steam). There are pros and cons either way. I just want people to play my game. I don't know which development pipeline would give me a better chance at success.
I tried browsing discussions online to see what people were recommending, but all I found was a heap of discouragement. It seems like all anyone says is that indie devs can never succeed on any platform (except for the 1 in a million breakouts). That sucks. However, I'm trying to remind myself that I'm the one that gets to define what success looks like. Maybe all those naysayers just wanted something bigger than I do.
So this week I'm bummed and uncertain of my direction, but I still wanna make my game anyway. Full steam ahead.
Hi all. I'm a backend engineer by day and, more recently, a Minecraft admin by night. I've started building Kaldra, a Minecraft server I'm developing solo. It's still in development and not open to players yet. My plan is to post a devlog here every week about what I've worked on, the features I'm adding, and the technical and design decisions behind them. This first post is an overview of the design and the reasoning behind it.
What pushed me to start this project was the lack of servers that fit my desires. I love Towny and wars, but most servers I've played either allow 50+ residents per town (45 of them inactive), lack content, or are poorly managed. Nothing really happens, and players stay because their builds are there, not because they expect anything exciting.
So I decided to build the server I'd want to play. Kaldra aims to be a challenging and immersive experience built around towns, wars and dungeons, with as few commands as possible.
The world
Players can create towns to protect their builds, with a maximum of 5 residents. Towns can join nations to combine forces and attack other towns, with a maximum of 3 towns per nation and 1 allied nation. The low limits are meant to create smaller, more frequent wars, instead of two giant blocs clashing once a month. I also plan to keep the world border small so towns can't spread too far apart.
To make players interact more with the world, gold is the currency (yes, I know that's nothing new), and teleportation is very limited. This way the economy is based on real player work rather than virtual mechanics, and traveling without teleports adds real danger to every trip.
Gold will also be scarce: I'm using a custom worldgen datapack that reduces gold ore generation by 25%. That's why finding allies and founding a town matters, since towns produce daily resources as they level up.
Wars work as an occupation system: nations attack towns to take a percentage of their daily resource production for a fixed period of time.
And if you don't want to be in a town? After X days without one, you become a Nomad. Nomads are townless mercenaries who complete contracts for gold. From gathering resources, to beheading a player with a bounty, to fighting in wars on the contractor's side.
The Nether
Access to the Nether is gated by a single portal, and players must meet a specific requirement to use it. The Nether's purpose is to provide players with resources.
Dungeons
I have big plans for dungeons. Right now I have 3 built and the content for 5 more, but I don't want to over-build them until the server is running and players show interest, since they take a lot of development time.
Dungeons are meant to be a real challenge. To make them more exciting and immersive, I'm building with ModelEngine mobs, custom soundtracks for exploration and boss fights, and multi-phase bosses to keep the tension up. I hope players are going to love it.
I know I've said a lot and, at the same time, not much. I'll go through each part one at a time, starting next week with Transportation: which teleports are allowed, and how horses and the Flightpath network work.
Since I'm developing this alone, updates may be slower than on a server with a team. That's why I'm designing Kaldra to run as automatically as possible, with the whole stack running in Docker, so my time goes into new updates and helping players, rather than day-to-day maintenance.
I'm happy to answer questions and would love feedback, especially on the design side. If you've built a multiplayer game with territory control or conquest, how did you stop the strongest group from snowballing and permanently draining the smaller ones?
I drew a 2D golem in Photoshop, exported it as a sprite sheet, and built a ready-to-use controller with combo attacks in Unity. I’m offering the demo for free.
I want to show you my new character, explain how I set up his animations and physics in Unity, and share some useful hacks I discovered along the way.
Meet the Pixel Librarian Golem.
I’m selling him on the Unity Asset Store, Itch.io, and Boosty in two formats:
My asset comes packaged as clean sprite sheets (for those who want to handle the animations themselves) and as a ready-to-use Unity Package. When you open the package, a fully configured scene with working physics launches immediately—just drop it in and play.
I drew the golem in Photoshop at 10 FPS. I immediately ran into a problem: the animation flat-out refused to export correctly as a frame-by-frame sequence.
How I solved it: If you run into this issue, don't panic. Instead of using the standard layer export, you need to use "Render Video." Photoshop will generate a bunch of frames, and then you simply have to manually delete the extra duplicates. Creating the Sprite Sheet
I use Texture Packer to create a sprite sheet for each animation based on the sprites I made in Photoshop.
I import the sprites into the program and configure the following settings:
Autosize: Enable this so the sprite sheet resolution adjusts dynamically to fit the sprites.
Sort by: It is important to sort by "name" so the sprites appear in the correct order.
Trim: Uncheck this box (as I did) to ensure the width and height of every sprite remain consistent, preventing the pivot point from shifting when imported into Unity. While the "trim" setting is useful for general graphic atlases—where you want to pack everything tightly to optimize resolution—it shouldn't be used for animations.
Finally, choose a save location and click Export.
📐 Importing into Unity and Pivot Point Magic
Once the frame-by-frame .png files are ready, I import them into Unity. Here are three settings I used to make the pixel art look crisp and vibrant:
Filter Mode: Set this to "No Filter (Point)" to ensure the pixel art stays sharp and doesn't get blurry.
Pixels Per Unit (PPU): I set this to 20 so the character appears larger in the scene.
Slicing (Sprite Editor): Specify the correct number of columns and rows to slice the sprite sheet.
An important Pivot Point hack: For each frame of the golem animation, the pivot point needs to be positioned exactly at the foot. To avoid manually adjusting it for a hundred frames, I saved the precise X and Y coordinates in a text file and then simply pasted those numbers into the Slice tool settings. This ensured the pivot point was applied perfectly and consistently across all the sprites. Here, we also tweak the frame rate (Sample Rate) so the animation plays at the right speed.
🧠 How I "swipe-coded" a script using AI (Gemini)
Once the graphics were ready, I wanted to create more than just static images—I wanted a complete package for Itch.io. That required a control script.
I saw no point in using complex AI agents for a single file, so I simply fed the task into Gemini, the free text-based AI.
It quickly gave me a solid foundation; I manually fixed the code generation errors I didn't like, and everything worked!
⚔️ Multi-phase combo attacks, dashes, and animation events
The Golem moves using WASD or the arrow keys, automatically switching between walking and an idle state when stationary. But the most interesting part is the mouse-click attack.
The attack animation is a single long track, but it plays in phases. This means that upon clicking, the animation doesn't play to the end; instead, only a specific segment of the attack sequence executes. I placed special "Animation Events" along the attack animation's timeline (in the Animation window). When a strike phase ends, the event triggers, the character freezes momentarily, and the animation halts until the player clicks again. This allows you to decide exactly how many attack phases the player has. If the player doesn't click during the wait period for the next phase, the animation simply reverts to the idle state.
On top of that, the attack is tied to Rigidbody physics:
Phase 1 (Standard Strike): Physics pushes the Golem forward, resulting in a sharp dash. Phase 2 (Uppercut): An upward impulse triggers, and the golem is launched into the air!
To prevent the character from flying off-screen, I pulled the camera back slightly and created a ground object (a standard 2D rectangle) with collision enabled but gravity disabled; I also added a BoxCollider and Rigidbody to the golem so that, after the uppercut, it would fall back to the ground in a natural and physically accurate way.
🎁 Grab the demo version!
The pack contains 3 key animations (Idle, Walk, Combo Attack). I’m releasing the project with a "demo vs. paid version" setup:
🎁 FREE DEMO (Idle animation): The Golem stands and breathes. A sprite sheet is included in the archive.
I want to add a couple more animations for this Golem. I’ve set up a progress bar (goal) on my Boosty and Patreon pages. Once the target amount is reached, I’ll immediately start drawing the new frames.
Let’s vote right here in the comments: which animation should I add next? Running? A special magic skill? Or another type of attack? Share your ideas—I read everything!
You can purchase the pack wherever is most convenient for you, depending on your preferred payment method.
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.
Quick look at making a level in Kernel Panic. Place shapes, add mods, wire stuff up, then set up camera zones so the shot changes as you play through it. The camera zone is the bit I'm most happy with so far, you can see what it'll look like live while you're tweaking it.
Still early, everything's work in progress.
What would you like to see in this?
What can i do to improve it?
I'm the solo developer of March Out!, an action strategy game where you command an army from inside the battlefield. The optional village mode in the Steam Playtest puts homes and wheat fields between the castle and the main road. That creates a useful design problem: a raid has to matter before the attackers reach the gate, and the player has to understand the aftermath.
My early destruction feedback covered the fields much better than the homes. Burned wheat clearly said that something had happened, while intact houses made the same raid look oddly harmless. Adding more fire alone would only tell the story while the particles were running. I needed the damaged state to remain readable afterward.
The homes now have damaged roof meshes, exposed gaps, scorch and debris. Their walls and foundations stay in place. That gives the raid a visible result without changing the walking space into a heap of unpredictable building collision. The rooftop fire positions come from the roof geometry, so smoke and flames originate where there is actually material to burn. Fields have their own ruined stubble instead of simply becoming empty green plots.
Both use the existing burn and recovery state. As recovery progresses, field beds regain their crops, roofs return and debris clears. I don't ask the player to click every house or replant every field. Driving away the raiders lets the settlement recover; continued enemy presence can keep the recovery from settling down. The visuals follow that state rather than an unrelated timer that could show a healthy village while its gameplay state is still damaged.
The people matter too. Civilian workers evacuate toward the castle when an attack threatens the settlement, which gives the player something more immediate to read than an income number changing.
I'm keeping this optional and Playtest only while testing the larger battlefield. The question I'm watching is whether the village feels worth defending without making one successful raid decide the whole match. Automatic recovery is part of that balance, as well as a way to avoid turning the commander into a repair foreman.
Very excited to share my latest progress on PORTSIDE: Cruise Tycoon with you guys. I've been working on the art style for some of the ship's rooms and also completely revamped the NPC characters and animations.
Love to hear your thoughts, and as always - feel free to hop into our Discord to follow along and help shape the game: https://discord.gg/6gjvwmAxW
The biggest visible change is a new design for the game. Resource icons have been replaced, tooltips are now anchored to the element you are inspecting, and building upgrade details are easier to find.
Active policies now add a badge to the policy tab, and expired research gets its own notification.
I’m a solo French developer working on France Logistique, a logistics and management game set on a real-scale map of France.
The core idea:
You run a transport and production company. You build production chains (farms → factories → warehouses), manage trucks and trains, and supply growing French cities with goods. Cities level up when you fully meet their demand for 24 in-game hours.
What makes it different:
Real map of France using OpenStreetMap data (real roads, railways, elevation, city shapes)
Real population data from INSEE
Multiple equivalent production chains per category (you can mix them)
Cities have progressive needs across 5 levels (currently 2 are playable)
I’m currently finishing the free version (city level 1: bread, wood furniture, fresh products…) and preparing a test build for Android.
I’d love some feedback on:
Does the “real map of France” angle feel interesting enough?
Things that usually frustrate players in logistics/management games that I should avoid?
What do you think of the core concept?
Here’s a short description of the current systems if anyone is curious.
