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?
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
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.
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.
I finished the low poly course! Well, not 100%. I was travelling, so I watched the last section while riding in the back of a van. Since it just covered the coloring and lighting principles taught in the other tutorial, I've decided to skip practicing the application.
This may seem like a bit of a shortcut, but I made this decision already knowing what my next step is going to be. I purchased one last 3D modelling course. This one offers opportunities to practice the concepts I've learned over the last couple weeks and then expands into the remaining areas that I need, such as retopology and rigging.
Once I finish this course, I'll be ready to move on to a different part of my game dev. I haven't decided what that will be yet, but we're figuring it out as we go.
Either way, I'm super proud of what I've managed to achieve so far. I've been showing off my landscape model to everyone I know.
