Elecorn ® : The Animated Coder

Studio XYZ is making a game.  They have experience making games and decide that they spend way too much programmer time on the user interface.  They decide to give a solution like Scaleform a try and are amazed with the nice looking visuals that they can get running with minimal programmer involvement.  They sign off on it and begin development.

Halfway through development the programmers (there are more than one working on UI now) start complaining about Scaleform and the artists are miffed they can’t do certain things that they thought they would be able to do.

Just before shipping the project, almost all the programmers on the team are smashing keyboards, cursing, and taking required “time away from the desk” when dealing with Scaleform.

So what happened?  Why all the frustration and anger?

The problem is that the development team was hoping to take what was normally an entire programmers full time job of doing boring UI work and move more of that work over to the artists.  The artists would be happier being able to have more behavioral control over the UI and the programmers would be happier because they don’t need to put an entire programmer on UI.

The reality is that Scaleform introduces so much complexity to the game engine that it ends up requiring work from several engineers just to stay on top of it.  It takes the “simple boring work” that the engineers were trying to get rid of and replaces it with a “hard to debug, memory hogging, performance sucking, obscure crashes in messy complicated code (providing you even have the source)” system.

The simple answer is:  Scaleform adds too much complexity.

In trying to make life easier, they made it more complex and costly.

So I gave myself and some of my friends a challenge to make a game in 10 hours.

My purpose for this was to have an excuse to finally try out the Unity engine for real.  Not just playing around with it here and there, but legitimately trying to make a real game with it.  Here is the result:

A, S, W, D and Arrow keys to move / shoot or use an xbox 360 controller.  You’ll need to download the small unity plugin for your browser if you haven’t already.

www.mikedsmith.com/Moderation.html

And here’s what Kyle Schouviller did using the Flat Red Ball Engine:

www.kyleschouviller.com/files/AcidBoots.zip

I went through the Unity tutorial and played around a little bit before getting started.

I had an idea for a game design… however, I never got to that point with this project.  I still plan on trying out the game design idea (probably with the Caster engine), but the main purpose of this was to take Unity 3D for a test run.

I met with the Unity Team a year ago at Casual Connect in Seattle.  At the time they were just starting to get some traction.  I was immediately impressed with their tech and paradigm for game development tools.

There are so many good things I can say about Unity, but I’ll just some it up with it’s done right and it’s awesome.

So where does that leave me with my Caster engine?  Well, I’m a “right tool for the job” kind of guy.  There are some things the Caster engine does better than Unity and some things Unity does better.  Depending on the type of project I do next, I could go either way…. I could, but I think I’ll just stick with the Caster engine.  More control (I can fix bugs in the engine instead of hoping Unity does it), better performance, super sweet features you won’t find in any other engine ^_^.

So when looking into what engines to use for your next indie project, I suggest you check out the following and see which one best fits your needs.  Prices vary, but FlatRedBall is free.

FlatRedBall  (www.flatredball.com) Xbox Live Communities / PC / Silverlight in the works, best developer support you will find anywhere.

Blade3d (www.digini.com) Xbox Live Communities / PC

Unity (www.unity3d.com)  Mac, PC, Web Browser, iPhone, Wii

Viva la Indie!

When I first started programming, a bug was an indication that something was wrong with the code.  While this is still true, I now look at bugs a different way.  I pretty much take a “glass half full” attitude towards them.

A bug is an opportunity to make your software better.  Instead of asking: “How could this happen? Who made this mistake?”, rather say: “What can we do to make our system more robust or safe so this doesn’t happen in the future”.  Sometimes it’s a code fix and sometimes a process fix.  But either way, finding a bug is an opportunity to improve in some way.

This attitude avoids the “quick and dirty fixes” and reduces occurrences of future bugs of the same type.  It lets you focus on other areas that need work resulting in better, more stable software.

So next time you get a bug, try asking yourself “What can I do so that I handle this type of thing better in the future”?

You’ll find that you actually get excited when things break because you’ll see it as an opportunity for improvement rather than evidence of a mistake.

For soooo many reasons. The root of which is them trying to do things the way they did 10 years ago because “there are some people that are used to that” (IE the user interface is a complete mess). That and Max crashing all of the time when it doesn’t know how to handle what you give it. So yeah, terrible user interface and poor stability.

However, I really like maxscript for the power it gives you and for all the sweet utilities.

Looks like I’m going to have this love hate relationship with it for quite a while because our studio is using Max as its principle modeling package.

Why can’t we just use Maya, Softimage, or even Blender *sigh*