Defender's Quest 2 March Update

Alrighty! Time for an update on where we are in Defender's Quest 2.

Those of you who follow me on twitter know I've been active, but I sometimes forget that our followers are spread out over multiple channels - our forum, our steam page, our gog page, our newsletter/website, our blog, etc. So, I'm going to try to shift from my "ignore everything but twitter" mode that I've unconsciously slipped into. From now on I'll try to supplement my daily twitter spew with decently-sized blog posts from time to time, and then link to them in all our forums, etc.

What We've Been Doing

First of all, until very recently we've been finishing up the last bits of legacy support for the original Defender's Quest. Now, you might ask, "Why would you spend all that time supporting an old game when you have a shiny new sequel to work on?" Several reasons:

1. It builds up sustainable long-term revenue
2. Our strategy is to slowly build DQ2 preorders over time to avoid Kickstarter-style pressure.
3. Send a clear signal that we really do support our games long-term

We have been doing some DQ2 work in the last few months, of course, but it's mostly been pre-production and part-time engine work. Lots of game mechanics and design depend on the story, and we wanted to give James (our writer) the proper amount of time to go through several drafts.

Oh, and my wife and I had our first baby (as did Anthony and his wife) about 8 months ago. So that's been a little bit of a time-sink :)

All that said, we have gotten plenty of stuff done and have some things to show. Alpha and Beta are still a ways off, and the official final release date is "When It's Done."


First I'm going to talk about the DQ1 legacy support we've been working on, then I'll get to the DQ2 stuff.

DQ1 Stuff

Six languages!

 

The biggest thing we've done for DQ1 legacy support is add five foreign language packs -- German, Japanese, Czech, Korean, and Russian. We contracted Fabian Bindel and Thomas Faust for our German translation, and worked with PLAYISM, a Japanese PC games publisher, for our Japanese translation. The japanese version just recently launched on their site (english page here).

The Czech, Korean and Russian translations were generously provided by awesome fan volunteers. (The Czech translation was provided by our own forum superstar 'coyot', the Korean translation was done by Team.SM, and the Russian translation by a large group of fans). It was a lot of work to get all these translations working, particularly when it came to user interface and font stuff, but we've learned a lot from the experience, and thanks to all that, DQ2's localization process will be a lot smoother.

In fact, we've already written the framework and released it under MIT license on Github, behold -- FireTongue! Like the rest of DQ2, it's written in Haxe, and is already being used in other cross-platform games, like this one! It was even featured in a brief talk at this year's GDC localization summit.

SteamOS, bugs, etc

We fixed a lot of bugs and  have been working on getting DQ1 running on SteamOS ever since we attended Steam Dev Days. Since DQ1 is still stuck with Adobe AIR, this is not an easy task. Although we have a good solution for regular Linux distributions (Ubuntu, Mint, etc), SteamOS is harder to get working. The difference is that SteamOS has a unique default setup that changes how the default user interacts with commands like sudo.

It's easy enough to work around it on my SteamBox by messing with the configuration, but we need to create a simple script that will work flawlessly for any user using only default factory settings. Thanks to the heroic efforts of Alexander Sturm and the nice folks at Valve, we've finally figured it out, but it's not up and running *just* yet. As you can imagine, I can't wait to have all my tech running natively on Linux via Haxe rather than AIR, as I blogged about recently.

We also need to get a Linux build ready for GOG Linux. Given that the intersection of GOG players and Linux users are solidly unified in their hatred of Adobe AIR, this is more of a delicate communication problem for us to solve rather than a technical one, but we'll get it sorted out soon enough.

Thagomizing

Finally, I've been steadily looking for opportunities to chase DQ1's "Stegosaurus Tail." You can read the linked article to get the full story, but the short version is that we've made more money in the second year of release than in the first.

By relentlessly chasing down promotional opportunities, we can keep introducing brand new people to DQ1, keep the bank account afloat, and thanks to our silly mini-ARG update, let new players know about DQ2 and drive pre-orders. Maintaining DQ1 sales is important because we don't want to rely entirely on pre-order revenue; the entire purpose of running a low-key "anti-kickstarter" is to avoid the intense pressure and hype usually associated with traditional crowdfunding drives.

FUN FACT: in the aftermath of writing the aforementioned article, I learned that the proper scientific term for the spiky bit of a stegosaurus tail is a "Thagomizer", originally coined by Gary Larson in a Far Side cartoon, and has since been officially adopted by paleontologists!

So from now on, I'm using the verb "to thagomize" to refer to the act of pursuing promotional opportunities for an old video game in order to drive further sales spikes on the long tail. 

"What you been up to lately?"
"Oh, the usual - coding, blogging, thagomizing."

DQ2 Stuff

Okay, so you probably want to hear about all the DQ2 stuff we've been doing!
Before I go any further, allow me to properly deflate your expectations with a metaphor.

The Iceberg Effect

Here's a picture of an iceberg. Notice that almost all of it is under water, and only a tiny bit pokes above the surface:

Via Wikipedia (source)
Uwe Kils (iceberg) and Wiska Bodo (sky).

A lot of work goes into making a video game, but the only part you can really experience as a player is the bit that pokes above the surface of the water. You see the graphics, the audio, the controls, but you can't see the thousands of lines of code behind the surface that keep the whole structure in order. And even if you could, you couldn't see all the planning, discussion, communication, etc.

When you're watching a game in development, what you're going to see is a whole lot of nothing for a long time, and then suddenly it will seem as if there's a sudden flurry of activity close to the end as stuff finally starts to poke up above the water line.

Only a few of you were following us back in DQ1 pre-alpha days, and absolutely nobody was following us for the whole first year of its development. For most of you (especially post-Steam), DQ1 just arrived fully-formed without having to wait for anything. So, please understand that "visual progress" is a really terrible metric for actual progress.

With all that said, here's what we've go to show for ourselves so far.

Arts!

Karen Petrasko has been working on some new concept art! Here's what the inside of a domed city might look like (click for hi-res mockup):

You can expect the same level of detail/visual fidelity in our battles, though I doubt very many will take place inside of a town. The above is more likely to be used in our in-engine cutscenes for when our characters are in a domed city.

And here's some random bits of concept art:


Top: Domed city exterior and interior Bottom: Emperor, soldiers, scavengers exploring the surface.

Here's a sketch of what our overworld map might look like:

And here's a new character we've been working on, who just goes by the name "Smug Captain" for now:

Dean Dodrill is still on board for this project, but he's had to take some time off to properly support/thagomize his last project, Dust: An Elysian Tail, and recover from a brutal, multi-year development slog. So we don't have any animations to show just yet, but we'll let you know when we do.

Musics!

Meanwhile, Kevin has been working on some of our first music tracks, which you can listen to here:

Defender's Quest 2 concept piece (mp3)
"Enemy City" WIP piece (mp3)
Untitled WIP piece (mp3)

Kevin wants me to SUPER EMPHASIZE that NONE OF THIS IS FINAL, it's all very early/rough work, and it will almost certainly change before the game hits final release.

Programmings!

We've made a lot of progress porting the Defender's Quest engine (known internally as the "TDRPG Engine") over to Haxe/OpenFL. I'm a big fan of open source development, so I'm releasing whatever bits I can as open source, under the MIT license. Since I started doing this, I've been officially accepted as a regular contributor to the HaxeFlixel project, and two of my libraries have been officially adopted into HaxeFlixel itself. The TDRPG engine itself remains private, but I like spinning off little bits of it wherever it makes sense to do so.

My most notable contributions include:

1. flixel-ui: a GUI library made entirely of flixel-native widgets, so you can intermingle them with other flixel objects, rather than awkwardly overlay a UI pane over your flixel canvas. This started by porting over legacy DQ1 code, but has since been massively improved. It's also easy to integrate with firetongue, so automatically making buttons twice as big in German mode is easy!
   
   

   

   This is just a demo -- DQ2 will look much better

   Defender's Quest has an enormous amount of interface, so this and the battle engine represent the bulk of the coding work.
2. flixel-editors: a set of editing tools for flixel. Right now it only has my "Animator" tool, but it should have more stuff soon enough.
   
   

   

   The Animator tool is not for building animations from scratch, but rather for previewing spritesheets in-engine, and building individual animation sets out of frame indeces. It also lets you set "sweet spots" to define where projectiles (for example) should originate in an attack animation, and various other features.
   
   It also comes with built-in support for re-coloring both pixel-based and "HD style" sprites. In the screenshot you can see an example of the latter -- I'm using a sprite from Glitch to test with for now while we work on getting more our own stuff ready.
   
   It's important for us to know what the basic limitations of our tech is so it also has the ability to run rudimentary stress tests. We'll need better benchmarks to really know where the boundaries are, but initial results seem promising, and way better than what DQ1 could handle:
   
   
   We plan on having a cutscene and level editor eventually, too. I haven't decided yet whether those should be open-source, too, but I'm leaning towards it.
   
   Why am I spending so much time with tools and stuff?
   
   50-75% of DQ1's development time was CONTENT CREATION, and LOTS of time was wasted manually processing/integrating content with bare-bones tools (text editors and photoshop, basically).
3. firetongue: my localization framework. Originally ported from DQ1 code, but massively improved.
4. flixel-demos: I didn't create this repository, which showcases various flixel features, but I did contribute these individual demos: cursor, heatmap pathfinding, blend modes, rpg interface, file browse (Note: file browse has to be compiled on native targets to see its full functionality). All of these demos are the result of me testing features we needed for DQ2.
   
   
   

For the rest of my stuff you can see my github profile or open source report card.

NOTE: this is open-source development, so all "my" stuff has received lots of bugfixes and improvements from the HaxeFlixel community, for which I am very grateful.

What's Next?

So there's still a lot of work to be done. I really need to dig into the new battle system engine, and story material is starting to mature. Then we can draw on that for a few story announcements, we can get art from that, get music from that, etc, and roll that all back into the design.

When will Alpha be? I hope to have something playable before the first half of the year is over, but no promises.

Other stuff we're looking into is whether it's worth it or not to plan for a console release. Now, there's no chance we'd be interested in from-scratch ports, so everything depends on us being able to get the Haxe/OpenFL stack working for those systems. In theory, it's possible, it's just a matter of building out the native targets. So far we've made some good progress using HTML5 (believe it or not) for the WiiU's Nintendo Web Framework, but what we'd really like is truly native support on everything, especially the 3DS and PS3/4. We're putting little feelers out and seeing if we can find the right people for this, because I sure as heck can't build it myself. So far we have some promising leads but we can't announce any of that just yet. Let's just say I'm not regretting switching to Haxe.

And in any case, our top priority is getting the game running on Windows/Mac/Linux. If -- and I do emphasize "IF" -- we release on console, we will make sure that is most certainly not at the expense of PC development.