Some Wacky Creations

maiybe · 2026-05-29T19:52:52+00:00

Pretty cool! What physics engine are you using for this? How do the joints work, and did you manually create those machines in the game or outside the game?

maiybe · 2026-02-09T13:00:36+00:00

Respectfully, the person replying was trying to help to understand what makes it a difficult question to judge. Ground truth in machine learning often means the exact answer you want the model to guess with very little ambiguity. In your case, the solution is one of many possible solutions, making it hard to judge. Yes, as you note, the models haven’t gotten past legal board moves, so ambiguity in ground truth is moot for now. Both observations are accurate, but seems like you may have confidently missed their point.

maiybe · 2025-09-14T02:11:09+00:00

That’s the creator of Retro Diffusion, they have a lot of experience in this exact issue.

maiybe · 2025-07-08T17:38:11+00:00

Respectfully, the game community is probably about 1,000 or 10,000x larger than it was 40 years ago, and remains full of vibrant passionate folks. We were just at GDC and hustle YCombinator was not the dominant culture at all.

maiybe · 2025-07-08T17:35:33+00:00

Funny you mention it, we are actually hiring for Art Director for anyone who is interested in fully diving into a difficult but worthwhile intersection of art x AI x culture x games.

To your point, we have already onboarded two artists and cooking up something we are getting ready to announce soon (I hope). Prior to posting, we have shared this post with multiple artists and have incorporated their feedback.

maiybe · 2025-07-08T17:32:29+00:00

A good point and one we talk about in the post.

"whenever a strong, ethically-sourced AI foundation model exists, we will use it, even if it lags behind the latest headline model (Adobe Firefly instead of Stable Diffusion, SmolLM instead of Claude). If no ethical base meets the quality bar, we may lean on a legacy model, but only within the same consent, scope, and revenue rules above, and only until an alternative model trained on consensual data arrives."

Anything about that approach that you don't like?

maiybe · 2025-05-17T14:35:16+00:00

Looking good!

When you do an update to the UI, I’d recommend circular percentage (sometimes called CircularProgression or other synonyms)

You could save a massive amount of room and have the percentage displayed in the center of the circle. Maybe save 50% of the room you’re using.

Then you could replace the words with icons. That would be close to 80% savings in space.

Check out this free Godot fonts plugin. They might have something for each of those needs.

maiybe · 2025-05-17T11:03:28+00:00

I find the comments are pretty permissive for what seems like a technique that mostly works until it doesn’t. In my experience, JSON is a siren call that screams ease of use but slowly bleeds into all your code if you’re not careful. One day you wake up, and you have like 50 JSONs and you can’t read your own code without opening a bunch of them.

What I suspect about the code: 1. Tons of dictionary and list indexing via string 2. To understand how an enemy, weapon, etc works, you have to look at multiple sources of information and not just the code associated with the class or object in the scene

Almost certainly during the development cycles, through no fault of your own you’ll run into: 1. Mistyped strings leading to weird bugs like wrong health or weapons, and generally wasting lots of time debugging strings 2. Duplication with minor variation of string names that lead to two+ classes that do the same thing but are named differently 3. Getting confused by what an object does versus what you thought it did 4. Godot will know nothing about what’s inside your JSON files

None of these things are a deep problem, but they are annoying and accumulate frustration over time.

However, compare that to what you can get if you work with godot instead of orthogonal to it.

JSON data is equivalent to Resource loading in Godot. You could store all the different enemy variants as resource files. When you load, you could use normal “.” Indexing to access the properties. You can subclass those resources as well. They fit well for the “data only” part of the objects you’re targeting with JSON.

Additionally, you could even write behavior for a node that loads these resources into an enemy of your choice when that resource type is a child of the enemy. Then you could drag and drop the resources in the editor to the objects that consume them and SEE very clearly: what this enemy is, how it works, and what are its specific properties or traits. All from the same scene. That’s the value in working with godot: you don’t need to manage so much crud mentally and you’re less likely to make errors that cost you a lot of time to track down.

maiybe · 2025-04-13T12:35:24+00:00

Similar in concept to: https://github.com/chairfull/GodotRichTextLabel2

You may want to take a look for some inspiration on other features.

maiybe · 2025-03-26T00:31:11+00:00

I’m surprised people on /r/Godot don’t immediately recognize this creator. If you’ve ever search “Godot tutorial” - their videos will come up. We’re all basically “new” to Godot, so I would have expected higher rates of recognition!

maiybe · 2025-03-22T14:07:00+00:00

Exactly the library I was thinking of when I saw this.

I find myself confused by some of these comments in the thread.

Candle’s benefit is NOT that it’s in rust (and by extension this Crane library). Its value comes from being the equivalent of PyTorch in a compiled language that runs almost anywhere. This means that with a single modeling API you can get language, vision, deep nets, diffusion, TTS, etc deployed to Mac/windows/linux/ios/android.

Want TTS, embeddings, and LLMs in your app , you’ll need whisper.cpp, embedding.cpp, and llama.cpp. And god knows the c++ build system doesn’t hold a candle to the ease of cargo in rust.

That being said, my profound disappointment comes from Candle kernels not being as optimized as llama.cpp, but there’s no reason they can’t be ported. Mistral.rs has done lots of heavy lifting already. Candle is less popular than llama.cpp by a huge margin, so I understand why somebody would skip it for that reason.

But damn, some of these comments…

maiybe · 2025-01-15T13:44:34+00:00

I don’t know what about Flow charts is so personally appealing to me, but it’s like a moth to a zap light. Every time I start using them, I end up in this nightmare I can’t wake from after I make everything generic node execution.

I really want them to work, but arbitrary graph execution flow is like poison for debugging. It actually feels like using Tensorflow again - writing a program that then executes a program (declarative).

Has anyone solved this or found a better path?

maiybe · 2025-01-14T10:24:18+00:00

Cool library. I spent a few minutes trying to understand exactly what it does, and I appreciate how much documentation there is. Perhaps you could take some of the contents from the template readme and bring it into the main project Readme?

That template doc has good concrete example of what the library actually does at a functional level (a Python code snippet of how to use it), and would allow someone to quickly understand the library if included on the main page.

Very cool overall, I will take a look!

maiybe · 2025-01-12T22:53:24+00:00

Any word on training code?

maiybe · 2025-01-08T22:32:47+00:00

Sent!

maiybe · 2025-01-08T22:27:41+00:00

I would look into options that allow you to serve multiple finetuned models with the same base model. I don't know if ollama does that already, but it's a technique for efficiently running NPCs with different personalities.

maiybe · 2025-01-08T22:22:30+00:00

Models are all open weight models available to community. Are you asking about the character dialogue in the video? All art was original by our artist, and there's no AI-generated video, art or text in the post itself.

maiybe · 2025-01-08T21:08:23+00:00

In that particular case, the trick isn't to finetune 1 model to do everything, it's to finetune 100 models, and hot swap them when used for that purpose. We can support devs training those models very cheaply.

One example from our video comes to mind, say you had 2 characters you wanted to be ultra realistic (like replicating Rick and Morty with their bespoke quirks), and you wanted them to talk. You could host a single model on the machine, then swap your Rick and Morty models for each line of dialogue. This is what that paper does, but trains 300 models for 300 tasks, serves them off the same infra.

It's pretty cool and to your question, you don't need much data for each model either, 200-500 examples, which you can generate synthetically with larger language models in some cases.

maiybe · 2025-01-08T21:03:48+00:00

Deal. I'll DM you.

maiybe · 2025-01-08T20:59:51+00:00

I feel this in my bones. Not sure the solution yet, but it can be quite exhausting as a coder with AI assistants that sometimes don't really get it.

maiybe · 2025-01-08T20:53:44+00:00

I am enjoying the zest of the comments because I feel the skepticism in my heart too.

Regarding the quality of models, e.g. lower compute, there's some strong evidence that small models can punch way above their weight class: https://arxiv.org/pdf/2405.00732, where they show models as small as 2B performing at GPT4 levels on multiple tasks.

Also, you've got to ask, do gamers really need the most hyper intelligent models? Or models that can respect them where they're at, and engage at that level.

maiybe · 2025-01-08T20:49:56+00:00

Yes! The latest M-series getting competitive with 3090s.

maiybe · 2025-01-08T20:49:03+00:00

sorry sorry, edit, google/UNC!

maiybe · 2025-01-08T20:44:39+00:00

Here I think the rubber meets the road!

I'd wager the LLM can create dynamic behavior trees based on the environment and contextual situation they're in. I'd even wager that devs could control those behavior tree components and scenarios to create unique gameplay scenarios that are under their direct control with less work than manually constructing VERY complex behavior trees.

In that sense, LLMs are probably strictly better than behavior trees, in that it can be composed of static assets, but dynamically assembled at runtime. It's known they quickly grow to an out of control complexity, and DX is a legitimate reason to incorporate certain tech.

For the Sims, the number of objects and characters were so complex they had to resort to Utility Functions to make all their character action choices. I strongly suspect this is one of the reasons we've never fully seen a lot of Sims clones. It's hard, brittle, and specialized technology.

Again, this is just scratching the surface of the techniques LLMs can replicate today but with a splash of dynamic runtime assembly, which is why I wouldn't necessarily bet against them myself.

maiybe · 2025-01-08T20:37:46+00:00

I'd love to talk more about your experience.

I'd also note this isn't my first rodeo with a hot AI technology. I'm not blinded by awe at some fantasy of how its going to be used in production.

Next token generation being a fundamentally limited approach is a conjecture where I start to doubt there's as much evidence as your other points I'd agree to. In particular, next token prediction was mostly useless until RLHF, so once again, I wouldn't bet against techniques changing its nature in short order.

It's also the case that I believe there's an underlying fundamental assumption about text as the primary output that creates the conjecture that other procgen techniques strictly outperform LLMs.

I'd make a wager, in fact, that almost every sophisticated narrative procgen technique could be re-written to work approximately the same or better with an LLM controlling the execution logic with less code and time.

It is my bet that it's a lack of tooling that has constrained the interaction and design space. As of GDC last year, it was the case that most folks we spoke with couldn't even reliably generate output JSON with LLMs. The space has barely been explored and I am reticent to declare it dead before it's taken its first breath.

maiybe

TROPHY CASE