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!
No comments:
Post a Comment