Day 232: Re-re-port

It's been a while since I blogged but unlike last time that happened, I've actually been busy in the meantime. Here's what I've been up to:

• Ported everything to new-style events. This was fairly easy and straightforward


• The player can now give their pilot a name. Eventually this will be rolled into savegames, so you can have more than one pilot per module


• I fixed a Rubygame bug where if your application was minimized and lost focus at the same time, it'd crash.


• A freaking ton of map work! I have to say that creating maps is a lot easier with an editor. Coming up with ideas for a ton of sectors, however, remains difficult. I made the mistake of giving my initial generic filler sector a description, and so now have to go out of my way to explain how boring the other dozen filler sectors are.

The map descriptions I've written already depict a lot of lore pre-game. There was a time where humanity didn't know hyperspace lanes could go to empty sectors, for instance. After that, the Sandwall spurred the invention of shielding. There was an alien invasion scare at some point. All these are completely divorced from the plot, just things I've come up with as I made the map.

I was asking myself the question: Should I write this down somewhere so I remember it? Then it occurred to me: I just did!

Day 228: Demo!

So today I fixed a bug. It was less a bug and something I didn't realize was missing. I mis-clicked while making the map for the new scenario, and ended up creating a sector I didn't need. That's when I realized the map editor didn't have a 'delete' button!

What an accomplishment! I'm totally spent.

Oh, yeah, and I made a demo.

DEMO!!!!!!!!!!

That's right! I loaded Fedora 9 onto my VM and tested the file I just linked to right there. On a pristine Fedora 9 load, it works with no issues. It also runs on Ubuntu! It even runs on both at the same time! On the VMs it chugged down a bit during the combat, which says to me that I've still got more optimization to do, but it may also have been due to the fact that I was running it on a VM while I was also running it on another VM.

That link may not be permanent. It's my home server, so be gentle :)

Day 227: Execute!

My current build does not work with the current Rubygame/dev-2.4 branch due to one of my patches having not yet made its way in. It'll die the moment an AI-controlled ship attempts to figure out how to move. This will hopefully change soon.

This should hopefully not matter; the demo itself is looking even more likely to come out this week. Rubyscript2exe is everything I'd ever hoped for and more! Mainly because it will use whatever libraries I have on my system, including my already-patched version of Rubygame. I unintstalled Rubygame from my system entirely, as a matter of fact, and the executable still ran. I'm waiting until I can get it to run on a pristine Fedora VM, and then I'm releasing the demo to you, the public.

Rake can now make .tgz files out of the entire distribution (actually, it could always do that, but I only just figured out how today). This makes my life even easier, because it means I can use rake to build the executable and then put it in a .tgz file for distribution in one step!

Finally, it turns out that Rubygame 2.4, which I'm now targeting as I can't live without my mousewheel support, has the new event classes that will one day be part of 3.0 and which I just finished moving all my code away from. Luckily, I knew I'd have to switch back and made a giant list a few posts ago about what I changed. And I did, in fact, tag the last commit before changing over in git, so a (very) careful merge may turn out to be the easy answer.

Then again, I seem to remember that it's never easy!

Day 226: The Coming Storm

Instead of doing all that releasey stuff I mentioned yesterday, I instead started creating the map for the module I intend to include with the game when it ships.

It was yesterday, actually, that I started writing up the outline, and three hours later it was included; those who don't want the plot spoiled for them should avoid poking around too deeply in the Github repository.

Oh, did I mention? Kuiper's on Github now. It's nice having a backup of my work that's not just another machine in my house. Right now if you want to play the game, you'll have to use Rubygame's 2.4-dev branch, and to be perfectly honest I haven't exactly tried downloading it and integrating with it. That's a task for Soon(tm).

Anyway, the point of the post is that the new module is called, creatively enough, "The Coming Storm". The short description is:

Humanity is alone among the stars and, as always when humanity has only itself to deal with, war is constant. An inner circle of systems are allied against separatist rebels who seek their independence. It would be a tale told a thousand times, if there were not much worse in store....

Yeah? Seemed like I was going to go with a typical empire vs. rebels thing there, but then I promised it totally wouldn't go down that way! Remember that when you're playing Part I and being all like "This is a typical empire vs. rebels thing!"

Day 225: More Returning

Getting back into the swing of things is difficult. Sundays are great for working on the game because I feel pressure to make something out of my weekend and time's running out; every other day... not so much.

That said, milestone:Tutorial is complete. Sometime soon, hopefully this week, I'm going to look at RubyScript2Exe, see if I can get it integrated into Rake, and have a 'preview' available. I've started to set up a few VirtualBox VMs for testing. Likely the preview release will be linux-only, unless I get very very inspired to build it on windows.

I'm at a critical juncture for this game, because it was right around exactly this point that I stopped developing for TraderMissions. The engine was there, I'd written a tutorial that worked perfectly, I was all ready to create my new universe, and then my enthusiasm for the project vanished entirely.

I'm hoping that won't happen this time. One of the big differences between TM and Kuiper is that Kuiper has a built-in editor. A lesson I learned from TM was that I don't especially enjoy creating content when I could be programming. Hopefully the editor will streamline these efforts for me.

While we're hoping, let's hope I continue working on this and you can all see a blog from me tomorrow!

Day 218: Re-port

Today's major task was to port Kuiper from the old 3.0 codebase to the currently developed Rubygame 2.4. This seems to have gone off without any problems, with the exception that I'd made a number of changes to the 3.0 codebase (mouse wheel support, etc) that hadn't been backported yet.

Well, I'm not a Rubygame developer for no reason, so I went and backported them myself. As alluded to earlier, I'm starting to use Git, and it turns out that you don't even have to be an official developer to make changes to Rubygame if you're going the Git route. Instead, you fork the github Rubygame project, make changes to that, and send a 'pull request' back. If you didn't understand any of what I just said, feel better knowing that I didn't really either. I'll have to wait and see if I did it right :)

So on that list, three of the four things I mentioned I wanted to do have mostly been done. I just need to make a little more balance for the tutorial, and then I'm doing a preview release!

The following are the notes I made to myself on the porting process, so later when I need to re-port the game to Rubygame 3.0, I remember what I had to change. You can safely ignore these:

• Had to change the screen portion of engine to use 'or's instead of an array


• Put support in 2.4 for key repeats


• Put support in 2.4 for mouse wheel


• Fixed bug in ftor new_from_to


• text.rb keyTyped used symbols, changed to Rubygame::K_*


• Options.rb, change symbols there to Rubygame::K_*


• Clock.wait uses milliseconds, Clock.tick returns milliseconds


• mouseUp in state used symbols, replace with Rubygame::*


• Change emergency hooks from syms to Rubygame::K_*


• Change unit tests to use constants instead of syms


• Map::update used syms for arrow-key movement

Day 217: Extended Rest

The subject is a reference to D&D 4th edition. A normal extended rest lasts about 6-8 hours. In my case, it was nearly two months!

But I have resumed. It turns out that optimizing code is fairly soul-crushing. The flipside of "Premature optimization is the root of all evil" is today's Programming Tip of the Day:

It's not premature optimization if it's actually time to optimize

But if you've been approaching development the entire time with the attitude that you don't need to optimize, it becomes quite an adjustment to go back to the problem parts and realize how horrible your code actually was.

I want to post this before midnight, so I'm not going to go into a lot of detail on the fixes. Most involved caching a value rather than recalculating it, something I know is faster but won't do unless the situation really calls for it, as I've been bitten in the ass before by out-of-date cache data. I replaced a linear search of an array that happened every frame with a dictionary lookup, which provided the expected results.

So on one hand, not optimizing early is a good idea. On the other hand, you have to pay for it later when the time comes. On the gripping hand, the code's so poor that I really had nowhere to go but up!