Who said debug consoles have to be boring?

(Quick note: I did write a following part of my openSocial series but stupid wordpress keeps inserting weird stuff in my pasted code snippets. Yes, others noted and diagnosed it, so I’ll post&fix it sometime later. Stop nagging you imaginary reader)

One of my quirks as a programmer is that I often sprinkle cr*ploads of comments and debug log messages all over the place, preferably in conversational tongue-in-cheek tone, even if I’m the only one on the team that might ever read them.

On a slightly related note, yesterday I got fed up with my PHP debug console’s boring endless-lines-full-of-unit-char-codes and the likes, so I dropped my real work and instead tweaked the output formatting a bit for two reasons:

1. If I spend so much time staring at the darn thing while tweaking bot behavior – attack me you stupid! - might as well make it a bit more ‘visual’ when debugging gameplay-related events, and
2. because I can. Ha!

So here’s a snippet of my debug output during gameplay as it currently looks:

My php debugger, mid-action

Chaotic, lively, and just a tad short of ’serious’: now there’s how hobby coding projects should be.

P.S.: the bots are still buggy now.

Making the bots better

As experience has learned by now, nobody will ever ‘get’ this game from the first time, let alone when playing directly in multiplayer. As with any RTS, and true to the name, some tinkering will be mandatory for each player to understand the gameplay enough to enjoy a game.

(I wonder how the chess inventor ever got betatesters?)

Conclusion: without descent single-player the game will never take off. And obviously there’s the next step, an actual training campaign: ‘first, your men must learn how to march!’ (Say it with a Scottisch accent)

So I am tweaking my bots a bit (there are actually quite some severe bugs in the decision algorithm, but at the time I was just happy to have something that could advance rounds without me having to play myself from to browser windows).

As you can see, they are still not very bright, but this one is definitely more assertive than before:

bot_john (blue) decided that playtime is over

From php game to openSocial app – part 1: the plan

I’m embedding Tinker Tanks in social network Netlog (not for real, just using their sandbox) to get familiar with openSocial (both the JS and RESTful API), and I plan to write down my steps pretty carefully. So yes, this will be an OpenSocial tutorial series, with real code snippets and all.

For part 1, let me just list the steps to take 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 too as a bonus: users simply visiting tinkertanks.com can log in using their Netlog user account: in other words, would be nice to get my feet weet with the most esotoric of all these ‘open’ protocols flying around: OAuth and OpenID and that stuff.

Ok that’s it for now. If I pull all of these off succesfully I think I can rightfully say I’ve covered the most important ‘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 – check back for more to come soon!

Next steps: blogging and advertising!

*** 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

Dusted off the Social Container plan…

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 … )

To play: press ENTER 3 times.

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?

Proudly presenting… The Tinker Tanks soundtrack!

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.

Making the db scheme less insane and various other tidbits

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 insanely stupid – 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 more or less full rights on the database which is kinda… Well, silly. To top it off, I am pretty sure this approach was mega-slow too…

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, excitingly, triggered many people to stop by and take a look, which drove me insane because I wanted to play them all at once (starting games is a lot more obvious than joining them which I should fix), so I lost a crapload of games because I was so slow in each of them.

Making It Social

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).

Construction works

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!