A comment on comments

Much has been said about comments in programming. I feel like when I was first learning “comment everything!!” was popular advice to newcomers which eventually shifted over to “your code should be self-documenting!”, though I suspect the latter advice has been around for about as long. I’ve never been a huge comment user since I wrote most of my code during short term contests, making it disposable. Mostly documenting things that might need to be adjusted later, possible problems/deficiencies, and often using them to separate unrelated chunks of code (which is likely a bad practice that generally indicates the code should just be split apart). I should do a better job of documenting the API, particularly considering how often I use dynamic languages.

But after working on such a long term project for so long, the realest purpose of comments is starting to dawn on me. Comments are band-aids for when things aren’t ideal. If you’ve analyzed a situation and decided to go with a compromise to get something done just “good enough”, you can use a comment to explain the particulars of an odd line of code instead of wasting the reader’s time figuring out the chain of reasons for it. I’ve probably used them for such a purpose countless times without realizing it. But there are just as many times where I’ve done something convoluted without bothering to explain it, and then had to understand it again later. I need to make a more proactive effort to notice these situations and then explain them for the future. It’s not as good as just having obvious behavior, but it’s better than nothing.

This isn’t a mind blowing revelation so much as reminding myself by writing about it. Most people writing about “self-documenting code” will say something very similar. Though they mostly refer to it as using comments strictly for non-obvious or complicated sections of code, as opposed to just admitting it’s to alleviate bad code. I don’t think I fully absorbed the idea when it was about “non-obvious” code. But bad code. That I understand.

July 27th, 2014

We’re through most of the “oh man everything is depending on a different API that we need to update” phase of conversion and into the “we need to actually change these things to work better with the new stuff” phase of conversion. At this point I almost regret not just leaving the existing systems as they were and limiting the new system to the UI. There ARE benefits to converting the entire game to the new system, but 3 weeks is a much worse price than I anticipated. Though I wouldn’t say this has been 3 weeks of pure work, things have been a little messy lately.

In general I’m starting to get more into a mindset of “get it done”. Been spending less time over thinking minor issues to be perfect. Converting older code to the new scene system has made me brush with some of the worst remaining parts of the codebase, and I’m starting to accept the fact that I just won’t have time to improve those parts any time soon. We’ll see what happens when we get down to polishing, but the things I need to do are holding up other aspects of production so they need to get done first. You can either build the perfect engine or you can build your game, but you can’t do both.

July 20th, 2014

Well it finally happened this week. Sew came up to me and told me that he couldn’t really start on that much final art until there’s a finalized plan for the game. This was inevitable. Several months ago or so when I decided whether to do the UI/Display overhaul first or prioritize finalizing the game design I chose the UI, despite my gut feeling otherwise. I suppose that’s this year’s big mistake.

It’s a better mistake than last year, though. It taught me the valuable lesson that while development UI doesn’t need to be pretty, it does to be functional and expose needed information properly to players. Putting it off alongside prettiness can lead to false results. The changes will also make it easier to do certain design changes that I would have avoided before due to development costs. So it’s not a total loss.

Regardless, I immediately put the remaining UI work on the back burner (though I may try to work on it once a week so I don’t lose my place) and set to converting the existing game to use the new display system. The work needed to convert the existing map engine has been worse than expected. While I fully expected updating all the systems that depended on it to be a pain, I didn’t expect this much resistance from the engine itself. So it seems like it’s going to be a 2-3 week job instead of 1 week. It’s quite frustrating when all I really want to do is get back to work on the game itself.

So the game itself. Why is the basic game not finalized after nearly 3 years of work? Basically, it’s costly to iterate on a complex game.

The initial goal here was to build a system that could support the basic idea of the game we wanted to make and to then tweak it to make it better. Along the way I deliberately overbuilt portions of it to be able to handle common RPG mechanics that we might or might not need. At the same time I underbuilt other portions of it since time was at a premium. This system probably took about 1.5-2 years of production to become stable enough to really build sample content for and to test thoroughly.

Under the lofty ideals of iteration as king we should have then proceeded to rapidly tweak the game into a better state. But even with a solid foundation in place, I found the larger changes I wanted to make taking months to add because the original system was in no way built for them. In a game with a small central concept you can with rebuild the central mechanic again and again with relative ease. Say you wanted to make the perfect player movement in a platformer. Player movement isn’t an expensive thing to build over and over again, especially if what it interacts with doesn’t exist yet. This, as it turns out, isn’t so much the case when you’re already hauling around the rest of the game on your back. This is largely on me for building the entire game before iterating, but it’s also on our genre for relying on interactions between many things for the “game” to really start to exist.

I think I adapted to this fairly well. After the first changes being very high cost, I built newer versions of the map system in a direction where I could experiment with lots of things for a fairly low cost. It’s very unlikely that I’m going to shift from that fundamental system now, but I also haven’t completely figured out what really works with it yet. The battle system meanwhile was overbuilt to begin with and has been cheaper to iterate on.

There’s something Sew has asked me again and again the last year or so: “what is the game any more?”. The more I’ve tweaked the game in an increasingly complicated and mangled direction, the more I’ve lost him. There’s a method to the madness, and for every failure along the way I’m getting closer to what I’m looking for. You’ll just have to trust me on that.

I’ve done two approaches to making games in my life. The first one is creating a design doc and then building just that and fixing it in post. Very efficient for simultaneous team work, though it can lead you right off a cliff if you were wrong. The second one is building a core idea that you’re happy with and then continuing to build more and more around it until you run out of ideas. Not a technique I’ve had the opportunity to use much since it’s hard for teams, but it was probably the funnest to work with and led to the most reliable results. I had hoped to use the second technique for this game, but finding that first step has been a doozy.


July 13th, 2014

This week was a matter of closing the last flaw in the design of the new scene system. In short I originally designed it around every parent node having its own set size, rather than having them expand to fill their children. This was workable but had various drawbacks once I started actually working with it. So the big change was the capacity to set parent node sizes based upon the size of their child layout. Since the system wasn’t designed for this there were numerous problems.

It’s all in now and working fine, if a little sketchy from not being designed for it. Most the week was spent on it. Implementing it wasn’t so bad, it was just a long series of new problems needing solutions cropping up the further I went into it. I don’t feel great about this time allocation. Next up is deciding whether to finish the remaining UI widgets or to convert the rest of the game to the new system. I’d personally prefer doing the conversion first so I can take a break on the UI and start testing out the new gameplay ideas. But it’s a risky choice if UI widgets end up requiring changing something fundamental. I’ll probably do it anyway since I’m sick to death of UI at this point, and anything requiring massive changes seems unlikely.

Meanwhile recent AMD drivers broke part of the game’s visuals and I am currently in a waiting game of deciding whether AMD, the library we use for rendering, or myself will end up fixing it. I’m guessing it won’t be AMD, but the game is far enough away that I can afford to wait and see.

July 6th, 2014

Scrolling is done, it took longer than expected (largely due to being the first real production test on the event system and other such things), so on and so forth. Nothing to talk about this week! Probably not next week either.