Game dev is hard

Whilst playing around with the scripting for my new project, I often wonder about how the hell Ron Gilbert et al. managed such a great job on much lesser hardware. Some of the complexity that I've added to the Point-and-click engine up to this point probably out-sizes the entire game size of those 8/16-bit classics.

It was also getting to the point where I couldn't even follow my own code well anymore, particularly when it came to the "threading" systems for dealing with background scripts, cutscenes, queuing actions, etc. And given that my own personal stubborn mantra in my professional job is "if you can't understand the code, or it's not well commented, it's bad code" - I decided to rethink.

Turns out that that was a decent move rather than my normal one where I feel gassed by the time I've got to parity with the original. Things are WAY cleaner, and so far more fun to work with. More importantly, the code is FAR smaller, simpler, better documented and organised.

I've probably spent more time thinking or researching on this project than any other so far, as perhaps I underestimated how difficult the groundwork stuff is. Game dev is hard.

Still, we're at a point now where we can move around, animate, point at things or even turn our head, collide, display text/dialogue, etc all backed by a relatively simple "threading" & job manager - perhaps 90% of all of the key functionality for gameplay. Most of the rest is fairly easily layered on top once you can get things on screen, find out what was clicked, move things around, etc.

There are a few headaches left, but they're relatively trivial and probably only "headaches" as I'm spending proper time making sure they're the *right* additions in the right places. We're not ready to start adding hacks just yet...

Leave a comment