Game design is the ultimate lockbox - you're unlocking an entire imaginary world which has some platonic existance in your mind.
And since you mentioned Luanti, it deserves to be much better known as a credible open alternative to Minecraft. You could do a lot worse then designing/prototyping your game with Luanti as the game engine.
The styles of Cyberpunk 2077 and Red Dead Redemption 2 are also dead givaways about their training data. There might also be a whiff of the Witcher 4 demo in one sequence.
The interesting possibility is that all you may need for the setting of a future AAA game is just a small bit of the environment to nail down the art direction. Then you can dispense with the army of workers to place 3D models on the map in just the right arrangment to create a level. The AI model can extrapolate it all for you.
Clearly the days of fiddly level creation with a million inscrutable options and checkboxes in something like Unreal, or Unity, or Godot editors are numbered. You just say what you want and how you want to tweak it, and all those checkboxes and menus are disposable. As a bonus that's a huge barrier to entry torn down for amateur game makers.
> [LLMs] spit out the most likely text to follow some other text based on probability.
Modern coding AI models are not just probability crunching transformers. They haven't been just that for some time. In current coding models the transformer bit is just one part of what is really an expert system. The complete package includes things like highly curated training data, specialized tokenizers, pre and post training regimens, guardrails, optimized system prompts etc, all tuned to coding. Put it all together and you get one shot performance on generating the type of code that was unthinkable even a year ago.
The point is that the entire expert system is getting better at a rapid pace and the probability bit is just one part of it. The complexity frontier for code generation keeps moving and there's still a lot of low hanging fruit to be had in pushing it forward.
> They're great for writing boilerplate that has been written a million times with different variations
That's >90% of all code in the wild. Probably more. We have three quarters of a century of code in our history so there is very little that's original anymore. Maybe original to the human coder fresh out of school, but the models have all this history to draw upon. So if the models produce the boilerplate reliably then human toil in writing if/then statements is at an end. Kind of like - barring the occasional mad genious [0] - the vast majority of coders don't write assembly to create a website anymore.
> Modern coding AI models are not just probability crunching transformers. (...) The complete package includes things like highly curated training data, specialized tokenizers, pre and post training regimens, guardrails, optimized system prompts etc, all tuned to coding.
It seems you were not aware you ended up describing probabilistic coding transformers. Each and every single one of those details are nothing more than strategies to apply constraints to the probability distributions used by the probability crunching transformers. I mean, read what you wrote: what do you think that "curated training data" means?
> Put it all together and you get one shot performance on generating the type of code that was unthinkable even a year ago.
>The complete package includes things like highly curated training data, specialized tokenizers, pre and post training regimens, guardrails, optimized system prompts etc, all tuned to coding.
And even with all that, they still produce garbage way too often. If we continue the "car" analogy, the car would crash randomly sometimes when you leave the driveway, and sometimes it would just drive into the house. So you add all kinds of fancy bumpers to the car and guard rails to the roads, and the car still runs off the road way too often.
what we should and what we are forced to do are very different things. if I can get a machine to do the stuff I hate dealing with, I'll take it every time.
After a while, it just make sense to redesign the boilerplate and build some abstraction instead. Duplicated logic and data is hard to change and fix. The frustration is a clear signal to take a step back and take an holistic view of the system.
And this is a great example of something I rarely see LLMs doing. I think we're approaching a point where we will use LLMs to manage code the way we use React to manage the DOM. You need an update to a feature? The LLM will just recode it wholesale. All of the problems we have in software development will dissolve in mountains of disposable code. I could see enterprise systems being replaced hourly for security reasons. Less chance of abusing a vulnerability if it only exists for an hour to find and exploit. Since the popularity of LLMs proves that as a society we've stopped caring about quality, I have a hard time seeing any other future.
>In current coding models the transformer bit is just one part of what is really an expert system. The complete package includes things like highly curated training data, specialized tokenizers, pre and post training regimens, guardrails, optimized system prompts etc, all tuned to coding. Put it all together and you get one shot performance on generating the type of code that was unthinkable even a year ago.
This is lipstick on a pig. All those methods are impressive, but ultimately workarounds for an idea that is fundamentally unsuitable for programming.
>That's >90% of all code in the wild. Probably more.
Maybe, but not 90% of time spent on programming. Boilerplate is easy. It's the 20%/80% rule in action.
I don't deny these tools can be useful and save time - but they can't be left to their own devices. They need to be tightly controlled and given narrow scopes, with heavy oversight by an SME who knows what the code is supposed to be doing. "Design W module with X interface designed to do Y in Z way", keeping it as small as possible and reviewing it to hell and back. And keeping it accountable by making tests yourself. Never let it test itself, it simply cannot be trusted to do so.
LLMs are incredibly good at writing something that looks reasonable, but is complete nonsense. That's horrible from a code maintenance perspective.
SEEKING WORK | Remote | Onsite San Francisco Bay Area |
Versatile back end code and infrastructure development services. Typical deliverables are Dockerized microservices specified by OpenAPI, written in Go or Python, with a REST/JSON API and backed by PostgresDB or MySQL. CI/CD pipelines included and deplyment on any of the major cloud vendors. And of course your custom business logic.
If you have more complex needs, e.g. project or team management please reach out as I have extensive career experience in all aspects of of technology development and management in startups and large enterprises. Need a contract manager or CTO perhaps?
At minimum I can help you develop your back end infrastructure from the ground up. Basically I offer development of back-end componenets you can slot into your Kubernetes or Docker environment from day one.
On the business side, you get a fractional developer for a no-haggling fixed monthly rate, corp-to-corp billing, long term support for your code, careful vetting of dependencies for licensing and security, and a professional approach to your technical needs.
Maybe that should be the future of K8s 2.0. Instead of changing the core of the beast tweak it minimally to get rid of whatever limitations are annoying and instead allocate resources to put a hefty AI in front of it so that human toil is reduced.
At some point you won't need a fully dedicated ops team. I think a lot of people in this discussion are oblivious to where this is heading.
> At some point you won't need a fully dedicated ops team
I think programmers are more likely to go extinct before that version of reality materializes. That's my secret plan on how to survive the alleged AI apocalypse: AI ain't running its own data flow pipelines into its own training job clusters. As a non-confabulation, I give you https://status.openai.com. They have one of every color, they're collecting them!
In the age of AI arguments about a configuration language are moot. Nobody is going to hand craft those deployment configs anymore. The AIs can generate whatever weird syntax the underlying K8s machinery needs and do it more reliably than any human. If not today then probably in 3 months or something.
If you want to dream big for K8s 2.0 let AI parse human intent to generate the deployments and the cluster admin. Call it vibe-config or something. Describe what you want in plain language. A good model will think about the edge cases and ask you some questions to clarify, then generate a config for your review. Or apply it automatically if you're an edgelord ops operator.
Let's face it, modern code generation is already heading mostly in that direction. You're interacting with an AI to create whatever application you have in your imagination. You still have to guide it to not make stupid choices, but you're not going to hand craft every function. Tell the AI "I want 4 pods with anti-affinity, rolling deployment, connected to the existing Postgres pod and autoscaling based on CPU usage. Think hard about any edge cases I missed." and get on with your life. That's where we're heading.
I'm emotionally prepared for the roasting this comment will elicit so go for it. I genuinely want to hear pro and con arguments on this.
All the more reason you need a concise, strict representation of your actual config. If you're trusting an AI to translate fuzzy human intention into a machine protocol, there's less need for fuzzy human affordances in that machine protocol, and you should use one that plays to the strengths of a machine representation - one that's canonical and unambiguous.
If you want to dream big, why not give that post to AI and let it parse it to generate K8s 2.0, then you can get it to generate the application first, then the deployment. You can even have it feature-ask itself in a continuous loop.
Reznor released 5 movie scores last year. He's got 2 Oscars, 1 Emmy, 4 Grammys, and 3 Golden Globes the latest one this year. Multiple nominations in all those categories. He's far from done.
Another similar game to Dwarf Fortres is Song of Syx [0]. It's more accessible then DF and I think they can have up to 20,000 entities active in the world at a time. The world map is pretty huge, and the player gets to control a one group among many. Every entity in Song of Syx is individually modelled, though probably not in quite the details that DF is known for.
Game engine design is a rabbit hole :)
Game design is the ultimate lockbox - you're unlocking an entire imaginary world which has some platonic existance in your mind.
And since you mentioned Luanti, it deserves to be much better known as a credible open alternative to Minecraft. You could do a lot worse then designing/prototyping your game with Luanti as the game engine.
https://www.luanti.org/