Choosing a great side project
August was a pretty busy month for me, mainly because I spent it working on an amazing side project.
By the end of the summer most of my really good friends will be spread across the country (graduating college tends to do that). Frankly, it sucks, and I was wracking my brain for the perfect sendoff before real life takes over. My brother and I also wanted to plan something big for his birthday, because why not?
So we hatched a crazy scheme: we’re going to turn Kerbal Space Program into a Co-Op game. How? By stealing from Artemis’ playbook: turn it into a mission control. Everyone in mission control has a specific station and coordinates to tell the pilot (who’s in another room) what to do. How hard could it be?
“Mission Control parties” for Kerbal Space Program aren’t a new idea, but we wanted ours to straddle the line between challenging and fun. Artemis abstracts away the heavy lifting of running a starship bridge while still giving you the exhilarating feeling of working as a team to pull off the impossible.
To do the same for KSP, I had to build an entirely new UI for Telemachus, a telemetry mod for Kerbal Space Program. It’s called Houston, and you should check it out!
Did it pay off?
So we didn't land on a moon, but we did dock with an orbiting station! 😄 everyone had a great time & loved Houston! pic.twitter.com/dokr1duWYy
— Thomas Cannon (@tcannonfodder) August 23, 2015
Sure, we didn’t reach a moon, but so many other great things happened! There’s nothing like debating maneuver nodes for a rendezvous or conversations like this:
Pilot: CAPCOM, what’s our next maneuver?
CAPCOM: Pilot, one second; FIDO?
FIDO: Okay, we need to adjust the orbital plane to match the inclination of…
SCIENCE: Right, target inclination is 0.673 degrees.
FIDO: We’re at .2 degrees now, so it’s a short burn. Next ascending node’s in approximately 10 minutes.
CAPCOM: Affirmative, BOOST what do you recommend?
BOOST: Hrmm… let’s say burn at 25% for 15 seconds, see how that turns out.
CAPCOM: Pilot, you get that?
Pilot: Roger.
CAPCOM: Awesome, turn the ship to face normal and we’ll burn after we warp a bit.
Not to mention brewing coffee at 10PM to make up for jokes about CAPCOM’s planning abilities, or how Mission Control was on the edge of its seats when the pilot was misaligned with the docking port and couldn’t see it.
Oh, and the coolest party favors ever (credit where credit’s due, it was my parents idea):
When we decided to wrap it up, everyone asked:
Sooo… when are we doing this again?
We immediately started planning another mission for October via Skype, which adds some interesting wrinkles. Heck, I’ve even grown Houston a bit: I fixed a few bugs, designed some icons, and it’s now Twitter-official
I’m usually pretty bad with side projects: they tend to fizzle out or I stress myself out of the enjoyment. I think Houston’s different because of how I approached it from the start.
Actively avoid expectations
I’ve made some key decisions about how I’m working on Houston to keep it fun. Mainly, there are no expectations about what I’ll work on, or when; and it will never be remotely perfect.
I briefly debated accepting donations for Houston. But one of the reasons I love working on it is that there are no obligations. It’s an interesting problem I can tackle whenever I find time. Houston’s 100% free, so if I can’t touch if for a year no one’s being gypped. It becomes a “business” once I start accepting money, and I take business pretty seriously.
Pick something fun
Building something for my brother’s birthday party that brought some of closest friends together again was extremely rewarding. And I focused my efforts on things I would never do normally: deciding to go all-out on a skeuomorphic design, researching real mission control centers, designing station UIs from piles of raw data, and diving into the deep pool of orbital mechanics. Working on Houston was all about doing something fun for great people.
I got to put on a lot of hats and play pretend for a bit: UI designer, physicist, project manager, mission controller, and mad scientist. And at its core, its downright silly. All this time and effort poured into a mod for another mod, for a videogame about launching rockets with little green men.
Seriously, embrace imperfection
Because there are no expectations with Houston, I’m totally okay with the myriad of bugs and imperfections. There’s no pressure for me to actually fix them: No one’s going to be hurt, and no one’s paid a dime for it.
I didn’t even bother checking how Houston looks on a tablet. I knew everyone would be using a laptop for the party, so that’s what I focused on. Heck, I couldn’t even be bothered to check browser compatibility for the same reason. Cardinal sins in today’s hyper-responsible mobile browser-agnostic landscape? Sure, but it’s a side project.
Heck, all the bugs and issues make Houston more authentic. Kerbal Space Program’s all about embracing failure and strapping solid rocket boosters onto something until it explodes, so a few bugs and rough edges are right at home. Plus, it let me be more playful in the README:
Houston has a ton of really cool features, some of which work!
- A ground track, for plotting the path of a ship in orbit
- An altitude estimate for said ground track (heavy emphasis on “estimate”)
- Readouts for the stock resource types in KSP
- Status light indicators
- A 3D navball (huuge thanks to Lokaltog/KeRD for an awesome implementation)
- Throttle and Atmosphere gauges
- Position Maps
- A Hohmann Transfer tool (not guaranteed to properly transfer you as per Hohmann’s specifications)
- Links to the Telemachus Console and MKON
- Data Tables, whoooo!
Avoid your actual job
A side project’s a lot more rewarding if it’s only tangentially related (at best) to your day-to-day work. It’s freeing to tackle an entirely new set of problems. A “side project” that’s actually part of your job that you’ve opened-sourced and support is just that. You don’t have to do your job 24/7, and I’m tired of real work disguised as “side projects” being a career expectation.
Houston involves HTML, CSS, and Javascript; yes. But writing Noko doesn’t involve complex orbital math (yet), building a near-realtime UI, or planning how to stuff 5 people into a living room so they can concentrate. I used entirely different parts of my skillset, which made it exhilarating.
It rebuilds your foundation
Stepping outside your comfort zone is a good way to relearn a bunch of skills that got you to where you are in the first place.
Simultaneously taking physics and calculus as a college freshman prepared me for dealing with compiler nonsense in later compsci classes. By the time I encountered a mile-long gcc
error log I was already familiar with being in waaay over my head and finding the right rabbit hole to get the job done. Relearning orbital mechanics forced me to use those skills again, and I found they’d gotten a little rusty.
Deciding to take the plunge on building Houston from the ground up this went sort of like this:
“Man, I used to be really good at BSing my way through complex math. I miss that.”
If you’ve got skills you want to sharpen, try to find a tiny side project that’s laser-focused on them. ☺️
You surprisingly learn some stuff along the way
By the end, I did learn some stuff that will pay off in my day-to-day job:
- nanoc has partials, which is super useful!
- I got better at writing a bunch of semi-maintainable javascript really quickly.
- I have a better handle on how browsers handle animating and repainting. Houston’s UI requires a lot of near-realtime updates, so I had to tackle some nasty performance issues towards the end.
- “Orbital math is hard, but not impossible. I’ve done that, so I can probably tackle this.”
- Sketch is a pretty great tool, albeit prone to crashes
What’s next?
Well, I’ll probably keep tweaking it when I get the itch. Plus, I’ve got a new party to plan! Like any good side project, I’m happy with what I’ve done already and comfortable with letting it rest for a while.