Year 1

Today is the first day of the new year.

If you're browsing any of the open-source game websites out there, you've no doubt noticed that my game is not on them. Nor is it just pending; sadly, I missed my goal for last year, which was to actually finish this game.

For a recap of what happened, see my postmortem - nothing's changed since then, except for the "this is doable" part. Obviously I missed that one :)

Still, the stats on the right show the story: As of right now 327 hours and over 27,000 lines of code. What I didn't really grasp when I started this last year was the fact that this game is huge! November really brought that into light, considering that given the effort I put in during just one month I could have finished an entire novel.

Where next? I'm not sure. The game is still fairly near to completion, so I'm confident I'll actually get it out this year given a similar amount of work. The question is: Do I want to put in that much work? As far as I see it, here's my options:

• Keep working on the game, an hour a day, until it's done. This is the option most likely to actually get something done, at the risk of burning myself out.


• Work on a different game: "All Kuiper, All the Time" gets very tiresome after a while. Especially over the last month, just contemplating working on the game was an unpleasant experience. Doing something completely different might help.


• Do something completely different: Go back to writing novels and gaming, programming on the side. Essentially this is the eclectic blend of stuff I was doing before I sat down and made a schedule for myself. The upside being that it's far more relaxing, the downside being that nothing ever actually gets done.

Obviously, I'm leaning toward the second option, or maybe even the first with a somewhat relaxed schedule.

Day 332: Hindsight

In retrospect, it would have been a good idea to make the "have you completed this mission" system a little more unit-test friendly. More on that in a moment.

Every fleet the game is going to have for part I is done. You may have noticed how I keep talking about parts of the game and whatnot. Why is this? Well, the plot's in three parts. How will the player know? That's the other major ticket I completed today: Banner states. Simply put, this scrolls things (probably words) upward so the player can read them, so I can now create all the "PART II: The Revenge" scrolling goodness I want. I've already implemented the game's credits screen this way.

I also started making the random missions for my game. In any coding project, I'm always a bit wary of returning to some functionality I haven't used in a while, for fear it'd broken somehow in the meanwhile. As superstitious as this sounds, it happened to be the truth this time around: My junk was broke. Some of this was changes I'd made in the meantime, and some of it was the fact that parts never worked correctly in the first place.

For instance, random missions. My testing of this involved generating one and then flying around and making sure it worked. That was fine. What I neglected to do Way Back When I first made the functionality was test it any further. It turns out, when a random mission generator makes more than one mission, it tacked on the conditions for every other mission it generates. Oops.

Day 325: Label Randomly

Yesterday I took a well-deserved rest.

Today I figured I'd take an easy ticket, the one whereby I make random missions accept labels. As though welcoming me back to coding my game, this was far more difficult than I'd wanted it to be.

The first step was to adapt the KuiAtCondition to also respond to labels. As it is, you give it a list of destinations (either planets, organizations, or sectors) and if the player is there, it passes. It seemed simple to extend this for labels....

It's never easy.

For one, only the root KuiObject knows how to handle labels, and I'd hardcoded that in. My choices were: Refactor labeling out to a more generic module, or copy and paste the code. For once, I did the responsible thing and refactored. It took an hour!

The refactoring turned out to be worthwhile, as it happened. I needed to do similar label handling in at least two other places later, so as usual, it paid for itself.

Still, it's never easy!

Day 323: Game Over

Today marks the last day of National Game Finishing Month. I closed five tickets today, mostly content-related. Every ship that's in part1 of the game is now created. Every weapon that's in the game entirely is done. Even helpful standard addons have been made.

In conclusion, of the list I made yesterday, half of the items are now done. So now, the NaGaFiMo postmortem!

• What went right
  
  
  
  1. Effort The spirit of this exercise was to devote my Nanowrimo time to the game. I've done more than that - as of today, I'm nearly 4.5 hours ahead of schedule. If it were a novel, it'd be done by now.
  
  
  2. Learning While I won't say that I haven't learned anything from the rest of the programming I've done, I've definitely learned more this month. Specifically, I had to create new art via Blender, which I knew how to do long ago but have since forgotten. Making art is definitely out of my comfort zone, but I learned quite a bit.
  
  
  3. Atomic Coding The linked article talks about the practice with Subversion, but I've found it even more effective using git. Having a local repository lets you commit nearly everything once you've made the smallest workable change, yet not embarrass yourself by pushing out to the remote (public!) repository.
  
  
  
  


• What Went Wrong
  
  
  
  1. It's Not Done! The goal of this was to actually have the game finished by now. That didn't happen, but given that I actually put in all the work, I count this as a failure of estimation rather than of effort.
  
  
  2. Learning Yes, that was above on the 'what went right' portion. The downside to learning how to use a tool like Blender is that I had to take time away from the rest of the project in order to do it. If I'd already known blender or already done all this, I'd have ended up a lot closer to the original goal.
  
  
  3. Going Dark Though I updated the blog when I was done with major features, I didn't update daily. As I've found the blog to be useful in the past, I'd like to keep it up.
  
  
  
  


• What I learned
  
  
  
  1. This is Doable This particular schedule works for me. I initially thought 1.5 hours a day might be somewhat difficult, but though not easy, it is at least workable.
  
  
  2. Get it Done Rather than putting off seemingly unrelated work until it absolutely must be done, it's probably better to learn these things when it won't interfere with big goals
  
  
  3. People Might Actually Play This I've had a number of requests for the demo, which while being exceedingly out of date is still a reasonable facsimile of how the game plays. My novels have had only a few token readers, with the vast majority of people who inquire not bothering to actually read them. Everyone who asked for the demo has played it however, making me think that I may have better luck!
  
  
  
  

Day 322: The End is Nigh

National Game Finishing Month is nearly over. Tomorrow I plan to do a marathon of getting stuff into the system then blog resignedly about it. Today, however, was all work.

Specifically, I animated the rest of the ships. Then I created the standard ones in-game, and used Mass Distribution to push them out to every standard planet in the galaxy.

High profile things left to do:

• Random Missions should use labels: The mission system in general could use an overhaul to use the labels, too. It'd be handy for an "are we there yet" check to include "anywhere with this label" as a satisfying condition.


• Fleets: Once I have the ships done, I need to put the patrols, pirates, traders, visitors, etc, in their place so they'll show up in the sectors they're supposed to.


• Alliance/Rebel weaponry: The war-fighters should have better weapons than you as a regular pilot should get (but you can get them later, when you join)


• Alliance Ships: The alliance has three ships specific to them.


• Rebel Ships: Likewise, the rebellion also has ships just for themselves.


• Standard Addons: I don't think I'll have faction-specific addons unless I really get inspired.


• Random Missions: These are essentially the filler of the game.


• Scientist Scout Missions: This is the essense of the plot for the entire game, right here.


• Alliance/Rebel Scout Missions: The only thing close to a major sidequest, this is the initial alliance/rebel war.

Day 319: Blockified

Every single time I do graphics for anything, I have to re-teach myself Blender, which I'm actually somewhat decent at. It turns out my wife has an eye for what would make spaceships look even better, so I've created quite a few. I should now have every ship I need.

I rendered all 36 frames of one of the ships before remembering that I had no way to change the 36 individual .png files into the one giant .png file that the engine could handle. I've written this script easily twice before (once for TraderMissions, and once more for a pyweek competition). But I couldn't locate the first script, and the second one wasn't suited to my current engine. So I had to, once again, write the script.

It was an easy task, for once. blockify.rb is a pretty brittle utility without a lot of other uses, but it gets the job done and hopefully I won't have to re-write it next time I need it!

Day 316: Weapons of Ordinary Destruction

I fixed an important bug today: In the old system, changing an object's tag after it had been created was a bad idea. The game would simply crash upon reloading, if not sooner. The new system exchanged this fatal bug for a more subtle one: Re-naming caused duplicates to exist in the repository (the old name stuck around).

This sounds trivial to fix - just see if there's an old tag and delete it. However, objects which are duplicated (like, say, weapons) always have the old tag of the object they were created from. So any new weapons were destroying the old instances.

But can't I check to see if they're being duped? Yes, I can - now. Most of my coding work today was enabling exactly that. So now you can change an object's tag, and unless you change it from object_thing to object_thing:4490, you're fine.

Hint: Don't do that.

Finally, I created every weapon I wanted to be available to the player at the start of the game, and distributed them to all the planets where I wanted them to be available.

Unfortunately, I used up all of the weapon art I had in TraderMissions, thus meaning I'm going to have to create new stuff soon. Re-learning Blender, ahoy!