Which reminded me I had never linked it here on my blog! So if you’re curious about why components are a great fit for games, I encourage you to watch my 5 minute video above, and check out the resources linked in Steffen’s post.

I will be doing a BYOL session at Adobe MAX 2009. It’s a lab where you learn how to build a platformer in Flash in 90 minutes, and it’s Wednesday at 4pm. It is titled “Build a Flash Based Platformer in 90 Minutes” in honor of its subject matter.

It is pretty cool stuff, and I’m excited to be sharing it! You get introduced to the PushButton Engine, get a preview copy of Clint Herron’s excellent Platformer Starter Kit, and (assuming things go smoothly), you end up building this platformer:

(Click image to play demo)

We’re excited about it. 🙂

If you are a Flash game dev and at MAX or in the LA area, I’d love to talk games with you. Shoot me an e-mail (ben dot garney at gmail dot com) or DM me at @bengarney and let’s make it happen!

Also, with luck, Monday there should be a cool update on that secret project I was working on. 🙂

We’ve been trying different approaches for the documentation for PushButton Engine. We have reference docs, API docs, and tutorials. There are comments at the class, function, and body levels. There are example applications of varying size and complexity. There’s still a lot more to document, but what is covered seems to be making sense to people.

Lately, I’ve been doing short – 5 or 10 minute – Keynote presentations, recording them, exporting them with the iPod video export option, and putting them up on YouTube. They’re a nice workout for presentation skills; I spend an hour or so building a slide deck, then run through it a few times before recording and uploading. They also seem to be a good way to explain high-level concepts about PBE.

Speaking of presentations, I will be talking about Developing in the Cloud at Austin GDC this Friday, 4pm. Talking to game developers, I have noticed there is not a lot of awareness of how cloud computing can help cut budgets, shorten development time, and increase features. We’ve been using cloud resources heavily at PushButton Labs, so the talk will cover the risks, rewards, and tradeoffs related to things like EC2, S3, Google’s services, SVN hosting and so forth in terms of letting you focus on your game. I’ll also talk about how you can directly integrate things like Google Spreadsheet and Analytics directly into your game, and why it is a good idea to do so.

I’ll be at Austin GDC Wed-Fri. If you want to meet up and talk cloud computing, Flash game dev, or PBE, shoot me an e-mail, tweet, or comment and let’s make it happen!

Like this:

Our latest game, Grunts: Skirmish, has 200 tweakable parameters. There are 9 player units with three levels of upgrade, and another 9 enemy units. Each unit has between three and ten parameters that can be altered.

We tried a few approaches – hand-editing a large XML file (but it was too large and spread out) and an in-game tweaking UI (but it was too much work to get the UI to be friendly to use). The old standby of having the designer and artistfile bug reports to have the programmer update the game wasn’t getting us very far, either.

“Well,” says I, “We’re some sort of Web 2.0 startup, right? And we’re developing a Flash game aren’t we? And Flash can talk to websites, can’t it? And don’t we use Google Docs for everything?”

It turns out there is an XML feed from public Google spreadsheets. And ActionScript 3 supports E4X, so you can directly manipulate XML without any extra work. Now we tweak our game using a shared spreadsheet up on Google Docs.

And wrote a quick component that would fetch the spreadsheet feed, parse it, and stuff it into the right places on named objects or template data. Now I have a little entry in our level file that looks like:

Each line maps a cell in the spreadsheet to a property on a template or active game object. Some properties have to be set several places, which the system deals with automatically.

The biggest wrinkle was Google’s crossdomain.xml policy. Basically they do not allow random Flash apps to access their site. So I had to write a small proxy script, which sits on our development server next to the game and fetches the data for it. Figuring out I had to do this took more time than any other step.

The main difference between the snippet and the full code is the version in our repository is 220 lines long. I only have around 150 of the full set of 200 parameters hooked up, but after a hard afternoon’s work, the process for tweaking the game has become:

Open Google Docs.

Edit a clearly labeled value – like level 1 grunt health.

Restart the game, which is running in another tab in your browser.

This takes you about a minute between trials. Not too bad. Before this, the process was:

Get the game source from SVN.

Find the right XML file – there are several.

Find the right section in the XML – altogether we have 200kb of the stuff for Grunts!

Change the value.

Commit the change.

Wait 5-15 minutes for the build system to refresh the live version of the game.

Ten minutes per tweak is not a good way to develop.

I’ve heard about developers using Excel spreadsheets for tweaking, but can’t find anything about using Google Docs to do it. But Google Spreadsheet is obviously a better choice. It has built-in revision tracking. You can edit it simultaneously with someone else. You can access live data in XML either publicly (like we did) or privately via their authentication API. It’s absolutely worth the half-day of your time it will take to add Google Spreadsheet-based tweaking to your game – even if it’s a non-Flash game, downloading and parsing XML is pretty easy with the right libraries.

I strongly suspect this feature will find its way into the next beta of the PushButton Engine. Which, by the way, you should sign up for if you are interested in developing Flash games. We’re bringing people in from the signup form starting this week. If you want more information, or just like looking at cool websites, click below to check out the new version of the PBEngine site, which has a bunch of information on the tech. Tim did an awesome job on the site design.

Edit: Patrick over on the GG forums asked about the proxy script. It’s actually ludicrously simple. Not very secure either so I wouldn’t recommend deploying it on a public server. I got my script from a post on Aden Forshaw’s blog. In the real world you would want to have some security token to limit access to your proxy script… but since this is for tweaking a game that is in development I didn’t sweat it.

Buy My Game!

Solve Your Problems!

I've developed a love for consulting and run The Engine Company. We solve hard problems in AR/VR, embedded systems, internet video, mobile/IoT, cloud/backend, game technology, fractional CTO and a lot more. Visit our site for more info.