Frayed Knights 2: Virtual Graph Paper and Tool-Driven Development

Posted by Rampant Coyote on August 30, 2012

(UPDATE: The original game, Frayed Knights the Skull of S’makh-Daon, is now on Steam Greenlight. If you are on Steam, I’d be most appreciative if you’d kindly vote it up at this link: Frayed Knights for Steam! )

So if you were to ask me what the number one challenge I faced making Frayed Knights: The Skull of S’makh-Daon… well, okay, the answer would be lack of budget. Number two would be the lack of a full-time artist. Number three, however, would be tools. Or the lack thereof.

The Torque engine supported Quake-style maps, which we used for the dungeons in Frayed Knights. This sounded good in theory, especially when using the cool Quake-style optimizations that allowed really big levels to be rendered pretty dang quickly. And there were tons of tools out there for doing that, which were nice and mature and stuff.

In practice, it didn’t work out very well. Torque didn’t have much by the way of the optimizations that Quake had. We could do some things with portaling, but there were tons of “undocumented features” in the engine that continued to frustrate us when trying to build and optimize levels. The lack of integration between the level-building tool and the game (or engine) itself caused more problems. Without hooks or standardization for gameplay elements, all important interactive stuff had to be added later, in a different (in-game) editor that was still depended on hand-built or hand-tuned code and data  fit in the environment and work correctly in-game. It was time-consuming, error-prone, and often pretty dang boring. This is not a winning process for rapid development!

Doors are a prime example. A simple door – without any special trap or other trigger associated with it – would take several minutes to place, orient, align their collision, and code. And then another few minutes to test – though I usually did this as a single pass after several doors were placed. Sure, it was only about five minutes per door (so long as they had nothing special going on), but multiply that by over 30 doors in a dungeon – many of which DID have special triggers or events attached to them which took significantly more time – and you are talking 3+ hours spent *JUST* placing and testing doors. Due to little visual errors in placement or dumb cut & paste errors in coding, I’d probably spend twice as much time on them as this finding and fixing problems.

So – okay, six hours doing the doors for a dungeon is not, by itself, a huge deal. But multiply that by all the other stuff that had to be placed and “wired up” in a dungeon, and you get the idea that there was a lot of long, tedious, error-prone work going on in addition to just creating the geometry of the levels. Those six hours could have been spent adding more details and quality to each level. Which is what I really wanted to do – not just because it would make the game better and more polished, but that’s the stuff that can be a lot more *FUN*.

This sort of thing was everywhere. Placing items and decorations. Setting up encounters. None of this seemed like a real problem when I was just making a single dungeon for the pilot. Hand-tweaking something doesn’t seem so bad when you are only doing it three or four times compared to the effort required to make a full-on toolset, particularly when you are still in R&D mode and your actual process is still in flux. But three hundred to four hundred times? Not so great.  But sometimes, when you aren’t so sure how far you’ve got yet to go down the road, it’s hard to judge whether or not it would be worth it to build a shortcut.

Suffice to say, I did a lot of things the hard way, with very few tools to make my life easier.

Going to a brand-new engine isn’t entirely a “clean slate,” as we’re building upon the foundational rules and systems (with improvements) of the original game. We’re actually porting code where we can. But this time, I am determined not to make the same mistake the next time (so I can move on to brand new mistakes), so I made a decision that I was going to focus on tools.

Nowhere was this a bigger deal than creating the dungeons. With the new engine, the Quake-style dungeon building is gone, baby. I had to architect an entirely new system for developing a core aspect of Frayed Knights gameplay – the dungeon crawling. I want them bigger,  better, cooler, and far, far easier to build and test and polish.I wanted big dungeon levels that rendered quickly, which meant that simply creating a ginormous level in Blender or Lightwave and dropping it in the game wasn’t going to cut it – and it would have all the same problems that we had in the first game. No, what I needed was a tool that would allow me to do all that complicated, tedious stuff *quickly* with massive automation to prevent mistakes (especially the ones that might slip through into release). As this was the highest-risk, most experimental part of the sequel, it’s what I focused on first. And longest.

I created a kind of laundry list of features, with my new, improved “dungeon engine” going hand-in-hand with my editing demands.  I wanted something as easy to use as drawing maps by hand on graph paper – in fact, something that felt a little like that would be awfully nice. It had to be powerful enough to create something like the maps of Ultima Underworld, and more so… with things unlimited map sizes , and true 3D capabilities with the ability to go over and under territory (yet, considering how humans work mainly in the horizontal, optimized for horizontal movement with small, smoother elevation changes). I wanted to be able to create something as weird and as vertical as the Pit O’ Doom from Frayed Knights: The Skull of S’makh-Daon. Finally – where the capabilities of the editor met their limits – I should be able to just swap in much more sophisticated level geometry from a tool like Blender to replace pieces of a the dungeon built by the tool. That way I could get the best of both worlds, right?

I went through several iterations of the underlying architecture (while learning Unity), many of which ended up requiring me to scrap almost everything several times. After four or five months of this, I was beginning to wonder if I was going to be able to pull any of this off.

I think I did. I’m pretty excited about it. The last of the technical risk items (the “will this actually work?” problems that could send me back to the drawing board yet again) were resolved a few weeks ago. While the focus so far has been on functionality rather than aesthetics, making screenshots not particularly thrill-worthy, I’m pretty pleased with how things are coming along.

The core of the dungeon-editing side of the toolset looks and feels like drawing a dungeon map on graph paper. This is not accidental. I figured anything that helped me tap into the raw creativity and love of RPGs of my youth is a good thing. And after all these years, it feels natural. Adding a vertical element to everything isn’t quite as easy or natural, but building ledges and slopes is not a big deal either. Even better – while much of this is still under construction – most of the gameplay logic is controlled via the editor as well.  No more having to build stuff in six different places to get it to work.

My general approach is that that this toolset should be an 80%-85% solution for everything in the game. This should hopefully preserve my sanity through development of both Frayed Knights sequels, and any other projects built upon this foundation.  In other words, 80%-85% of the game – beyond basic content (textures, models, animations, sounds, etc.) – should be developed in the editing tools. This way the tools can help catch or prevent bugs, maintain consistency, and and automate everything that can automated. The time otherwise spent doing the tedious, boring, technical work can now be devoted to doing the cool stuff (and, hopefully, doing the cool stuff much, much faster).

Now that I have the advantage of hindsight and the core systems of Frayed Knights are already in place from the previous game,  I’m taking the approach that as a general rule, if it doesn’t exist in the editing tools, it doesn’t exist in the game. It’s like “editor-driven” development – when I want to add functionality to the game, I start by building it into the editor.

While the lead time on developing the tools up-front has been a little daunting – especially after having to throw away a bunch of failed experiments – I’ve been very pleased to note that 80-85% of a dungeon can be thrown together really easily. If I were to allow a dungeon to be completely “flat”, I can whip out something like the above map in seconds. Literally as fast as I could sketch it out on paper. Doing something with more interesting vertical elements gets a little more complicated, and will often require more iterations to test, but it’s still very, very fast.

By way of comparison, the Hobgoblin Bunker in Frayed Knights 1 took a couple of weeks (of part-time effort) to build just the basic layout with the texturing, geometry, and lighting. That’s without adding interactive elements and scenery (like furniture), combat encounters, or anything else. With this tool, I can do the same thing in just a few minutes. I am not kidding. It’s that significant. And doors? If I don’t want to mess with the defaults, they get placed and “wired up” automatically, taking zero time. And there’s no need to do a special testing pass on them afterwards.

While other aspects of the level-design process may not enjoy quite as dramatic a time-savings, I’m pretty confident as pieces are coming together that the improvements will still be pretty impressive. In addition, there are some neat new features that can make more interesting gameplay that will hopefully be more present in the game since they are easier to create and use.

Okay, before you ask: No, I’m not building the tool with any sort of plan for releasing it to the public. I’d not be at all surprised if that actually happens at some point down the run (with significant clean-up effort), but for right now the game is still the primary focus – the tools are simply what we need to get there.

Unfortunately, talking about editing tools can get pretty dang boring really fast, so I won’t be providing many updates on the technical progress on this front very often. But the ‘clean slate’ provided by switching to Unity has allowed us to approach the series with a more fresh viewpoint, so there’ll be some changes (all for the better, I hope) to Frayed Knights’ design that are ongoing that I’ll be talking about for the next few weeks.

Filed Under: Frayed Knights - Comments: 11 Comments to Read



top