Man oh man. I said before that finishing games is what helps me figure out what I like and don't like in my code workflow. It's still true.
Interstice Academy is my latest game, a dating sim made with a bunch of writers and artists and composers on team Milk Chocolate for a month-long jam. This is my second finished game using Heaps, first using ECS, and last using the current iteration of my dialogue engine. It was a good experience overall, working with high quality creators but also rushing a good bit toward the end. I had something of a dialogue engine already built in a prior workflow, and bringing it over wasn't that hard. I think I worked on it after playing Half, which I really appreciated and kinda inspired me a bit. But I need to work on it some more. Code is here, minus the assets.
As far as my workflow, let's start with the bad:
There are 286 manually created "dialogue" files. This worked in Quarantine which didn't have as much dialogue in comparison, but man this sucked. I didn't have time to make sweeping changes to my parser, but even some tiny changes probably saved me hours of effort in copying from a Google Doc to the code environment. The doc was either one huge file or like 7 smaller divided but sizeable files, and I feel like my code can get closer to either of those. An innocent option in game with 3 choices that all end up at the same line is 5 individual files: the original, the final, and 3 for the options. This could definitely be inlined, if nothing else, to all be in the same file. Times 60 for the entire game. The biggest time sink was coming up with new names for each file.
The UI library didn't correctly scale with the game. This was annoying. When I implemented fullscreen towards the end, I realized that the mouse interactions didn't scale with the game. Everything on my side scaled, but the UI interactions either didn't or just broke. Fixing this would have taken several weeks on its own, just because of how entrenched interactions are in a User Interface library. This one sucked because I assumed resolution was easy and handled already. Even zooming into your browser or people on tablets with a default Windows scaling breaks it. Unfortunately, I think the solution is rolling my own in-engine UI components. I had so many other gripes that just fixing resolution wouldn't make things that much better for future projects.
The dialogue file syntax was too strict. This wasn't the worst in the world. After submitting, I talked with the coder for Love Me Newgrounds, who used Renpy. Just loading that game, not even getting to the title screen, I could tell it was a whole ass thing, and they agreed. But, reviewing the narrative syntax, it was much easier to write because it was less strict. I think something closer to Renpy or Twine, with syntax highlighting in the code editor, but also extreme flexibility in manipulating the UI or adding random shaders like IA asked of me, is the ideal. Something that checks the syntax in either case would be even better, making sure I didn't forget a quotation mark deep into the story. Renpy by itself seemed annoying and had some bizarre restrictions.
The good:
Workflow is clean. I'm getting more used to my own ECS workflow, and man it is so easy to do things. Tweens, fades, and delays just happen with barely any thought of side effects (though the UI library made visual glitches happen without being careful). Editing code is easy because everything is organized by function. In a separate project, I'm finding that something like AI is overcomplicated by the methodology, but here it worked well. I think a hybrid approach, whatever that ends up looking like, will be good in general.
It mostly works on mobile. My input handling code just dealt with mobile without me having to try, so touch input was supported right off the bat. Scaling mostly worked, though hampered a bit by the UI stuff. I haven't tested enough to be confident, but it seemed like high DPI screens didn't scale independent of mouse coordinates, ie the mouse position scaled with the display. I need to experiment more, but it's good to know ahead of time that it will work one day.
So, A) progress, B) I'm gonna end up making a whole ass game engine one day, C) we got daily #1 which is my first!, D) I have a bunch of new names I'd want to work with or commission in the future.
Pretty good pretty good.
Gimmick
Every time it looks like something's good enough, there's always that one thing that you end up finding that borks it either a little (if you're lucky) or entirely (if you're not), and is just nagging enough that you can't shove it under the rug and pretend it doesn't exist.
With regards to your previous post, it's frustrating to say the least when you have to face breaking changes in upstream. I haven't faced that issue directly, but I've had ones where a library that looked promising (albeit poorly documented) just turned out to have a ton of logic errors after all the finagling I had to do to fix the syntax errors, leaving me to find an alternative which meant my time before that was pretty much a total wash.
Offtopic, but if there's anything I hate about academia, it's that people end up having horrendous code and zero documentation at all to go with it. I totally understand the reasons why this happens but damn if it isn't frustrating as all hell. (Don't even get me started on Python 2 vs. 3, everything seems to be written haphazardly and in a throwaway manner - little to no attempts at futureproofing at all)
MSGhero
Yeah, I’m starting to find the more involved libs don’t work with the level of control I’m after.