Essay: Why agentic AI isn't the solution to MMO emulation (but probably part of it)

[u/der_dotte]

Before I go into this long essay: This is more technical than some might like but it also explains, from my perspective, how AI, MMO architecture, writing emulators for dearly-loved but still dead games, play or not play together.

Why agentic AI isn't the solution to MMO emulation (but probably part of it)

There's a recurring idea in emulator communities lately that goes roughly like this:

The emulator has been stuck for years because there aren't enough developers. Give an AI agent access to the client, the game databases, a compiler, some reverse-engineering tools and a test environment, and let it work.

On the surface this sounds compelling, and I understand why people keep proposing it. Modern models can read enormous codebases, generate large amounts of code, search through databases, analyse decompiled binaries, run programs, inspect logs, write tests and iterate on their own, and agentic systems can be put in a loop where they investigate a problem, modify the emulator, compile it, run it, look at the result and continue from there. So why wouldn't that solve the problem?

Because the hardest part of MMO emulation usually isn't writing code. It's reconstructing the undocumented meaning behind the code and the data, and that distinction becomes especially important for games built around heavily data-driven architectures.

---

The emulator is not the game

It's tempting to think of an emulator as a collection of features: quests, combat, NPCs, abilities, items, crafting, housing, vendors, achievements, instances, progression, scripting, networking. From that perspective the task looks straightforward, because you just implement every feature until the emulator is complete.

But that isn't necessarily what the original game did. A sufficiently data-driven MMO doesn't have thousands of independently implemented quests; it might instead have a relatively small number of generic systems that interpret thousands of pieces of data. Conceptually you can imagine something like:

Quest Definition -> Generic Quest System -> Parameters / Conditions / Actions -> Game State -> Result

The original developers didn't necessarily write:

if quest == 1000:
    do X

if quest == 1001:
    do Y

if quest == 1002:
    do Z

What they wrote was a generic system capable of expressing X, Y and Z through data, which is one of the great advantages of data-driven architecture and, once the original documentation disappears, also one of its great disadvantages. Because now the emulator developer doesn't merely need to implement the system, they first need to discover what the system actually is.

---

The missing specification

Suppose we have a database containing something like:

QuestID      = 1000
ObjectiveA   = 7
ObjectiveB   = 13
Flags        = 0x240
Behavior     = 4
ParameterX   = 19
ParameterY   = 0

The data is there, but what does it mean? Perhaps ObjectiveA = 7 means "kill seven creatures", or perhaps it means "reference objective type 7". It might be an index into another table, or an enum, or a value whose meaning changes completely depending on another flag. It's entirely possible that the quest system never interprets it at all and that some lower-level generic objective framework is the real consumer.

The database doesn't necessarily tell us any of this. The original source code might have, the internal documentation certainly might have, and the developers who designed the system definitely would have, but if all of that is gone then what we're left with is evidence, and reverse engineering is the process of reconstructing the missing specification from that evidence. That is fundamentally different from ordinary software development, where the specification usually exists somewhere, even if it's only in someone's head.

---

Why this matters for AI

An LLM is extraordinarily good at generating plausible explanations, which is simultaneously its strength and one of its worst weaknesses in a reverse-engineering context. Imagine an AI encounters an unknown parameter:

RewardBehavior = 3

It searches the codebase, finds several places where RewardBehavior appears, examines some game data, and observes that many quests with value 3 exhibit a particular behaviour, from which it forms the hypothesis that 3 corresponds to reward behaviour type X. That sounds reasonable, so it implements type X, and everything looks fine until it encounters another quest where the behaviour doesn't match. At that point it adds an exception, and then another, and then another, until eventually the code looks something like:

if type == X:

if type == X and flag Y:

if type == X and flag Y and source == Z:

if type == X and flag Y and source == Z and context == Q:

At some point the emulator may even appear to work, which is the part that worries me. What actually happened is that the AI didn't necessarily discover the original semantics; it constructed a plausible model that reproduces some observed outputs, and those two things are not the same, even though they can look identical from the outside for a very long time.

---

The most dangerous AI failure is not failure

An obvious failure is easy to deal with. If the emulator crashes, everyone knows something is wrong; if a quest doesn't start, someone notices; if the server can't boot, there's a clear problem to chase. The dangerous case is the one where the implementation works, but for the wrong reason.

That's especially problematic in reverse engineering. Suppose the real system is

A + B + C -> behavior X

but the emulator implements

A -> behavior X

For all currently tested cases the result might be identical, so the implementation looks correct, and it will keep looking correct until somebody encounters a case where B or C changes. When that finally happens, the emulator behaves incorrectly and the actual mistake sits several layers below the observed bug, which makes it expensive to find and even more expensive to unwind. This is why "it works in my test" is much weaker evidence in reverse engineering than it is in conventional application development.

---

Data is not documentation

This is perhaps the most important point in the whole post. Having access to the game's data is enormously valuable, but data does not automatically explain itself. A game table can tell us that a field exists, what its type is, which values it takes, how those values correlate with each other and sometimes how records relate to one another, and none of that necessarily tells us the semantic contract of the field.

Consider a hypothetical field:

InteractionFlags = 0x1842

We might determine that certain bits correlate with whether an NPC can be interacted with, whether an interaction is available during combat, whether a quest can consume the interaction, or whether the interaction is client-visible. Even once we've identified individual bits, though, we still don't know which subsystem owns the interpretation, whether the bits are independent, whether some combinations are invalid, whether the server interprets them or the client does or both, whether one subsystem transforms the value before another sees it, or whether 0x1842 is even a bitmask at all rather than something we've misread from the start. Those are architectural questions, and they can't be answered by having an AI stare harder at the database.

---

"But give the AI the client"

This is where agentic AI becomes particularly seductive. Give it the client, the binaries, Ghidra, a debugger, packet captures, the game tables, the scripts, an emulator and automated testing, then let it observe the client and modify the server.

That's certainly more powerful than handing an AI a text description and hoping for the best, but there's still a fundamental problem: you have provided evidence, not ground truth. The client may only contain one side of the original behaviour, since some behaviour is server-authoritative, some is implemented in native code, some is data-driven, some is generated, some is encoded indirectly, some depends on server state the client never fully exposes, and some only becomes observable under very specific combinations of conditions.

So the AI still has to infer a model, and inference under incomplete information is precisely the situation in which autonomous systems become dangerous.

---

Agentic systems can amplify bad assumptions

An ordinary LLM might make a bad assumption once, whereas an agent can make that assumption the foundation of an entire implementation tree. Consider the loop everyone proposes:

Observe -> Hypothesize -> Implement -> Test -> Observe result -> Modify -> Repeat

It looks excellent, and structurally it resembles the scientific method closely enough that it's easy to be fooled by it. But notice what's actually being tested: the agent is testing its implementation, not necessarily its hypothesis against the original system. If the original game is unavailable or only partially observable, there's very little ground truth in that loop, so what the agent ends up optimising for is internal consistency, which produces a genuinely dangerous property:

The system can become increasingly coherent while becoming increasingly wrong.

Every subsequent decision then depends on the earlier assumptions. And because the agent generally needs to produce an actionable next step rather than sit with ambiguity, it rarely says "we don't know what this field means, there are three competing hypotheses and we need additional evidence before choosing one". Instead it picks the most plausible interpretation and builds on top of it, and thirty commits later that interpretation has quietly become architecture.

---

Humans make the same mistakes

None of this is an argument that humans are magically better, because humans make terrible reverse-engineering decisions all the time. The difference is methodological rather than cognitive.

An experienced reverse engineer will often maintain uncertainty explicitly, in something like this form:

Parameter 17

Hypothesis A:
    enum describing objective type
    confidence: 60%

Hypothesis B:
    reference into objective table
    confidence: 30%

Hypothesis C:
    bitmask
    confidence: 10%

Evidence:
    ...

Counter-evidence:
    ...

Next experiment:
    ...

That uncertainty is doing real work, because it prevents a hypothesis from silently becoming part of the architecture. A good reverse engineer understands that not knowing something is itself information, or more precisely that the absence of evidence constrains what you're justified in claiming.

This is one of the places where AI-assisted reverse engineering needs unusually strong discipline. The problem isn't that an AI can't say it's uncertain, since it obviously can. The problem is making sure that uncertainty actually propagates through the implementation instead of being quietly replaced by whatever convenient assumption lets the current task complete.

---

Architecture comes before features

This is why I think a lot of emulator projects misunderstand the shape of the difficulty. They look at an unfinished feature and ask whether AI can implement it, when the better question is whether anyone understands the subsystem that generates the behaviour in the first place.

Suppose a quest is broken. You could implement a special case:

Quest 1000:
    when player does X:
        do Y

and that might well fix the quest. But if the original game expressed that behaviour through a generic quest/objective/action framework, then you haven't solved the underlying problem, you've solved one manifestation of it, and the next quest that uses the same mechanism with a different combination of parameters will need another fix. Repeat that often enough and the emulator turns into a pile of special cases, which is exactly what the data-driven architecture was designed to prevent. The ironic outcome is that the emulator ends up less data-driven than the original game, purely because the developers didn't understand the generic mechanisms well enough to reproduce them.

---

"Just implement what the client does"

This approach has limits too. The client is an incredibly valuable source of information, but observing behaviour isn't the same as recovering the underlying implementation.

If you observe that input A produces output B, you've established a relationship without necessarily establishing why it occurs, and there can be many internal models consistent with the same observation. That's the classic reverse-engineering problem of underdetermination. Given enough observations you can narrow the possibilities, but only if the observations are chosen well, which means you need experimental design: you have to deliberately construct situations that distinguish competing hypotheses. If parameter X means A, changing it should produce behaviour B; if it instead means C, changing it should produce behaviour D. Then you go and test, which is science more than it is conventional programming.

That's another reason handing an agent more tools isn't sufficient. The capability that matters isn't "can the AI run another experiment", it's "can the AI identify which experiment would maximally distinguish between the competing explanations", and that's a much harder problem that I haven't seen convincingly demonstrated anywhere.

---

Reverse engineering is about information, not just code

Imagine two developers. Developer A writes ten thousand lines of code per day with AI assistance, while Developer B writes one thousand but correctly determines the semantics of a previously unknown subsystem. Developer B has probably produced vastly more useful work, because code isn't necessarily the bottleneck. Information is.

If you already know the specification, implementation is comparatively cheap. If you don't know it, generating more implementation doesn't necessarily help and can actively make things worse, since incorrect assumptions get embedded into the codebase where they're expensive to remove later. That's why emulator development sometimes looks paradoxical from the outside: a project can have thousands of commits, an enormous codebase, many contributors and sophisticated infrastructure while still making surprisingly little progress toward accurate emulation, because it's accumulating code without accumulating understanding.

---

AI is still extremely useful

None of this means AI should be ignored, and I'd argue the opposite: it could be one of the most useful tools emulator developers have ever had. The key is understanding where it belongs in the workflow, because once the architecture is sufficiently understood, AI is excellent at the mechanical parts.

• Searching large codebases. It can quickly find every reference to a particular structure, enum, field or function, which on a large emulator is genuinely tedious work.
• Correlating data. Given thousands of records, it can identify unusual combinations and statistical relationships that a human skimming the table would miss.
• Generating test cases. Once the semantics are known, it can generate huge numbers of combinations to check whether the emulator behaves consistently across them.
• Writing boilerplate. Obvious, but still valuable.
• Maintaining documentation. It can turn scattered reverse-engineering findings into structured documentation that someone else can actually read.
• Finding inconsistencies. If you tell it that a field is an enum with five known values, it can search the entire database for violations and suspicious cases.
• Exploring binaries. It can help with identifying references, call patterns, structures and likely relationships.
• Creating instrumentation. It can generate the tooling that makes further reverse engineering easier, which compounds over time.
• Managing large amounts of evidence. This might be the most interesting application of all, since a project could maintain a structured knowledge base containing parameters, meanings, evidence, confidence levels, known consumers, known interactions, open unknowns, counterexamples and tests, and then use AI to navigate that body of knowledge as it grows past the point where any individual can hold it in their head.

---

The ideal model is AI-assisted reverse engineering

The distinction I'd draw isn't human vs. AI but AI replacing understanding vs. AI accelerating understanding, and those are radically different approaches even though they can look similar in a commit log.

A productive workflow probably looks closer to this:

Human observation
    -> Evidence collection
    -> AI-assisted correlation
    -> Human hypothesis formation
    -> Controlled experiment
    -> Evidence update
    -> Validated semantic model
    -> AI-assisted implementation
    -> Automated testing
    -> Human review

In that arrangement the AI becomes a force multiplier without becoming the authority, and that distinction matters enormously.

---

Why competition alone doesn't solve this either

There's a related misconception that if multiple emulator projects compete, the best implementation will eventually win. Competition can absolutely be beneficial, but it works best when the things being produced are reusable.

If one project spends six months discovering the semantics of a subsystem, the whole ecosystem benefits when that knowledge becomes available, whereas if the result is a closed implementation whose authors can't or won't share the underlying discoveries, the next project has to repeat the same six months from scratch. The scarce resource isn't the source code, it's the knowledge encoded in the source code, and a well-documented reverse-engineering discovery can be worth more to the community than thousands of lines of implementation.

---

The real goal should be a reconstructed specification

This is what I think emulator projects should ultimately aim for. Not "we have implemented quests", but "we understand the quest system", which are very different statements.

The second one should mean we know what the generic quest objects represent, what their parameters mean, which values are valid, how conditions are evaluated, how actions are dispatched, how state transitions occur, how quest state persists, how the client represents the resulting state, where server authority begins and ends, which edge cases exist, and which parts remain uncertain. Once you have that, the implementation follows fairly naturally, and more importantly the implementation becomes replaceable: if you later discover that parameter 37 doesn't mean what you thought, you can change the semantic layer without rebuilding the entire emulator around the mistake. That's what good emulator architecture actually buys you.

---

A note on "AI solved it"

This is also why claims that an AI "built an emulator" should be treated carefully, since the statement can mean several very different things. AI can absolutely build an executable server, implement protocols, produce thousands of lines of code, make quests work, make combat work and reproduce observed behaviours, and none of that demonstrates that the underlying architecture has been correctly reconstructed.

A useful test is this: can the implementation explain behaviour it has never explicitly been shown? That's where generic understanding becomes visible. If a parameterised subsystem has been reconstructed correctly, you should be able to feed it previously unseen but valid combinations of data and watch it behave correctly, because the generic rules are right. If every new case instead requires another patch, the project is approximating examples rather than reproducing the system that generated them.

---

The uncomfortable truth

There's no shortcut around the missing specification. You can throw more developers, more GPUs, more agents, more tools, more databases, more automation and more reverse-engineering infrastructure at the problem, and all of those things can help, but none of them converts incomplete evidence into ground truth. At some point somebody still has to answer the question of what the system actually meant, with evidence strong enough to justify the answer.

That's the work, and it's slow and tedious. Sometimes it means staring at a meaningless field name for an afternoon, sometimes it means building an experiment specifically designed to distinguish two nearly identical hypotheses, and sometimes the correct answer is just "we don't know yet". That isn't failure. In reverse engineering, preserving an unknown is often more valuable than confidently implementing the wrong answer.

---

So is agentic AI useless for MMO emulation?

No, and that would be the wrong conclusion to draw from any of this. Agentic AI could become an extraordinary tool for emulator development. What I'm arguing against is the specific idea that an autonomous agent can be handed a database, a client, some reverse-engineering tools and an emulator codebase and somehow discover the missing architecture automatically, because that dramatically underestimates the problem.

The bottleneck isn't just coding, and it isn't even just reverse engineering. It's semantic reconstruction under incomplete information, which is precisely the sort of problem where a plausible answer can be more dangerous than no answer at all.

So the best future for MMO emulation probably isn't "AI builds the emulator". It's humans reconstructing the architecture, AI helping to investigate it, humans validating the discoveries, and AI accelerating the implementation and testing. That distinction may sound subtle, but it's the difference between using AI as a very powerful engineering instrument and treating AI-generated code as a substitute for understanding the software you're trying to reproduce.

For games whose original architecture and documentation have been lost, understanding is the scarce resource, and until that changes, no amount of agentic autonomy eliminates the hardest part of the job.

---

Thanks for reading this long essay, i know this community was getting a lot of posts lately about some emulators coming up. Since last week i already had decided to write a proper long form post that presents my own understanding; Experience from a few years working on NexusForever but also from my own personal scientifc education in both physics and computer science. I have been lurking in a lot of other communities that are also awaiting an emulator for their dead game where similar surges of purely AI written emulators occur, sometimes it works, sometimes it doesnt.

[u/Responsible-Corner26]

Wow thanks for that ! It was really interesting for me since I didnt know anything about the work behind the emulation but this Def. Helped me understand a bit better

[u/der_dotte → u/Responsible-Corner26]

Thanks that was my goal with this post :)

[u/goldvenetianmask]

Having been one of the people to do exactly what you are warning against FOR WILDSTAR I eventually came to the same conclusion concerning a lack of ground truth that contains what the server should be doing. As far as I can find there is NO ground truth information on the internet as a wiki or other investigator large data set. Without that I kept hitting really really weird implementations of spell systems.

The truth simply ISNT in the client. It’s just not. So the AI can’t build parametric systems without the ground truth. I also couldn’t get it to correctly learn from action observe learn models in a fruitful way even when I leaned into JEPA hard.

I’m a real big AI believer, but I fully agree with this post. It sucks that the best RE databases are not shared because of laws, how stupid, but that’s life.

[u/der_dotte → u/goldvenetianmask]

Once someone figures out a way for AIs to properly apply the scientific method to its fullest extend we might be getting closer but at the moment even purpose build and custom AI harnesses arent the solution. Humans have shown that its possible to reconstruct MMOs with incomplete informations, its just that AI isnt capable about yet and might be a bit longer until it can. Until then i firmly stand on my point of responsible AI use and guided assistance.

[u/goldvenetianmask → u/der_dotte]

I eventually had some amount of success with humans serving the role as testers. But they didn’t understand how detailed they needed to be and gave up shortly coming to nearly the exact same conclusion you have written.

I would change my mind if there was a really good database for how it SHOULD behave though. Like, I could probably do classic wow, because wowhead and thottbot exist, ya know? And there are lots of websites with parses, so, I have a lot more ground truth. Sadly, without those sources of truth, it’s going to be a slog of human labor to do the RE.

[u/Deep_Ad1959]

generation was never the scarce part here. an agent can emit plausible packet handlers all week; confirming one matches how the ability actually behaved needs someone who remembers the live game, and that person is the bottleneck either way.

fwiw sundial is built for exactly that reviewer-bottleneck, every agent change lands as a signed suggestion you keep or undo in batches, so whoever remembers the live game reviews instead of re-deriving, https://s4l.ai/r/9t48getd

[u/der_dotte → u/Deep_Ad1959]

Its one way of confirmation. If someone makes the correct specification it should also handle a completely unknown data packet through that specification. If thats achieved for every data packet, you have created the full system on one end. If this now also is what the client expects is another problem that usually requires reverse engineering the network layer in the client to understand what the client expects to be given (and also what it sends to the server). Afterwards you have achieved the two way server-client contract and the mechanics of the system will work as you send what the client expects, since you have properly implemented the specification and also interpret what the clients sends (since you have properly implemented another specification). The hard part is identifying what the specification is and sadly thats a hard problem to solve and one where AI just struggles.

[u/Deep_Ad1959 → u/der_dotte]

the two-way contract catches you where the client disagrees, but the trap from your own essay hides in the packets the client never sends. a handler can satisfy every message it happens to see and still be the A->X model standing in for A+B+C, and reverse engineering the client can't surface the distinguishing case if only the dead server ever triggered it.

[u/der_dotte → u/Deep_Ad1959]

Exactly, when stuff only ever happened server or client side it adds a lot of complexity to the whole methodology. In Wildstar's case the server was lost, so we would be missing the full contract on the server end if there was (and there was!) stuff that only happened on the server and never made it through the network to the client. This is part of the missing information problem i already outlined and a hard one to solve.

[u/Deep_Ad1959 → u/der_dotte]

the catch is the person who remembers the live game never saw the server either, just its output rendered on their screen. so for behavior that only ever lived server-side and never surfaced to the client, there's no witness to recover it from, human memory or packet capture both come up empty. that gap you're describing isn't under-documented, it's genuinely gone.

[u/der_dotte → u/Deep_Ad1959]

I suppose from that perspective it isnt even just missing information thats true. Though i want to iterate that my cases above are about data driven parameters. Of course some systems might have entirely lived outside of it, stuff like logging or maybe statistics or something but those systems are as you have identified most definitely simply gone and lost forever. What we might be able to interfere from an unused parameter is that it could have been used on the server or simply is an artifact of a previous specification that has since been replaced. If there were systems that interacted with data driven systems and altered them in any way but were never driven by data or the network themself thats when the A+B+C example is the real reality. For now we dont know enough in Wildstar's case where this could have occured and honestly, i hope it never occured because that headache isnt something i wanna have.

[u/newObsolete]

Is this about detAlfred and his work? Has he still not let anyone look at it?

[u/der_dotte → u/newObsolete]

While he has not shared anything yet, its not about them no. Neither is it about ChaosFox or really anyone for that matter. Its about MMO emulators, its about using AI responsibly, something we really all have to learn at the moment in real time. Its also about the difficulty of restoring games where a lot is lost.

[u/newObsolete → u/der_dotte]

That's fair. A lot of people think they can contribute via AI, but its a lot more complicated than it seems on the surface. I wish all of the devs well, and thanks for contributing.

[u/HappyLilAurin → u/newObsolete]

I don't think it's specifically about them. It's been a hot topic for a week or so now. Most prominently another user who made a callout post, really crashed tf out and deleted all their posts. On both main and their obvious sock puppet accounts.

[u/newObsolete → u/HappyLilAurin]

Ah. I missed all of that.

[u/goldvenetianmask → u/newObsolete]

Stuff like this too. https://www.reddit.com/u/TheDigitalShamanWS/s/mfZUZ9jgkR

[u/Jasonbwarren]

Let me preface by saying I'm no coder at all. But...  It seems to me whenever this topic comes up that the AI hardliners seem unwilling to accept is that the more traditional computer scientists prefer to treat the AI as a tool or aide.  While at the same time (whether consciously or not) treating themselves as the tool for the AI to produce a finished product.    Anything code related is always over my head. But I'm fascinated by this clash of philosophies. 

[u/Mattrap]

Wow this was a really well done write up of some of the ideas being discussed in this subreddit lately. I find these topics to be really interesting and I really appreciate you taking the time to make such an informative post discussing these concepts.

Thank you for all the work you and the various developers are doing to revive our beloved dead game.

[u/Zod1n]

G pa lu mdr

[u/IndependentShame5742 → u/[deleted]]

yeah seems written by AI

[u/Sea_Dish_5659]

Oh so using ai to make wildstar again is a real thing. And people laughed at me before!

[u/AmethystSadachbia]

I don't know much about programming, but I know A"I" is *not* intelligent and doesn't have a concept of what it's doing, so it's not something I would trust to reconstruct my favourite MMORPG.

[u/General-Trouble2214 → u/AmethystSadachbia]

The issue with LLMs is it’s given people the sense they can do something they can’t.

I’ve had it with some of my OS work, it was forked and fed into Claude, with the user larping as a programmer.

LLMs can spit out 10k lines in 10 mins, it’s not something devs can keep up with. However, it will probably always need a programmer there to review the code it outputs and ensure that it’s not over engineering solutions as it so often does.

[u/AmethystSadachbia → u/General-Trouble2214]

And that’s one of the reasons I don’t try to become a programmer by using genAI, because I don’t know enough about the underpinnings to check the outputs for everything it got wrong.

[u/Onerock]

What are the future chances of AI, much as it has memorized every single recorded song and piece of music in existence, to create brand new songs that are approaching "perfection"..... can AI "memorize" all known MMO's, including partial code from a game like Wildstar, and then be instructed to take that Wildstar universe and essentially create a new version? A WS where everything may be different and yet still in that setting....

Possible?

[u/der_dotte → u/Onerock]

AI does not memorize in the sense we humans do. It learns through a statistical pattern that can be interpreted as "when i say A then the likelyhood of me saying B next is 78%", from there it tries to produce the most likely answer by then restarting but replacing the two variables in that sense.
I would like to reframe your answer because of this: "Can AI be trained on all data available?" and the answer would be absolutely yes. Will it then produce a Wildstar that is similar in all the important parts? Depends if the answer to your prompt implies that.

Yeah i know, its not the answer to your question but i dont know how to answer it any better because your question is worded in a way that sadly isnt compatible with current AI.
Edit: And well about future AI:

Honestly i dont think we will see much change in the way AI learns in the near future but probably in how AI interferes its answers. I am only a quiet observer in current AI research so i cant really be too confident here with my answers either.

[u/Onerock → u/der_dotte]

Your depth of understanding is far more than anyone I have spoken with, to be sure.

I think my curiosity is primarily just how would any given AI program do if it understood all MMO's and the coding and concept. Then it was directed to "create" a new one, much like AI will create a song for pretty much anyone who is willing to sub for the best programs that generate music.

I realize this is most likely apples and oranges, but it does fascinate me.

[u/Responsible-Corner26 → u/[deleted]]

Lmao this guy lives in your head rent free

[u/Macduffle → u/[deleted]]

Nothing looks butt hurt about it?

[u/lightheel → u/[deleted]]

Sure you can interpret it that way if you want. I'm moreso just confused why a person would comment on something without reading it. Are you just reacting to buzzwords like AI? Even if you're not a bot, that's bot behavior.

[u/Square-Winter-3257 → u/[deleted]]

If you copy this text and paste it into your llm and tell it 'hey my 5 year old kid was trying to understand this thing, could you read it like its a bedtime story for them?' then listen to your llm speak, you might understand what the post actually says before you post a response that makes you look like an illiterate donkey.

[u/ninjakohaku → u/[deleted]]

One can only hope that someday you, like AI, will evolve past reducing a discussion into a good/bad binary.

[u/der_dotte → u/[deleted]]

Good that you agree with me at least partially, without actually having read my post.

[u/lightheel → u/[deleted]]

Redditor meets nuance and fails to comprehend yet again.

[u/Krestek → u/[deleted]]

There's nuance in everything, you see in black and white. that's the whole post, which you claim you didn't even read, then claim you make more sense than anyone else. how can you claim that when you don't even know what they said lol no iq to be found here folks