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.

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):

ModelManager.cs

The release of the next update for Caster is fast approaching so, time to make another t-shirt design!

I’ve always liked the negative space design ideas for t-shirts where the color of the shirt becomes a dominant factor in the design itself.  Here’s an example of a favorite t-shirt of mine from back in high school:

I’ve also liked the idea of an unbalanced composition where the design sits on one side of the shirt.  Here’s an example of a design I did back in 1998.  The idea was that the picture should sit on the left side if the shirt.

And here’s what I just finished for Caster.  The black is replaced with the color of the t-shirt (preferably a dark color for higher contrast).  And since this is a “Caster” shirt, the white is of course glow in the dark.  (Click image for larger view).

Now who wouldn’t want a shirt like that!

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!

http://www.elecorn.com/mikedsmith/data/iPort_GDC_Austin_2009.key

http://www.elecorn.com/mikedsmith/data/iPort_GDC_Austin_2009.ppt

http://www.elecorn.com/mikedsmith/data/iPort_GDC_Austin_2009.pdf

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.

Thanks!

My first job in college was to create several dozen 16×16 icons for an engineering software package.  Obviously at this level you work per pixel since every pixel counts.

In the app store, icons need to be 57 x 57 pixels.  While this allows you to do quite a bit, it’s still a small space to work in.

When designing the icons for Caster, I wanted to convey a sense of movement and power as well as display something representative of the game.

Here’s the icon I came up with for the first version of Caster:

While I like this icon because it’s clear, I don’t really like how it looks.  I decided to do a new icon for the next update for Caster using this source art:

Click HERE to download a high res version.

Here are a few icons I came up with:

I think I’m going to go with with the last one.

Hopefully this will help it stick out a bit more.

Which icon is your favorite and why?

Last year at Casual Connect in Seattle, I met Omaha from iGame Radio.

Here’s a recent interview we did on Caster.

Enjoy!

http://www.igameradio.com/2009/07/09/podcast-ep-75-plants-vs-zombies-9-innings-and-elecorn/

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.

Here it is! The first public preview on Caster!

http://www.indiegamemag.com/2008/11/caster-preview.html

The chaps at the Indie Game Mag gave what I feel is a very fair assessment of Caster.

Based on their feedback (which is similar to some other feedback I’ve had before) I will be upresing some of the textures and increasing the poly count a bit on some of the models.

Thanks Indie Game Mag!