I've been thinking about how the animation system will work for a while. Some of the time I've been awake for the thinking and not just dozing off pretending to work on the game. My thought processes are often quite visual so I get struggle when trying to indicate my thoughts with mere words. I think in colours, shapes, and expletives when it doesn't quite work out.
Some people may think it odd that I'm working out the interface to the program before I've even worked out exactly how a program works. It's not quite like that, of course. I have a general concept in mind before I start. Once the vague premise is in place, I start working out where all the buttons go, how they look, why they do something. I revise as I go along, too. This might mean I take a few iterations of conceptualizing the GUI (Graphical User Interface – you know, buttons, switches, shiny things), but it helps me work out what I should be including as well as what works best. Writing out what buttons you have on screen is all very well in text, but until you see them there you won't know if it actually makes sense.
It's in this manner that I began to build a menu system for my level editor and animation toolkit. This is not the game menu or anything, it's just for the tools that I'm building to make the game itself. Why waste my time? I'm not – these tools are part of the final game package. I want people to be able to be able to use these tools to not just modify and add to my game, but to create their own games. The games themselves don't even have to be Flash games at all, just something 2D in whatever language people want to develop it in. I just figure you can never have enough tools to do anything, mostly because any particular game development tool is designed for certain types of games. The more types of tools around, the easier it is for game developers to find a tool to suit their needs.
I love designing user interfaces, in particular ones that are user friendly, unique, and pleasing to look at. Which is actually sort of my day job anyway. And that's why I tried to make an animation system interface that makes to the user. Have you ever tried to learn how to use Flash, Photoshop or Microsoft Word? Those are great examples of really awful interfaces. They are designed from a programmer's perspective (as in, it makes sense to a cubicled person who drinks far too much coffee and enjoys discussing how to generate fractals using only 25 lines of code*).
But people use programs. This is not to say programmers aren't people, but they certainly don't think in the same way as most ordinary folk. Intefaces should be designed to maximise workflow within an application and, as much as possible, be intuitive. If you're program is complex, then naturally the interface will follow this trend, but the application designer needs to keep in mind who the audience is.
I don't have a perfect completely intuitive system by any means, but I think I've come up with something that will enhance workflow and still be quite open to some modification by others. I'm trying to keep it simple for the user (it's already become fairly complex code-wise – oh! the things I do for you). I'll post up how this all looks and works shortly. Minus an interactive demo - only pretty pictures for now.
*This is a fallacy of what a programmer is like and I apologise to all my fellow coders out there. I know you aren't like this, I know many of you (those 8 in the back) have spoken to girls before, and some of you (0.06%) don't even drink coffee. Many of you probably don't even discuss fractals, or know how to obfuscate code so that you have to stay hired at the company because you're the only one who can fix it, but that's because you're weird.