In-Game Editors

I spent about four hours today working on my current project, code-named RPG4. (It started as a Ultima IV knockoff, hence, "the U4-like RPG project", aka RPG4.)

I think in-game editors are a bad idea. In the past, they've made my game code ugly. Objects that would otherwise be constant and have no modifiers suddenly become mutable. Usually it's easier/faster/cleaner to keep a list of objects in a container optimized for game code, but that container isn't good for editing. Editing and playing are two different worlds and trying to do both just consigns your code to not be well-suited to either one.

This is different than an engine that can be used in a custom-built editor. I'm fine with that, and encourage it (where making an exporter for 3DS or Maya isn't a better choice). An engine is a library, though, and most of your custom-created editors are going to be for gameplay data, not graphics.

An in-game editor mode is tempting. It helps out in development, cuz you can just change stuff using the editor commands. It doesn't require a separate package. This arrangement means there's no chance that the editor and game get out of sync. The resource pipeline in shorter, and hence simpler. But I don't think the savings are as great as they appear. If making an editor is easy, then there isn't much to "save" by bundling the editor into the game executable. In-game editors are more useful the uglier your code is, and if you've got crappy dev tools. If poking around in your code and seeing what's going on is tough, then yeah, an in-game editor can help you debug faster. What you really need is good debug tools, though. I hate Microsoft, but their tools are great. (Maybe I've just been hitting myself with a hammer for a couple years; my previous job was all text-mode *nix development for an embedded platform with minimalistic debugging tools.)

I used to build editors by hand, in part a legacy habit from building game-engine UIs, working with old frameworks, and, to some degree, the amount of manual construction necessary a decade ago. Tools have moved on, and now for us Win-centric developers, it's cake. Cake cake and cake. There's no reason to have an in-game editor. I think having a separate tool adds a lot to development.

With good tools, developing a separate data-file editor is easy. I've always felt that a strong description of your data format is a good thing; it defines gameplay, to some extent; what can be edited, what their ranges are, and what combinations are verboten. If you have one person working on the editor and another working on the game code, and they have a well-specified data format to share, then they're both less likely to err. They can refer to the documentation and learn about the format at their own pace, without interrupting another developer with noob questions. If your data format is in a shared place (Wiki > code repository for this), then a new-hire junior guy can jump right in and start working on his own. And when he finds out that the documentation sucks, he can fix the documentation. Right then, right there. Plus, he doesn't need to know how both the engine and the editor work, so he can't bork the code in a way that cripples either game performance or editor features. And then you can give the documentation to the designers! But that's a different rant.

I love WinForms. I spent about three hours today putting together a tileset editor. All it's good for is moving tiles from one .bmp/.png/.jpg to another, but it should save me some time -- I plan on mostly using public-domain images for this title. It's great to be able to go into the designer and mock up an interface really quickly. Better yet, that mockup is your interface. It's not MVC, but I've seen MVC debated. MVC is not my holy grail. Working, maintainable code > appeasing the design gods.

I figured it'd be cool to add a checkbox to control whether or not the source icon auto-advanced after every Grab operation. So I threw a checkbox in the form. I didn't have to connect it to anything; no magic CASE connector ribbons to stream around. Edit the label, give the checkbox a useful name, and blammo. It's in there. Rather than figuring out where to put some bool so that both the UI and the code can get at it, the code already has access to the checkbox, so it can just query state.

That was for a control that determines editor behavior, though, and isn't saved in the data format. Having controls that go both ways (ie populate from the data store, and then save their values back into that data store) can be done with data binding, but I'm not a data binding guru yet. Maybe next week.

And even further I'm learning a useful job skill. I use data binding, a bit of WinForms, and a ton of C# in my day job. My hobby and my day job are feeding off each other, and that's cool.

I'm still a WinForms noob, though. I've got a decent book that I'm reading through, but the first few chapters are even more noobish than me and that's slowed my progress cuz I know it all already. :) I haven't yet read through the meaty middle chapters. Having Intellisense (when it doesn't fall into a fey mood) plus online help makes it easy to just do what I want to do and not mess with other features. I rilly rilly need to build some custom controls. My main editor has seven tabs, and right now all of the handling functions for every sub-editor is there in the main form code. Holy Blobs, Batman.

I know it's easy to fix. Heck, I could probably find out how to get custom controls working in design-time in less time than it took to write this sentence, but ... well I guess things aren't so bad yet. I'm learning, I'm getting stuff done, and I know I'll get to those chapters in a few days, so I'd rather read through everything than skip around. I have a feeling if I got custom controls working fine, I'd drop the WinForms book and run straight to...

XNA

... which is what the game engine will be built in. I'm looking forward to that, too. My last few engines have been OpenGL, but I've been ignoring the games industry for a couple years while working a day job. Vista sucks, still, and so I haven't dabbled with DX10, and I was playing with DX9 back then, so it seems mostly that graphics cards haven't passed me by. Cool graphics features await in the pristine Vista future (*cough*), I know, but I'm not shooting for triple-A titles right off the bat. As I said in a previous blog, my goal is to GET IT DONE. Finish the game; ship it.