Last Friday was the 2nd Adobe Game Jam. It took place in Chicago and I was fortunate enough to attend. I live in Milwaukee so it was only a short trip down.

The event was held at The Nerdery. I’ve heard of this place for a few years but have never attended an event. They’ve held many Flex-user meetings there but I never had the chance to attend. It’s a pretty cool place. The tabletops are whiteboards, there are tons of video game consoles, and a cold keg was on tap! (off limits to us but still cool)

The Adobe crew that ran the game jam was Marie Nedich, Michelle Yaiser, Tomas Krcha, and Lee Brimelow. All really nice people who did a great job with the event.

The first night kicked off with a quick demo of current games built on Stage3D. They demoed both desktop and iPad games. All were enough to get me pumped to start coding. Especially the iPad ones.

After that, anyone with a game idea was to present to the group. The plan here was that if anyone liked your idea they would come and work with you. We could join a group or work alone. I was pretty hell-bent on working on the game that I came prepared to do. We were given the theme “Chicago” a few days before. I spent the prior 2 weeks studying starling since I’ve been so into EaselJS lately, and had device-debugging ready to go on iPad using Flash Builder 4.7.

My idea for the theme was to make a simple RPG-type card game using 1920’s Chicago gangsters. Instead of monsters, or wizards, or whatever. It would have simple AI for your opponent – the New York mob, particles, feathers UI, and some fancy card-flipping effects. I planned to use a die to whack others – or be whacked yourself of course. I was going to present on the iPad and make it simple enough to demo a quick and complete game.

After these pitches we were given some time to form the groups. I attempted to find an artist for my game but teams were pretty much set before we even started. Most people knew others or came with a partner. Nobody had the iPad in their plan so it looked like I was going to go it alone and scrounge for my own art. No big deal since there are no copyright rules in a game jam.

It turned out the we actually did have to be in a team. I was told I had to go find a group to join so it looked like my first game jam wouldn’t even involve my own game. Kind of a bummer. I admit I was a bit salty at first. I always imagined my first game jam to be a chance to pour all of my talent into a full-speed, no-distractions code-a-thon. And maybe actually finish something!

A guy named Jason Latte from Kentucky was sitting next to me. I had heard him talking to others about using a Kinect and Away3D. The game would put you in the game as Poseidon, somehow damned to occupy Lake Michigan instead of the ocean. This being the reason for the ‘Windy City’, and using the Kinect the player could create wind to waste the cars coming down the downtown streets. 3D is definitely not my style (or skill set) but it still sounded pretty cool. He was more than happy to take me in and we began planning right away.

I hurried through Lee’s Away3D tutorial to get my feet wet, then started getting the city ready for our game. I had way more questions than answers. I did my best to set up the city and camera controls. I actually did get that working but Jason and I agreed that it’d be best if I produced SWCs for the UI. I’d much rather be useful then to be constantly asking noob 3D questions. We prepared as much as we could and then all went back to our hotels.

I got back the next day at 9 and Jason was already there. He had gotten our environment set up overnight at the hotel and that put us in a pretty good spot. Pad had laid out some UI. The wind meters / power, scoreboard, screens, etc. I dove in and started coding them. It went pretty quick. By midday I was coding the game with Jason. He was in the driver’s seat, and at best I was able to periodically keep him in scope when he got tired. He was definitely coding like a madman!

Once the the game was working and the controls were connected using the Kinect, he grabbed my SWCs. They plugged right in. The wind meter (controlled by frantically waving your arms) was connected right away. And the power meter too. It felt good that I was able to provide him exactly what he asked for.

We then hit some very strange issues with my Kinect-style hand / hold-loader for ‘mouse’ presses. If you have a Kinect you know what I’m talking about. We had less than an hour left and it was wasted on issues we never figured out. The hand cursor was a pretty cool feature but it never made it in. I kept exporting the SWC but my properties and methods just stopped becoming available in the project. We have no idea why. Very weird. We must have exported that SWC 8 or 9 times but it just wouldn’t update.

Same with audio and most textures. The Kinect / controls just took up all of our time. Lee surprised us with a bonus 5 minutes so we were at least able to get some building textures onto the front cubes.

Oh by the way, a guy named Edward was building the 3D Models for the game. Poor Edward barely got a lick of his work in and we could tell he was upset about it. The whole thing may have been a bit too crazy.

We all presented. We presented 2nd and I volunteered to be the fool who demoed the Kinect controls by flailing my arms and body around to create wind, blowing away the crude vehicles coming down the streets. It worked pretty good. In the end it was more of a tech demo than anything but I think people appreciated it nonetheless.

The winners were a couple of guys who came in from Detroit. (pictured above) They were perhaps the nicest, most modest guys I’ve ever met. One guy from Chicago who joined them had created the sounds.

The game was fantastic. It was controlled by an XBox controller which was more than a simple key-mapping implementation. The little fire fighter, who really did look like a ‘Chicago dude’, would creep along at the speed controlled by the force of the joystick. Very cool! These guys killed it and the art was very good.

Afterwards, we all went to a reserved portion of a bar down the street. We had all of the drinks we wanted and a nice little buffet was waiting for us. Anyone who’s been to an Adobe event knows how generous they are.

I finally had a chance to have a conversation with everyone who had participated. I’m thankful to have met so many talented people. Lee was about as cool as anyone can be and had a lot of encouraging things to say to me. It was awesome to finally meet him.

So I ended up pretty drunk by the time the Adobe crew took off to experience some Chicago-style pizza. The last few remaining developers filled up our provided to-go boxes with cold, leftover buffet food. I walked to Grand Ave, caught a cab, and crashed hard back at the hotel. It was a fantastic weekend.

I picked up the framework very quickly, but I wanted to continue with my usual work flow for working with graphics. Primarily the use of TexturePacker. The easelJS API for spite sheets and animations is great, but its not obvious on how to deal with non-animated sprites and how to use string keys to access them from your sprite sheet. The way a TexturePacker user may be used to. This key/value approach assures me that the key ‘coin’ will get me the coin graphic I need. Preventing me to worry about further manipulation or re-ordering of my data.

So this being said, how can I use this amazing framework while not sacrificing the TexturePacker work flow that I’ve become so fond of? It turns out to be pretty painless and works great.

First off, translating the TexturePacker JSON data to an EaselJS-friendly object is simple enough. We could keep it simple and loop through the JSON, build our SpriteSheet data by building out our frames array. This is great, but we’ll forever need to know that our ‘tree’ graphic is on frame 3 or our ‘coin’ graphic is on frame 8. And if that changes, we’ll need to update any code that drew those graphics.

We can’t label our frames, but we can label animations. What we can do now is add a one-frame animation for every frame in our loop. We can then access these animations in a BitmapAnimation by using a string and simply staying at its first and only frame.

I’m not going to write out this data-conversion loop. If you are finding this topic useful, then you can surely figure that out. Just get from Point A to Point B.

var texturePackerData = {
"frames": {
"red_coin.png":{
	"frame": {"x":0,"y":0,"w":354,"h":550},
	"rotated": false,
	"trimmed": false,
	"spriteSourceSize": {"x":0,"y":0,"w":354,"h":550},
	"sourceSize": {"w":354,"h":550}
},
"blue_coin.png":{
	"frame": {"x":354,"y":0,"w":354,"h":550},
	"rotated": false,
	"trimmed": false,
	"spriteSourceSize": {"x":0,"y":0,"w":354,"h":550},
	"sourceSize": {"w":354,"h":550}
},
"flower.png":{
	"frame": {"x":708,"y":0,"w":354,"h":550},
	"rotated": false,
	"trimmed": false,
	"spriteSourceSize": {"x":0,"y":0,"w":354,"h":550},
	"sourceSize": {"w":354,"h":550}
}
}};

Note: TexturePacker uses the name of original png file as the name of each object. I chose to extract the ‘.png’ when converting the data.

data = {
   images: ["pngFromTP.png"],
   frames: [
   [0,0,354,550],
   [354,0,354,550],
   [708,0,354,550]],
   animations: {red_coin:[0], blue_coin:[1],flower:[2]} };

var gamePieces = new SpriteSheet(data);

//USAGE
var bmpa = new BitmapAnimation(gamePieces);
bmpa.gotoAndStop("red_coin");

So that’s it? Well, not quite good enough.

Using this approach would require us to retain BitmapAnimation objects to simply display single pieces of a bitmap. Seems like a waste doesn’t it? We should be able to convert that single frame from our animation into a simple Bitmap object. The Bitmap object takes one parameter, which can be an Image or a path to one. Unfortunately, there is no way to assign it a rect to draw from that image. Luckily, EaselJS provides a method that will extract the first frame of any animation and return an Image. We can then pass that image into a new Bitmap object.

var img = SpriteSheetUtils.extractFrame(gamePieces, "red_coin");
var bmp = new Bitmap(img)

Using this method, and the dynamically generated SpriteSheet data built from TexturePacker data, we can easily draw single frames from our sprite sheets using strings as identifiers.

var bmp = new Bitmap(SpriteSheetUtils.extractFrame(gamePieces,”red_coin”));
addChild(bmp);
bmp = new Bitmap(SpriteSheetUtils.extractFrame(gamePieces, “flower”));
addChild(bmp);

Terry helped a lot with the port, providing me with all of the images and tons of feedback / direction. I plan on doing a few more Terry Paton ports in the near future.

Click the image above to play the game.

Click the image above to check out the tutorial. I’d love to hear your feedback!

HTML5 Flipit from Terry Paton on Vimeo.

For the past week or so I’ve been remaking a Terry Paton game. It’s called FlipIt and can be found on a variety of app stores and desktop.  I had the idea to do a remake of one of his games in an effort to get more canvas practice, and to maybe even help spread his games to more screens.  It’s already proven to run great on the iPad.

Last night Terry recorded a video of the progress so far.  As you can see, canvas runs pretty poorly on Android devices.  This is frustrating in ways but I’m confident that it will catch up.  I’m just happy it’s at least running great on iOS browsers and of course desktop. That’s a great start!

Anyway, here is the video he shot.  Maybe it will finally push me to start doing my own videos and screencasts.

First of all, Scoreoid is awesome!  The API is straight forward and a cinch to implement. I was saving and retrieving scores within 20 minutes of signing up.

The Scoreoid dashboard is one of the most user-friendly experiences I’ve ever had on the web.  Even the simple things, like the COPY button for the Game and API keys make a huge difference. Other web services should take note on how things are done here.  It’s a shame that most of them out there are so complicated and over-featured.

As far as Fakezee goes, I’m honored to be mentioned in such a great site / service.  I have many more games in the works and will definitely be using Scoreoid for all of them.

I spent the most part of Q4 last year focusing on HTML5 Canvas.  Primarily for game development. Code maintenance was top priority and I tried to carry over as much Actionscript techniques as I possibly could.

 I’m refusing to use frameworks, not because they are bad but because rather than just quickly releasing a game, I am far more interested in mastering Javascript.  I’m sure I’ll dive into these frameworks this year but I think I’ll feel better about my code taking the slow route.  I’m still working on what will be my own personal game framework for Canvas games but I still have much to learn, such as inheritance, before I can say I am truly happy with Javascript.

I finished a few games, nothing fancy, but enough to hone in on code structure, animated sprite sheets, and Canvas best practices.  I’m at the point now where I feel that practice time is over and I want to start getting serious about my Canvas games – start developing original content and contributing to the future of practical deployment and portals.

One area where I put a hold on was getting these games to perform on devices.  I had enough to learn about Canvas as it was without worrying about poor device performance or gameplay.  But after Fakezee I started to realize that it was about time to throw those factors into my games.

This weekend I spent my time preparing a code structure that would properly hold a Canvas game on the iPad.  This involved things that I didn’t anticipate being so annoying. Primarily getting rid of, not only scrolling , but the ios5 rubberband dragging of the browser window. Also handling multiple touch points, which is extremely easy (at least in mobile safari).  Then there’s handling screen orientation and rotation.  You can’t prevent it, but you can listen for it, which gives way to a few tricks for handling what could turn very ugly for a game. Of course you can adjust layout, but depending on the game it could take a serious amount of work and testing.  Especially in Canvas.

All of this is leading up to a possible tablet-game portal I’m drawing out with a designer friend of mine, Taylor Martens, of Robots Made It.  There are many factors to consider when building such a portal but we ultimately decided to start by focusing mainly on iPad-specific games.  This gives us a set resolution, consistant sound /event handling, and performance.  Of course a portal such as this could, or even should focus on running everywhere, but we feel there is room for device-specific portals in the future of tablet browser gaming.  We are, after all, bypassing the app store, and could eventually control our own advertising / income.

More on this portal later.

My latest Canvas game is a Yahtzee remake. I must have made Yahtzee in about 5 different languages. It’s kind of my go-to game for learning a new platform. I used this game to develop my workflow for handling sprite animations on Canvas. Click the image or link to play.