Two months ago CartoonNetwork published five games on their new mobile site, and HeavyBoat was there developing the titles with loving care. It was a fun project to work on, five games with four different IP on two technologies. Good times.

It was our first time with HTML5 and it tuned out pretty well. Both “Toonix Tap!” and Ben10′s “Extreme training” were developed in HTML5 and they look and play awesome. So, if you happen to have an iPhone or iPad, give it a try on the CartoonNetwork mobile site.
If you have an Android phone or tablet, don’t get too upset, you can play another three great games: “Volcano Scape”, “Gumball dodger” and “Sword fighter”.

All in all, working on those five games was a great game development experience for the whole team. The coding minds of HeavyBoat will be writing about HTML5 soon enough.

Cheers!

Having a clear and informative log can serve for many things: finding bugs, the culprit of a change or just for the fun of reading it in an orderly fashion. In order to achieve that clearish log I’m using a handful of extensions, each one of them for a given scenario.

Scenario 1: Automatic merges

If you’re using a distributed version control system, like git or mercurial, sometimes you’ll find that the majority of merges don’t contribute to the story being told, they are just automatic merges messages.

But, instead of merging I use the rebase extension like this: hg pull --rebase and by doing so I’ll have sequential information instead of branches.

Scenario 2: Wip messages

Another common scenario is when I’m in the middle of a feature and a teammate pushes something I need in order to finish it. Here, instead of committing a lame “wip” message, pull and commit again I use the shelve extension. This does the trick of saving my work in progress in a virtual shelve, and then I can:

Scenario 3: Recovering wrong commits

Sometimes I just forget to add some file to a commit or the commit is just plain wrong. What I do here is to use the rollback command to revert my working copy to the exactly same state as if the commit never happened, and then you can add or modify whatever you want and commit correctly.

Scenario 4: Cherry-picking commits

Sometimes when I’m in a middle of a new feature I find a bug, I squish it and keep going. The thing here is what message should I write on my commit, should I mention the fix or not? What about if I could pick the modifications I’ve made and commit several times? That’s when the record extension came in handy. With it you can visualize which diff chunk you want to add to the commit log. This way you can cherry-pick which ones you want to be part of one commit and which parts belong to another one, therefore differentiating the bug fix from the new feature.

Once again it’s been very quiet around here, the blog I mean. I keep telling myself that I will update this thing more often, and all I do is forget about it. Too much work, must build, iterate and ship those games! And in the meanwhile, no one knows what we do here. Sad story.

But no use in complaining, so let’s do a recap of the past months.

-A series of minigames developed for CartoonNetwork’s mobile site were published two weeks ago. You didn’t knew? Maybe because we didn’t tell you! No social networking Twinkie for us!
-About to launch a new soccer card game.
-Working hard on our first iPad game. It should be on the appStore by August.
-More HeavyBoaters! Fabian García, a veteran game developer jumped in not long ago. Pure awesomeness.
-New website on the works, should be up before June.

I’ll make a post about those minigames sometime this week. In the meantime, go check out the CartoonNetwork mobile site and give it a try. You’ll see three games from an Android device, and another two from an iPhone.

Thanks for not cleaning us out of your RSS feed yet.

Continuing from the previous post I’d like to write something about how we got the AI to play the best card from its hand.

The logic behind this is to give each playable card (and possible action) a value. Each value needs to be in the same scale so you can compare each card’s value, so the higher the better.

This technique is comparable to the one artificial chess players use: each piece has a given value, but it also depends on its position on the board and the game’s context. Luckily for me our card game is not that deep, but this kind of logic still applies.

Mini closing rant: The beauty of the lost art of reading technical books is that you can get ideas of how to do stuff. That’s something copy-paste coders will never do. Understanding how things get done gives you leverage on how to make a better game.

1- This will be incredible, best game ever. Tons of features, fast development, lets imagine the sequel!

2- This is boring, I’m working like hell and can’t see progress.

3- Fuck this shit. I have a new idea.

It’s inevitable, you can’t go around it. The three stages are there and you are going to encounter each one on your way to a finished product. My tip: don’t try to avoid it, it will only be a waste of energy. Say “Hello, how are you? Sorry I can’t stay to chat… I’m in a hurry” and keep walking.

Don’t ever think your next project will miss one of the three stages.

We are on stage two as I write this, and it sucks.

PC/Mac/Linux, Consoles, Mobile, Social, SmartTV’s… games are everywhere. During the last decade we saw games get humongously big occupying everything. Everyone is making games or “gamificating” something, it’s over saturated… but still virgin. My guess is that technology is still in its infancy and nobody knows anything, we are running blind because we are surrounded by chaos and noise. There’s no time to test new ideas or to let them evolve, it’s a race against the clock to see who’s the first rather than the best. Add the marketing side of game development and you have a nasty picture.

At HeavyBoat we are developing some great new games for CartoonNetwork, in some way it releases us from the pression of getting noticed. They have the machinery to bring in the eyeballs, and that let us focus only in getting a great game out. On the other side, it comes with a cost. We will never fully own the product of our craft, taking out some of the thrill of launching a title. In short, it takes away the gamble. Anyway, I think it’s a good scenario anyway and we are looking forward to turn it into a profitable and exiting venue, but it takes time.

During the next few months we are going to finish the Cartoon Network games and release a beta version of “Backstabbing Pirates!” to test if there’s an audience for such a strange multiplayer game. Even more chaos.

In the past few weeks we have been making the most awesome computer card game ever. And what’s more: It’s our biggest project yet!

From a coder’s point of view the most daunting task is to create an Artificial Intelligence (AI) that is challenging, not impossible to beat, with different difficulty levels and, most important of all, to be fun to play against. Truth being told, I’ve never coded a single line of anything resembling AI in my entire life, but luckily I’ve always kept an AI book from my college days (yes it’s collecting dust in a closet).

I’d like to summarize the AI basics of the process to create an intelligent agent (something that is capable of resolving some task in an efficient manner). Every agent perceives data through sensors and is capable of taking actions in response to that information. Those actions are aimed to reach a specific goal.

Here’s a list that gathers all the design information of the agent

Percepts

• Cards currently on hand
• Cards already played
• Cards on deck
• Field control (Information on the game board)
• Powerups (awesome, huh?)

Actions

• Play card
• Shoot (yes you can shoot)

Goals

• Win the match
• I can’t think of any other goal the AI should have right now…

I’ll be expanding this post as I find interesting stuff in the AI book.

A game that ends? What kind of sorcery is that?!

A conversation from the future:

-Remember that game? How was it called? It was on facebook
-TripleTown? CityVille?
-No, the one with… oh! Baking Life! That’s it! It was great.
-Yeah, to bad it ended.

A game that ended, disappeared, it’s not available anymore, it went maybe while you were still interested in playing. It’s something new in an industry in its infancy.

PS. not that that many people were interested in playing BakingLife, but still, it’s interesting.

It’s been a busy 3 weeks since we started our new project. I would love to make an article about all the iterations the design for this game is going trough, but it’ll be too long and nobody will read it because I can’t write. So take my word for it, it’s been a long and interesting road. Instead of a long article I’ll make a list with the key element of the design process that we are carrying.

1. Place a savepoint on the design when things look somewhat solid, take a deep breath and go crazy questioning everything. No matter what.
2. Always look for a better solution, then look again and find the problem behind it, repeat until everyone dies.
3. Find the joy in bringing chaos by finding gaps in the design. Then help fix it, don’t run away.
4. Say: “Let’s leave this problem here and go fix that other one for a moment”. New ideas and solutions will flow your way.
5. Know when to say “enough”.

1 - GET IT
The game is going to fuel an existing show’s audience, you must understand who they are and what they relate to. Seinfeld, The Simpsons, Adventure Time and Hey Arnold!, they all talk different languages, one that their fans understand and you should too. If you do that right, there’s a better chance at making a great pitch.

2 – 80% SHOW 20% TELL
Most likely the IP holder will want to see that you can reproduce the art style of the show flawlessly before even considering hearing your pitch. Make final art examples from the get go, and cover the 80% of your pitch with it. Use the other 20% to tell what’s the game about, what does the player do and how much does it costs.

3 – BALANCE OVER INNOVATION IN GAMEPLAY
The IP is the star, not your new experimental game idea. Adapting existing game mechanics to reflect the show’s humor and mood is always a good idea. Once you sell the game you’ll have to fine tune game mechanics and level design until your brain melts, since that’s the way to deliver a memorable experience without stealing the IP’s thunder.

4 – ORGANIZE THE READING
Start with a one sentence Overview and a gameplay image, follow with 5 Key Features and another image (progress map, menu, etc), lead to end with Core Gameplay elements with more images and finish with cost and production time.

5 – MAKE IT FUN
Have you played games based on shows? If you did, you know why I make this the 5fth point. Please make fun games, even when you use others IP’s. And show that you intent to do it on your pitch.

Hope you find this tips useful. Go sell ideas and make awesome games!