Okay, I’ll admit that I didn’t get straight to coding after I posted my outline for Alpha 1.0. That’s because, at the time, it was nearing the end of the school year and teachers were doing their very best to cram as much busywork as they could possibly into that last month and a half. Now, however, the school year is over, and I’ve got no shortage of free time–some of which has been spent working on Shipyard.

If you read–or even skimmed–my rambling, essay-length outline, you’ll know there’s a lot to get done before Shipyard is ready to go into alpha. So, I figured I’d start at the top with free-form systems. Before I wrote the first line of code, it took a lot of thinking and scratch work to figure out how I was going to implement it. I’ll spare you the details, but suffice it to say it took a several sketches in Paint.net and a considerable amount of math to nail down. Once that was done, I was ready to start coding. The first system to get the free-form makeover was the humble corridor. While not the most exciting system in the game, it is the simplest, which made it a good starting point to get the concept locked in.

Here’s a short video demonstration of the new free-form corridors:

So how do free-form systems work? Well, I’m glad you asked! Behind the scenes, free-form systems are actually discrete 1-by-1 systems, which change only in appearance when placed next to neighbors of the same type. This is especially easy for corridors, which have no stats, no hitpoints, and no crew or power requirement.

But what about systems that do have a crew and power requirement? Nobody wants to individually allocate one crew member or power unit to thirty separate tiles of the same system! The solution: tie crew and power to types of systems rather than individual tiles. Once implemented, this means you only have to allocate crew to weapons, engines, etc. in general, and the game will handle the rest.

Well, that’s it for today! Check back soon, because I plan to be doing a lot of work on the game this summer.