Need GML architecture advice: I built a CSV-driven quest system to avoid spaghetti code, but is it scalable?

[u/VeterinarianLeast491]

Managing branching RPG quests and dialogue with raw GML and endless switch statements was turning into a spaghetti nightmare.

Out of frustration, I moved all my logic into a raw CSV spreadsheet (1 row = speaker, text, choices, triggers) and wrote a parser to handle it. It feels way easier to manage on the data side, but I’m worried I'm building a house of cards for a larger game.

I packed up my GML logic and the base structure into a free demo here if anyone wants to poke around the code and critique my approach:

https://francisco-89549.itch.io/rpg-quest-system

Is relying heavily on CSV grids in GameMaker a trap? Should I be converting all this to JSON and Structs instead? Would love to hear how you guys handle heavy narrative data in GMS2.

[u/mickey_reddit]

Just going to point this out that you want someone to pay $9.09USD to tell you if your code is scalable isn't going to get you anywhere. Your "demo" is a CSV file and readme showing zero library code.

Good luck

[u/VeterinarianLeast491 → u/mickey_reddit]

Ah, the classic Reddit detective. Thanks for the breakdown Sherlock. The free version is just a layout demo for anyone who wants to see how the CSV hooks up before buying the full parser. Appreciate the free engagement though

[u/mickey_reddit → u/VeterinarianLeast491]

yup that's me, just the basic reddit sherlock... 🙄

[u/WhereTheRedfernCodes]

Almost every architecture has flaws in it, the question is usually are the benefits for you better than the problems.

I haven't dug into your specific solution, but in general by encapsulating the data into a file you are making it easier to rewrite in the future if you need to.

My recommendation would be don't rewrite it again now, move forward with what you built and see how it works. Because really, how can you predict that any other solution is going to be that much better than what you put together now? Don't solve problems that you haven't identified yet.

[u/VeterinarianLeast491 → u/WhereTheRedfernCodes]

100% this. "Don't solve problems you haven't identified yet" is such a good reality check. I tend to over-engineer things before they're actually an issue, so I'm just going to run with this and focus on making the actual game now. Really appreciate the sanity check

[u/NationalOperations]

If you're only going to have a few thousand lines of dialogue then gml array/structs will be much faster not having to parse.

global.dialogue = { intro: { text: "Hello there.", choices: [ { text: "Hi", next: "greeting" }, { text: "Bye", next: "exit" } ] } };

If you're going to go way beyond that and in memory becomes wasteful, look into custom binary formats and loading them I. Chunks

[u/VeterinarianLeast491 → u/NationalOperations]

That’s a fair point, hardcoding structs directly in GML is super fast for smaller scales since there's zero parse overhead. I mostly leaned toward spreadsheets just to keep the dialogue text clean and away from the core scripts, but for lightweight stuff, structs are definitely hard to beat

[u/sonofmoon69]

I didn’t look at your code, but would suggest looking into YarnSpinner and the plug-in Chatterbox. It goes a long way towards managing dialog trees and variables, and it keeps sections pretty readable. If you find that your solution isn’t scalable and you don’t want to reinvent this particular wheel, give it a glance.

[u/VeterinarianLeast491 → u/sonofmoon69]

Appreciate the tip! Hadn't heard of Chatterbox before, but a Yarn option tailored for GameMaker sounds solid if my spreadsheet approach ever hits a wall. I'll definitely keep it on my radar