How stuff is designed here…
One of the things we have been trying to do in producing Emerald Kingdom: being open about some or most of our process. Sure, we have done things like Open Source our server, and we have talked in the past about features and things planned for Emerald Kingdom.
Today I want to talk to you a bit about how things get designed for Emerald Kingdom. I am going to focus today on Code and Art.
You can learn how “industry standards” work, or how workflow happens in most offices. But one of the things we try to do is keep the process open to change up until the very last moments before something becomes “final”. This gives us a very specific advantage in some ways…our stuff is almost always in a “revision state” until we stick it in Storyteller, or on our game wiki. Despite this method, we manage to avoid things like feature creep in code, ridiculous changes to artwork, and having to redo animation processes. Why? Because we have some really professional and smart folks here who take quality very seriously. Another big one? Double Cluepon is a close knit group. Very close. While we like to have fun, we’re also highly disciplined in our various core competencies. We all have a deep respect for each others area of expertise. It’s why an artist can tell a producer “no”. It’s why a writer can pan on a story idea. It’s why a floater can suggest new methods of producing props.
We also do this without boring the hell out of each other with constant daily meetings.
But, on to the show. I’ll start with code:
Believe it or not, on some levels…designing what happens is more about question and answer sessions, to flesh out a specification. In the spec for Emerald Kingdom, Server, StoryTeller and Client….we obviously have “items” on there. We even flesh it out with English; “Characters can hold items in a bank or inventory”. To a person actually writing the code…this is about as useful as bucket with a hole in it. The developers need to know what an item is, and even just as importantly…what an item is not. You might think your +10 sword of pastrami slicing is badass. You have no idea how many attributes it has behind the scenes. Developers need to know things like:
- What are the initial properties? (which also in and of themselves need to be defined!): Are they Wooden? Do they have Edge? Fire, Ice, Stone? Sharp, Dull, Rusty?
- Are they used in creating some other thing?
- Does this existence of this change something else?
- Is the item defensive or offensive?
- Is the item usable?
- What is the base cost of the item?
- Is the item equippable? (just because something is usable, does not mean you can necessarily equip it)
Once they have all the information they need for something most players consider trivial, or standard…like items, they go off, and start working on the code. They add some tables/rows to the db to accommodate this new piece of functionality. Then, it has to be tested, and tweaked. Etc. But, even while we test or play with the functions…we either get clarification on what we feel does not work, or we suggest something and play around with it in discussion to make sure it’s elegant. The number one rule: elegant solutions are the prime mover. We never care who’s idea it is, as long as it solves the problem neatly, and with some innovative or novel thinking. There’s even a balance equation there as well, just because something seems slick does not always mean it’s the best way to do something.
Code at Double Cluepon is really all about group specification writing. As a producer, it’s my job to translate between the various native dialects. I explain to the artists what the programmers are trying to say, I act as a go between for the writers and the developers on the story system. It’s actually a great deal of work, but it’s also a great deal of fun too.
With the Art Department, it’s another kettle of fish entirely.
With the Art Department, there are two very distinct stages. There is the concept, and design stage. This is where we get to dream up how the world will look. How it will feel. Then there is the production stage: turning the pretty concepts into assets, animations, and pretty in game things. I’m going to focus today on the first stage, and touch on the second.
When something needs to be designed, or conceptualized….I don’t leave it to chance. I, or the person requesting studio work try to work very closely with Uriel. Literally. The first step in this, is learning how not to waste hers, or any other artists’ time. You can do this very simply: research what you want! A talented and trained artist can take references and pictures…even something torn out of a magazine with a circle around the desired feature…and transform it into a whole from the parts you bring them.
How did I want Thrynity (or for that matter, any of the Sprites…) designed? I’ll tell you: I went looking for references. I found a picture of a girl with a beret on. I found a girl with hair I liked/wanted for the character. I found several pictures of girls with the facial features I felt would work for the character I envisioned in my minds eye.
I then took these references, and my own ideas I could not get from references and sat down with Uriel. She then started a very rough sketch of Thrynity. I nixed some things, and told her to run with others. With the references in hand, I told Uriel I wanted something of a more stylish looking skater girl, who exuded a great deal of attitude…and you could tell by looking at her.
I got exactly what I asked for. But I think one of the things that’s important to point out here is, during the design process, Uriel has the right to come out and tell me “no”. When she does, she always has a reason for doing so. She’s a professional artist, and it would make no sense whatsoever to not listen to a person trained in the profession. If you are not going to listen to people who are trained for their core competency, and you just want to bark out orders…you’re not going to be an effective manager, producer or game designer.
Not all of the concepts are designed this way, a good example of this are the Gremmies. Believe it or not, the Gremmies were designed from doodles, and an extreme case of Uriel being over-tired.
When we get concepts done for things like clothes, or body models…the base parts of it are drawn out, handed to Caelum for pathing in Illustrator, and then handed to Sandalphon for animating. For things like buildings and props…Caelum takes a flat drawing, runs them through Maya, does a render…and then we take both the isometric angles we need from the render. Uriel then paints these.
But, even the artists get to contribute to things like code too. The animation editor in StoryTeller? Sandalphon has had a hand in how it looks and how it works. She had to work with Raguel on things like, whether or not we would use sprite sheets, animation timing, offsets, etc.
In closing, 75% of the stuff we do here is centered around design. We take it very seriously. We love cool stuff as much as you do. We could have settled for shiny stuff you see in facebook or flash games…but, it was not going to cut it. Not for us. Not for you. We have even delayed decisions in some cases, in order to ask the public what they think. We honestly just care that much. It’s why we try to encourage people to poke us, ask questions, point things out.






