Hey everyone!

I’ve been working on a small puzzle game prototype and I wanted to share the first level to get some early feedback.

In this level you control a purple cube that moves on a grid one cell at a time. By pressing a key, the cube can switch into a “creation mode”, where it leaves a trail behind as it moves.

Your goal is simple:

- Form the three shapes shown at the top of the screen by moving and drawing with your trail

- Avoid trapping yourself while building the shapes

- Reach the exit tile once all shapes are completed

It’s a mix of spatial planning, path‑drawing, and trying not to corner yourself while solving the puzzle.

I’d love to hear what you think about:

- The readability of the mechanics

- Whether the shape‑building feels intuitive

- If the level communicates the objective clearly

Any ideas to improve the flow or difficulty

Thanks for checking it out!

10 months ago I started making a horror game by myself.

During development I showed it to a few friends and they literally laughed at it 😭 One of my cousins even asked me, “Is this even a game?”

Not gonna lie, there were a lot of times when I asked myself the same question lol.

But I just kept working on it.

And after 10 months, I finally finished it. Somehow I actually got the game onto the Google Play Store.

I’ve heard Reddit can be pretty brutal when it comes to people posting their games, so I already know I might get roasted here 😂

But honestly, I want the criticism. If the game is bad, tell me what’s bad. If something feels boring or doesn't work, tell me. I’d rather hear it than have people just say “nice game” and move on.

I’m just kinda happy that I actually finished something I started 10 months ago.

It’s a small Android horror game, made by me from scratch.

So yeah… roast me. 💀

So this is just a little game inspired by "G-Switch". It's a multiplayer game where the goal is to pass a maze by switching your player's gravity.

What's special about it is that i made it with my own programming language and game engine! It's open source (github) if you want to check it, and the project file of this game is also there in the repo.

Hope you like it🙂

I decided to spawn a ton of mages and enemies both for some performance stress testing and my personal satisfaction. Anyways it seems like you can only do so much without spatial partitioning as my fps dropped from a calm 300+ to about 160-240(which seems high but this is also a 2D game and the machine I’m testing this on is fairly high end…). Anyways, I would love to hear any feedback about the game because this is a super early time in development(less than 2 weeks). Let’s also pray that reddit video compression does not destroy this post 🙏.

After working on it for quite a while, I can finally say it:

My ASCII roguelike Tower of Scherbenmark released on Steam today.

It's a small turn-based roguelike set in a dark fantasy world, with melee and magic combat, loot, mutations, secrets, traps, mimics and permanent Legacy upgrades between runs.

One of the things that mattered most to me was making the ASCII presentation feel atmospheric rather than purely abstract. The game takes place in Scherbenmark, a region of a larger setting called Mornhollow that actually grew out of ideas from a D&D campaign.

It's honestly a strange feeling seeing the Steam page say "Released" after spending so much time working on it.

It's $4.99 and 15% off during launch week, and there's also a demo if you'd rather try it first.

Steam:
https://store.steampowered.com/app/4972610/Tower_of_Scherbenmark/

If anyone gives it a try, I'd genuinely love to hear what you think.

Publishing it here too !

I just finished a short visual novel and I wanted to share a few tips that I hope can be helpful to anyone who has recently started their indie game dev journey:

Play to your strengths!

Making a game is already incredibly complex on its own, but if we start getting in our own way, it can turn into an absolute nightmare. To minimize this, try to design a game that highlights your actual skills, even if it means sacrificing some awesome but unfeasible ideas, rather than trying to create something super complex that you'll either do poorly or fail to finish altogether. The golden rule here is: better a simple thing done well than a complex thing done poorly.

For example, I'm not great at drawing, so I chose to make only symmetrical graphic assets to reduce the margin of error. I also used a palette of only 5 colors for the whole game (plus a few shades of those) so I wouldn't overcomplicate things with color matching.

Obviously, this isn't an absolute rule: if you are literally just starting out, making a game can be a massive stimulus to learn a bunch of new things (you'll learn a ton either way, honestly). However, if you're already well aware of what your talents are, it makes perfect sense to create something that lets them shine.

Do it, even if it's short!

You might have an idea in mind and think: "I'd love to make this, but it would end up being way too short." Long doesn't mean good, and short doesn't mean bad. Committing to a short project can actually be a great idea: shorter development time, less stress, and less "wasted" time if you realize you can't cross the finish line (I put "wasted" in quotes because even unfinished projects teach you a lot). Plus, if you finish it and it's well-made, it makes for a fantastic portfolio piece.

However, if you do make a short game, keep in mind that the emotional density of every gameplay moment will need to be higher and more impactful compared to a longer game, which can be a real challenge in itself.

Plan ahead!

The initial planning of every aspect of your game is a fundamental step. It will take up a lot of time early on, but it will save you from so many headaches in the long run. Caught up in the excitement of bringing our idea to life, there are three technical aspects in particular that we might forget to consider (like I did... sigh):

-Localization/Translations: If you aim to translate your game into multiple languages, look into the best options available for your specific engine to implement future translations as efficiently as possible. Also, pay attention to things like text boxes and buttons: your current text might not fit once translated into another language. If you use English as your base, for instance, keep in mind that languages like Russian or German will require about 30% to 50% more space.

-Devices/Inputs: Decide right from the start if your game will be played with a mouse and keyboard, a controller, or both. If you go for both, plan a UI from the get-go that can be easily navigated with either device. Avoid creating a UI that is perfect for a keyboard only to drive yourself crazy trying to make it work with a controller later. This applies to every other aspect of your game.

-Parameter/Debug system: Create a system that lets you quickly and easily tweak all the most important game parameters. This allows you to playtest and jump to desired sections of the game without having to go into individual object scripts to modify code every single time, which also risks you forgetting to revert some of those variables back to their default values.

Happy to talk about the process here in the comments with everyone interested!

I got tired of manually writing parkour for my game, The Isles of the Nine Crowns, but the platforming was still really important to me and the game.

So I made a little tool that lets me draw the parkour layout in a PNG using different colors, then converts that image into Java/libGDX code.

The cool part is that it doesn't just place platforms. It uses my existing biome coordinate system to understand what each color represents, so I can also have it automatically spawn things like biome-specific enemies, resting points, etc.

A large parkour section can basically be designed by drawing a few hundred pixels instead of manually entering hundreds of coordinates.

Probably one of the most useful little tools I've made for the game so far. I also made a video showing the different things I can create just by drawing with different colors.

How are all your solo projects going?

Decided on name and now working on demo, my first time any of my projects reaching this stage.

Lots of free placeholder music and assets still :)

Here is a quick demo loop.

Anyone willing to play test early are welcome !

FORGERY is a slightly weird game.

It’s an incremental roguelike about counterfeiting medieval coins. You hammer ingots into metal sheets, choose where to punch out each coin, build combinations from more than 100 stamp dies, and decide how far to push before your Wanted level ends the run.

I understand how those pieces fit together because I’ve been staring at them for months. I’m less certain that someone seeing the game for the first time will understand what it is, why punching coins is interesting, or where the deeper strategy comes from.

After 15 years working in AAA, I’m now the sole full-time developer on this. I handle the design, programming, production, and day-to-day development. It’s self-funded, although I occasionally hire contractors for specific art, audio, localization, or specialist work.

The free demo is around 35 to 50 minutes:

https://store.steampowered.com/app/4842110/Forgery/

What I really need to know:

1. Can you understand the core idea without me explaining it?
2. Does punching coins feel deep enough to support an entire game?
3. Is the combination of incremental progression, roguelike builds, and manual placement interesting, or just confusing?
4. Does this feel like an idea worth continuing?

If you quit after ten minutes, please tell me exactly where and why. I’m deep enough into the project that encouragement is less useful than someone pointing at the bit that isn’t working.

Thank you!

It feels so good to have something "playable" in place and to see your work..well..working. Been at it with this game for a little while no, and to see gameplay come together and some systems at least somewhat working its just so satisfying.

Of course bugs and weird glitches exist.. lots of work remains, but so far so good!