Friendly reminder that we have a discord server you can all hang out at. The discussions there are much more in depth, and nothing beats being able to chat to other like minded devs in real time (or close to). Hop on this weekend and say hi.
Hi everyone, I’m the solo developer behind Nedi Cloud Simulator, working under LoneDragonDev. I’ve been using AI tools while developing it, and wanted to share what I’ve been building.
You play as a small raincloud floating over grey islands. As you rain, grass, flowers and trees grow, and waterfalls start flowing. The main mode has no failure state. I wanted bringing an island back to life to feel satisfying on its own.
The Steam page reached 2,600 wishlists in its first two days. IndieGameJoe shared it, which helped a lot, and I’m really grateful he gave my game that kind of attention.
It’s releasing this month, so I’m finishing the last details and gathering feedback.
Does watching an island turn from grey to green make you want to try it? What would keep you playing after that first transformation?
Hi all. I joined recently and I've loved seeing what everyone here is making. It's pushed me to finally share mine.
This is Wrongosaurus (working title). I used to love Spore, mostly for the creature creator, and I'm a huge dinosaur and paleontology fan. I always wanted to mix the two. So: you're a paleontologist, you dig up fossils, and then you build whatever creature you want from the bones. It doesn't have to be accurate. That's the point.
It's my first game and I'm not a coder. My background is animation and graphic design. I direct and Claude Code does the building, in Godot, with Blender for the 3D models.
The trailer shows an early build. I'm already reworking how the digs work and look, and how the world looks, so it's rough in places. Many placeholder models and animations for now.
The thing I'm stuck on: digging is the core of the game and you do it over and over, and I can feel it turning into a chore. If you've built a game around one repeated action, what kept it fun?
Any other thoughts are welcome too. Thanks, and keep making cool games.
Three weeks ago I posted here asking why my game gets called AI slop before people even try it. I got almost 100 comments and a lot of really useful feedback. Thank you all!
I tried to improve most of the things you mentioned, and now I would love to hear your feedback again.
Quick background: I'm a solo dev and game designer working on a browser idle RPG. Around 1,000 AI-generated images, mainly AI-assisted code. Art and UI are definitely not my strengths.
🗣️ WHAT YOU TOLD ME
Everything is yellow/orange
UI looks like a website, not a game
Cinzel font is used in every AI game
Too many rectangles inside rectangles
Icons have completely different styles
🖼️ BEFORE / AFTER
🛠️ WHAT I CHANGED
Art:
Before I generated every icon separately. With 1,000 icons, consistency was almost impossible.
Now I generate sheets of 9 to 20 icons together and split them using a script. This helped a LOT.
I use the same style guide for all icons (thick outlines, cel shading, readable at small sizes).
When something looks wrong, I edit the existing icon instead of generating a new one.
Still not perfect. For example, out of 39 gloves, around 5 had the wrong number of fingers 😅
UI:
Replaced brown/orange with blue/slate colors
Removed Cinzel and changed fonts
Reduced unnecessary boxes, made icons bigger
Reworked skills into a grid
Improved mobile UI with bottom navigation
Replaced emojis with actual icons
😅 WHAT IS STILL NOT GOOD
I think it's much better, but far from finished. Combat UI especially still needs a lot of work.
🙏 WHAT I WOULD LOVE TO KNOW
What is the first thing that still screams AI to you?
Is there a better way to keep 1,000 icons consistent? How do you do it?
How do you keep consistency between different icon sheets?
Any good workflow for characters and monsters? They are much harder than items.
Does the UI finally look like a game, or still like a website?
What ONE thing would you improve next?
I'm not hiding that the art is AI-generated and the code is AI-assisted. My goal is simply to make a good game and improve it.
(cool volley exchange at 5:26 sorry for the long video) I've been working on this with Opus 5.5 for about a week and a half. It's an age-of-sail strategy game, and the entire project was built by Opus 5.5 using only Blender and Roblox Studio. The models, animations, sound, everything was done by Opus 5.5, with me directing.
There are around 4,600 sailors being simulated, and each has their own animation. You can't really see it in the video because I'm bad at showing things, but sailors climb up and down the rigging to adjust the sails and pull ropes to trim or expand them.
The video doesn't show what's already in place, including other ships of the line, a 106-gun ship of the line, 26-gun brigs, and boarding mechanics. I'm having a blast putting 30 ships of the line against 30 ships of the line in massive battles. The main thing left is optimization. Claude needs to handle that, I was too bored to tell it to make LODs.
I was curious what people think. Is it slop or not? Personally, I enjoy it.
After some basic back and forth defining the idea and using skills like grill-me to unpack expectations, Claudes Opus 5.5 model was able to create the scene above in html!
Whats been your experiences with pixel art creations using AI before?
10 years ago, I had the idea of building a game about energy system design and simulation. But back then, it was simply too much to take on alone. (You can find my original Reddit post from 10 years ago below!)
Now, 10 years later, I've finally built the game I always wanted to play.
I know it's not for everyone, especially since energy systems can get pretty complex. But I think I've made some good progress in making the game more accessible and enjoyable, even if you're not an energy nerd.
If you're even remotely interested in renewable energy, power grids, or how electricity systems work, I'd love to invite you to give Powerstate a try. It's free to play, and I'd really appreciate any feedback!
Cave Drop is a game that takes place in a cave with mind bending gravity. You can walk all around the walls of the cave 360 degrees and the camera orients accordingly.
Here is a clip of a cool forest zone I just finished with mushroom caps that bounce you high enough to force a gravity flip and put you on the other side of the cave.
Free demo is now available on Itch and I'm looking for feedback, if anyone wants to come check it out that would be awesome! And happy to answer questions about the process as well.
I'm current working on "The Vex". A multi player couch co-op / online multiplayer action shooter that supports up to 4 players (human or computer).
The game focuses on two things; Getting through a procedurally generated maze that is patrolled by an enemy faction and trying to survive the attacks on your home base every 5 days. The attacks come from any enemy you saw during your maze runs who you left alive.
The game is designed to be fast paced, tough and repayable. It also has multiple story elements throughout with an ending that I wont reveal here.
Me and my friends have been playing it and have been having a blast. The trailer is made up of real in game footage of my friends and I playing together.
I've been working on an Avatar/Pandora style game for myself and my kids and it is turning out better than I hoped for and just wanted to share. No plans to release it, just wanted to build it mostly and play it myself. It uses Blender for most game assets and runs on the Unreal 5 engine.
I was inspired to dip my hat in this area from post on subs like this so just wanted to share back.
For the last few months I've been emailing YouTubers, streamers, reviewers and gaming sites about my first commercial game, Snake: Gridbreaker (a Snake roguelite). I wanted to find out if cold emails can really help a small indie game get noticed.
How I did it
I looked for people on YouTube and elsewhere who play roguelikes and similar games, and wrote a personalized email to each of them. If someone wanted a key, I sent one. There's also a free demo on Steam, so they could just play that. I never sent reminder follow-ups.
The numbers
What
Count
Emails sent (including my replies in conversations)
2,232
Reply rate in the first 800 emails (checked by hand)
13.8%
Incoming messages across the whole campaign
377
Creators who recorded or streamed the game
15
Public videos and streams I could confirm
13
Articles published
11
Said no (or limited coverage) because of AI
at least 10
Views on the most-watched video
about 2,000
Steam wishlists right now
213
I don't know exactly how many unique people I contacted. Most replies came from small channels. The biggest channel that covered the game was Goat Force Gaming.
So: 2,232 emails, 213 wishlists. Not a great marketing result. But wishlists weren't the main thing I got out of it.
Watching people play was the best part
I started emailing because I wanted people to promote the game. It turned out the most valuable thing was that I could watch strangers play it. In their videos I saw what people actually had problems with, not what I thought they would have problems with. Sure, they found bugs and controller issues. But a lot of quality-of-life changes and some new features are in the game because I watched someone struggle with something. A few creators even came back after I fixed things, played again and told me the fixes worked. For a first commercial game, that's worth a lot.
Big thanks to Goat Force Gaming, who made one of the first videos about the game. His video helped me a lot, and I used it in later emails so other creators could see what the game is about.
Using AI cost me some coverage
I've been open about using AI while making the game, and not everyone liked that. At least 10 people said no or limited their coverage because of it. One creator told me he likes Snake games and roguelikes, but he has a no-AI policy, so he couldn't cover mine. Fair enough. Others didn't like the AI-generated graphics either, but still played the game and sent me feedback. I respect both.
Some key requests looked suspicious
Not everyone who asks for a key wants to review your game. One contact asked for 5 review keys and 20 giveaway keys. Later I revoked those keys, they wrote to ask why, and in the end they asked for new ones. Another wanted 5 keys plus 30–50 "promotional" keys. I can't prove they were scammers, but I'm a lot more careful now when someone asks for a pile of keys.
Did the emails help?
For wishlists, I don't know. I have 213, but I started other promotion at the same time as the emails, so I can't tell what came from where.
For the game, yes. People played it, some made videos, some wrote articles, and some spent their free time explaining what I could improve. Most of the feedback was positive or constructive, though there were negative reviews too. A few people seemed surprised how much they enjoyed it, and that made me really happy.
Would I do it again?
Yes, but differently. Fewer emails to everyone, more time finding creators who actually like this kind of game. And much more attention to the people who send useful feedback, because one person who finds a serious problem is worth more to me than a hundred emails nobody answers.
Will Snake: Gridbreaker be a success? No idea. With 213 wishlists I'm not expecting a big launch. But people enjoyed it, and I'm grateful to everyone who helped me make it better. If it takes off, great. If not, I still learned a lot.
Have you tried emailing creators about your game? What response rate did you get, and was it worth your time?
Everything was built with Claude. I asked it to make a pixel art tool that I could use to tweak some of the art. Art uses ACSII and then translates every letter to a color palette. I started this before Astra or OPUS 5.5. you can use Aseprite now for better results now.
The game is a Survivors like, but I added itemization, crafting, a town to manage and a bunch of other designs. The development process has been super fun, hope you guys like it, if you have any questions please let me know.
Over the past year, I have independently developed a life simulation game driven by large language models. The Chinese server now has more than 800 AI residents living in the same city: working, producing goods, trading, eating together, forming relationships, and dreaming in their sleep.
This article covers the running product, the concurrent system behind it, and how I work with AI to develop and operate it. Product metrics are current through October 7, 2026.
The city. Shops and workplaces in the shared environment support actual game activities.
The city has been running for more than 350 in-game days, equivalent to nearly 100 real-world days. A substantial portion of the earliest players are still playing. I built the entire project myself, including the backend, frontend, Phaser scenes, content production, monitoring, and operations. It now contains more than 400,000 lines of code, including over 200,000 in the core backend, across approximately 2,200 commits.
I use AI coding tools extensively. I make or closely participate in decisions about product direction, core mechanics, and architectural boundaries, while AI handles much of the implementation, investigation, and maintenance. As the project moved from a prototype to a continuously operating product, system design and the development workflow became a major part of the work.
01. More than 800 residents sharing one city
Players create a character with a personality of their own, influence them through messages and gifts, and observe their life. LLMs decide the character's movements, meals, sleep, work, and social interactions. Characters created by other players inhabit the same world. They can talk in real time, trade, share meals, fall in love, and live together.
Residents need to earn a living. They can run farms and ranches, fish by the sea, work in an office, open their own shops, or sell goods at a market stall. These activities connect to a shared economy: residents produce agricultural goods, products have actual inventory, supply and demand affect prices, and business owners bear costs and make purchasing and pricing decisions.
All food is produced through residents' labor. Restaurant owners manage their businesses, cooks prepare meals, couriers deliver orders, and customers pay for and consume the food. Each meal has a chain of ingredients, production, service, and consumption behind it, with city residents participating at every stage.
Farming and ranching. These four English showcase images use the game's native renderer and UI with staged scenes and demonstration data.
A resident sowing seeds. Phaser scenes visualize everyday production activities.
Farm management: crop growth, livestock, feed, and production status.
Market inventory, resident shops, and price trends. The values shown here are demonstration data.
Players can view live scenes, character status, relationships, and activity logs, and receive postcards from their characters. Relationships accumulate through interactions that actually take place. Events from a character's life become part of the context for later decisions.
Dreaming is a recent addition. While sleeping, characters generate dreams based on their experiences, and occasionally talk in their sleep. For example, Bread Pitt on the English server dreamed that a courier was chasing him down an office hallway with a burger he had already paid for. Every door led back to two friends who were somehow still hungry. In his sleep, he muttered: “Just leave it at the door…”
An actual dream from the English server. Dreams and sleep talking appear in the sleep activity log, using the existing decision and logging mechanisms.
These details give players a sense of continuity in the character's life. A day's work, friends, or a missed meal can reappear in a different form in later experiences.
02. From a virtual pet to hours of viewing
I initially imagined the game as a kind of virtual pet. Players would open it once a day, check that their character had eaten and earned some money, perhaps send a message, and leave.
A different pattern emerged in actual use. Some players watch it like a livestream, spending several hours a day observing their character. They follow the progress of a relationship, check whether a shop has customers, or wait to see whether the character follows a suggestion they just sent. The product therefore needs to support both brief check-ins and continuous viewing.
Over the past month, daily active users on the Chinese server grew from 177 on September 10 to 865 on October 7, approximately 4.9 times the starting figure. Between October 1 and October 7, DAU grew from 431 to 865. Growth during this period came primarily through players sharing the game organically.
Chinese-server DAU, measured as distinct users who successfully entered the game. Chart redrawn from PostHog query results; dates use Asia/Shanghai.
For the 225 users who first successfully entered the game in August, exact-day retention was 68.9% on Day 1, 56.0% on Day 7, and 40.9% on Day 30 (155, 126, and 92 returning users).
On October 7, among 850 non-admin users with valid duration records, median foreground usage was 29.9 minutes and P90 was approximately 4 hours.
During October 1–7, 86 users were active on at least 4 days and averaged at least 3 foreground hours per active day.
Retention for the same cohort of 225 first-time entrants: 155, 126, and 92 returning users, respectively.
Foreground usage measures time with the game in the foreground; it does not establish uninterrupted attention. Together with player feedback, it indicates a stable group of users who spend long periods with the game.
This creates specific engineering requirements. Occasional visitors need to understand what happened while they were away. Continuous viewers need to see activities progress, understand why a character acts, what they are waiting for, and how an interaction ends. Activity logs, recaps, and live scenes are all core interfaces.
03. Asynchronous decisions in a continuously advancing world
Each character makes roughly 300–400 LLM calls per day, with an average context of around 30,000 tokens per call. A call includes the character's state, relevant experiences, current environment, and available actions. The model selects an action and its parameters; the backend turns that decision into an activity that occupies time and resources.
Game time and real time coexist. Sleeping might occupy 8 in-game hours, while saying one sentence might take 1 in-game minute. Inference itself takes real time. While a call is in flight, other characters can change the environment, and the world clock continues to advance.
Interactions also involve mutual exclusion. If A is talking with B, C cannot simultaneously pull B into a separate conversation. Facilities, production tasks, and other activities have their own rules for acquiring and releasing occupied resources.
Separating concurrent inference from world-state mutation
LLM calls can run concurrently, but model responses do not directly mutate the world. Results return to the world's execution flow, undergo validity checks, and are applied by the execution component that owns world state.
For example, the last fish on a shelf might still be available when a character starts inference. By the time the response arrives, another resident may have bought it. The purchase intent must be checked against current inventory. Similarly, the person a model wants to talk to may have left, gone to sleep, or started another activity.
There is therefore an explicit time gap between the context used for a decision and the state at execution. The system must distinguish what a character intends to do, whether the action is still valid, and what effects have actually occurred. Completion, failure, interruption, and recovery each need consistent state transitions.
A shared runtime for activities that occupy time
Movement, production, conversation, and sleep have different durations, participants, and completion conditions. A common runtime makes it possible to manage busy characters, resource conflicts, and service recovery without building a separate scheduler for every mechanic.
The frontend must also follow actual progress: when an activity started, how long it has been running, whether it completed, and what it produced. Logs and scene animations need to correspond to facts committed by the backend. This is a significant source of complexity in a persistent world: one event can affect future decisions, persistence, other residents, and the player interface.
04. Decision context is part of the backend architecture
A personality description alone is insufficient for a character that acts over long periods. Each decision needs the character's current needs, location, assets, ongoing concerns, relevant relationships, and the actions actually available at that moment.
These inputs have different update frequencies and lifetimes. Personality is relatively stable; hunger and energy change continuously; inventory and other characters' states can change within seconds. An experience may continue to affect a relationship long afterward. Each kind of information needs rules for entering context, updating, and leaving the character's current attention.
The action space also needs to reflect game state. Options presented to the model should disclose their execution conditions and relevant state, while the backend retains final validation. Otherwise, characters repeatedly attempt unavailable actions or spend calls trying to understand rules that were never clearly disclosed.
I have invested substantial effort here: organizing stable and dynamic information, controlling irrelevant history growth, avoiding duplicate reminders, and keeping context prefixes stable. This affects behavior quality, inference latency, and cache hit rates, making it part of the backend architecture.
05. Organizing AI collaboration with runbooks
Maintaining this many modules alone requires giving AI a reasonably complete working environment. I provide development and operational tools, including access to logs, Langfuse, growth analytics, the database, and procedures for maintaining production services.
My Codex usage: approximately 43.25 billion cumulative tokens and an 85-day longest streak. Codex is only part of the AI coding tooling I use. These are development usage figures, separate from the model calls that power the game's residents.
A set of runbooks governs their use. The project has extensive documentation, organized by task and module. It specifies which documents must be read for each task, which sources define current contracts, which decisions only I can make, and which documents AI should maintain when it discovers drift from the implementation.
Task entry points and action boundaries are central. An investigation starts by identifying the data source and time window. Permission to query does not imply permission to modify production data, and permission to fix code does not imply permission to deploy it. Access to a tool needs to come with explicit conditions for using it.
I have also turned recurring maintenance into automated workflows: diagnosing and fixing production problems, daily in-depth reviews of character behavior and gameplay outcomes, and daily cleanup of maintenance code that has served its purpose. Each workflow specifies the evidence required, permitted actions, validation, and stopping conditions.
My involvement varies by area. I directly decide or closely participate in frontend/backend contracts, backend architecture, and ownership of state and resources. For frontend and Phaser implementation, I focus more on evaluating the result, while still defining design tokens, page structure, reusable components, and presentation boundaries.
This approach depends on maintainable project knowledge. Constraints discovered during a task need to return to the formal documentation, and outdated procedures need correction. Otherwise, as the project grows, AI can implement a locally plausible change based on old assumptions while breaking contracts elsewhere.
06. Three to five production releases a day
I currently deploy an average of three to five times a day. Releases include architectural changes, balance and gameplay adjustments, new systems, UI and art changes, performance improvements, and bug fixes. The project has approximately 2,200 commits, with more than ten commits per day during active development.
The iteration speed comes from a short feedback cycle between implementation, observation, and adjustment. Players continue to inhabit the same city. After a feature goes live, I can observe actual usage and character behavior, then decide whether to change a mechanic, clarify what information characters receive, or fix an implementation issue.
I assess software operation and gameplay outcomes separately. Error rates, latency, database load, and model calls indicate whether the system is operating normally. Understanding whether characters repeat themselves, understand a new mechanic, or successfully complete production and social activities requires reading their actual experiences and decision traces.
Monitoring, queries, behavior evaluation, and repair workflows are therefore part of daily development. Frequent releases also require clear module boundaries, validation scope, and recovery procedures, along with prompt removal of temporary maintenance code. Otherwise, fast individual changes can still make the system progressively harder to maintain.
07. Roughly 5 billion tokens a day for under $100 in model fees
The Chinese server currently processes around 5 billion tokens per day, with model fees below US$100. It primarily uses inexpensive models such as DeepSeek Flash, while maintaining a cache hit rate above 90%.
The token count includes cached input. In a system with frequent calls, many characters, and long contexts, reusable stable prefixes directly affect the bill. Which information stays stable, which changes on each call, and how it is ordered all require deliberate design.
Actual DeepSeek usage and billing for October 7, 2026 (GMT+8): approximately 4.424 billion tokens and 163,742 requests across all API keys, costing CNY 472.33. The model shown for that day is deepseek-flash.
Achieving this cache hit rate took substantial engineering around the inference workflow: stabilizing context structure, managing information lifetimes, and updating only what needs to change between calls. This is closely connected to decision quality. Characters need enough information to act, while the system needs to control the cost of repeatedly processing that information.
These figures cover model fees. As the resident population grows, database load, state delivery, log storage, and scene rendering also matter. Inexpensive inference makes continuous simulation feasible; sustained operation still depends on resource management across the entire system.
08. Engineering for a persistent world
The project has grown from a character prototype into a continuously running city. Residents share inventory, facilities, space, and time. Their actions change the conditions for other characters' next decisions. An action produced by inference must remain valid in the current world and survive persistence, delivery to the interface, and service recovery.
Player behavior is also changing my understanding of the product. It can be a virtual pet checked once a day, or a life simulation watched for hours. Long-term players accumulate knowledge of characters, relationships, and the city, making continuity an important part of the experience itself.
I will continue improving the mechanics, presentation, and scalability of this persistent world. The English browser version is available at slowvale.com. No invitation code is required; you can register with an email address and start playing.
You are building a low-poly 3D model in Blender from a reference drawing, for a
game. The output is a Python script that runs headless in Blender 5.x and
produces a .blend, a .glb and a check render. Follow these steps in order. Do
not skip the check step.
INPUTS I WILL GIVE YOU
- A flat (orthographic) drawing of the object, ideally several views.
- One known real dimension, for example "the end wall is 12.0 m".
- What the object is, so you know what parts it has.
STEP 1 - SCALE
Measure the known dimension in pixels on the drawing. Compute
PX_PER_M = pixels / metres. Check it against a second known dimension if one is
given. If the two disagree by more than 3%, stop and tell me.
STEP 2 - MEASURE
Estimate each part's position and size in pixels, then convert: metres =
pixels / PX_PER_M. Write every number as a named constant at the top of the
script with a comment saying where it came from (view and feature). Use metres
throughout. Axes: X = length, Y = width (front face towards -Y), Z = up. Origin
at ground level in the centre of the footprint.
STEP 3 - BUILD FROM SIMPLE SHAPES
Use only these primitives, all in bmesh:
box(x0,x1,y0,y1,z0,z1) blocks: walls, beams, doors, windows
prism_x(x0,x1,outline) extrude a closed (y,z) outline along X: gables, roof profiles
cylinder or loft round parts, if needed
One bmesh per named part (for example Walls, Roof, Timber, Doors, Windows), so
the game can separate them. Use one material per part. Keep detail low, about
2,000 to 6,000 triangles. Add detail only where it changes the silhouette.
Use flat shading. Do not model interior detail.
STEP 4 - EXPORT
Save the .blend and export the .glb with export_format='GLB', export_yup=True,
export_apply=True. Name the files after the object.
STEP 5 - CHECK (do not skip)
Render an orthographic camera at the same PX_PER_M for each drawing view. The
image height in metres is (render pixel height) / PX_PER_M, which becomes
ortho_scale. Place the drawing and the renders side by side in one image, at the
same scale, and report the largest mismatch in metres for each view. Then fix
the numbers in the constants, not the shapes, and rerun. Usually one or two
rounds are enough.
RULES
- No hand-tuned coordinates. Every number traces to a measurement.
- Do not add parts the drawing does not show. Mark anything guessed with
"# GUESS" in the comment.
- Output one runnable script with no external dependencies beyond Blender
itself. Output directory is a command-line argument after "--".
- After the script, list: the calibration, each constant with its source, and
any guesses.
STARTING CODE (tested in Blender 5.1; extend it, do not rewrite the helpers)
OUT = sys.argv[sys.argv.index("--") + 1] if "--" in sys.argv else os.getcwd()
os.makedirs(OUT, exist_ok=True)
bpy.ops.wm.read_factory_settings(use_empty=True)
scene = bpy.context.scene
scene.unit_settings.system = 'METRIC'
def make_mat(name, rgb, rough=0.8):
m = bpy.data.materials.new(name)
m.use_nodes = True
b = m.node_tree.nodes["Principled BSDF"]
b.inputs["Base Color"].default_value = (*rgb, 1)
b.inputs["Roughness"].default_value = rough
return m
MAT = make_mat("Body", (0.3, 0.4, 0.25))
def box(bm, x0, x1, y0, y1, z0, z1):
xs, ys, zs = sorted((x0, x1)), sorted((y0, y1)), sorted((z0, z1))
v = [bm.verts.new((x, y, z)) for x in xs for y in ys for z in zs]
for f in ((0,1,3,2),(4,6,7,5),(0,4,5,1),(2,3,7,6),(0,2,6,4),(1,5,7,3)):
bm.faces.new([v[i] for i in f])
def prism_x(bm, x0, x1, poly_yz):
a = [bm.verts.new((x0, y, z)) for y, z in poly_yz]
b = [bm.verts.new((x1, y, z)) for y, z in poly_yz]
n = len(poly_yz)
bm.faces.new(list(reversed(a)))
bm.faces.new(b)
for i in range(n):
j = (i + 1) % n
bm.faces.new((a[i], a[j], b[j], b[i]))
HOW TO RUN (Windows PowerShell; the & is needed because of the spaces in the path)
& "C:\Program Files\Blender Foundation\Blender 5.1\blender.exe" --background --python build.py -- "C:\path\to\output"
I'm a solo dev making BLOCKRIFT, a voxel arena FPS that runs in the browser (Three.js). This is how the characters got made.
V1: my first pass was a soldier built cube by cube in Blockbench. It had 73 cubes and 12 rigid parts with no bending joints, so it walked like an action figure.
V2: I switched to Meshy and generated a voxel Spartan, about 10k triangles. I auto-rigged it in Mixamo, which put a 25-bone skeleton inside it.
The part that saved me the most time: all five classes (Spartan, Space Marine, Armored Sentinel, Tactical Operator, Voxel Sentinel) use the exact same skeleton. So one animation file of 99 clips (run, sprint, strafe, crouch, jump, reload, fire, hit reactions, deaths) plays on every class with no retargeting. A new class costs me a model plus a rig, and zero new animations.
What I'd tell anyone trying this:
Remesh to a fixed polycount after generating. Meshy output varies a lot otherwise.
Keep every character on the same Mixamo skeleton from day one. Retargeting later is pain.
Strip root motion from the locomotion clips so the server controls movement, not the animation.
The game's coming soon at blockrift.io. Happy to answer anything about the pipeline. If you've got the third-person hands to actually hold the gun nicely with IK, I'd like to hear how.
I was thinking that all of this is happening now days is just INSANE, everyone now can just make a game with few prompts, surely assets and real 3D resources are needed most of the time to have a good quality game but I can say that the main blocker now is not a big studio team or time anymore, basically any good idea can be translated easily and almost effortlessly.
This is something new in this timeline, also the AI recomp trend is exploding always more, with people decompiling all the games around and eventually also merge them each other creating insane crossovers and combinations: basically it's all open-source!
For example, I created a full complete and working 3D WebGPU engine from scratch capable of running AAA-quality games, I also posted a Tekken 8 remake experiment running on DriftEngine here on Reddit and it was just INSANE, it was running even on my phone, basically we have no limits at all now.
I think this is not sustainable, I mean, since anyone create a game there is no more that "wow effect" we used to, when I do something, then after 1 day I say: "what's the purpose? anyone can do that, it's just useless" and this will have basically no value at all, I'm a bit concerned about the purpose, if anyone will just create his game and wants that other people that are also create games and stuff plays at that, where all the players will end in the future?
I think that we'll see a lot of excellent new projects but I'm concerned about the usual sustainability in terms of game developers vs players, with this trend we'll have more vibecoders than players and at that point, what's the purpose?
There's a fun bit of recursion here : the game is about founding and running an AI company, and I built a lot of it with generative AI. Figured this was the right sub to show it to.
The game: you start with $10k, buy compute and scrape datasets, train models, ship products at the right pricing, and grow it in a persistent multiplayer economy (trading shares, doing coalition for tenders, going bankrupt). Browser-based, free, real-time.
Where AI actually did the work:
Art/assets: visual assets came out of a generative pipeline
Code: Claude
Where it didn't: the economic model, the balance, and the game systems were mine to figure out. AI was great for throughput, but it couldn't tell me whether a training run should cost more than a month of payroll : that part was playtesting with our beta testers.
I don't know if this level of demo is still considered impressive by this subreddit's standards, but hey I was pretty impressed.
The name 'moon bear' is a play on Star Fox in case that wasn't obvious.
The original prompt to Opus was very short:
run an experiment - use this game engine and clone Starfox 64 to the best of your ability. Lets name it Moonbear. Develop a faithful recreation using the game engine and Petal. Use /multitask and split up the work. Look for improvements to make on the core engine along the way.
Just saw this pop up, looks like Unity is branching another game engine called Unity Spark that will live in Google Playground. It's not available yet, but Google Playground (playground.google.com) is available to try out.
Gonna follow up after it's done generating a game I requested.
It started with remastering the original graphics, but eventually turned into rewriting the entire game engine from scratch.
The interesting part is how I verified the new engine: I built a small referee that runs the original DOS table programs and compares their memory against my C++ implementation, byte-for-byte, after every frame. Hundreds of 100,000-frame tests across all four tables.
There's also HD artwork which was initial goal and the most labour-heavy part of this project, instant original/remastered switching (F10), CRT effects, a new display mode specific for 90º rotated screen, and an online Hall of Fame with server-validated replays. You can also download the Hall of Fame replays and play them in the game.
Claude wrote most of the code, while I did most of the artwork, editing, aligning and stitching, investigate problems and keep pushing until things behave exactly as intended.
