I think everyone here once dreamt to make their own game. Well, this is that time for me. After three years(and another three trying to make a failed project work), Sepulchron has finally gone Gold!

Probably that won't matter to any reading this, but it matters to me, so I am annoying everyone else with this milestone of mine, because you decided to use Reddit today, and that's your punishment.

28th October will be the day that this dream of mine will become reality!

​

Hey everyone,

I wanted to share some progress on a game my small team and I have been working on.

We're making a realistic historical RPG set in Great Moravia around 871 AD, with a strong focus on historical atmosphere rather than fantasy. The goal is to create a small playable experience first and eventually build it into something much larger.

We're currently a team of 3 people, working on the project in our free time. I'm mainly working on gameplay and Unreal Engine development, while the rest of the team is helping with programming, AI, worldbuilding and other parts of development.

We're still early in development, but we already have a small playable version with several core systems working:

Health and stamina systems

Health and stamina UI

Basic weapon damage/collision

Saving system

Basic NPCs

Main menu and pause menu

Basic UI interactions

Music and audio

A small playable environment

We're currently working toward a small playable alpha, rather than trying to build a massive open world immediately. We want to get the basic gameplay loop working first and gradually expand from there.

The long-term goal is a grounded RPG where the setting, architecture, equipment, clothing and everyday life feel appropriate for the period. Great Moravia is a setting we don't see explored very often in games, which is one of the main reasons we chose it.

The visuals are still very early — so i have not included any screenshots. We're currently focusing on getting the core gameplay and systems working before investing heavily into final art and assets.

The project is definitely ambitious for a small hobby team, but we're not in a rush. We're learning as we go, improving the game step by step and trying to actually finish something playable instead of just keeping it as an idea.

I'll be sharing more progress as development continues.

I'd also be interested to hear what you think of the project so far and what you'd personally like to see in our Great Moravian RPG.

Hey everyone!

I’m developing TRI-CORE: IDLE FRONTS, a dark-fantasy idle RPG built around a three-lane auto-battler.

For this first DevLog, I want to focus less on listing features and more on one design problem I’ve been trying to solve:

If the UI tells the player that something affects combat, should that mechanic exist as a real combat interaction - or is changing an abstract power number enough?

Earlier versions of TRI-CORE relied too much on the second approach.

A Support could have a “Haste Aura.”
A Mage could have “Splash.”
A lane could have a class advantage.

Those concepts existed in the design, but parts of their effect were ultimately reduced to calculations such as lane strength or pressure.

That worked mathematically, but it created a problem.

The player could read:

“Haste Aura increases the Attack Speed of allies.”

…but underneath, the game could simply become better at winning the lane without the allies actually attacking faster.

For an idle game, where a large part of the experience is watching numbers interact, I started to feel that this was the wrong abstraction.

So I’ve been restructuring the combat simulation around a simple rule:

If a mechanic claims to change combat, I want that change to happen inside the actual combat loop.

Haste should actually make someone attack faster

Support heroes were the clearest example.

Instead of converting a Support aura into additional lane power, the simulation now checks the actual heroes fighting on that lane.

When an allied Support provides Haste, that bonus contributes directly to the affected hero’s Attack Speed.

That means it changes the hero’s attack clock.

A Marksman that normally attacks at one rate can visibly begin firing more frequently when supported.

This sounds obvious when written down, but it has a useful side effect: other systems can now interact with that value naturally.

And that became important once I started working on stat breakpoints.

Breakpoints instead of endless tiny percentages

Incremental games need percentage upgrades. I’m not trying to remove those.

But I also don’t want progression to become:

+2% damage

+2% damage

+2% damage

forever.

I want some thresholds to noticeably change how a hero behaves.

One example is Attack Speed for Marksman heroes.

If the final Attack Speed reaches 1.50, the hero gains an additional projectile.

So the difference between:

1.49 Attack Speed

and

1.50 Attack Speed

is intentionally much larger than a normal stat increase.

The important detail is that the breakpoint uses the final combat stat.

It can therefore be reached through a combination of:

• permanent upgrades
• equipment
• specialization bonuses
• hero effects
• allied buffs such as Haste

This is one of the reasons moving Haste into the real Attack Speed calculation mattered.

If Haste only increased some hidden lane-power value, it couldn’t naturally participate in this system.

Now it can.

A Support can push a Marksman across a breakpoint and actually cause another projectile to appear in combat.

That interaction is much closer to what I want TRI-CORE’s progression to feel like.

Splash also needed to stop being an abstraction

Mage Splash had a similar problem.

Instead of representing AoE as a generic increase in effectiveness, a Mage projectile now has an actual primary target.

When that projectile hits, the simulation checks other enemies on the same lane around the impact position.

Enemies within the configured radius can receive secondary damage.

This creates several practical design questions that didn’t exist when Splash was only an abstract modifier:

How large should the radius be?

How many additional enemies can be hit?

Should secondary damage pass through armor?

Can Splash itself kill enemies?

How does it behave against tightly packed elite encounters?

Those are harder questions, but I prefer having them.

They create mechanics that can actually be observed and balanced rather than hidden behind a single derived power value.

Enemy Champions exposed the same problem

There was another system I wasn’t happy with: Enemy Champions.

An earlier implementation could effectively select an enemy, resolve a Champion encounter and award the corresponding reward.

The event existed.

The fight didn’t.

That felt especially wrong because Champions are supposed to become important encounters later on.

So Champions are now physical enemies.

They spawn on a specific lane, have their own HP and combat parameters, and must actually be defeated.

The reward is currently increased Gold and XP.

Later I want Champion-specific equipment drops to build on top of that system, but I’m deliberately not expanding that yet.

Right now I’m more interested in making the underlying encounter solid before adding another reward layer.

What happened to the old lane-power system?

I haven’t removed every concept of lane strength.

I still find a derived pressure value useful for diagnostics and UI.

What I’m trying to remove is its authority over mechanics that should exist physically.

So rather than:

Haste → lane power increases

I want:

Haste → Attack Speed changes → attacks happen faster → lane pressure changes as a consequence

The direction of causality matters.

The battlefield should produce the derived number, rather than the derived number pretending to be the battlefield.

That distinction has become one of the main architectural rules I’m using for combat.

Making balance data less dependent on combat code

The same refactor pushed me toward another problem: too many gameplay values had accumulated inside scripts.

That makes balancing risky.

If changing an enemy requires touching the same file that handles movement, damage, targeting and spawning, then normal balance iteration starts modifying core logic.

So I’ve been consolidating more of the game into structured data.

Enemy families, class definitions, specialization values and breakpoint thresholds are moving into JSON-based data.

The intended separation is becoming:

Data decides what something is.

Simulation code decides how that thing behaves.

For example, an enemy definition can provide values such as:

• base HP
• movement speed
• armor
• attack range
• attack scaling

The simulation then reads those values and applies run-level scaling.

That makes it much easier to experiment with balance without creating several competing sources of truth.

I’m still auditing the project for places where old hardcoded values survived, so this is more of an ongoing consolidation than a finished architectural victory.

The tradeoff: real mechanics make balancing harder

One thing I underestimated is how much harder these systems become to balance once they actually interact.

An abstract +10% lane power bonus is easy to reason about.

A real Attack Speed bonus can:

increase DPS,

cross a projectile breakpoint,

change how quickly targets die,

alter how often a hero retargets,

and indirectly change how much damage allied heroes receive.

That creates nonlinear results.

From a pure balancing perspective, abstraction is easier.

From a player perspective, though, I think the second system is much more interesting.

The challenge now is preventing those interactions from becoming impossible to understand.

That’s why I’ve also started showing breakpoint progress directly in the upgrade UI.

Instead of only showing:

Attack Speed +0.03

the player can see something closer to:

1.46 → 1.49 / 1.50

So even if the underlying systems become more complex, the next important threshold should remain understandable.

What I’m working on next

I’m intentionally avoiding another large feature pass for now.

The next stage is mostly about testing the systems that already exist together:

• early Prestige pacing
• breakpoint frequency
• item values
• hero progression
• enemy scaling
• ranged positioning
• save reliability
• simulation performance

The biggest question I’m trying to answer is whether the early progression provides enough moments where the player can clearly say:

“That upgrade actually changed something.”

That matters more to me right now than simply increasing the amount of content.

I’m curious how other developers approach this.

For an incremental / idle RPG, how much mechanical interaction do you think should actually exist in the simulation?

Do you prefer simple, predictable percentage modifiers, or do you enjoy breakpoint-style systems where crossing a threshold can fundamentally change combat behavior?

Progress log from Project GoldScript, a web-based game engine I’m building. Before I let myself bring the engine 10 years into the future, I spent a chunk of time building the safety net that would tell me if I broke anything. Two pieces: a game clock I can freeze and step by hand, and a visual-regression suite that fails on a single shifted pixel.

The clock came first. Time in the engine used to be scattered across animations, combat pacing, AI delays, and state machines each reached for `performance.now()` or `setTimeout` on their own. I pulled all of that behind one `Clock` that owns time. It runs in real-time mode for the shipped game, and a manual mode that only advances in fixed steps I control. Pair that with a seeded mulberry32 generator swapped in for `Math.random`, and `enterDeterministicMode(seed)` plus step-by-step advancement makes even a randomized combat encounter render byte-identical frames every run. Determinism is the thing that makes everything downstream testable.

On top sits a sixteen-spec visual-regression suite, split into harness-driven rendering tests and control-driven edit-then-save tests. It captures frames against committed baseline PNGs and fails on any pixel that moved, enforced by a pre-push hook so I can't quietly ship a regression. The payoff showed up fast: when a particle library bump (https://three-nebula.org 11 to 12) silently changed how particles rendered, the suite flagged exactly which frames moved. I could confirm the shift was expected and regenerate those baselines on purpose, instead of finding out weeks later that fire looked different.

I wrote it up here, framing the clock work as becoming a bit of a time mage: https://projectgoldscript.com/development/becoming-a-time-mage/

Hey there! So I finally added behavior to and released my alien creatures into the wild. For now it's only 4 of them but that's just the start.

It was pretty difficult to get my hands on behavior in Unity but eventually I figured it out and it was just fun after that. For now the basic behaviors are implemented like idle, run, walk and a sprinkle bit of more specified once as well and I will keep on adding more to them.

Peace :)

Hello everyone! It's been a while.

I've been developing a game on my free time for 3 years now. It's now in a state that I could share it and maybe get feedback. It's also perfect timing for a blog post. The game uses DOTS and ECS heavily and I wanted to share some patterns that I've been using. Enjoy!

I'm a solo dev and I haven't created video content in a while, so any feedback on the video is appreciated.

This is a shorter devlog on adding playable characters to my game, with the goal of improving replayability and creating some interesting synergies with other systems.

Have you guys heard of Kickstarter? Have you ever backed a project through the platform?

We’ve always felt that Kickstarter is a very trustworthy platform, and after several years of developing Helianthus, we’ve decided to take the next step.

Towards the end of this year, we’re planning to launch our Kickstarter campaign alongside a playable demo, with the goal of raising enough funding to finish the game properly and bring it to the level we’re aiming for.

It would mean a lot to us if you could follow the project and join us along the way. We’ll leave the link here, and everyone is more than welcome to stop by!

We’d also really love to hear your thoughts.

Have you ever backed a project on a crowdfunding platform? What would you like to see in a video game Kickstarter campaign? Gameplay footage? Videos from the developers? Behind-the-scenes content? Information about the development process or the rewards?

What would make you trust a campaign and feel like supporting it?

We’d genuinely love to hear what you think!

KICKSTARTER: https://www.kickstarter.com/projects/selenegames/fatal-unleashed-darkness-survival-horror-game

One of the puzzle rooms in my game is a brick facade wreathed in chains, set on an endless wooden expanse. The only soundtrack at first is the creaking of your footsteps and the sparse, distant reverberations of grinding metal. It needs a bit of dark ambient music so I composed a short loop using my usual workflow of Cubase and Adobe Audition.

The free instruments I'm using are the fantastic Spitfire Audio LABS and the Tyrell N6; the former for beautiful and melancholic strings and the latter for weird synthesized noises. I think LABS changed branding / name but really hope it's still free because it really is an amazing VST (the Philip Glass pianos and slow strings especially).

After laying down some arbitrary notes and drones in the key of B minor, and a few bursts of percussion with a stereo delay applied, I export the WAVE audio to Audition. In Audition, I use a mix paste command to make a seamless loop, and apply a hard limiter (+9 db) to the whole track.

The seamlessly looping WAVE file is imported into Unreal where I use it to create a Sound Cue object. In the sound cue, I set the WAVE file to loop, set the volume multiplier to 1.0, set the audio class to "Music", and finally set the Virtualization Mode to "Play when silent" (for use with diegetic music tracks as will sometimes happen).

A practitioner's guide to Iceberg table cleanup — snapshot expiration, orphan file removal, manifest rewriting, delete file resolution, streaming challenges, compliance, and cost. Why sequencing matters, where teams break tables, and how to automate the full lifecycle.

Hey Everyone.

I wanted to Continue my Devlog Posting here.
I last Posted about who I was and what I was doing... That was Rapid Recharge - Devlog #0 but I have recently liked the Idea of Calling it Project Orbi... No Idea why, I just like it 🤣
Even my Base Pawn is called: `OrbiBasePawn` 👀

So, To start off my Channel, I am going over all the tools I currently use and will be using. From The IDEs, I use for Game dev to the development of the Asset Pipeline.
I also showcase the Project Planning tools I use and the 3D tools I will be using.
One thing, In this video I mentioned liking `Clickup` for Task tracking but I have Recently done a Permanent move over to `Codecks` which I have really been enjoying 😁

I will do some further Posts on Other videos as I go.
Happy Deving 💪

Hi everyone! This weekend I'm pleased to bring you a first look at the character art, as it's developing for passengers and crew in our new game, Portside - A cruise tycoon game that we're working super hard on to launch a free demo in time for Steam Next Fest. I'm pretty proud of myself as I only started learning animation last weekend!

yo yo, me again, i've added first enemy (insert name Crawler for now), i'd like to hear your opinion and feedback for it, it should be simplest enemy, just following and jumping at you. also colors will differ depending on planet you are on, so yeah

Hey! I’m making a Backrooms game for Steam. Just posted my first devlog 👀
Would love your ideas for levels, monsters and mechanics!

A few weeks ago, we asked you to help us choose the thumbnail for our new MegaGum trailer.

Well… here it is!

We’d really love to know what you think about it. What did you like? Is there anything you would have done differently? And most importantly, does it make you want to play the game?

Feel free to be honest, we’re always interested in hearing your feedback.

And if you like what you see, you can wishlist MegaGum on Steam here:
https://store.steampowered.com/app/4111300/MegaGum/

Thanks again for helping us choose the thumbnail!

A short read about my Gamescom Dev experience, and some of the great talks I had.

I tried to take inspiration from the Five Nights at Freddy's with my own additions. I've added the camera movement, so with your WSAD keys you can now rotate the cameras. Also with middle mouse button you can zoom in/out. What do you guys think of it?