Fixes, tweaks and rebranding while I am still unpopular

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.

Introducing naval warfare

Remember when I said I would stop adding new features and just devote my time to debugging and optimizing the thing? Yeah, well, I lied. Guess I just can’t help myself.

The game has got naval units now: the naval port, war ship and submarine. Sea units cannot move on land and vice versa, but attacking each other is of course possible. So that should make deciding what to spend your money on even harder, which is a good thing. Here is an in-game screenshot from the map Chokepoint which features both sea and land elements:

In-game screenshot

Ok, and now after the CSS, it’s time to get the JS to work in IE. Goodnight.

Kaboom! 3 brand new units

Ok, I hereby pledge to stop adding new stuff and devote my time entirely to debugging and optimizing the code so that it’s rock-solid and fast. And promoting the game on the internets, maybe. And implementing a descent rating system.

HOWEVER. Alow me to introduce three new units that are – if I may say so myself – a lot of fun

1. The dynamite engineer 

He looks kinda cute, doesn’t he? Well he isn’t. This little fella will tear down your buildings in seconds if you don’t watch out. He is as slow as an ore truck and twice as vulnerable though. Had to make sure it wasn’t too easy to sneak one of these guys into somebody else’s camp.

2. The nuclear missile attack 

This one is devastating as well. To units this time. It will attack a whole area at a time, dealing a severe blow to all poor units – and to a lesser degree buildings –  that were in the wrong place at the wrong time. The drawbacks? Well there aren’t any, really. You can only launch them from (oh right I forgot) a new building I created, the research center: 

It looks quite spectacular launching one of these and seeing this entire area marked for attack at once… Careful though, as it affects friends and foes alike. And to diminish at least some of its power, you can only select an empty grass tile as your center of attack. Ok, this has also reasons in the code, but still I kinda like it as a restriction.

3. The first-aid air strike

This is the natural counterpart of the nuke attack: heal an entire zone at once. Luckily, this time only your own units are affected so you can really use this one to turn the odds around in a battle.

You know what? At first the existance of Weewar kind of upset me, as in damn somebody already did it. But frankly I can say it out loud now: I believe my game is / will be cooler than theirs. There I said it. It is far more fast-paced, it has less of a cartoonish feal about it, you can construct buildings, and now it has nuclear missile attacks ! They do have the terrain thing though, that’s also pretty cool and strategic. And the air and water units. And waaaay larger maps of all shapes. Ok, maybe it’s a tie

The small size of my maps has been bugging me for a while, maybe I should experiment with bigger maps and see how it affects performance…

Artificial Unintelligence

Because somehow millions of enthousiast users aren’t pooring in since the game started functioning properly (i.e. a week ago), I decided to write a bot mechanism. So as of this afternoon, when creating a game, you can now throw in some artificial intelligence players!

Well, ‘intelligence’ is overstating it really. Bots just dabble around the map randomly, completely oblivious of any enemies or mines near them. They also cannot purchase are construct anything. But hey, they work, they make for very loyal beta testers, and I will definitely improve their behavior in the future (including an option to specify their difficulty level). The current algorithm for deciding their actions is ‘move towards the map center at random speed’.

There’s also a tiny issue that I want to correct ASAP: it looks like bots move right away, because they get the blinking ‘moved’ next to their name the very first time the round loads the player states. While this is convenient (you never have to wait a bot for round advance) it is also confusing. Because in fact, the bots’ moves are stored as taking 5 seconds, and evaluated as such. So no worries, you can kill those bot’s units. It is also quite entertaining to watch them kill each other.

I just won my first game, too, yay!

As a reminder to myself: here are some JS/PHP thingies I ran into while developing Dice Attack that may be worth writing about. Given the amount of stuff I learn through blog posts by people who encountered my same problem and solved it for me, I think it is only fair to return the favor. Some interesting tidbits I ran into that might be interesting for others are:

• Getting a page to remember a draggable’s position (so the chatbox doesn’t forget where you put it when the round advances)
• Getting a page to remember what you were typing in a form (so the chatbox remembers what you were typing)
• Giving a text field focus on page load, and putting the cursor at the end of its content rather than selecting it (chatbox, again)
• Writing a rudimentary PHP debugger that really ‘tells the story’ of how your page is made
• Writing the simplest possible PHP forum (this one’s old)
• Writing a rudimentary AJAX chat (including private chat)
• Using AJAX to detect who is still on the same page with you and who left
• Injecting an animated GIF at a precise location and then removing it again to simulate explosions (also used this for ‘attack’ and ‘range’ circles)
• Dynamically generating images with PHP (handy to generate those 16 possible tile states when inventing a new unit)
• Timing how long it took a user to do something after entering the page
• …

Boy did I run into many tidbits

Stay tuned!

Once upon a war in the test…

After weekends of hard-assed JavaScriptin’ labour I found I had deserved a treat. In other words: redesign time, baby!

So I fired up the good ol’ Word 2007 (for new readers: that’s my vector graphics editor) and decided to give the intro screen and portal a repainting. The portal is where you end up after entering the site and it has the chatbox and your running games, and you can also join and create games from there.

There was also a small usability reason: I figured the fact that the portal’s left pane was blue could potentially confuse users about the fact that in the game, your left pane actually indicates your player color.

The redesign is kind of a blast to the past in a double sense, as I designed it to look retro-militarish, just like it did in the very first iterations. Boy do those early days seem long ago by the way! About the only graphics left from then are the basic tank and the green grass tile. I guess it’s fair to say building a multiplayer strategy game all on your own takes above-average persistence to! Above average? Freakin’ OCD is what it takes! Or at least an outlook on profit. Or on users... Or in my case, just a stubborn passion for envisioning and then creating stuff. Meh.

Anywhoo, here’s how the portal now looks:

The new portal look - retro army-style

Stylish eh? And yes it’s mis aligned but frankly, getting DIV margins exactly right is the one part of web development I can’t really get excited over, sorry.

I also played the first fully-functioning, start-to-end game with my good friend and patient tester Smieghtus. All the other times Dice Attacks broke his computer after about three rounds. But now it didn’t so it which gave him all the time to crush me, which he happily did of course. Maybe I should spend some time actually learning the game. But enough of the chatter – time for some in-game action!

Here’s a screenshot from near the start of the game, when things didn’t look that bad for me:

In-game screenshot

But things turned for the worse quickly… Yes that’s my last buildings you see exploding here, even though I tried to sneak in his backyard to make things turn:

In-game screenshot

(actually I should fix that you can just build anywhere but for now, everything that is not a browser-burning bug is a feature baby!).

And here is the sad, desolate landscape after the madness:

In-game screenshot

I know, I know, the outcome of war is never pretty.

Holy jeebus, even more new features!

Boy, did I finally arrive in the fun part of developing my game, where the idea-spec-implementation cycle has become sweet and short, often a matter o mere minutes! The drawback is that the JavaScript behind the game is turning into the same messy state the PHP code was in before I made the MVC framework.

I still don’t feel I fully grasp JavaScript’s Object-Oriented possibilities, so there’s surely a lot to clean up there later. But hey, you live you learn, right?

Anyway, the new features:

• Destructed units/buildings now leave a pile of rumble behind (in the loosing player’s color). Another response to the ‘WE NEED VISUAL FEEDBACK OF WHAT HAPPENED’ theme that I’ve been hearing so often. Seems to be something important to people. Maybe that’s also why so few people play chess over the phone just taking turns  saying algebraic chess moves out loud. And, frankly, I agree, visual feedback to your actions (in particular destructive ones) adds a lot to the experience.
• On the front end side: hovering over a unit now flashes the tile it has attacked. It’s really becoming a big JavaScript fireworks party with all these explosions, circles, sound effects and flashing times flying around. But the game’s also increased dramatically in fun and playability because of it, even though the load is starting to get quite heavy. One of these days I’ll minify the JS and do some of the other things Google Pagespeed suggested me.
• Units purchased at the War Factory are now placed in a more sensible way, depending on  the location of the factory. Before the algorithm always searched from left to right – below – the factory, which is of course heavily in favor of the player at the upper-left corner. Now, units are placed ‘towards the center’, no matter where your War Factory is.
• Chat messages are strip_slashed, yay! No more \’newbie\’ style escaped messages in the chatbox.
• Oh, right, I almost forgot: games have private in-game chat now.

Exciting: I played some more ‘real’ games with real people other than the usual me, myself and I! Very exciting to see my own creation being used in such unpredictable ways. Users Battlefiend and Generall_Balls totally crushed me in map Party of Three and I never even saw it coming. Wonderful. Particular kudos go out to Battlefiend, who turns out to be quite an expert in strategy games. He pointed out some flaws right away, and gets (some of) the credit for both the purchased units placement and flashing attacked tiles improvements mentioned above.

P.S.: I finally figured out why IE was not loading my external CSS: there was an ” in the CSS file it did not like… So I guess I just tripled my potential audience or something, right?

Two, no wait three, new features

I know Joel says ‘look at your customers, not your competitors’ but Paul says that a cool product is all about new features, so I added some more of those today.

The first new feature is (optional) e-mail notification when it is your turn to move. Yes, I stole that idea from my ‘competitors’ over at Weewar, and no I would never use it myself. I still envision a Dice Attack game as taking place from start to end in one session, or at least in a couple of sessions, not with days or hours between each move. But hey, a friend who tried it out said he liked the ‘play on the background’ feel in Weewar more, and he is one of my 3 users, so I guess I have to listen to him, too. The e-mail itself contains a link to the game, but if you enter the page like that it ‘forgets’ the game you try to enter, forwarding you to the default intro page. But whatever, at least it kinda works and I’ll clean it up later.

I guess we have a corollary to Joel’s lesson here: if you want to listen to your competitors anyway, just find a (potential) user you have in common with them and he’ll back up your idea.

The second new feature is way cooler – but less obvious – than the e-mail notifications: you can now actually see whether or not your opponent is actually on the game page. This should remove a bit of that nagging feeling you get when there’s no attack moves coming in from the other side EVEN THOUGH I AM KILLING HIS BASE DAMMIT HELLO ANYBODY THERE? You know what I am talking about, you have even had it with Instant Messenger, haven’t you.

It works by updating a database field to right before the user leaves the game page, using an AJAX call in JavaScript’s onBeforeOnload event. The value is also updated again whenever the user enters the game again.

Now, since the game effectively advances rounds by reloading the page this means that in-between each round advancement we get two completely useless db updates, basically saying ‘hey he’s gone… oh no wait there he is again, it was just a reload, nevermind’. And I am already being crazily inefficient on my db calls I suspect. But whatever, at least it kinda works and I’ll clean it up later, and this way will be already the good mechnism for in that bright day when round advancement will happen entirely through AJAX calls without page reloads.

Also, of course, this won’t detect if the game page is open and the user is simply not looking at it.

Oh wait, there’s a third new feature: sound works again! Just like notifications, you can turn it ON/OFF at any point straight within a game. It uses the Scriptaculous sound function, which seems really slow in comparison with that other JS-flash sound library I used before, but whatever, at least it kinda works and I’ll clean it up later (in this case that would be precaching the mp3s). My work ethic for this project could be better, I admit

I should propably add hyperlinks to all the external references made in this blog post, but I’ll do that some other time or something.But whatever, at least it kinda… You know the drill.

More progress

Things are moving forward fast now – creating that framework keeps paying off, and it makes the coding simply more fun, too. For example, I have this one file where I declare very units’ (growing list of) properties. Adding a unit is basically just a matter of adding some numbers to this file.

Different units now have a different ’speed’ (= how far they can move) and ‘range’ (= how far they can attack). Both are also indicated with a semi-transparent circle that shows when you start dragging a tile. Green is for speed, red for attack range. Hooray for visual interaction!

I noticed that the number of unit properties assigned to the JS side of things is growing, with separate methods for each property (price, range, speed…). So like a good programmer I think I’ll abstract that away to one generic ’send properties to page’ function one of these days…

The fact that all these unit properties are so nicely centralised in one file got me thinking: one of the really cool but not very well-known things you could do with Red Alert was edit a file with detailed properties for each unit, really crafting the game to your own style. Of course, what you did was create an atomic-bomb-blasting Tany with infinite speed and health, but still

So, how about I give my dear users the chance not only to play and learn the game, but also to craft the unit properties themselves to the last detail? I think I could even come up with a little interface with image uploader and all that enables people to add their very own units!

Not for now though, first I could use some users Or get friggin’ IE7 to load my CSS.

Removing barriers

Hey, at this point I am – happy – for everybody willing to shell out a minute to try out Dice Attack. So who am I to bug people with account creation?

As of today you can simply pick a nickname and start playing (if it’s not taken already). I’d like to think people will appreciate that as a nice touch in these times where you have to create an account for even the stupidest thing, never really knowing what they might do with that e-mail address you so kindly submitted and verified…

Of course, once the game will have a proper rating / game-history system, it will pay off to have an account so the system remembers you and your game performance. But for now it does not.

So, in short, there’s really no excuse anymore: visit Dice Attack, tell some online friends to do the same, play a lil’ game of in-browser RTS sweetness  and let me know how it worked out! I am still not confident enough to really send out beta invitations, but every passer-by is welcome to take a peak

I also added a ’submit feedback to game creator’  form right in the Portal so me and everybody else can freely throw stuff on the Dice Attack to-do list.

feedback form - bring on the bugs!

And last-but-not-least, the game manual is greatly enhanced now. I’ve made it into one of those hip ‘modal boxes’ you see so often these days (thanks to Lightbox-gone-wild from the nice guys over at Wufoo), and tweaked the text some more so first-timers get a better grasp about what the game is. Still a lot can be done here though, but it’s a pass ahead.

Oh and btw: I added those explosions I mentioned in my earlier post and, frankly, I love them

MVC, FOW and some new feature ideas

I started working for these guys a while ago, and I I’ve come to realise these 2 (obvious) facts:

• PHP 5 is really the first version where you can do descent OO programming
• For projects of a certain complexity it pays off to have a descent framework

And so I’ve moved Dice Attack to a server with PHP 5 on it, and finally started reworking the code to be less of an intertwingled mess and more of a consistent, well-structured, logic-and-layout-separated MVC framework, with a basic (but expanding) php debugger on top of it. And boy has it paid off so far! In a couple of days I’ve been able to scrap off almost that entire to-do list I posted a while ago. It has become a lot easier to fix bugs, watching the code really be ‘told’ in the debugger. For every piece of code I now know without thinking where to put/retrieve it. Adding features is a breeze. I know that by touching one piece of code, I wont have too many unforeseen side effects, etc…

As for the game, I started implementing ‘Fog Of War ‘ where you can only see parts of the map where you have units, this should add a bit to the tension. Economy kind of works now, including converting ore fields to money-generating mines. I also dismissed the JS alert pop-ups that came up when submitting moves or advancing a round, so that playing the game and advancing rounds feels a lot smoother now.

A Dice Attack game with Fog Of War and chatbox

Oh, and there’s also chat now. And I moved a lot of functionality from the session to the DB so you can now easily rejoin an earlier game you were in. Even though it is not how I have gameplay in mind, this kind of opens the door to ‘I’ll check my game and move when I feel like it’ type of game play, like Weewar has.

Kaboom! Something like this oughta draw attention to the fact that something attacked something

Here are some more things on the to-do list:

• More intelligent moves processing, so you cannot for example, attack your own units.
• The few brave souls that have tested with me so far keep screaming for feedback, feedback and even more feedback! So I should really indicate each round what exactly happened in advancing from the previous state to the current one. I am thinking animated explosions
• The map creator hasn’t been moved over to the new framework yet, but when I do I will make sure that ‘placing a building’ code can be easily reused for the gameplay itself, so that players can construct war factories or defence towers and the like. Maybe a tiny tesla coil that automatically damages nearby units would be nice?
• I haven’t implemented any ‘end-game’ features yet. So I should make it possible for a player to surrender, or to declare the game over when all but one player are left, etc…
• I was tantalizingly close to making the game proceed entirely without reloads, AJAX-calling for new gridstates and budgets, but I didn’t quite nail that one yet. Still, this would make the game feel so much more fluent.

So, in conclusion, a lot done, and even more still to do!