So, I Got a Little Lost

Posted on July 9, 2014 in Dev Journal: Omesa | 0 Comments

I had a vacation last week. It was a golden opportunity, with scads of unfettered development time. I holed up in the library with snacks and drinks, buckled down, and got hellbent to get as close as possible to alpha.

Three days later, I found myself tangled in a proverbial mess of wires and sparks, wondering where the hell I went wrong and why alpha wasn't coming together more naturally. After taking some time to reflect, it became painfully obvious to me what happened - I had no idea what the hell I was actually building. So far, I've been creating features and functionality based on need, and based on an intuitive sense of how the game should grow. People lovingly refer to this as organic development - and it works sometimes, but Omesa has finally reached a degree of size and complexity where intuition isn't enough to stand on. I really should have seen it coming before now, but I fell right into the trap.

"But CodeMoose, if you knew organic development is bad, why did you keep doing it?" In short: it's easier. It's a very tempting mindset as a coder to plan things as you build them. For smaller projects and widgets, it's a really efficient way to build - code what makes sense, and if you back yourself into a corner it's a small matter to change direction. For larger and more sophisticated projects, though, this becomes a lot more difficult and chaotic - the deeper the project goes, the harder it is to backpedal if you make an error in judgement (and you're going to make an error in judgement at some point). There's no clear line at which organic development should stop in favor of rigor and structure - it's just up to common sense, and I haven't done enough large projects to refine that sense yet.

I've taken a couple days to decompress, and Omesa's direction is now clear - we're not going to achieve alpha without some more solid concepting, namely for the battle system. I'm sorry I don't have solid progress to report, but this won't take nearly as long as last time; I'll be back in a few days with some concept art, if not more prototype screenshots!

Cheers!

0 Comments »

Halfway Update - Battles

Posted on June 18, 2014 in Dev Journal: Omesa | 1 Comment

The train is rolling! We're a good amount of the way through the development needed to reach Alpha. This gif is a preview of the battle launch and interface - it may not look like much of a change, but a lot of work has gone into this since the last update. (I realize it might be a bit annoying - don't worry, it only loops 3 times).

In terms of architecture, the Battle screen is the Yang to the Map screen's Yin. They are counterpart and deeply intermixed, but two separate entities. You can't just toss a sheet of paper over the Map and draw a battle scene on it - the Map layout and interaction have to be disabled in such a way that it can be re-enabled in the exact same state, and a Battle scene has to be created without interfering with that. Otherwise you need to re-request and re-draw the map after each battle, and, well... let's just say it gets ugly. But, it's already working! A few weeks ago we barely had a sliding cube - we're already seeing signs that it's someday going to be an honest-to-goodness RPG!

(For those of you wondering, the two Titans in the demo are our alpha beasts - BatPug and a green ogre thing. I just call him Grogre.)

I'm dying to get battles to a stable point - it's the largest obstacle in the way until Alpha. Building the battle system means setting up mechanisms for Titan stat manipulation, experience/leveling up, and stat persistence (eg damage carries from battle to battle). It also means setting up hooks so we can build inventory, moves and attributes, capturing, evolution, and all kinds of other goodies down the road. In short, when battles are done, we'll have a huge head start on everything else that hasn't been built yet.

I wanted to do this halfway update because there are some back-end workings that need to fall into place before anything else can progress. The next couple weeks stand to be more abstract gruntwork and less visible change, and I don't want to hold back on posting visible progress when it's made. So, worry not - progress continues in a mighty way!

Development Completed:

  • Meshing Battle canvas with Map canvas (play nice, children)
  • Additional dispatcher API for battle setup information
  • Adapting Map Gui into separate utility class - Battle and Map now both use Gui to create windows and interface elements
  • Wireframe battle timeline - choice vs execution phases

Remaining Alpha Goals

  • Titan persistence (every hero needs a party)
  • Battle timeline management - menu interface, dispatcher API for timeline response, party and enemy hit animations and scheduling
  • End-battle execution - message, experience, rewards
  • Basic Map pause menu functions
  • Debugging Map Gui dialogues (they broke a bit when Gui became a utility class)
  • Map-state modification - completing a battle changes map state

1 Comment »

To Grunt or Not to Grunt

Posted on June 13, 2014 in Tools of the Trade | 1 Comment

grunt

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.

1 Comment »