Hey folks,  we’ve been quiet this week so I thought I’d drop you guys a note and let you know that we’re not gone.  It’s a hectic week from a personal and professional aspect and we just have our noses to the grindstone.

A little preview of stuff coming up:  Right-Brain has a bug to do a little tutorial on the iPhone and getting 3rd party native apps running there.  I’m still working on part 3 of the AS3 game programming tutorial, and I’ve also started pondering an article on rsync. . .love that nifty little tool.

Anyway, stay tuned, we’re still here and working on bringing you guys some (hopefully) useful info.

LB

P.S.  Oh, two quick things: 1) I’ve updated the vmware-server backup stuff again.  If you’ve been keeping track, take a look.  2) I’m PISSED. . .You can’t make calls to native applications (ie, exec) with Adobe’s AIR product.  That irritates the hell out of me!

Welcome back. Today I’m going to give you a brief overview of the tools that I am using for developing a game in Actionscript 3.0. I’m also going to throw in a bonus paragraph or two and describe Quacker Whacker in more detail as I should have done in Part 1.

There are, of course, options for everything, but the tools I seem to have settled on are Flexbuilder 3.0 beta (free public beta until release, Flexbuilder 2 is fine also), Adobe Flash CS3, and Adobe Illustrator CS3 and Photoshop CS3(sort of, I’m very novice with the last 2).

Flexbuilder is my IDE, it’s based on Eclipse (my personal favorite) and does most of the nifty-cool things that an IDE should do; code highlighting, in-flight error checking, running the app, full debugger, etc. The one thing is doesn’t have, that I have been able to find is snippets - the ability to attach some tedious, often used bit of code to an expandable abbreviation. All of the Actionscript coding is done here, along with your frequent testing and debugging. It is NOT necessary to use Flexbuilder to create Flex or Actionscript applications, the Flex framework is free and contains command line compilers. However, the how-to on using the command line stuff is beyond the scope of this article and is covered heavily in other books and sites.

The 2nd piece of the puzzle is Flash itself. I know. . I know, in the intro article I said that is what I was trying to avoid. The reason I wanted to avoid it though is because it’s not designed for programmers to create large amounts of code. It was, however, created for animators and graphics geeks to do what they do best, and in that, it excels. So, yes, I do use Flash, but I’m only using it to create my animated assets which are then imported in the game as objects that I am free to instantiate and use as I see fit. It’s really very cool. I’ll be covering how to create an asset in Flash, export it to Actionscript, and using it in the game (from a very novice graphics standpoint).

The final tools mentioned are Adobe Illustrator CS3, and Adobe Photoshop CS3, and mentioning them is about all I’m going to do. If Mr. Right-Brain is interested in doing an article on them I would encourage that. But I’m very much a novice and would probably do you more harm than good ; ) They are being mentioned, however, as these tools, or tools like them, are very important in this process for making really super-duper graphics, especially when you start making games that you want the public at large to enjoy. Typically the base graphic assets would be created and tweaked with these applications before moving them into flash for animation.

So, those are the tools in a nutshell. Now for the bonus material. What is Quacker Whacker?

As I mentioned in the intro article, Quacker Whacker is a knock off of the old Galaga/Space Invader type games. There’s a formation of ducks that fly across the screen. While making this journey they have the potential to poo or to drop eggs. The hunter is at the bottom of the screen and is able to shoot the ducks with one of 3 types of rifle, semi-automatic, automatic, or shotgun. If the hunter is hit by a poo, splat, he loses a hat (life). If the hunter catches an egg, he is gifted with a bonus. . .score, new gun, ammo, extra hat (life), etc. When the flock goes off one side of the screen, the flock will drop down a bit, turn around and cross the screen in the other direction. The hunter gets bonus points when he shoots the entire flock. The earlier he does this, the higher the bonus. Finally, it’s not implemented yet, but there are plans for a Hawk that will dive at the hunter. The hunter must shoot the hawk or be got by it. There will be a large bonus for shooting the hawk. That’s the basics of the game.

That’s it for this installment. Join me again next week when we will discuss the basics of creating a game. The various screens, game manager, game loop, etc. There will be code (finally)!!

See ya then!!

Adobe Flash content. . .it’s everywhere. Can’t hardly look at a web page without seeing some, and it makes up an astounding chunk of the casual games market. It’s installed on damned near every single individual’s machine, and it’s kept current by the Flash update mechanism. It’s been around forever, had very few problems (that I’m aware of), and is just about universally trusted as an interactive content delivery mechanism (as well as loathed as an ad delivery mechanism . . .who cares how many bananas I can peel for a free iPod? hehe, whatever!)

This, friends, is obviously the place to be if you want to create software in the casual games space. However, there is one BIG historical problem. Creating games in the Flash application, via the time-line concept, is not very intuitive for us “real” programmer types if not down right confusing*. It’s definitely something that’s easier for the designer types, and has provided them with incredible opportunities to break into that space. However, times are a-changin’. With the introduction of FlexBuilder 2.0, Actionscript 3.0, and Flash CS3, us software engineering types can finally get into the game with gusto. And let me tell you something. . .I, for one, am LOVING it!

So, I guess I’m going to try and share the love a bit. I’m just about finished writing a game called Quacker Whacker. It’s a loose and wholly silly take off of the Space Invaders/Galaga platform games and was conceived and created strictly as a learning project for this technology. The goal was to do it strictly as a coding (AS3.0) project, not a bunch of Flash, etc. I have deviated from this a bit and used Flash to develop my animated assets. Flash is NOT necessary, but I think it’s a very strong and complementary tool in this context. I think as we go on, you’ll probably agree.

In these tutorials I will cover a number of topics that are specifically related to this technology. It is not my plan to get into good game design (which this game doesn’t demonstrate anyway : b), coding practices, how to create the Flash assets (aside from what’s important with this specific set of tools), etc. This tutorial will not be a 0-100 walk-through of creating the game. However, I will be providing complete sources (code, and assets), and the game itself will be available to check out.

I think that pretty much wraps up the introduction. It is my intention to post a new section of the tutorial at least once a week for the next 3-4 weeks. The next section to come next week will look at the tools we’re going to be working with, including: FlexBuilder, Flash CS3, and Illustrator.

LB

P.S. If there’s something you are interested in seeing in the tutorial, let me know. I don’t have it completely developed yet so there’s room for additions and now is the time ; )

* I know I’m leaving out some technologies that allowed you to programatically build flash content. But I’m pretty much a stickler for standards personally. So I just never totally warmed up to them.

If you’re interested in the vmware-server backup script, it’s been updated to include suggestions from you guys. Can see it here.

LB

Recently I’ve had the pleasure of developing a new dynamic navigation piece for the University we work for. This currently consists of a collection of somewhere around 300 separate Flash movies, and is obviously a challenge to maintain.

When originally tossing around ideas to complete this task, we rejected a javascript / css approach because the font we were required to use wasn’t standard. The navigation for the school’s site is enormous and complex, so an image solution is obviously a no-go as well. So, the (questionable) wisdom of our crew and The Whole Brain (Left and Right hemispheres, UNITE! Geek powers ACTIVATE! Form of a MICROPROCESSOR!) dictated that we go with a solution using Flash for the nav interface, our existing Postgres database to store all the info, and a Ruby on Rails application to populate the DB and serve the menu contents to the Flash navigation via XML. Yay! Sounds great…

Whooped my tired ass to implement. Let me tell you why, one problem at a time.

1.) Flash movies cannot resize from within.

I needed this thing to dynamically resize itself vertically. I didn’t even give this a second thought initially, and that was a mistake. (though not a big unrepairable one, also known as a “you’re fired” bug. Hate those. ) I thought this was going to be the most rudimentary ActionScript api call ever. I was wrong. So I scoured the web, no answers. Found a few people saying things along the lines of “can’t”, but with all the disparate technologies we have to work with on the web, I just wasn’t accepting this. So I pulled out my thinking cap, my JavaScript Super-Bible 9000, and got to work.

Long story short for everyone who got bounced here from Google and need the quick answer: yes, you can do this, but it requires a little bit of weirdness, and if you can stand a little “flash” when your movie loads (think camera flash, not Macrodobe Flash), it gets simplified. If you’re a perfectionist as we tend to be around these parts, well, it gets even a little more kludgy. But, it works, and the people upstairs could really care less about how kludgy I think my solution is… With that nice wordy intro behind us, here’s how to make it happen.

On the page that needs this resizing movie, I have one single JavaScript function call, and two external JavaScript files pulled in. One has all my code, and the other is a nice little library that is located here:

http://blog.deconcept.com/swfobject

Grab the download over there, and yank out swfobject.js and throw it in your working dir.

If you are dealing with Flash, this script makes movie deployment to the page way more pleasurable, but even more than that, it gets rid of the Internet Explorer issue that requires users to click the movie before it starts doing anything (ooooh, I feel so… protected. Trojan, eat your heart out.) AND gets rid of that ridiculous border with no user intervention. For the price (free!) you can’t beat it. It does some other neat stuff too, so check it out.

As of now, we have our .html file (or whatever variant: php, asp, rhtml, it really makes no difference), our custom js file (which I named flash.js), and our swfobject.js file from deconcept. If you need code for this, fine, be that way you lazy monkey. Here’s what should be in your <HEAD> somewhere:

1
2

<script src="/javascripts/swfobject.js" type="text/javascript"></script>
<script src="/javascripts/flash.js" type="text/javascript"></script>

See, that’s not so bad! (yet…)

The next thing you want to do, is set up a DIV element on your page where you want your movie to show up. Using a DIV keeps the area flexible, easy to target, and just so happens to be the way swfobject.js is designed to work. Within that DIV, we are going to put the single call to our super-do-it-all function. We will also give our DIV an id of our choosing. I choose “dynamovie”! Here’s the code, add it to your HTML file.

1
2
3
4

<p id="dynamovie">
<script type="text/javascript">
  showMovie();
</script>

See, that was easy as well! (for now.)

For our purposes, our work with the HTML file is complete. Now we move on to the meat, the flash.js file.

This is where we start to get naughty. What we’re going to make happen here is this: the Flash movie loads, by the time it’s done, it knows what it’s height should be. At this point we call to the JavaScript super function from within our Flash movie using getURL, and build it all over again, but this time, displayed at the correct size. Neat huh? The only problem is, this reload is what causes that flash (think lightning) I warned you about. Lets start with our custom flash.js script:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

var DESTINATION_DIV_TAG = "dynamovie";
 
function randomXDigitNumber(size) {
 
    return Math.floor(Math.random() * (Math.pow(10,size)));
 
}
 
function whack(str_to_whack, num_chars_to_whack) {
 
    if (str_to_whack.length <= num_chars_to_whack) {
        return "";
    }
 
    return str_to_whack.substr(0, str_to_whack.length - num_chars_to_whack);
 
}
 
function showMovie(height) {
 
    // Fake default args.
 
    var height = (height == null) ? 0 : height;
 
    // set a flag as to whether this is the first time through (with no height)
    // or the second (with height already calculated and passed back in.)
 
    flag = "true";
 
    if (height == 0) {
 
        flag = "false";
 
    }
 
    random = randomXDigitNumber(6);
 
    var movie_url = "/dynamovie.swf?r=" + random + "&flag=" + flag;
 
    var so = new SWFObject(movie_url, DESTINATION_DIV_TAG, 150, height, "6", "#0F1D4E");
 
    so.write(DESTINATION_DIV_TAG);
 
}

We have three functions in this file, two are just helpers, but the one we are concerned is showMovie(). If you’ll scroll to showMovie() function, we can go over it a bit.

The first thing we deal with is default arguments for this function. This basically makes things simple on our web page by allowing us to not think about parameters for this function when we don’t need them. If you have no idea what’s going on with that, do a search for “JavaScript default function arguments” and you’ll get enlightened. In short, it sets things up so that if no argument is passed in, our “height”argument will have zero, just like you had passed it in yourself. We do need this argument, because when we re-call this function from WITHIN the Flash movie, we need to let it know that we actually DO have the height, so use it, and DON’T call the function recursively again, because that would just get us stuck in a loop, right? And enough of life is already like that…

The next portion is just some simple code to set up a flag that we use to decide if we should call in again later. (Yes, this could be written more simply. For the couple bytes it takes, it keeps it clean and understandable. It’s like comment-in-code, know what I’m sayin’? :-))

Next, we generate a random 6 digit number just to make sure that when our Flash movie is re-called from our Function, it actually applies our params, and doesn’t just reshow us the same movie from cache. (Which in my case, caused it to NOT reload it’s XML from the server.) Depending on your circumstances, you may be able to remove that if you really don’t want it, but all it’s harming is a couple bytes of ram and a minute number of cpu cycles.

Next we build up a string pointing to the location of our Flash movie on the server. We then use a function from our magical swfobject.js script to build, then display our movie. Simple enough, right?

Now, here’s the big, silly trick. This stuff runs, and your Flash movie gets called and revved up. I built this up in 99% actionscript, and as I’m building my dynamic movie in code (working from the top of the movie down), I’m using a variable to keep track of the height of the movie. By the time I’m done creating my nav, I have the exact height my movie is! (albeit a little late, as the HTML is already built that states how big my movie is, so that’s what we’re gonna try to square up now).

Now, the last part of this rig is the code to use in your ActionScript, which is super-simple. The (slightly) challenging part will be for you to develop your movie so you know the actual height when you’re done. This is beyond the scope of our problem here, and there is a lot of great ActionScript info out there, go exploring. In the past few months quite a few good ActionScript 3 and Flex books have hit the shelves as well, don’t be afraid to poke around those either.

So in the bottom of your Flash movie ActionScript code, you want to do something like this:

1
2
3
4
5
6
7
8

// if the height of our movie doesn't equal what we thought it should have been, we need to
// re-call our function and redisplay...
actual_y = Math.round(actual_y);
 
if (actual_y != navheight) {
  // this javascript function stores the new height, then redisplays.
  getURL("javascript:showMovie(" + actual_y + ")");
}

The navheight variable is what got passed in to Flash from the movie URL. The first time through, this is going to be zero, the default JavaScript param, remember that? We check to see if that is equal to what our calculations decided the size of this movie REALLY is, and if it isn’t, it means we need to call back out to our JavaScript function again, and feed it our calculated height, and it will redisplay. If it IS the same, then we know we’re done! All the magic here happens thanks to our good buddy, the getURL() Flash API call.

The first time through, when the movie displays, it will not have the correct height, but it WILL display some of the movie. When the JS function gets called again, there is that quick blink I told you about, but it’s really fast, and not too bothersome in most situations, especially for quick jobs that not too many people will see, like back end applications.

That’s about it for part one of this series. That’s a decent amount to digest! The whole key to dynamic resizing is understanding the reasoning behind the recursive showMovie() function, and what’s happening in the Flash movie. This is NOT a complete example, there are lots of holes to fill in to make this code run, but I’m sure you understand the philosophy of what I’m doing with this now.

Good luck, and I’ll c-ya in the next article where I show you how I used this solution, a field in a database, and a little touch of Ruby on Rails to eradicate that bothersome blink! (Go ahead and try to figure it out yourself if you need it right now, you know it’d be a great exercise, and I gave you all the clues you need!)

Until next time, keep on keyboardin’ code soldiers!

[Updated 08-30-2007: script updated to fix a typo where the deletion of files after x days wasn’t functioning. The single quotes should have been double quotes. . .apologies folks. -LB]

[Updated 08-10-2007: script updated based on feedback. Now allows for exemptions via the EXEMPTION_ARRAY and will create the backup directories if they’re not there. Also put in a little more documentation -LB]

Ok, I do love VMWare, an absolutely terrific series of products. They solve so many problems, and do it with ne’er a hiccup in my experience. However, this particular post is about a problem, and its solution.

For those that haven’t been keeping up, not so long ago VMWare took their GSX (low-end server) product, relabeled it vmware-server and released it for free (not open source, just freeware). It’s truly a great product, it allows you to create and run VMs in a server environment. It’s not particularly crippled, and that I can recall, I’ve had zero downtime related to vmware-server. If you’re running on the cheap, don’t want to mess with Xen, Microsoft Virtual Server, etc. this is the way that I would recommend going.

However, you notice that I qualified crippled up there. Backing up a vmware-server virtual machine without bringing it down is impossible (at least without a third party product). That being the case, the goal is to minimize your downtime while maximizing the viability of your backup.

With this criteria in place, you do not want to back up the live data. The vmware-server disk images are quite active, and if you were to just copy them live, you would certainly end up with, at best, corrupted data, and at the worst, a completely fubar’d disk image. Either way, it’s most likely a useless backup. So, that means that we need to find a way to back up the disk image while it is not actively in use.

Click “Read More” to see a few options, and the bash script created to solve this issue.

Read more

Postroduction, and by that, I mean an introduction after the fact. Hey! I used it, so it’s a word now. Since Mr. Super-Right-Brain had to get all random and whatnot on us and get the ball rolling without proper introduction (proproduction, I suppose), I’m going to take a few minutes and elaborate on exactly what’s going on here.

Who are we? Right-Brain did address that a little in the About section. But, just to place it at the level of front-page news: We’re geeks - meaning we’re both software developers. Right-Brain has, historically, done a lot of Windows based stuff, ASP, Visual Basic, etc. He’s also a pretty good designer when you hold a gun to his head ; ) I’ve been much more Unix based, PERL, Java, C/C++, etc. We’re both currently into Ruby on Rails, and coming up to speed with Flex 2, and ActionScript 3.0. We are employed as part of a web team for a highly regarded business school at a private university.

The original impetus for this blog was that we both are always having to come up with some solution to a problem that we can’t find good answers for and have to create the answers, or we have to pull information from different sources to compile an answer. It is our hope, that aside from entertaining some folks from time to time, we are able to save other folks (or same folks, for that matter) some time looking for answers.

I have a few projects (Ruby on Rails, Java/J2EE, AS3) that I will be open sourcing and making available here for reference purposes, and one project that is nearly complete that I will be going over in detail. This later project is a game written pretty much exclusively in ActionScript 3.0. As ActionScript 3.0 is new, and almost never discussed separately from Flash (disclosure: I do use flash to save time on animations, but it’s minimal) or Flex, I’m going to offer this as a tutorial for budding AS3 game programmers. Personally, I’m VERY excited about this medium and I think it’s going to provide a lot of creative technical people a terrific outlet for projects that might not otherwise see the light. . .more on this in some other *rah! rah!* post.

As mentioned in the About area, we are both musicians. Right-Brain is an extremely talented guitarist (among several other instruments) and excels in writing, recording, and performing more rock/pop type stuff. I’m a trombonist and my passion is swing and jazz. We’ve both performed in public a great deal, though neither of us are performing regularly at the moment. I am, unfortunately, not playing at all at this point. I look forward to the day when I am again, but there are just other priorities at the moment.

What else? Oh yes! We are both fairly avid gamers, as avid as life allows anyway. We poke around with World of Warcraft a bit, we’re both currently playing Guitar Hero (myself the original, Right-Brain: GH2). Our goal is that when we grow up, we want to be creating some fun games for people to play on a regular basis. We’re looking at a few things, but we’re really focusing on fun game-play over eye candy and thumb calisthenics. Another purpose of this blog is to document this journey as well.

On the more personal side of things, we’re both closer to 40 than 30 (some of us MUCH closer), both married, and I have a 6 month old daughter (see www.andnoplacetogo.com for more on that last one).

It’s been discussed, and will likely be the case that we will also have guest contributers from time to time, perhaps even on a regular basis. Stay tuned for more on that.

I think that’s the hemispheres in a nut shell. Welcome, and I hope we are able to enlighten or entertain you from time to time. If not, at least you were able to spend a couple minutes reading this instead of dealing with an annoying co-worker.

Left-Brain