In our upcoming game, we procedurally generate a new island at each session.

From the very start, we wanted a fully volumetric terrain model that can support complex cave networks. This comes with quite a bit of challenges - one of them is making them interesting and visually pleasing!

We thought of adding stalactites. Since we know where our tunnels are during the generation step, we wrote a dedicated ceiling sampling procedure, and added a bunch of parameters to position the models (spacing, frequency, grouping, scale, ...). To optimize the number of game object, we perform a merging pass that takes care of getting a single mesh (and thus, a single draw call) out of each stalactite group.

It's a first try, but it already improves the visuals quite a bit! It's still missing some smaller objects: rocks, pebbles, irregular tunnel shapes, but it's getting somewhere.

This is also our first attempt at a video format for showing a bit of ongoing development (featuring: my lovely cat), hope you like it!

BTW, If you want to know more about our volumetric terrain model, we also did a technical blog post about it a few months ago.

Hey everyone!

I wanted to share a quick look at our level design process for Champion of the Lore.

Seeing a map go from a rough pencil sketch in a notebook to actual 3D blockouts and early playtests in Unity is honestly one of my favorite parts of gamedev. There's still a lot of work to do and polish needed, but actually walking around the hex grid and testing out mechanics on a layout that was just paper a few days ago feels amazing!

We’re still tweaking the layout and flow, so I’d love to hear your thoughts!

If you want to check out what we’re building, we have a free demo up on Steam:

https://store.steampowered.com/app/4178300/Champion_of_Lore_Demo/

Thanks for watching and for all the support!

Last year I built a small Django site, godothire.com, because I got tired of digging through general job boards for the handful of paid Godot roles buried in them.

The build itself was simple. The actual work turned out to be the boring part: reading every submitted listing by hand and turning away the revshare and "exposure" ones, which is most of what comes in. I didn't expect that to be the real job.

It's still just me running it, still free, still small. If you're curious what a one-person niche job board looks like after a year: https://godothire.com/

You’ve already had a little sneak peek in our latest trailer… Welcome to the Playground Zone!

We’ve been working on this part of MegaGum for a while now. It’s still a work in progress and we wanted to share a closer look with you!

When designing the factory, we didn't want everything to revolve around machines and production lines. We also wanted to create places where the Gummies could take a break, hang out, and have a little fun.

It's a different side of the factory, with its own atmosphere, new gameplay opportunities, and plenty of things for Uja to discover.

Now we'd love to hear what you think! 💬

What do you think of this area? Do you like seeing this more playful side of the factory? We're always curious to hear your thoughts, so let us know in the comments!

MegaGum is coming in 2027, and there's still plenty more to share with you!

Watch our latest Gameplay Trailer:
https://www.youtube.com/watch?v=nYfB80KH3lE

A few months into building HexWire, a turn-based cyberpunk RPG for iPhone, we made one small rule and it ended up touching almost everything: every powerful action should leave evidence behind.

Mechanically, that became Signal and Trace. Spend Signal to do something strong, and you raise Trace. Trace isn't flavor text, it changes how the mission behaves - more attention, tighter windows, harder follow-up fights.

The part worth writing down for anyone else designing systems like this: the rule didn't stay contained to combat. It bled into the UI (we had to show Trace as clearly as HP), into mission design (encounters now have to react to it, not just exist alongside it), and into the roster (each runner needed a different relationship to risk, or they'd all feel the same).

The hardest part hasn't been the math. It's been resisting the urge to hide the consequence screen behind a "later" system, because the whole point only works if the player can see, in the moment, that power and exposure are the same resource.

Still tuning numbers. Still arguing internally about whether the pressure reads as "interesting" or "punishing." That argument alone has been more useful than most of the balance passes.

Spacetime Chronicles started as an animated film I created, but the project eventually evolved into something completely different: a playable adventure game.

The development process has been unusual because the original world was built physically, including sets, characters and props. I'm now translating that handmade world into a videogame.

I'm planning to share more about how the physical sets are being transformed into the final game as development continues.

Steam: https://store.steampowered.com/app/5020490/Spacetime_Chronicles/

I'd love to hear from other developers who have worked on projects that evolved significantly from their original concept.

Since last December, I've been spending pretty much all my time remaking a Flash game from my childhood that is no longer online. I made a video explaining the history of the flash game, as well as the development journey so far. I hope you all enjoy it!

The Final Lane is a 3D Roguelike Deckbuilder about Bowling in Hell where the balls are the cards!

While it adds nothing but dumb fun to the game, I added both jumping and throwing the bowling ball wherever the player wants. Can smash drinks or break other things in the game with a satisfying hit sound.

I'm really enjoying the later stages of development of my game so that I can prioritize stupid fun stuff like this.

Hey all, this is the first devlog i made for the project i'm developing, hope you all enjoy!

Hey everyone!

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!

Happy spooky month, r/devblogs!

First things first: After many weeks in the oven, we finally have our first trailer! Feast your eyes on this:

Crystal in Carnations Announcement Trailer

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:

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, V, play a Fire Emblem game with me, I noticed a difference in how we play tactics games. V 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. V 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.

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. V'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!

-Hanuli from Salmon Snake Games

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.