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!

Day 315: How not to use Mass Distribution

The next big thing on my plate was to create the various cargos that the player could buy and sell. This was aided by the fact that I'd already diagrammed out how much I wanted the low,high,and medium versions of those cargos to cost.

I started with 'Food'. It's cheap on Earth because of the lots of landmass. So I created a cheap version of food, and moved on.

It then occurred to me that this was going to take /forever/. I'd have to create 3 states for each of the different cargos I wanted to sell (and as of now there are 6). Also there'd be no consistency between prices. A low 'food' price could be half the price of medium food, while low specimens might end up half a buck off.

"Wouldn't it be nice", I thought, "To be able to automate this in the editor somehow?"

Yes, yes it would. And since I'm the guy who wrote the editor, I did it. There are now 'auto low', 'auto medium', and 'auto high' buttons in the cargo editor, which set the values and names of the cargo to 15% lower, the same, or 15% higher than the base price, respectively.

This would still require me to create all 18 cargos. Wouldn't it be nice, I thought, if when you create a cargo blueprint it automatically created the low/med/hi versions of itself?

Yes, yes it would. And so again, I did it.

Here's where my brilliant plan fell down. The planets hadn't been tagged for specific cargo. So while a number of planets shared the feature that their food was cheap, I hadn't tagged them to take advantage of that and use the MD system to do all of this at once. I had two alternatives:

1. Go through all the planets and re-tag them


2. Go through all the planets and just add all the cargo I wanted

As these were equivalently labor intensive, I did the second. That's when I ran into another problem: When the cargos are automatically created as outlined above, they're just tossed into the repository. The repository stores everything in a gigantic dictionary, which of course means they're unsorted. So I still end up looking at a list of 18 different cargo items, all in arbitrary order.

Wouldn't it be nice, I thought, if those were sorted?

Yes, yes it would be. Done!

I again reiterate that, as frustrated as I've been in the past by editors for other games, it's enormously liberating to actually be able to do something about it :)

Day 309: Mass Distribution

The Mass Distribution (or, as I shall refer to it from now on because I'm already tired of typing the whole thing, 'MD') system took me a few days, and then it was done.

To recap: The idea behind MD was that I could label objects (say, sectors) in a certain way, and then distribute objects (say, fleets) to aforementioned sectors. So if I'd created a trading fleet, I could put it in every inhabited sector at once rather than one-by-one going through each sector and adding the fleet manually.

The only thing this really required was some GUI work (the actual adding of the objects was, as it turns out, ridiculously easy), but it required something I hadn't created before: Namely, a way to find any object in the entire universe. Thus was born:


THE OMNICHOOSER

On the top-left, all the model classes in the game. When selected, the results show every object of that type. The top-right features every label in the game, and when it's chosen it'll show every object with any of the selected labels. When both are active, it shows all objects with any of the selected labels of the given type. For my example above, I picked "KuiFleet" and "traders" to get the trading fleet I'd just mentioned. There's another one of these for the 'destination' objects (i.e. all the sectors in the universe) - there I chose "KuiSector" and "inhabited". A few button clicks later and I'd placed 20-some-odd fleets.

What this means is that I'm likely to return to creating actual content soon. I haven't kept the blog updated because I've been doing the same thing every day ("Look, listboxes are broken! Look, the OmniChooser is broken! Look, both are broken at once!") but hopefully now the MD will speed everything up and I'll have more to say.

Day 302: RTFS

I finished Phase II of the great XML change yesterday. I would have posted then, but there was testing to be done to make sure it was Actually Fixed This Time, Dammit. I'm discouraged by the number of bugs that this change uncovered in my code - that is, not bugs in the new code I wrote, but code I wrote months ago and has been working fine since. This includes bugs of the "How did this ever work in the first place?" variety.

But that's all fixed, at least until I discover the bugs in this code a few months from now.

I've been trying to use XSLT as my patch tool of choice, and so far so good. Only I found a bug where it wouldn't preserve linefeeds in attributes, which was important because a lot of my descriptions ended up being like this:

<sector name="foo" description="Name.

  Here is some other stuff about this
sector.  That linefeed's important
because I don't want to go back and
manually put linefeeds where they
should have been."/>

No problem, I think, because I'm still somewhat new to the XSLT scene there's probably something I missed. Hours of all the whitespace-preserving options I can find, and no luck. Finally, I find the answer.

The coding gurus of Stackoverflow were the lucky ones to inform me: It's not a bug. Not preserving whitespace in the attributes is actually part of the XML Spec.

The only way I got away with it for as long as I did was because Ruby's XML parser was ignoring this fact. So I wrote a ruby script to do the transformation. I felt somewhat relieved that it wasn't actually my fault things weren't working out, there was a bug in REXML. Then I realized that, if I hadn't broken the spec to begin with, I wouldn't be in this mess.

Thus the Programming Tip of the Day: Even when it's not your fault, it's probably your fault.

Day 294: NaGaFiMo

It's National Game Finishing Month!

My next big part of the game to do is mess with the XML some more - specifically, making it look sane as I advocated a few entries ago. But that would require me to muck with XML again and after the nightmare it was last time, I declined to do so.

Instead, I closed out some old improvements I'd been meaning to do for a while:

• Ownership: The player will now see what faction his/her target belongs to.


• Fuel Regeneration: By default, fuel will now (extremely) slowly regenerate now. So if you're stuck out in the middle of nowhere with no fuel, you can just wait. It'd probably still be faster to save your game and change your ship's 'fuel' value in the XML, but now people less inclined toward cheating can continue to play.


• Description Comments: Sometimes I want to remember something about a planet or sector, i.e. "This is the place where Act I ends". There's no place for comments, so instead of taking the easy route and making a do-nothing 'comments' field, I made it so any string surrounded by /* ... */ would not appear if the game wasn't in edit mode. Instant comments!

I've got to get to that XML at some point, though....