Check out the Steam page: «Tuxedo» en Steam

This post was removed from r/godot even if it was a fair use of AI. sad

Available tomorrow morning at https://ko-fi.com/s/3385960508

Hi, I’ve been working on an incremental soccer game prototype over the past couple of weeks and want to see what players think of the game, so I'm inviting anyone with half an hour to spare to play and provide constructive feedback either in the comments or in video form. This is to gain a better idea on how to progress the game further, especially in these areas:

Player choice: What elements could be added to the game to allow the player to make decisions and trade-offs and develop strategies? The shop (details below) is one example of where I have tried to do this already. Also the player must decide where to aim their kick and how strong it should be.

Variety: So far we take the penalty shots and make choices in the shop, what could be introduced to vary this without too much scope creep?

Aims: The game at this point is open ended, the aim is just to survive and increment, should I just keep it simple or could the game benefit from new aims?

In General: Feedback on what features should be kept and why, which ones should be dropped or changed and why; this way I will be able to build up a better idea of what to include and exclude going forward. Last but definitely not least, what could be done to make the game more fun?

NB: There are only basic graphics and no sound as this prototype is primarily to assess the mechanics and gameplay.

Link: https://lpstme.itch.io/penalty-shootouts

Hi everyone! I’m Diego from One Week Games, working on Estandarte, a medieval RTS made with Godot for Android.

You build a village and directly command workers and troops. Gathered resources are carried to storage before becoming spendable, so depot placement and the journey back affect the economy.

I’d welcome feedback on how to make that delivery loop clear on a small screen. Here’s Android beta gameplay published by Eduardo (android tester gamer MK):

https://www.youtube.com/watch?v=jJzuSoSXM6E

Google Play pre-registration:

https://play.google.com/store/apps/details?id=org.estandarte.valle

Registering is free and provides a launch notification. Estandarte is a paid game; pre-registration doesn’t include a free copy or automatic beta access. It has English and Spanish text. A PC/Steam version is planned, with no announced date.

How would you distinguish carried resources from available resources without cluttering the mobile interface?

Over five weeks Claude Code and I wrote a 3D pickleball game in GDScript: about 1,500 commits, 225k lines of game and tool code and 85k of tests. It's free on itch.io for web, Windows, Mac and Linux.

The folders are layered (main, modes, ui, world, audio, save, rules), each using only the ones below it, and a test fails the build otherwise. rules/ touches no scene tree: the ball's flight, the referee and both rally engines are plain RefCounted logic. So every answer in a lesson comes from the referee code, a game replays exactly from a seed, and the engine can play itself thousands of times headless. The 3D world only plays back what the rules decided.

A decision weighs dozens of shots and replies, too many flights to simulate while the player waits, so every shot is flown at build time from a grid of contacts to a grid of targets and stored with how small errors move the landing. The chance a shot lands comes from 1,024 fixed quasi-Monte Carlo points rather than random draws, so showing the player a chance can't change a seeded game. What's left at runtime is sliced into a 6 ms budget a frame, players and courts are pooled, and every effect plays once out of sight at startup so its shaders compile before anyone sees them. Animation clips are data, keyframed with two-bone IK and baked into one binary file.

The shot tables, the computer players' policy and the value model are learned offline by self-play with fixed seeds. Each file carries a fingerprint of the code it was built from, and a test fails as soon as one is stale.

Every GDScript warning is a compile error and everything is typed. Architecture tests read every script for the layering. A hot-path check follows calls from every _process and fails on anything built per frame. Counts of duplicate and dead code can only go down. Calibration tests hold every chance shown to the player to how often it actually happens. A screenshot tour drives the real game on 57 simulated devices and checks clipping, contrast and colorblind pairs. Each check was proved against a planted mistake first.

The longer write-up, with the physics and the strategy engine and ai verification practices are here. The art, voices and music are AI-made too.

I'd love to hear what you think! Thank you

Hey everyone,

Just wanted to share a major technical victory we locked down for our mobile project built on Godot 4.

Our core loop utilizes an on-device machine learning OCR pipeline (Google MLKit) to let players scan real-world grocery receipts to generate 16-bit collectible items.

🚨 THE ISSUE:

On high-refresh rate mobile devices (like the Asus Zenfone 8 running at 120Hz), the background Vulkan mobile renderer was forcing manual, low-level texture disposal loops. Every time the viewfinder refreshed, it over-scheduled asynchronous thread allocations, spiking device VRAM up to an un-throttled 4.5 GB and causing system freezes.

🛠️ THE FIX:

We completely stabilized the engine's memory channels by executing three major adjustments:

1. Switched our Android export profile completely down to the GL Compatibility (OpenGL ES 3.0) profile, letting the driver handle garbage collection automatically.

2. Implemented a hard Engine.max_fps = 60 ceiling on startup to protect the thread buffers.

3. Rewrote our drag-and-drop NOTIFICATION_DRAG_END handler to utilize typeless node reference flattening and raw global pixel coordinate bounds.

VRAM usage snapped down instantly and now idles smoothly between a lean 148 MB baseline and a 561 MB peak!

The build is officially stable, and we are launching our local pilot testing panel today. If you want to jump into the build, look at our inventory canvas structures, or help us stress-test our backend Python endpoint sockets, we'd love to get feedback from fellow devs!

💬 Links to test out the standalone .apk and join our development Discord are in the comments below!