shortcuts & bottlenecks

It has been literally a full week since I’ve posted an update and tho I wouldn’t say that I owe an explanation for that, there certainly is one. See, a lot of people juggle time management, balancing work and play and code and life. I am no different, obviously, but this past week has been one of those weeks when a lot of other things have sidelined the code-writing and the pixel-art-making and the usual hunkering down in the basement turning my sweat and tears into a silly little video game.

I won’t go into details, but school and such account for most of it, and while as of yesterday I pushed through and submitted the last of a short list of assignments, to say I’ve dived headlong back into code would be slightly inaccurate, too.

But then the whole thing seems strange at this stage because even though I haven’t been able to spend nearly as much time as I may like on actually writing code, I also seem to have come to the part of this development project where two things are true:

1) what’s really slogging my progress is my ability to generate art, and

2) most of the progress I am making is expanding and duplicating features.

The first of those two statements seems pretty self-explanatory, right? I write some code for a player inventory and then I need to make art for the two hundred things that go in that inventory. I add a toolbelt, and now I need to draw all the tools. I added the ability to add decorative and interactive objects into playing field and now I need to draw dozens and dozens of interesting objects that might realistically populate the floor of a grocery store. My bottleneck there is art output, and I’m not an artist who has ever really been about volume production, so it all takes some mental shifting.

The second statement is a little more vague, perhaps? I mean, the whole effort here has always been expanding features, incrementally adding functionality to the game world. 

And yet, for a very long time that incremental enhancement was either entirely new code or entirely new functionality. Draw a room, add animations, add collisions, create database queries, respond to input. New. New. New.

But lately I find that I now have kind of two tiers of code: (a) stuff I wrote way back that is foundational and important and has been tested and refined and tweaked and expanded, and (b) stuff that I am squeezing into the gaps anew. And to make it more interesting, a lot of those gaps are emerging through copying stuff I already wrote and using it in a slightly different way.  This is a good thing, I think. If you build a system and it works and it is something that can be stretched a bit and nudged a bit and reused so that you have two very similar systems leveraging some of the same resources and working in pretty much the same way but resulting in slightly different outcomes, then that’s a good design practice.

An example might help here. Take my path grid code for example. 

I got ambitious one weekend and diverted myself by working on something I should have left for a later phase: I built a path tracking algorithm for npcs. It’s not complex. To be fair, the whole thing could be expanded easily, but as it stands it is literally an invisible grid matrix that corresponds to each tile of a room map. The two are independent, but they are tethered together digitally in that when one moves the other moves, when one changes the other changes, that kinda thing.  The grid consists of  and X x Y size, and each “cell” contains a bit of data: planar coordinates that correspond to the map, a “type” and most importantly for my npcs, and “occupier” code. An NPC exists as a varible inside the grid “occupying” a cell when it is standing still, then checks a path to see if the next cell is occupied or not. If so it changes direction. If not, it occupies two cells for a moment as it moves from one to the next, then releases the one it left back to a cleared state. It sounds complex, but it took less lines of code to make it work that than to explain it here. I tested it. I pushed it. I have tweaked and solidified it. It works pretty well.

And so rather than rewrite something entirely new for how objects exist in a room—sitting on shelves or on the floor as obstacles—I just duplicated some of my npc code and now, as far as the software is concerned, objects are just a kind of npc that lives on that same invisible grid occupying a cell.

The original npc code took me over a week to write. 

Building off of that code in the same amount of time I was able to add a store system, a player inventory and toolbelt, and an entire scheme of putting obstacles and objects in the room—all while I was deep in some school courses where I had rightly diverted eighty percent of my attentions.  I had once figured this second part would take me a month of coding. Instead, it just sort of was an oh-copy-paste-this-code-and it mostly worked.

I like to think that was all good planning, but it was mostly just a bit of fortuitous flukey foresight.

The short version of all this is that my code is sprinting because of these lucky shortcuts but now running into the bottleneck of my ability to art fast enough.

I guess I need to spend more time drawing and less time writing long winded posts about it, huh?

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *