Tales of the Rampant Coyote

Adventures in Indie Gaming!

Frayed Knights – Sorry, the Princess is in Another Castle

Posted by Rampant Coyote on April 11, 2014

fkvert1In 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.

gygaxflooreditorIn 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.

slopesDemoBut…

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.

E1M1_ArmorRoom_ProBuilderIncidentally, 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



  • Xenovore said,

    “…swearing at me over dealing with new tools…”

    Indeed. The issue is that ProBuilder is trying to take the place of CSG editors, while completely ignoring how CSG editors have worked in the past, e.g. Hammer and Radiant. I’ll admit that those editors have some particular weaknesses, but — especially in the case of Hammer — there is intuitiveness there that ProBuilder completely fails to build upon. (Apparently ProBuilder’s developer has never done any Quake or Source engine level building?)

    (And don’t get me started on the stupidness that is ProSnap; snap-to-grid is a completely separate product from the editor? Come on!)

    This video (linked below) demonstrates how a level editor should work, particularly how vertex/edge editing should work. (Go to 4:40 to see that in action.) Note the complete lack of fiddling around with vertex or edge modes; it’s all there in one mode, immediately visible and accessible with the mouse. (Also, the ability to hollow a volume and instantly create a room or hallway… huge.)

    Hammer editor tutorial

    So yeah, the primary issue I have with ProBuilder/Prosnap right now is that it’s so fiddly — hotkeys for this, special dialog that, some other UI for those; not to mention Unity’s UI as well — it all just gets in the way of building something. I’ll have a great idea for an area, but trying to actually realize it… grrr.

    Ultimately, I think the blame falls squarely on Unity and the mindset there. I mean, I’ll agree: it IS a nice idea to have everything and the kitchen sink integrated directly into Unity, BUT… so far the actual implementation leaves much to be desired. It all seems to get in the way of each other… 50 different toolbars/windows/buttons/sidebars/etc. all competing and distracting from each other.

  • Xenovore said,

    Oh, one more point (not that I expect ProBuilder’s dev to be reading this, but…):

    To really improve the easy-of-use, make the interface work like TrueSpace’s: Right-click (or middle-click, or button 4/5-click; make it user customizable!) a shape to enter point editing mode, then make the selection be based on context. I.e. if mouse pointer is over a vertex, highlight (and select if left-clicked) the vertex. Over an edge? Ditto. Over a face? Ditto. Right-click again to go back to object selection/manipulation mode. Straight-up, no clicking on UI or hitting hot-keys unnecessarily.

  • Bad Sector said,

    I was under the impression that ProBuilder was actually easier to work with than Hammer…. well, it sounds like i was wrong.

    I agree with Xenovore about how things should work though. And i prefer to have a single tool for a single task instead of everything shoved under the same program. It also helps keep the codebase focused and small (which in turn helps to keep the number of potential bugs low).

    In a totally unrelated note (really!), here is a map rendered in Unity made with my brush-oriented 3D world editor :-P. Sadly Unity sucks when it comes to importing stuff and i had to manually assign the textures. Also no lightmap or decal import. So i think i’ll stick with my engine, which also runs on a P3 PC with Win98 and i815 GPU :-P.

    Now if only i could get rid of this little voice in my head telling me to scrap my 3D editor because [...] and make a new one that will be better and more awesome. I don’t want to, i already spent a lot of time making this thing! :-/

    But i did start rewriting the viewport code since it was a big ball of muddy code that did everything bad and made adding new features hard (specifically: vertex editing and manipulators).

    Hopefully i’ll find some time this decade on making a game too :-P. Although there is this possibility of everything 3D being switched from triangles to voxels and i’ll have to make a new editor :-P

  • Rampant Coyote said,

    Part of it is probably due to the fact that Xenovore hasn’t ever used the Unity editor, either, so he’s learning both Unity and ProBuilder at the same time. It’s my understanding that ProBuilder started out a little more like a conventional CSG-style editor, but he stripped away some of the baggage over time. But a lot of it is simply that he has to work inside Unity’s editor, which carries quite a bit of baggage of its own.

    I like it, personally, but then I like Blender, and I have a lot of people telling me that I’m totally wrong in that.

    Unity really is kinda taking over on the indie side. As much as I love it, I don’t want its industry domination to be complete. That would be bad for all of us. So I’ll still cheer on the folks using Unreal, CryEngine, Torque 3D, Game Maker, their homebrew engine, or anything else out there. Competition is good for us and for the industry as a whole.

  • Bad Sector said,

    About Blender, i know some 3D artists who were used to 3ds max and told me that they actually prefer Blender for modelling and UV mapping to 3ds max (one actually uses Blender specifically for modelling and 3ds max for everything else). The biggest problem all faced (or at least they told me so) is the difference between how the UI works since Blender is totally different to what they were used to. But because Blender’s shortcuts are very well thought out they manage to do stuff faster once they learn the UI. Personally i’d also add that the UI is way more orthogonal (same keys in 3d editor, uv map editor, animation editor, node editor, etc) so once you learn one part it is very easy to learn the others.

top