Why Scaleform is a Bad Idea


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.


Comments Off on Why Scaleform is a Bad Idea more...

Rainbow Ball now available on PC

 I had not intended on doing it, but someone asked so here it is:

Rainbow Ball into Adventure for PC

It comes with no guarantees!

If you have a Windows Phone 7, I highly recommend getting it for that.  The controls ended out working really well.  It is also available in its pure original form for Xbox 360 Indie games.

Special thanks to Elwood ( for letting me use his song “Sunshine“.

The game plays best on PC with an Xbox 360 controller. If you use the keyboard, A, S, W, D, SPACE, Y, and J do stuff.

No, I do not plan to fix or update the game.


Comments Off on Rainbow Ball now available on PC more...

Caster Multiplayer

And so it begins…

New Voxel Based Game “Lexov”

So I’ve decided to take a little diversion from work on Caster… again… and make a small multiplayer voxel based shooter.  The development name is Lexov, but it will not ship with that name.

I have this trailer for Lexaloffle’s game Voxatron to blame for this diversion:

Pretty cool, eh?  Get more details here:

I’m targeting Xbox 360 via Xbox Indie Games.

Working on this game with C# on the 360 has some interesting problems that have been quite a bit of fun to try and overcome.  For example, say I have a 128 x 128 x 64 volume of voxels.  Simply walking across that volume of voxels requires over a million operations.  Doing one million operations alone in C# on the Xbox brings my frame rate down to less than 30 frames per second (just write a for loop and increment a local variable to see what I mean).

Here is an early version of Lexov where I am evaluating the voxel volume and adding the appropriate geometry for rendering:

Because of the performance issues with C# on the Xbox, I’ve had to get pretty creative in my approach.  I’ve started using approaches that reduce the number of operations that need to be done while favoring doing more work on the GPU (Graphics Processing Unit).  For example, in C# on the 360, it’s faster to draw an extra million triangles to save several thousand instructions per frame.

Currently, I’m using several dynamic vertex buffers and updating changes to the buffers as they happen in the game rather than evaluating the entire voxel volume each frame.

One important difference when using this approach is that I no longer have to render cubes on voxel boundaries.  This breaks some of the retro feel from being a true voxel volume, but allows for much smoother movement.

At this point I had to ask myself what it was that I really wanted to do with this game.  I decided that what I really wanted was a simple fun destructible environment game at 60 frames per second on the Xbox 360.  As cool as evaluating a single voxel volume would have been, it was secondary in importance.

Still, it’s hard to sacrifice the simplicity and beauty of the single voxel volume approach.  In the end, I’m actually very happy to have sub voxel movement in the game.

Here are some more videos of progress I’ve made.

And earlier today:

I’m going to try and keep an active blog on my Lexov’s progress.  I’ve been debating if the extra time to write blog posts is worth it when I could spend that time working on the game.  I’ve decided that if I get extra feedback and community support from doing the posts, then it will make for a better game.  Caster is a great example of this.  Caster would have been pretty lame and boring were it not for the amazing feedback I got while showing the game off to friends and colleagues.

More details on the plans for game play and design forth coming.


Bring on the Bevel!

Lately I’ve taken a break from Caster and have been focusing my “side project” time on SmithGame.  SmithGame* is a game I’m making with my kids.

*Disclaimer: It was named by my kids and I did try to talk them into a better name but to no avail.

The game was greatly inspired by Katamari Damacy <Tangent>It’s a game my entire family including my wife adores and one of three reasons I purchased a PS2… the other two being Shadow of the Colossus and the numerous PS2 demo disks that used to come in Playstation magazine… good stuff… </Tangent>

Anyway, I didn’t plan to spend tons of time on this project, but there are some things that are worth the extra time spent.

For example, I spent the past four sittings implementing procedurally generated beveled cubes.

Was it worth it?  See for yourself:

Before Bevel

After Bevel

I think the amount of extra polish something like this gives the game is significant.  Plus it was a lot of fun figuring out a good way to handle the corners–their triangle arrangement etc.  Yes, I could have spent much less time making one in a modeling program… but that’s not as much fun so I didn’t.

It’s been a while since I’ve done much with 3D geometry and mesh manipulation and it felt really good to get back into it a bit.

Anyways, for those of you interested in looking at the very-slow-non-optimized-code-because-I-only-run-it-once-at-startup, you can download the code below (look at CustomModel):


Comments Off on Bring on the Bevel! more...

iPort Slides from GDC Austin


Here are the slides in several formats from our presentation on porting games to iPhone at GDC Austin.

The notes section on each slide contains the real meat of the information.

Bolded notes were bullet points for me while reading the slides since many of the slides just had simple pictures.

Hope you find the info useful!  Hopefully I’ll have a video up soon.  Thanks!

GDC Austin! iPort: How to Bring Any C++ Game to the iPhone

I’m heading off to Austin tomorrow morning to attend GDC Austin.

I will be giving a lecture on some stuff my friend and I learned while doing the iPhone port of Caster.

We hope that it will help other people considering porting their existing C++ games to the iPhone.

If you’re going to be at GDC Austin, look me up!

I’ll be posting the slides and notes after the conference.


Game in 10 hours with Unity 3D


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.

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

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  ( Xbox Live Communities / PC / Silverlight in the works, best developer support you will find anywhere.

Blade3d ( Xbox Live Communities / PC

Unity (  Mac, PC, Web Browser, iPhone, Wii

Viva la Indie!

Embrace your bugs

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.

Coding Conventions: Boolean Function Parameters.

Here is a coding convention that I have recently adopted and wish I would have adopted earlier. I would recommend it to all without exception. It is:

Use enumerations instead of boolean values as parameters to functions when there is more than one parameter.

For example these are okay:

Show(bool value);
Setup(ShowState showState, Orientation orientation, CollisionState collisionState);

These are not okay:

Setup(bool showOnStart, bool orientLeft, bool enableCollision);
Serialize(string filename, bool save);

Consider reading:

Setup(true, false, true);
Serialize(“myfile.bin”, true);

Vs. something like this:

Setup(ShowState::Show, Orientation::Right, CollisionState::Enabled)
Serialize(“myfile.bin”, SerializeOperation::Save);

Another advantage is that this opens things up later if you decide to add in more than one state for a variable.

For example, let’s say we wanted to add “Forward” and “Backward” to Orientation, or a “LoadAndWriteBack” to Serialize.

So there you go. A little gem to make your code better and your life easier.

1 Comment more...

Copyright © 1996-2010 Elecorn ® : The Animated Coder. All rights reserved.
Jarrah theme by Templates Next | Powered by WordPress