Saturday, November 24, 2012


To jump on the seasonal bandwagon, I am thankful for an awesome team that can work together to accomplish amazing things. Over the course of the past few months we have gone from a fun conceptual prototype into a nearly feature-complete alpha, and I've retained (most of) my sanity in the process!

Now, down to business. Last time I talked about how UI conventions can be used to your benefit. This time I would like to discuss how NOT to build an editor. These are the hard-learned lessons I have picked up in my brief experience. I would love to hear from any readers (anybody out there?) with other suggestions, since there's an increasing likelihood that tools and infrastructure will end up being my focus.

Games, and editors in particular, require tender loving care. When you set out to write your first few lines of code you will be tempted to just throw things together quickly - after all, Agile is supposed to be all about diving straight into the code, right? WRONG! Agile is about quickly adding on features, iterating on a design, and integrating feedback as quickly as possible. If you screw up the overall structure of your editor in the first sprint it will become increasingly difficult to accomplish what you need to.

For example, take a relatively simple user story: A user selects an object and edits the properties of any attached components. Reading this you decide that in the MouseClick event of your form you will set a SelectedItem property somewhere and update the UI. Fantastic! You now have a functional editor!

You start working on the next item: A user updates an object's position by dragging it. Hmm - okay, so we need to keep track of where the user first clicked, then in the MouseMove event we check for a drag and handle that. Still not too bad, and we're still in Sprint 1!

Work progresses like this for a few weeks - new functionality usually requires a few extra variables and some extra logic. Eventually you end up with the MouseDown, MouseUp, MouseClick and MouseMove events being full of duplicated logic that seems to require an increasing amount of maintenance. Where did we go wrong? Well - to answer that let's look at how we COULD have handled these requirements.

What if we thought of our user interactions as a finite state machine (FSM)? Under this model, we just have to define the state changes. Well-written user stories often lend themselves well to a state machine. Given the above two, for instance, we can say that the default state is IDLE. If the user clicks on an object we know that they want to select it. We also know that, after dragging, an object should be selected. Putting these two together we can say that when the mouse button is pressed and the cursor is over an object, we select that object and change the state to DRAGGING.

One of the big advantages I have found in thinking of a UI as a FSM is that it gives you an automatic framework to consider what states there are, under what conditions one state can change to another, and it basically forces you to explicitly name the states. You also get access to all of the tools built around designing state machines - diagrams, simplification and a common language to speak with any engineers you might work with.

This is by no means a new concept - I'm sure this has been discovered and rediscovered time and again by upstart designers much like myself. Then again, if you come from an object-oriented background or you've never worked directly with state machines it probably wouldn't be your first inclination. Maybe you prefer to have a series of loosely coupled classes using databinding and viewmodels to represent granular data of what is happening in your UI. Even then, I feel it is helpful sometimes to take a step back and realize that what you're really doing is building the same state machine, just at a different level of granularity and abstraction.

Tuesday, November 13, 2012

Some notes on UI design

The editor continues to evolve. After sitting down with Becky (the Art Lead) I was able to implement some valuable feedback into the editor. I thought that some of the feedback might be useful for others who may find themselves building an editor in the future.

Toolboxes are your friends!

Coming from a development background I originally envisioned level design as involving a lot of manually tweaking objects, maybe adding them to a toolbox, then repeating over and over again. I am accustomed to manually tweaking the settings on a blank object then copy/pasting it where needed, so this seemed like a perfectly reasonable work flow. After turning the tool over to an artist I quickly saw the problem with this - as an artist, they simply want to pick a brush and paint with it. Photoshop, Inkscape, Adobe Illustrator - pretty much every artist tool known to man - focuses on placing a large palette within easy reach. Do yourself (and your artists) a favor and follow the UI conventions already established.
To deal with this feedback I instead focused on automatically building palettes that contain every possible prop they might want to drop into the game. I have the luxury of working with experienced artists who are very understanding of the realities of development. Even so, it's better to make your tool smart than to require that your users are.

Borrow conventions from other great tools

This one goes with the note on toolboxes above. When I use an IDE, I tend to expect some sort of code completion functionality. I find myself pressing Ctrl+E,D in an attempt to clean up my code. If I can't remember the complete name of a method, I want to type a dot and have the IDE tell me about what's available. Regardless of personal IDE preference, my point is that interactions with tools are learned. Don't fight this - use it to your ADVANTAGE!
If your editor needs to be able to place straight lines, use shift+click to draw a line from the last point. Use the mouse wheel to pan up/down and ctrl+wheel to zoom. If you support panning in your editor, use space+drag as a shortcut for pan. In short, find the shortcuts that your customer is used to and reuse those.

Who needs Undo/Redo anyway?

When I first sat down with Becky I was feeling pretty good about the state of the editor. Shortly after addressing the above issues she started to paint terrain. She was dragging new terrain, erasing a few pieces and having a grand old time. Then she made a mistake and asked why she couldn't simply undo. Hmm - good point! One mark of a good editor (or software of almost any kind) is that you should never feel trapped. If you make a mistake, you should be able to fix it. I have decided that when I am manipulating the level in ANY way, it is best to use whatever Undo/Redo solution you have chosen to implement. Better to have too much undo history than too little!

Timely preview is irreplaceable

So you've built yourself a WYSIWYG editor that renders content exactly as it will be seen in game. Everything is working flawlessly and using your editor for the first time feels like trying on an old pair of shoes. Fantastic! Now - how about taking that level for a test drive? No matter how good your level design team is they'll inevitably need to make changes. At a minimum your editor should allow the user to immediately (and at any time) load the currently open level into your game. Even better, if you can update the level design in the editor and have the changes synced to your game window you'll have a team of VERY happy level designers on your hands!
For our purposes I suspect simply having an easy preview will suffice, but I would love to explore how some of the more advanced options might work in the future.

Give them what they want

Everything above can be summarized here. My mission statement for this project is to make sure we never have to say no to a puzzle/level concept because of inefficient or insufficient tools. For indie games especially a strong central concept polished and iterated to perfection is FAR superior to a derivative or generic concept reskinned. In future posts I will address a few of these concepts in closer detail with code examples where useful. For now, though? Back to the code!

Saturday, November 10, 2012

Editor is ALPHA READY!

YES! So, with a coding frenzy and some help from my fellow coders-in-arms Brendan, David, and Paige the editor is now Alpha-Ready! Dave had a great thought of how to handle layers in the game, which also lended itself to a handy implementation in the editor. He also got the Magic Ground Finder (codename: MGF) working, which picks out what sort of tile you have placed where and builds an optimized hull from that.
I modified the editor to use the naming convention to automatically find all tile sheets and make them available in the editor. I'm using a sort of modified MVVM model to handle going from UI to actual data and it seems to work remarkably well. The ViewModel for the editor, for instance, exposes a 'SelectedBrush' object. This can be set to anything. When the user clicks within the actual editor window a small chunk of code decides what to do with the current brush (if it's a sprite, set the cell in the CurrentLayer; if it's a template, build a new object to place in the level).
This also made it very easy to add extra items that can be added such as the player spawn point or your trusty robot head sidekick. It also provides an easy way to handle future expansion - WIN!
I feel pretty comfortable handing the editor to our artists to start trying. I'm sure they'll find plenty of improvements they would like to make, and that's a good thing! I can't wait to see how this tool evolves over the course of the next few months.