As mentioned earlier, the next steps I’ll be taking with my game is embedding it in a social network to get familiar with openSocial: both the XML/JS-based and the openSocial REST API.

I will approach this as a series of posts, with more technical detail as usual. Here’s the steps as I see them now…

1. Injecting the entire game page in openSocial ‘canvas’ view, by inserting a new iFrame element in the DOM with the ’src’ parameter pointing to my game. Thanks to Prototype JS this takes just one line.
2. Wrapping some openSocial stuff around it, like fetching the user’s nickname. Also, we’ll be doing calls to the  Netlog-specific openSocial extension to make the user pay ‘credits’ to pay the game. Currently the user would have to pay each single time he wants to play, but I will transform this in paying after a free trial period. I will do this by storing the number of times played or the time since first play as persistent appData.
3. Passing on a security token as a GET parameter to that iFrame URL, along with the user’s JS-fetched nickname and some ‘I came from Netlog’ indication. Then I will catch this information on my site, and auto-create a user-account if needed, or auto-login the user with his earlier-created Netlog-originated user account. This way I still have my user’s nicknames, scores, played games…. in my database, while also skipping the login/signup stuff for users that come from Netlog.Of course, everybody can append GET parameters to a URL so I will need to carefully check that my security is watertight.

   I am also considering prepending Netlog_ to their nickname or something, so that there’s less chance of nickname collision and so that Netlog players are distinguished as such from non-Netlog players (or maybe later, players from other Social networks). Note that I am keeping it all on my server’s, so users can play happily together wherever they originate from.

4. Start implementing openSocial REST, so that I can send ‘activity messages’ from within the game. For example, if a game is over I can post ‘player1 won from player2 in a game of Tinker Tanks!’ back to the social Network. It’s viral baby!
5. Also, once openSocial REST works properly, I can start doing all kinds of cool stuff: fetch their avatar image for in-game use, send Netlog notifications from my server reminding players it’s been a while since their last game or that they were challenged, etc…
6. Back to my monetary model. As said, I will take a ‘free trial’ approach, asking a one-time payment after a certain trial period (either time- or gamebased, not sure yet). Apart from this I will also go freemium on them, making them pay for added-value features, most notably creating and saving custom maps.As the Netlog credits API is by far easiest accessed trough openSocial JS, I think it is best to ask users beforehand if they want to do ‘premium’ stuff like creating maps. Or maybe just create a ‘premium type’ account or whatever. Definitely to be retought later!
7. [EDIT] Ah what the hell, let’s also do it the other way around: users simply visiting tinkertanks.com can log in using their Netlog user account: in other words, OAuth+OpenID stuff.

Ok that’s it for now. If I pull all of these off succesfully I think I can rightfully say I’ve covered most of the ‘openSocial’ bases.

As the title indicates, I will approach these posts as a series, with detailed explanations and examples. So for the first time in this blog’s history I will (finally) go a bit more technical, posting real code snippets and all.

Canvas view asking for credits - first draft

Ok that’s it – more to come soon!

*** Posting this because I found it in my ‘drafts’, but it is already outdated ***

Ages since I posted something, or did anything on the site for that manner. That’s because I’ve been too busy finishing up my master’s thesis (but that’s over now, yay!). I DID start on a better ‘invite other online users’ scheme, seen in the portal below the chat.

I also did some more bug fixing and a bit of redesigning, mainly of the front page. Things still look butt-ugly, mainly because my big splash’s transparent color doesn’t quite match the page’s.

Also, I decided to have a change in ’strategy’. In my very first post I stated that ultimately I would be to implement Tinker Tanks as a an app in a social container, but now that I am working for one of those myself I think it’ll be more fun to keep it as a site on its own, and use it as a personal playground for testing new techniques/ideas.

Some new things I would like to implement:

- User blogs so they can write cool ‘battle reports’, or even tournament reports, because…
- A tournament system with fancy tournament calendars and invitations and ‘RSVP’ requests, etc… (I am building a PHP calendar for some other project anyway so might as wel reuse it)
- A nice spot on my site to put ads, and a system that cleverly rotates the ads from my many, many affiliates

In my very first post I mentioned that the original idea behind Tinker Tanks was to create it as an OpenSocial app within some kind of social network. Preferably this one, as they allow developers to ask for ‘play money’ to its young users, which can be traded for hard, real-life cash later on

Anyway, I left that ambition quite a while ago, since building the game itself was already enough of a challenge without having to worry about the ‘integration’ part. However, I always kept the design in its original, compact form.

Which turned out to be a good idea, because, hooray, I am now playing around with stuffing Tinker Tanks as an app in a social network! The reasons are twofold:

1. It turns out that all the XML-containing-HTML is not needed for your entire app, you can just use it as a wrapper and use JS to inject an iFrame element in your app. Remember iframes? Yeah, me neither, but somehow they kept around since I last encountered them (somewhere in ‘98).

   Even better, their site-within-a-site qualities make them perfect for just stuffing your entire external site in an openSocial ad. BAM, an openSocial app created in 30 seconds!

2. I actually work at the aforementioned social network myself, as my loyal readers know, and I got transferred to the helping-external-developers-integrating-their-stuff-with-Netlog department. Which means I am reading and plucking around with Everything Opensocial like a madman, to get up and running ASAP.

So opensocial-ized Tinker Tanks, here we come!

(just have to read up on that NDA to make sure my fun hobby side project doesn’t become property of my employer … )

I just tweaked the intro and portal a bit, prefilling and -selecting some form elements, and adding JS focus() where relevant.

As a result, let me present you the current flow to start a game of Tinker Tanks, even if it is your first time on the site:

- Go to www.tinkertanks.com.
- Press ENTER 3 times.

How’s that for smooth?

I actually created a soundtrack months ago, even before this blog, but I just realised I haven’t shared this with you, my loyal readers, yet.

Since the game still proceeds in reloads, I can’t quite play it on the page during a game yet, that’s for when the AJAXifying is done. But for now you could simply play it in the background, I found that it combines nicely with the sound effects

Without further ado, here it is (as an mp3):

the official Tinker Tanks soundtrack!

What do you think?

P.S.: it was created with Propellerhead Reason, software I adore so much that I once wrote an entire Reason tutorial for beginners. Check it out if you’re into music software, people seem to like it.

Let me tell you a bit about how, up till recently, the database scheme for a Tinker Tanks game worked. When you created a game, a number of new tables were created on the fly, specific for that game. And whenever I needed to access the db for a game – which is verrrry often as you can imagine – I first did some string concatenation to get the correct table name, and then worked on that one. The reasoning behind this – rather insane – scheme was that it would speed up games, as it only needs to retrieve data from very small tables. The drawback is that my PHPMyAdmin looked like an insane mess And of course it involves giving every user full rights on the database which is kinda… Well, wrong.

So I reworked things a bit to do stuff like everybody else did, identifying a game simply by an id field. Still, it leaves me wondering though, which approach would be the more scalable? My unconventional one (lack of experience is always a good trigger for out-of-the-box thinking) or the usual one? How large is the cost of creating db tables at runtime? I’ll benchmark it and let you know as soon as I have a million users

I also had a modest eureka moment yesterday, on how to transfer a shitload of tasks to the client side, which means the transfer to no-reload-round-advance is coming within grasp more and more. I am a bit ashamed to admit that 90% of the breaktrough insight was ‘fully grasping Prototype’s each() construct’. I guess there’s nothing wrong with learning.

[screenshot comes here but WordPress doesn't seem to like Ubuntu/Opera]

I experimented a bit with an ‘invite user to game’ scheme, where in the portal you would drag usernames of online players onto free game slots to invite them. But that didn’t really go anywhere so I’ll have to rethink that a bit further.

The ‘making it social’ I mentioned earlier is coming along nicely also, with both maps and players having their own ‘profile’ pages with a description and user comments. This gives another great boost to the communicating aspect of the site, which is a great asset I think.

Also, lots of other minor bugfixes. Like, start budget and ore income for the map creator now work. I first tried to do this by quickly injecting some hidden input fields in the save form before it was submitted (with innerHTML+=…). But this had the strange side effect of resetting the text fields already present to their default values. I’d love to share how I eventually fixed it but I am on a different computer now and I forgot

[screenshot comes here but WordPress doesn't seem to like Ubuntu/Opera]

Coming up next, hopefully: the finishing touch for profiles: pictures! Users should be able to upload a picture of themselves (currently every user has a remarkable resemblance with Winston Churchill), and map preview pictures should be generated on the fly with GD. I already use GD to automate lots of the artwork-creation of the game: see how every tile has a number of versions with different player colors and health bars. So I guess taking it a bit further to generate map previews shouldn’t pose to much of a challenge.

I also submitted my game to the gaming reddit which, greatly, triggered many people to stop by and take a look, which drove me insane because I wanted to play them all at once, loosing a crapload of games because I was so slow in each of them.

I am taking some more passes at making it social, meaning that I will give each map and player a ‘profile’ with some basic info and a picture. And people can comment on profiles and maps and add them to their ‘favorites’. You know, the usual stuff. Nothing fancy, I am not gonna turn it into a dating site. But these are the kind of things that keep people coming back.

I’ll let you know if there’s anything worth checking out (there isn’t yet).

There were two building-related problems that I’ve been wanting to fix for a long time, but I’ve never gotten around to them until now:

- you could place a building anywhere on the map without constraints.
- it was impossible to repair a building in any way.

I fixed both in the usual way: by inventing a new unit: the construction engineer. ‘attack’ one of your own buildings with him and it will be restored to full health. Repairing a building will remove the engineer though, so if you have to choose between a tower and a home base to repair with an engineer, you might want to pick the latter.

Also, construction of new buildings is now more constrained: you have to build them near a home base or a construction engineer. I could consider this into yet another option when creating a game, just like ‘vital homebase’ or ‘multimoves’, but the list of options is growing a bit to long and scary I think so I’ll leave it at that for now.

To make showing a ‘range’ circle when constructing work, I had to rework the code behind this considerably. As an added bonus, because the code is related, there is another improvement: you can now choose any tile (before it was just grass) to serve as the center of your nuke/first aid launch!

Yup, it’s getting more and more polished! Here’s some more fixes, some of which based on user suggestions:

• You can now add bots while already in a game. No need to stare at that one last Waiting… forever anymore! If a free slot doesn’t get filled you can just throw in a bot and start playing.
• You don’t need to be logged in to see any page anymore. Only the in-game pages (portal and map creator). If you click those you see a message that you need to be logged in. This is after somebody told me ‘nice, I see you already have the front page worked out.’ Excuse me sir? Just the FRONT page?
• Lots of minor bugfixes in the gameplay, units acting weird, towers moving themselves, etc…
• Sound effects are far from complete, but I added some discrete clicks and blobs to indicate your moves got submitted, a new round started, etc… More sounds (especially for placing a move and for the naval units and buildings) to come.
• These days I can’t do anything in the code/design without taking the occasion to create a new unit. So yes, here’s another one, again inspired by Red Alert nostalgia: the attack dog:

Trust me, he aint as cute as he looks. Mr. Woof Woof here kills infantry and jumps to their spot in one turn, so he makes for a nice addition to war towers for your town’s defence.

(I am still looking for a nice blood splash animation to go with it tough, currently a dog attack shows an explosion just like all other attacks, which looks ridiculous)

Fixed some of the following:

• The JS doesn’t break down anymore after the game is over (the grid just becomes a bunch of static images but you can still see hints and drag your chatbox around, etc…).
• I keep rewriting the how-to-play part (you do read manuals, do you?) to make it super-easy to get started with the game. But of course, it’s normal that at first the game will always seem a bit complex, no escaping that. That’s of course  an inevitable consequence of the rich, deeply layered gameplay (ahem).
• To make testing easier I put in some cheat codes
• You cannot launch unlimited nuke attacks in one turn anymore. Thanks to player Kung Fu Viking for reporting that, even though I can imagine it was good fun beating me with it. Maybe I should enable that through a cheat code also?

Oh, since everybody kept asking where the ‘dice’ are in the game (and rightheously so), I changed the name once and for all to… [drumroll]… Tinker Tanks! I figured now is the time since nobody plays to game yet so I won’t lose any ‘brand awareness’  - I didn’t have any to begin with. Also, Tinker Tanks is a cool name because it is short, sounds a bit cute and has the word ‘tanks’ in it. What do you think?

Other candidates were nuke attack, nuke wars, blitzkrieg battle, etc… But most of those domain names are taken by stupid search-engine cheating sites. (i.e. nothing but ’sponsored links’ on them)

But I sense your curiosity, dear reader. Indeed, where did the dice in the original name come from?

Well, it’s because I first saw this site as part of my Dice Commerce startup e-commerce company (stopped that now btw), so I thought I’d give it a ‘branded name’. Now, where’s the dice in an e-commerce package I hear you say.

Tough audience, eh?

Well, my e-commerce package was called Dice Commerce because I first started writing it in the context of my former company that was all about quantitative risk analysis, i.e. the mathematical modeling of insecurities in business/government decisions. And they also featured dice quite prominently in the logo and marketing materials. And in this context dice do make sense.

There you go.