THE SUCK RATIO
I haven't posted anything in a while. Let's fix that. Today we're going to talk about something I lovingly refer to as "The Suck Ratio," and it deals with creative programming, more or less.
Creating expansive projects is tiresome because usually the ratio of interesting code to boring code is around 1:10. I call this "The Suck Ratio" and use it as a measure of how much of a slog it'll be to grind a project to absolute completion. Ideally you want to minimize your suckage, but the nature of programming, and expansive projects in general, doesn't lend itself to that. In fact, there is a particularly nasty trap that I keep falling into over the years.
Let's say you have a sandbox type project that is fun to work on. There should be a point where it's feature complete, and then you can create the requisite content for it, and let the world enjoy it, but...... you suddenly realize you've burned through all the fun stuff, and now are faced with the task of spending hundreds or even thousands of hours grinding through boring code and asset creation rituals, and who wants that? So you avoid the inevitable slog by adding a new feature. PRESTO! You feel good again, and the sandbox had gotten a shiny new feature that you're proud of. We call this feature-creep, but sometimes the origin of the behavior is less steeped in bureaucracy, and more in the slowly unravelling sanity of a programmer's mind.
This artificially adjusts the suck ratio, but at a terrible cost. It's like drinking a fresh pot of coffee when you've already had 3 that day. You aren't doing shit other than making the situation worse.
I am, obviously, the king of never-ending software projects (until recently). How I broke out of the suck-avoidance-death-spiral was to concentrate on smaller projects, and attempt to minimize the rote nonsense that you normally grind through in certain type of projects. Also somewhat obviously, I run the 4x4x4 compo, which tasks people with making a mini-game based off of randomly selected emoji, with a month-long time frame for submission. We do it three times a year, and I always participate (except for this one time that I'm still particularly aggrieved about, but let's put that aside).
Smaller projects are nice because The Suck Ratio is closer to what we like. as projects grow in scope, the auxilliary and ancillary code needed to support the feature sets grows as well, and tends to blow the ratio out of proportion. Mini-games have a reduced feature set, and as such are easier to crank out without needing to leverage a ton of assist code. Working on these types of projects probably drives The Suck Ratio down to the 1:7 range, which is an automatic win. Hell, maybe even 1:5 on a good day.
The other trick I've been using is to aggressively debrief myself after each compo, and audit the state of the effort. I make a point of noting where I spent my time, and list items that were avoidable pain points. Between sessions, I take my mini-game framework and implement changes to reduce the effort involved in setting up a new project, configuring it, and getting ideas implemented. Beyond just the reduction of boilerplate, I've recently implemented menu and summary automation, cleaned up all the major framework features are made them definable assets (so we can knock out a #define and make whole files go bye-bye) and standardized entire features that have proven to be useful. Right now I'd say The Suck Ratio for new projects is hovering around the 1:4 range, and I'm sure I can improve that a bit more.
Ultimately a spate of glue code or other logical nonsense has to be crafted to get a game (or any other project) going, and that's not going to change. But concentrating on reducing that load, without bike shedding or feature creep, has been a winning combination. I've shaved entire weekends off of my projects, and reduced the friction of starting a brand new project. More fun; less stress.
The point is to have fun, right?