I took some time off over the fall/winter to focus on work and family, and I'm glad I did - things got really busy. I didn't even notice that this site was broken for months. Now that I have free time in my life again, I've patched the holes in DG's digital roof and am chomping at the bit to get back into game dev.
That's the good news - I'm back. The bad news is, in the time that I've been gone, the Kinetic canvas library was retired. This is the workhorse that was powering Omesa, and I mourn its loss.
I find myself faced with a choice; keep using Kinetic, or find a new foundational library and discard the bulk of the work I've done so far. The latest Kinetic build has some known bugs, but it's still stable enough that the game can stand on it for some time to come. On the flip side, sticking with Kinetic is riding a train heading for a cliff. Even if the cliff is potentially hundreds of miles away, we're going to have to jump at some point - and the more intricate Omesa becomes, the more work it's going to be to transition it to a new library.
Considering that and some new-to-me technologies that I've been working with at my place of employment, I'm opting to start over with something new. It hurts to lose a lot of the progress I've made so far, but looking back at some of the homebrewed code I wrote to control the game, it's also a relief to have a chance to redo some things. In particular, I've been treating the game as one poorly-defined view with a bunch of muddy, incestuous states that all attempt to track each other. I want to build up Omesa using Backbone, which should make things much more clean and modular, and discard about of 1/3 of the state-management code I wrote myself.
Can't promise weekly updates or anything like that - but I'll post progress when it's exciting enough to talk about!
I love my day job - I could spend a day just listing the reasons why. Today, it's because of the technologies and tools I get exposed to.
Grunt is one such technology. It's a very slick environment wrapper and automator - taking common build functions (less/sass compilation, beautify, uglify, minify, and jslint to name a few), and executing them with as little effort as possible. It even encapsulates your environment config into a Gruntfile, which any other Grunt instance can then use to manage your project. Sure, there are other entities that accomplish this (Codekit being a favorite), but Grunt is powered by Node.js, so it's platform-agnostic - which means when I hand my build to a PC guy, they already have access to all the build functions they need. This is the webdev geek's elevator pitch - you should check out their website if you want a more comprehensive overview.
The upside and downside to Grunt is it's very robust, and like most robust entities it's overkill/overcomplicating for smaller projects. I try to bring home anything that would be useful to DG projects - and this certainly qualifies - but for Omesa it makes sense to wait until later development stages. Just the crossover alone could possibly take a weekend, since I'm relatively new to it and there are literally thousands of build plug-ins to choose from. On top of that, the benefits gained are currently meaningless - we don't have multiple developers among which to set a standard, nor do we currently have a reason to make assets production-ready. Git and Codekit do a great job managing the things we currently need to automate, which means I get to focus on raw, lightweight development - and I like it that way.
While we won't be using it here yet, you can be sure that Grunt will be seeing its way into our pipeline someday. After all, Mooses were made to Grunt.
Well, here it is! This is my blog.
Well, not really a blog... more of a development journal. My name is CodeMoose, I build games and tools as a hobby - and for better or for worse, I'll be chronicling my projects here. I've been finding that I have a tendency to get distracted in my development, going after the shiniest rock in front of me. I've come to realize that I have two or three important games that I'm really excited to bring to the public, and that's all I need to focus on. That's partly what this blog is here for: to help me focus.
I'm hoping that maintaining this blog will be a powerful asset in a lot of ways. For one, it will show me exactly when I last made an update to a project, so I can keep track of what's getting neglected. You'd be surprised how easy it is to say "Has it really been a month since I worked on that...?" Two, it will provide tangible evidence when I'm getting off-track - as in, "holy crap, why do I have seven things in open development right now!?". Three, it will be a good reminder of why I started making some of these games in the first place. If you've done any development (or art for that matter), you know it's easy to get lost and overwhelmed in nuance, to lose sight of the idea that ignited the project. Keeping a log of everything is a great way to keep the big picture in focus - to remind you that the details are minuscule, and that tree you planted is part of a forest.
"Well, that's all fine and good Mr. CodeMoose, but why am I even here? So far this blog is all about you." Well, that's the best part! You're the reason I'm developing, and you're the second half of this equation. Sure, this blog is a great way to keep tabs on games you'd be interested in - but I have no reason to build a game or tell a story if there's noone around to enjoy it. I want to make games you're excited about - I want your input, your feedback, your comments and criticism. I want to know what features you love or hate, and I want to know if any projects aren't worth continuing. These games are about YOU - the more input you give, the more refined the games become. Be generous with your comments, and most importantly, be blunt.
All in all, I'm very excited to see where this goes. I'll be posting a few new project categories and a state-of-the-project post for each - so keep a sharp eye out, and please feel free to add your input!
Welcome, and watch your step; Moose Crossing.