Recently I hit a code-block (like writers block except for code) in my game development experiment that I have been slowly doing over a few years now because I absolutely hated data entry. I built a battling card game, prototyped it offline using pen, paper and excel, before creating my game in Unity3d. Everything was going well. I created my battling systems, setup data structures and refactored my code a few times to accommodate some crazy idea I had to support augments ala Warframe.

Data entry, however, was that elephant in the room. I had dozens of characters designed with unique spells and traits. I need to translate my plain English descriptions of spells and traits into my spell system. Before all of this, I have had set up script-able objects and custom editors in Unity using Odin. This worked fine for simple lists and dictionaries but since my spell system required heavy usage of sub-classes and nested components it became incredibly difficult for Odin to present a consistent user interface for my systems. One particular example was around nullable references to complex subclasses. A simple List<Spell> would show up as nullable with no way to change it in the editor. Data entry became difficult because I had to fiddle around the editor UI and figure out the origin of each element.

I kept working on other systems to avoid doing data entry until I got to the point where I more or less need to have more data in the system before I could progress meaningfully. A month or so later, I had a flash of insight.

Why do I even need to use the Unity3d editor for this? Why not store everything as code instead?

Code was easy to edit and manage. Code can be type-checked. Code is what I'm familiar with.

So I began reconstructing my game asset files into code. At first I tried to convert raw unity asset files into c# code. That didn't work. Then I tried storing them as structured YAML using some custom schema. That took on more effort than I would have liked, and was essentially duplicating my c# game structure. Then I said eff it and started rewriting it as just c# code, and that worked beautifully. It was a one way conversion. c# -> asset files was easy. The other way round was not. Kind of like a one way chemical reaction.

After that I realized that since this is just text on a schema now, why can't LLMs map my excel to c# code?

LLMs are extremely good at pattern matching against data. Their magic comes from mapping between stuff and figuring out how to do that based on some internal relationship. Knowing what they do best and how they suck helps alot in figuring out where they fit in the problem-solution spectrum.

However I don't really see anyone providing a proper analysis on how LLMs suck beyond big words like "creativity" and "its not AGI". So here's my take. LLMs suck at handling context poisoning. Humans handle this perfectly well because we forget by default. Our attention span is extremely short even though we can process huge amounts of information in parallel. LLMs however need focus and any extra information, intended or not, may cause the LLM to pattern match against the wrong thing since they are currently incapable of first-degree analysis that humans are fine with.

Instead of having the LLM just look at my excel and generate c# code, I first engage in a meta-step to generate the prompt by limiting what it can do (focus!).

I started out by saying "dont write any code unless i tell you to. the goal is to generate a prompt such that when provided a few files and a list of attributes, it will generate c# code or something like that. given these columns: ... and a row containing values ... after referring to available spells in Spell.cs and NullableSpellModifier.cs, reviewing structure from BattlerData.cs and BattlerDataDsl.cs, i get BattlerDataDsl_Ally.cs. If i find that the spells cannot be created using Spell.cs i would propose a new spell function by writing some specs and c# code according to the specs. Help me automate this effort by codesigning the workflow/prompt."

The LLM then went on to create an example prompt which had a bunch of errors because they tend to hallucinate and assume things instead. Fixing the prompt was a matter of providing more context and data. In the final prompt, the LLM helped provide lists of helpful mappings like "if you see these text, it usually maps to so and so functions", which would otherwise be done by hand for me. I even had it map localization keys and handle nested structures by identifying them as "pattern modifiers". The final prompt structure was like this

1. context
2. input format
3. column mapping
4. analysis steps 4.1. Parse Basic Properties 4.2. Analyze Spell Descriptions 4.2.1. Identify Core Actions: 4.2.2. Direct Actions: 4.2.3. Pattern Modifiers: 4.2.4. Conditional Patterns: 4.2.5. Complex Combinations: 4.2.6. Identify Targets: 4.2.7. Identify Attributes: 4.2.8. Identify Costs: 4.2.9. Identify Timing: 4.3. Map to Existing Spells 4.4. Identify Missing Functionality
5. Output Format 5.1. Option A: Complete Implementation (if all spells exist) 5.1.1. CRITICAL TRANSLATION REQUIREMENTS: 5.1.2. Available Translation Patterns (from TranslationsReference.cs): 5.1.3. Examples from existing keys: 5.1.4. Option B: Implementation + Missing Spell Proposals
6. Quality Checks
7. Example Analysis Process
8. Instructions

This was way more detailed than I could have done in a short amount of time and helped result in a satisfactory output that ultimately saved a lot of my time and prevented me from being burnt out from data entry. All in all, it let me continue do what I like, analyzing problems and writing solutions!