Development Concerns

azrael_headcon

As Alpha gets closer, let’s talk about policy.

3
4 weeks ago
by Azrael in , , , ,

I know, I know. A game company that wants to talk turkey on the subject of Policy. To be honest, when it comes to End User Agreements, and Privacy Policies…that’s pretty much boiler plate. We have those done, and we fully intend to not gank the public with mealy mouthed small print.

No, the policy I want to talk about today comes down to something that will affect each and every person who logs into Emerald Kingdom. It’s been discussed a lot over the last couple years, and it’s something we have thought about seriously. The number one policy for Emerald Kingdom is going to be a little something we like to call: The Syndrome Policy.

It states, very clearly the following:

“In every game, there should be two clearly defined groups. These groups are the people who win, and the people who do not. Winning is a recognizable achievement, and should not be diluted, or minimized through wanting to placate or soften the blow to the people who have not won.“

Or to put it more simply: the uniqueness of snowflakes diminishes as the volume increases.

The policy is named after the villain Syndrome, from the movie The Incredibles. In the movie, he states the issue with remarkable clarity:

Everyone can be super! And when everyone’s super, …no-one will be.

Really sort of hits the nail on the head these days, doesn’t it? Everyone’s a winner these days it seems. While we don’t necessarily have a problem with easy “gimmie” achievements on a base level, (They can tell others of how far you have progressed) we do have a problem with the over use of them. But more to the point, Emerald Kingdom is a game that we have designed with personal achievement in mind. We have designed the game to eventually incorporate the mid and high level game. There are going to be people who are the first to do this, or that. There are going to be people who perform remarkable feats. Those people will be immortalized in the player wiki we have planned. Notability will be something we not only plan for, but will encourage.

But, on the back end of things, we here at Double Cluepon plan to apply the Syndrome Rule to the inevitable crowd of folks who will eventually ask for a pony. The ones who will ask for specific things to be made easier for consumption by a wider audience. While we sympathize with the folks who feel everyone should be a winner…we disagree that everyone can, and should be one. Winning is an accomplishment. From slaying a monster to being best and above all others at a specific skill. The rewards should be special, and set the winners apart from the people who do not win. This is called accomplishment, and it should not be diluted or watered down.

While we appreciate that everyone wants to feel like a winner, games are about, at the core: skill and achievement. The staff here do not feel this should be muddied in any way. The spirit of this policy is that, being special should be because you have done something special, not because you happen to have a pulse. Recognition should not be diluted into meaninglessness. If you do something difficult, better than everyone else…you should be rewarded. Part of that reward is not diluting the accomplishment by then making the same task easier. Whether it be the next day, or 3 years from that day.

We have seen a few games do this, and we have to say: a lot of the time it’s done at the behest of two prime drivers. The first one is greed. If they dilute the challenge, more people will play, and pay. The second one is laziness (or, if you will, complacency)…creating and maintaining challenges is hard work. It’s easier to let everyone be a precious snowflake than it is to build pedestals for those who have earned the right to be recognized.

In the end, we believe accomplishment, and skill are good things, and they should be praised. They should certainly scale, and the reward should be equal to the accomplishment. But they should not be watered down, or diminished. So, what have we learned here?

If you do something awesome in Emerald Kingdom, myself..and the other staff will make sure the rest of the citizenry know, via mechanics, or forums, or the wiki. We also will not cavalierly throw your deeds into the fire of obsolescence by nerfing the challenge to open it up to a broader audience. (The only way I could see us modifying a puzzle, or a mechanic in such an instance is if there is a flaw, or it goes beyond our original design intent…but even then, we could never withdraw your accomplishment, and it would be noted regardless).

In the end, Emerald Kingdom should be about what all games are about: challenges, and how to meet them. We intend to try our damnedest to make sure that is in no way diminished.

What do you think about such a policy? How do you feel when your accomplishments are somehow diminished? Comment and tell us!

azrael_headcon

A couple quick blurbs on Exploitative Engineering and Ethics.

0
3 months ago
by Azrael in , , ,

1) Adamatomic has his say here.

And..

2) Tim Rogers hit the nail on the head here, with a pile driver.

 

I ask the simple, and honest question, when it comes to ethical and moral values in game design.

 

Could Pavlov’s experiments with dogs, be considered a “game” for Pavlov, the Dogs, both or neither?

 

  • If it is a game, why is it so hard to accept that a lot of F2P games are engineered to provoke a conditioned response from the people who play it?
  • If it’s not a game, then why is it so hard to accept that a lot of F2P games are engineered to look like a game, but are in actuality simply very pretty condition/response systems?

 

Why is it, some folks have such a hard time understanding that there is a difference between something that is fun, and something that is psychologically engineered to elicit a response?

And before you start in with “people have a choice”…you’re ignoring the last 100 years of scientific research into getting people to do things counter to free will. Choice can be directed, engineered. There’s a reason why psychological warfare, propaganda and push polls , and even Three Card Monte and The Shell Game work. I get why people use “Free Will” as an counter argument here…we like to believe we’re always in control. We have trouble as human beings, admitting and accepting that we can be manipulated, that while we have reason, and logic…we’re also animals…

Now, if you think psychologically engineering conditioned responses from people is in any way ethical when it comes to game design, and contributing positively to the art and mechanical design of game play…please do us all a favor…find another industry. Or rather, go back from whence you game: wall street and brokerage houses. Those are the places where mathematically and scientifically engineering money is accepted practice.

Just my $0.02.

 

Raguel-headcon

The definitive guide to why executable evironments are never “dead”

0
4 months ago
by Azrael in ,
By: Azrael & Raguel

There has been much hay made of the recent announcement over Windows 8 Metro not having support for all plugins. While this is an interesting move by Microsoft, it’s not completely unexpected. Like many they are enamored over the promise of HTML5, and what it can do. However, this has re-ignited the “Flash is dead” idiocy across the internet.

Yes, it’s idiocy. Hand-waving freak-outery aside… I’ll go one further: proclaiming an executable environment dead instantly shows to the world that you do not understand the technical issues of the debate, in which case you should really stop posting. Or, to put it in the way Raguel put it: Flash has evolved, but the arguments have not. Talking about Market Share, native support for Execution Environments… irrelevant. Especially when it comes to the PC.

Why is this lunacy? Because, for the most part, true native support for outside code interpretation has always been something that is an add-on. The argument that “Flash is dead” conveniently ignores the fact that Flash is no longer just a program for making banner ads. It shows a complete and utter lack of understanding of how Flash has evolved, along with the Flex environment, AIR, and ActionScript 3.

To understand it, you need to understand the underlying components of what makes Flash, Flash:

  • ActionScript 3 is an ECMAScript-based, compiled, Object-Oriented programming language. It’s syntactically very similar to its sibling JavaScript (another ECMAScript-based language).
  • ActionScript is compiled into bytecode into a SWF file.
  • The ActionScript Virtual Machine is the interpreter/run-time environment for compiled ActionScript programs.
  • Adobe AIR, the Adobe Integrated Run-time, provides support for JavaScript, ActionScript, MXML, and HTML to be used to build Rich Internet Applications which can run in a browser or as standalone desktop applications.

Now, let’s take a look at Java:

  • Java is a compiled, Object-Oriented programming language. Syntactically, it’s very similar to its predecessors, C and C++, and even moreso to its sibling C#.
  • Java is compiled into bytecode, in the form of a JAR file.
  • The Java Virtual Machine (JVM) is the interpreter/run-time environment for compiled Java programs.

The similarities do not end there either. Here are some fun quotes about Java from 1998 (bold emphasis is ours):

JAVA truly is the great equalizing software. It has reduced all computers to mediocrity and buggyness.

–Anonymous at NASA

There are a few things that are in the way of Java becoming a well-established platform for applications. IMO, one obstacle is the CLASSPATH stuff. Another is the fact that applications are not as easy to install as native ones. Performance is a consideration too, of course.

–Jose H. Solorzano on the advanced-java mailing list

Standards are, among other things, supposed to provide islands of stability with a minimum life of five years. Currently Sun seems to be shipping new (not entirely compatible) releases of Java every year. To my mind that is clear evidence that the product is not yet stable enough to be standardised.

–Francis Glassborow on the SC22JSG mailing list

Sure, Java’s great for distributed enterprise applications, and maybe even for embedded systems, but it simply hasn’t lived up to its promise of “write once, run everywhere.” And on the Web, even the smallest Java applets drive surfers crazy as they wait for their Java Virtual Machines to load. That’s why many people turn off Java in their browsers. They’re simply unwilling to wait for something that isn’t that interesting in the first place. And let’s face it, the vast majority of Java applets on the Web are a drag. Most Java applets don’t do anything but look cool.

–Fredric Paul

Java on the client doesn’t work, and we at Netscape have done an about turn on client-side Java in recent months. But on the server side, Java is taking off quite quickly.

–Marc Andreesen

So Java applets crash my browser, and the Java technology that’s supposed to be cross-platform plainly isn’t. A good portion of the blame for this surely belongs to Sun; the company has declined to release its hold on Java to an independent standards body, and Sun and Apple have been extremely late in delivering this so-called cross-platform technology to Mac users.If this is what Java is all about, I’ll take decaf.

–Joanna Perlstein

And on and on and on… But wait! Java is still in use practically everywhere. Java didn’t die then, and it’s certainly not dead now. Proclamations of it’s demise were, at the time, greatly exaggerated. Even if you count Microsoft’s attempts to Embrace, Extend and Extinguish Java. Java, in the mid to late 90′s was just as — if not more than — reviled as Flash is now. It was proclaimed dead many times. It was slow, buggy, inhibited performance of the browser, crashed browsers (and machines). Yet here we are today. Java is still around. Contrary to the worries of the pundits, it’s thriving.

Starting to see where this is going?

Now, let’s look at some other examples.

  • Perl is a high-level, general-purpose, interpreted, dynamic programming language.
  • Perl requires an interpreter, which is not included with Windows, in order to run Perl scripts. This must be installed by the user.
  • It is also dead. Though the Perl is not dead campaign is gaining momentum.

How about another?

  • Python is a high level, general-purpose multiple paradigm programming language.
  • Python requires an interpreter which is not included with Windows, and must be installed by the user.

When you begin to understand the technology, you start to realize Flash is not just about the Flash IDE, creating easy SWF’s with tweened graphics for a banner ad, or a menu bar on a website. If you don’t understand by now that Flash’s core ActionScript is an Object Oriented language executable environment then you do not have the technical knowledge required to make a judgement on technology.

Alternative executable environments are a staple of modern computing. They almost never ever die. Proclaiming that one is dead is akin to announcing to the world, “I’m an idiot who does not understand technology” while wearing nothing but clown shoes and chaps. Think we’re wrong about this?

Try this on for size:

  • While the original DOS was an operating system (and we use that term loosely) at the core these days, it’s a code execution environment. Good Old Games, Steam and others bundle DOS Box to run legacy games. While DOS is no longer supported by Microsoft, it still lives on to this day.
  • Z80 Environments, which have a long and storied history, live on in the MAME Project. MAME is the Multi Arcade Machine Emulator. Like DOSBox, it’s a legacy code execution environment.
  • Many other computing environments have been virtualized and have homebrew communities, like Atari 2600, NES, and others.

These are examples of how environments to execute programs never really go away. But let’s get back to this argument over how a lack of native support somehow is a death knell for these environments. People who make absolutist arguments about technology are the ones who typically have no grasp of technology beyond their own limited scope. They suffer from a very real tunnel vision. There are dozens, if not hundreds of sites offering cheap Apache/PHP hosting. Does that mean Perl is dead? How about the Microsoft IIS server? Apache is still in the lead. Especially when you throw in Tomcat. Does that mean IIS is an ailing and dying duck? No.

A lot of the arguments made about Flash these days (Sadly, by many an Apple fan, and others who should know better) are the same as the ones that were being shouted out back in the 90s when Gil Amelio was at the helm at Apple. Apple’s dead. They’re not relevant, they aren’t used in business, Microsoft won. Without vendor and software support, Apple is doomed. Yet, look at where they are today. (Disclosure Note: Azrael was once a devout Mac head, who spent many years in the wilderness with a PowerBook, and other assorted hardware, and still has his Newton. Raguel laughed when Apple died and now lives on current Apple laptops, and owns a half-dozen other devices in the Apple ecosystem.)

The problem with absolutist arguments when you work in technology is this: they preclude you from understanding the most basic rule in technology, which is use the right tool for the job you have before you. It also keeps you from seeing something else: technology evolves and matures.

When you start talking about a lack of native support in this context…you already lose the argument. We have news for you: with every Windows machine any of us have ever owned, We have had to install the Sun (now Oracle) branded Java JRE/JVM to run the things we want/need. You’re often auto-prompted to do so. We have installed the AIR framework to run AIR Apps, prompted to do so when the things needed to run the apps are not there. Like TweetDeck (which is a standalone app, btw)…which have no bearing on browsing. Oh, and we install Chrome, Opera and FireFox. With Chrome or Firefox being often being selected as the default browser. We rarely, if ever use IE. So, native support is not an issue here when it comes to non native code execution environments. It does not matter what Microsoft does with Metro on Windows 8. The landscape is not changing much, if at all when it comes to running the things you want to run.

Flash/Flex/ActionScript/AIR are far from dead. They will continue on, in spite of the continued pining of people who have not one jot of a clue.

With all that said, there are a few people who have pointed out the flip side to the coin. Seantron makes a very good point: Flash developers should be doing more to “get out of the box” that is the Browser. The “What Games Are” blog asked, “So where does this leave browser based games? Has Microsoft just announced their doom?” rather than just proclaimed doom and gloom. They also pointed out, this affects all browser games that are not HTML 5. While Flash is a most favored whipping boy…where does the no plugin policy leave Unity? By some people’s logic… Unity must therefore be dead. But, hey… Unity is a development environment, it has a code execution environment too. It uses a plugin! It’s not going to die anytime soon, and neither will Flash/Flex/AIR.

In closing, remember… absolutist statements when dealing with technology are often the telltale sign of someone who does not, in fact, understand technology. While some things may be more immediately apparent than others, remember this: at least once a day, your browser receives an answer from Perl, and PHP. You’ve received the results of Python in your time. You use Java more than you’re probably aware of. Every time you hit Armor Games, you’re using Flash. Oh, and for what it’s worth: most Flash games these days are not created in Flash CS. They are created using the Flex environment, or other open environments, or with free compilers outside of Adobe’s sphere.

There are a lot of people who think minimalist websites laden with quasi intellectual prose somehow stand as an authority to all that is. In our experience, it’s these types that talk a great deal, but say nothing. They’re willing to tell you the cost of everything, but omit the value of anything that stands in the way of their meager, tactless (and often factless) argument.

Despite Microsoft’s positioning, and in spite of the wishes of many, Flash, and its various components such as Flex, AIR, etc are going to be around for a long time to come. ActionScript and AIR are maturing, and getting better. So is Python, and Perl. (we use all three here). We apply the tech that makes sense for what we do. We do not make sweeping, absolute declarative statements when it comes to technology. Nobody should. When you see people do this, remember…it’s a sign they do not understand what it is they are talking about.

Ja Mata!

EDIT: It seems Microsoft has indeed clarified this positon: “Open distribution: retail stores, web, private networks, individual sharing, and so on” will be allowed, Microsoft says. Metro apps, on the other hand, will be “Distributed through the Windows Store. Apps must pass certification so that users download and try apps with confidence in their safety and privacy. Side-loading is available for enterprises and developers.”

Which basically nulls the “flash is dead” debate. The debate over whether or not a company should have the right to control what you may, or may not install on a mobile device is a separate one, and is still raging hard. 

Raguel-headcon

Building StoryTeller: Using Make to Compile Flex Projects

0
5 months ago
by Raguel in

I’ve been a Unix guy since I got my first custom computer. I am a king of the command-line, a die hard text-only advocate. I think in Vim and Bash, so it’s only natural that I use the command-line Flex SDK to build StoryTeller and SwfConduit.

However, the Flex SDK doesn’t have the convenience of the other Flex build systems. To build a SWF is one command (mxmlc). To build an AIR app from a SWF and an app.xml document is another command (adt). To test the AIR SWF is another command (adl). These commands must share similar configuration options, so it’s only natural to want some kind of script or program to handle that for
you.

GNU Make is a general build system. Given a set of “targets” (built files), a list of prerequisites for that target, and a set of instructions, Make will perform the necessary steps to build your software.

Say you have yourapp.mxml, and you want to build yourapp.air manually. You would have to perform three steps:

  1. Generate yourapp.swf from yourapp.mxml using amxmlc (for an AIR app)
    amxmlc -sp+=. -l+=. -strict=true -debug=true -o yourapp.swf yourapp.mxml
  2. Ensure a yourapp.pfx certificate exists to sign yourapp.air
    adt -certificate -cn yourcompany.com -ou YourApp -o "Your Company" -c "US" 2048-RSA yourapp.pfx yourpass
  3. Generate yourapp.air from yourapp-app.xml, yourapp.swf, and yourapp.pfx
    adt -package -storetype pkcs12 -keystore yourapp.pfx -storepass yourpass yourapp-app.xml yourapp.swf

To do this with a Makefile, we would do the following:

yourapp.air : yourapp.swf yourapp.pfx
	adt -package -storetype pkcs12 -keystore yourapp.pfx -storepass yourpass yourapp-app.xml yourapp.swf
yourapp.swf :
	amxmlc -sp+=. -l+=. -strict=true -debug=true -o yourapp.swf yourapp.mxml
yourapp.pfx :
	adt -certificate -cn yourcompany.com -ou YourApp -o "Your Company" -c "US" 2048-RSA yourapp.pfx yourpass

Once we have this saved as “Makefile” in the same directory as our source, we can simply type make at a command-line and it will create “yourapp.air”.

There are three sections to this Makefile, called “targets”. Each target is a different file, either yourapp.air, yourapp.swf, or yourapp.pfx. Since yourapp.air is the first target, it is the default target, so typing “make” with no arguments will build yourapp.air.

After the target file comes a colon and then an optional space-separated list of prerequisites, which are other targets that must be completed before the current target can build. So, in order to build “yourapp.air”, we must have already built “yourapp.swf” and “yourapp.pfx”.

After the prerequisites list we put a newline, then a tab, then the command that should be run to build the target. For example, to build “yourapp.swf”, we invoke the amxmlc command with some options.

Using Variables

Like most Unix tools, Make has plenty of flexibility for writing consise, easy-to-maintain Makefiles. The first thing we should probably do is use variables instead of copying the same strings in multiple places. This will allow us to simply re-use the same Makefile for multiple projects by changing a few configuration values.

You should put variable declarations at the top of a Makefile. Variables are declared simply with VARNAME = VALUE, like so:

AIR = yourapp.air
SWF = yourapp.swf
CERT = yourapp.pfx
MXML = yourapp.mxml

Once we’ve declared the variables, we can use them as either targets or substitutions in our commands using $(VARNAME).

$(AIR) : $(SWF) $(CERT)
	adt -package -storetype pkcs12 -keystore $(CERT) -storepass yourpass yourapp-app.xml $(SWF)
$(SWF) :
	amxmlc -sp+=. -l+=. -strict=true -debug=true -o $(SWF) $(MXML)
$(CERT) :
	adt -certificate -cn yourcompany.com -ou YourApp -o "Your Company" -c "US" 2048-RSA $(CERT) yourpass

While we’re at it, we should probably replace most of our commands with variables. Doing this will make our commands re-usable in other Makefiles.

AIR = yourapp.air
SWF = yourapp.swf
SWFOPTS = -sp+=. -l+=. -strict=true -debug=true
CERT = yourapp.pfx
CERTINFO = -cn yourcompany.com -ou YourApp -o "Your Company" -c "US"
CERTTYPE = 2048-RSA
CERTPASS = yourpass
MXML = yourapp.mxml
APPXML = yourapp-app.xml

$(AIR) : $(SWF) $(CERT)
	adt -package -storetype pkcs12 -keystore $(CERT) -storepass $(CERTPASS) $(APPXML) $(SWF)
$(SWF) :
	amxmlc -o $(SWFOPTS) $(SWF) $(MXML)
$(CERT) :
	adt -certificate $(CERTINFO) $(CERTTYPE) $(CERT) $(CERTPASS)

Now we can split our Makefile into two parts, the first part setting up the variables for this project, the second part included from a common directory.

# Makefile
AIR = yourapp.air
SWF = yourapp.swf
SWFOPTS = -sp+=. -l+=. -strict=true -debug=true
CERT = yourapp.pfx
CERTINFO = -cn yourcompany.com -ou YourApp -o "Your Company" -c "US"
CERTTYPE = 2048-RSA
CERTPASS = yourpass
MXML = yourapp.mxml
APPXML = yourapp-app.xml
include Makefile.flex
# Makefile.flex
$(AIR) : $(SWF) $(CERT)
	adt -package -storetype pkcs12 -keystore $(CERT) -storepass $(CERTPASS) $(APPXML) $(SWF)
$(SWF) :
	amxmlc -o $(SWFOPTS) $(SWF) $(MXML)
$(CERT) :
	adt -certificate $(CERTINFO) $(CERTTYPE) $(CERT) $(CERTPASS)

Now, Makefile.flex can be symlinked to multiple projects, since it doesn’t
have to change at all!

A Challenger Appears: Make on Windows!

I said I’m a Unix guy, but unfortunately I’ve had to switch to a Windows 7 laptop for a couple months now. Luckily for me, Windows has a Linux environment available called Cygwin! Unluckily, getting Cygwin to work with
the Windows Flex SDK, Java for Windows, and Ant for Windows took some hacking.

I installed Flex, Java, and Ant from their vendors using the Windows versions. I installed Cygwin making sure to include GNU Make. However, using the same Makefile I used on my OSX laptop ran into some puzzling errors: Unable to access jarfile /cygdrive/c/flex/lib/mxmlc.jar when that file definitely exists in the Cygwin environment.

It turns out that using the Bash scripts from the Flex SDK for Windows doesn’t work in the Cygwin environment, mainly because Cygwin has to map C:\flex\lib to a proper Cygwin Unix-like directory path, /cygdrive/c/flex/lib. So to make the Flex SDK work under Cygwin, we have to make sure to use the Windows-specific batch files and executables so that all the paths are found.

To make this simple, we will replace our commands (amxmlc and adt) with variables, then use an optional include file to override those variables on our Windows machines. If the optional include file doesn’t exist, we’re on a Unix system and everything works. If the optional file does exist, we’re on a Windows system and everything works.

In our Makefile.flex, we’ll change our commands to use variables, like so.

# Makefile.flex
ADT = adt
AMXMLC = amxmlc

$(AIR) : $(SWF) $(CERT)
	$(ADT) -package -storetype pkcs12 -keystore $(CERT) -storepass $(CERTPASS) $(APPXML) $(SWF)
$(SWF) :
	$(AMXMLC) -o $(SWFOPTS) $(SWF) $(MXML)
$(CERT) :
	$(ADT) -certificate $(CERTINFO) $(CERTTYPE) $(CERT) $(CERTPASS)

Now we’ll add an optional include for a Makefile.cygwin. The – in front of include means “ignore any errors, like if the file doesn’t exist.”

# Makefile.flex
ADT = adt
AMXMLC = amxmlc
-include Makefile.cygwin

$(AIR) : $(SWF) $(CERT)
	$(ADT) -package -storetype pkcs12 -keystore $(CERT) -storepass $(CERTPASS) $(APPXML) $(SWF)
$(SWF) :
	$(AMXMLC) -o $(SWFOPTS) $(SWF) $(MXML)
$(CERT) :
	$(ADT) -certificate $(CERTINFO) $(CERTTYPE) $(CERT) $(CERTPASS)

Finally, if we’re on a Windows system, we’ll add our Makefile.cygwin:

# Makefile.cygwin
ADT = adt.bat
AMXMLC = amxmlc.bat

Now Cygwin will use the Windows-specific batch files from the Flex SDK instead of the Unix-specific shell scripts, but only on Windows.

—

I’ve only recently started using Make to build projects, and it is an incredibly powerful tool.

If you have any questions about using Make with your own Flex projects, or if you have ideas for how to improve these Makefiles, let me know in the Emerald Kingdom Developer Forums.

For more information about GNU Make, see http://www.gnu.org/software/make/

azrael_headcon

How stuff is designed here…

0
5 months ago
by Azrael in , , ,

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.

Designing Thrynity was all about finding references.

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.

Go to Top