Frayed Knights – Sorry, the Princess is in Another Castle

Posted by Rampant Coyote on April 11, 2014

In development of Frayed Knights 1: The Skull of S’makh-Daon, a lot of the time and effort in the latter stages of the project was devoted to dealing with scaling the game. A lot of the practices which worked okay for one or two dungeons didn’t scale well to making two dozen locations. There was a lot of “butt in chair” work which would have been made much easier with better tools – especially with the ease of making mistakes. A lot of the bugs in the testing process came down to hard-to-find mistakes that came from trying to do things like manually place and configure every door in a dungeon. One cut-and-paste error in the tedious process, and you could end up with a bug that might take hours to find and fix.

In early development of Frayed Knights 2, I spent a lot of time building some editing tools, thinking they would solve this problem.  I spent months making an ugly but usable editor, with some really cool ideas (well, in my mind, anyway) to make this process faster, easier and less error-prone. I created an editor that let me draw out the dungeons in 2D, like I’d do on graph paper for dice-and-paper gaming, but with some great 3D layering with slopes, stairs, parts of levels crossing over each other with some decent visualization.

I was, and still am, pretty proud of the results. My intent was to create an “80%” solution – make it so that 80% of the level design could be massively simplified so we could devote the time to the most “interesting” 20%. It was a pretty good idea. I wrote a bunch of really cool code that would transform these designs from a 2D map into full-fledged 3D environments with features like ledges, slopes, waterways, and of course diagonal walls. I learned a lot about procedural object generation in Unity. The results were actually kinda cool looking.

But…

Yeah, there’s a big ‘but.’

I think it was in an Air Force ROTC class in college when they talked about how we have a tendency to go into a new conflict prepared to fight the previous one. In this case, while the approach was probably awesome considering the way I used the old Torque engine, it was not the best use of my efforts when making my first major Unity project. I didn’t fully understand the power of the system, or what everybody else was doing in the Unity world which could make my life easier.

The more I expanded on my home-grown editing tools, the more work I found I needed to do, and the more I looked at incorporating it into the Unity editor (I think someone on the blog even asked why I hadn’t done that already, and I didn’t have a really good answer). As I started getting serious about this, and as my editor needed some very serious development to incorporate additional functionality, I looked at some third-party tools to aid me in this transition.

What I found ended up replacing rather than supplementing my editor. Seriously – some folks were already working long and hard on these kinds of problems, and if I were willing to accept the same kind of restrictions I had already planned on with my home-grown editor (to make sure the “80% solution” was still fast, easy, and reliable), then I was ahead of the game from where I would be sticking with my old stuff.  There would be downsides, of course, but it looked like a net win.

This was back in the summer of last year, so it’s no longer news. But it’s still kind of painful.  When I made the switch, I effectively threw away many months of work. It wasn’t a total loss – I learned a lot about Unity in this process. But it still hurt. It’s rough parting with a sunk cost — spending so much time and effort to go one direction, only to realize that you are on the wrong track. I’d spent so much time working on tools that a lot of the actual game code still remained to be done. And I had to get up to speed on using the new tools, developing yet *more* tools, etc.

I am reminded of something Michael Abrash said on his talk at GDC several years ago about the making of the Quake Engine. He and John Carmack had tried numerous different approaches to rendering the 3D world of Quake, each one proving some kind of critical weakness in the end. After a year of development down fruitless paths, they eventually settled on an approach that was not too far removed from what Carmack had done for Doom. Carmack made a comment to Abrash at the end of the year-long process, “If we’d known what we were going to be building when we first started, we would have been finished in a couple of months.”

Or maybe like Mario, discovering that the princess is hidden away in another castle. Sometimes you just don’t know until you try. But I kick myself for not finding some way of knowing in advance…

So now my map-creator Xenovore is swearing at me over dealing with the new tools, but things are finally coming together into something that’s beginning to look like a game instead of just a tech-demo. You still have to squint very hard over the stand-in content, but it’s progress.

Incidentally, one of the major tools I’m using now is ProBuilder, a level-editing tool appendage to Unity’s main editor. It’s pretty impressive. Here’s a tutorial with the creator re-creating the E1M1 Doom level from inside Unity. The videos are sped up to 2x, but it’s still pretty impressive.

E1M1 Doom Level Recreated using ProBuilder (Tutorial)

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



top