Monday, February 21, 2011

How to Write an HTML5 Game in 30 Days with JQuery and Python

Kicking Ass and Taking Names


“I wanted to do in boxing what Bruce Lee was able to do in karate. Lee was an artist, and, like him, I try to get beyond the fundamentals of my sport. I want my fights to be seen as plays.” - Sugar Ray Leonard

Enough farting around. If you've been wanting to write an HTML5 game for some time now, but you were too busy trying to get a perfectly timed grenade jump on Halo 3 while munching away at the leftover Doritos that fell between the cracks in your couch cushion, then you've come to the right place. I'll show you how I did it - and in 30 days. Actually, I lied - it took exactly 33 days from starting to launch to produce Towers of Wolin. Here's how.




You've Got To Have What it Takes


“I'll think, If this is his first punch, how are the others gonna feel? That's the only fear I have for myself.” - Sugar Ray Leonard

Day one starts when you decide that in 30 days you're going to release a game. Read this article on Gamasutra about prototyping in 7 days. These guys were full time, I have a day job so I can only spend on average 2 hours a day (less on weekdays, more on weekends); this works out to around 30 days equivalent time, so that was my goal.


It's important to be realistic about it - in 30 days you're not going to make Starcraft III. Well in fact, you're never going to make Starcraft III unless you have tens of millions of dollars and hundreds of people and a huge marketing budget. What you can make is something
small, simple, and fun. Think Tetris.



Most importantly, don't be afraid to fail. Don't be afraid that people will hate your game, you, your dog, and your IDE (I prefer vim). You know what? Fuck 'em. This is your game, and even if you're the only person in the world that likes it, it's your baby. That's reward enough.


Week One: Game Design


“You have to know you can win. You have to think you can win. You have to feel you can win.” - Sugar Ray Leonard

You've got four weeks, and little wiggle time at the end. Where do you start? Game design. Many programmers miss this. An awesome technical game with a fast reactive engine that's not fun to play is still a shitty game. Likewise, artists forget that a beautiful display of visual mastery can still be boring. You're making a game, not an art museum. You need a design that is, most of all, fun. Think Angry Birds.


Week one is Game Design Week. There are a million great game ideas out there. If you're a gamer, you probably already have tons of them. When I need inspiration I head on over to HTML5games where they have a huge collection of HTML5 games, all for free, that's given me lots of ideas. But don't just think video games, think board games, children's games like Tubang Preso, sports you've played. In the time constraint of a week, you need to focus on the simple.


When I was writing Towers of Wolin, I had just come off being dazzled by WordSquared, and listening to a friend discuss his latest Settlers of Catan match. It was fuzzy, and I briefly thought of doing a Settlers clone like
gSettlers or
JSettlers, but I wanted to do my own game with a unique set of rules. So I started playing around some div tags and SVG graphics commands just to see what I could throw up on the screen, using source images from OpenClipArt. If you're good at Photoshop or Inkscape you can do this stuff yourself, but I'm not so I used SVG commands instead. I tossed in some backgrounds from CGTextures and
4FreePhotos and pretty soon I was looking at a board of hexagons with a sea background and a few different colored tiles. I wasn't sure what to do with it so I put on a few farms, fortresses, bridges, RPG stuff. I drew lines for roads, put things at the vertex. There were cool free fonts I saw at Dafont, sound effects at PacDV.
Just messing around.



Now after a few days of this I needed to figure out what the game was actually going to be. Originally I was thinking Massively Multiplayer Role Playing with resources, characters, an economy. Needless to say, such a game would take years if not decades for a single person to write. So I had to toss this out and think about what simple rules might be easy enough to implement but still fun enough to be worthwhile.

At this step in the game of making a game, Simplicity is the keyword. KISS - Keep It Simple, Stupid. At this point you'll have 1000 ideas, 100 of which are good, 10 of which are implementable. But you can only do 1 idea, so you have to toss all but one game idea, even the good ideas! You'll have a chance to do them later. Toss everything you can. I tossed characters, multiplayer, the economy, vertex drops, roads, until all I had left was a humble tower on a humble tile. There was only one action, the humble mouseclick. Click on a legal move tile and a fortress is built there. The enemy does the same. Whoever gets the most territory, wins. Game design complete.

Well, it wasn't really complete. I had to think about the level design - did I want to custom-design all my levels or do it automatic - I chose automatic using a fractal, since I'm lazy and I didn't want to play the same level over and over again, it's randomly generated each time. Also I had to think about progression - how does the game get harder, how do you advance levels - I wasn't sure but later during playtesting I just gave the AI an additional initial move with each level. There was a question of how all the graphics was going to look - some I didn't toss in until the end - but the basic sprites I needed were defined.


But in sum, it was enough to proceed to the next phase, programming.


Week Two: Programming


“Generally, the more weight you put on, the less effective you are.” - Sugar Ray Leonard

Only one week for programming? Well not exactly, you're going to be programming the whole thirty days. But your core coding needs to happen in a week. What I mean is, by the end of week two, you should have a basically playable game. It's going to have some quirks, bugs, maybe missing the splash screen and user login, but the core game mechanics should be present.


But how do we get from design to a running game skeleton? There are many paths to the goal, but first we've got to discuss platform. You should have already decided what platform you want to target - desktop, iPhone/iPad, android, browser, Xbox, Gameboy, PS3, whatever. They each have advantages and disadvantages: desktop is great for maximum power and graphics but hard to distribute; iPhone is easy to distribute and monetize but hard to port or expand; android gets you to lots of phones but limits screen space; browser can run anywhere but is harder to monetize; Xbox, Gameboy, PS3, any console device has a big market but production and distribution costs can be very high. For my game, I chose browser because I wanted to reach the maximum audience, I didn't want to front money for a Mac and a development license, and I have more experience with browser-based technologies.


Once you've picked a platform, you can start setting up the framework. I didn't know JQuery very well when I started, but it was the framework my friends at MindQuilt had the most experience with, so I knew what it could do, and I'd heard good things about how javascript has matured in the past few years. On the server side, I'd already been writing some python, and appreciated its lightweight approach compared to Java, especially with Django and Google App Engine. Plus, I wanted to play around with some of these to learn new technologies and enhance my computer hacking skills. So I got a basic app up without much difficulty.


Essentially your programming task is to convert the game design into functioning code. It's not quite that clean, because you'll revise the design and flesh out details as you're coding, but you need to think about how to implement all those fancy features in the model. A great site I recommend for this "making the dream reality" is Amit's Game Programming. What helped me the most was his excellent article on Grids. This gave me the algorithms I needed to implement a hexagonal grid, transform world to screen coordinates, and view adjacent tiles. I spent a day stuck until I realized that the origin of an HTML screen is top left, not bottom left as in Cartesian coordinates. Sometimes, we can all be dumb.



With a browser you'll need to decide on HTML divs, canvas, or flash. I tossed flash right out because I don't want proprietary stuff and it's a dead end on iPad. In comparison, getting the game to run on the iPad for me was a simple one-line inclusing of the iPad Plugin
for jQuery. Canvas is trouble on IE but otherwise lets you do almost anything you can imagine: I started with that but quickly shifted to divs when I saw an article that divs can actually be faster in some cases. There are some graphics-intensive games that can only be done in canvas, but for the tile-based game I was writing, divs work just fine and have probably a 10x or more developer productivity. With divs, you have the browser doing most of the work for you with events, lots of library support for moving things around, images, overlapping, dialogs. Canvas is more like writing a dos game back in the 1980s, you have to do everything yourself from scratch. In my case, divs were the better option.


It still gave me trouble with sound - I used JPlayer which is great on FF and Chrome but problematic on other browsers - I'm not sure what the best technology would be for a very sound-intensive game. The site MediaIo worked great for audio conversion, though.


By the way, if you're going with a browser-based approach I really recommend looking at the javascript on wordsquared, not only did they do an excellent job but the code is clear and well-written and you can see how they do lots of the "tricks" that make the site look and work good.


Enough talk, now for the meat (or soy, for you vegans, or Gagh, for you Klingons). Here's a chunk of actual jQuery javascript code from the Board class which takes a set of hexagonal tiles, and gives them a fractal elevation attribute. I use this elevation attribute later to assign territory classes: less than 0 for water, +5 for mountains, grasslands in between, etc. The background images for different territory I assign later, I converted them to pngs from svg using fileformat.info.

self.fractalNoiseTiles = function() {
            // fractal noise for tile elevations, to simulate terrain
            var persistence = 0.5;
            var octaves = 4;
            for (var octave = 1; octave < (octaves + 1); octave++) {
                // add and smooth for each octave
                self.smoothElevation(self.tiles);
                self.fractalAddElevation(self.tiles, persistence, octave);
            }
        };
        self.smoothElevation = function(tiles) {
            // apply smoothing function to elevations
            $.each(tiles, function(coordStr, tile) {
                var newElevation = tile.attr('elevation') / 2.0;
                var adjacentCoords = self.hexAdjacentCoords(tile.attr('coords'));
                // find adjacent 6 coordinates
                $.each(adjacentCoords, function(i, coordStr) {
                    if (coordStr in tiles) {
                        // if it doesn't exist, assume it's sea, so elevation 0
                        newElevation += tiles[coordStr].attr('elevation') / 6.0;
                    }
                });
                tile.attr('elevation', newElevation);
                // set current value to smoothed adjacent values
            });
        };
        self.fractalAddElevation = function(tiles, persistance, octave) {
            var scaleFactor = Math.pow(persistance, octave);
            $.each(tiles, function(coordStr, tile) {
                var amplitude = scaleFactor * (-1 + 2 * Math.random());
                // -1 to 1, continuous
                var newElevation = tile.attr('elevation')*1 + amplitude;
                tile.attr('elevation', newElevation);
            });
        }

If you're doing a single player game, as mine is, you'll need an AI. Even with a multiplayer game, you'll want to have a basic pluggable AI just for testing purposes. Now as the IBM Watson match demonstrated, AI can be a fascinating field, but also very complex and difficult. Stick to obvious things you know to avoid getting lost in cascading levels of complexity and end up in Limbo. My first AI for the game, for instance, was very simple - simply move to a random legal position. Then I enhanced this by moving to the coast first, to try and block off enemy entry points, falling back on random moving if this was impossible. Finally I made a more sophisticated AI that took into account not just good moves offensively but also how to defensively block the enemy. Still the AI is not very good, particularly in its ignorance of disclosures. But here's the code for two movers, the Coastal and Random AI movers, in my javascript Player class, to give you a feel for what an HTML5 div-based AI looks like, and how easy it can be.

self.coastalMover = function() {
            // prefer inner coast
            var numMoves = $('.valid-move')
                .not('.perimeter-tile')
                .filter(self.board.isAdjacentTo('sea-tile')).length;
            if (numMoves > 0) {
                var randomMove = Math.floor(Math.random()*numMoves);
                $('.valid-move')
                    .not('.perimeter-tile')
                    .filter(self.board.isAdjacentTo('sea-tile'))
                    .eq(randomMove)
                    .each(self.board.makeMove(self.turnComplete));
                return;
            }
            // prefer perimeter
            var numMoves = $('.valid-move.perimeter-tile').length;
            if (numMoves > 0) {
                var randomMove = Math.floor(Math.random()*numMoves);
                $('.valid-move.perimeter-tile')
                    .eq(randomMove)
                    .each(self.board.makeMove(self.turnComplete));
                return;
            }
            // otherwise make a random move
            self.randomAIMover();
        }

        self.randomAIMover = function() {
            var numValidMoves = $('.valid-move').length;
            var randomMove = Math.floor(Math.random()*numValidMoves);
            $('.valid-move')
                .eq(randomMove)
                .each(self.board.makeMove(self.turnComplete));
        }

Along with the frontend code you will need backend, server-side code. I've heard good things about Node.js, but what I had available was python on Google App Engine so I went with that. It was a lot harder to get the scoring and login code to work than I expected, but that is due more to my ignorance than any real difficulty. Once I got the hang of it, it was a breeze, especially compared to the heavy-handed lugging I'm used to with jboss and war files. Here's an extract of my backend python code for the Scores class, which grabs the top 10 scores out of the datastore and, if the user is logged in, adds on the top score and ranking for that individual user.

def get(self):
        scores = db.GqlQuery( \
            "select * from Score order by score desc limit 10")
        # fetch top scores
        scores_list = [];
        i = 1;
        for score in scores:
            username = 'anonymous'
            if (score.user is not None):
                username = score.user.nickname()
            single_score = {
                'user': username,
                'score': self.format_score(score.score),
                'date': score.date.isoformat(' '),
                'place': self.format_ordinal(i)
            }
            scores_list.append(single_score)
            i += 1
        # append your top score if logged in
        user = users.get_current_user()
        if user:
            score = db.GqlQuery( \
                "select * from Score where user=:1 order by score desc limit 1", \
                user).get()
            # fetch your top score
            if score is not None:
                scores_list.append( \
                    {'user':'','score':'','date':'','place':''})
                # spacer row
                place = db.GqlQuery( \
                    "select __key__ from Score where score > :1",\
                    score.score).count() + 1
                # fetch your top score
                single_score = {
                    'user': 'Personal Best',
                    'score': self.format_score(score.score),
                    'date': score.date.isoformat(' '),
                    'place': self.format_ordinal(place)
                }
                scores_list.append(single_score)
        self.response.out.write(simplejson.dumps(scores_list))

With your basically playable game up and running - not ready for prime time, not even close - but playable, you're reading for serious testing.

Week Three: Playtesting

“We're all given some sort of skill in life. Mine just happens to be beating up on people.” - Sugar Ray Leonard

Okay it's really just "testing", or if you're fancy and want a higher salary, "Quality Assurance", but to make it more exciting we'll call it "playtesting". That is, you get to play your game.

Now playtesting isn't just about seeing if it works. Sure, you need to find the bugs and fix them, you need to do that no doubt. But what it's even more about is discovery. The best QA people you'll find don't just run the test scripts and report the results. Instead, they prod around the limits of the application until it breaks, and try to figure out what this implies about what else might be broken, and why. Where the user experience is lousy, where I'm doing something with menus when I just want to click, and vitally, whether or not it's fun. Most importantly, discover how this implies the game could be improved to be more playable. This is what you need to do while playing the game.

When the tile game was up and running I started clicking away, saw and fixed some obvious bugs, and found out that the game wasn't very fun. It was just too easy to beat the AI. I added a few tweaks for more aggressive playing, but still it got to be boring fast, and took too long to play after it was obvious I would win (or lose). So I added an Autoplay button to speed up play when it looked like you were going to be win - but be careful! - one time I caught myself with hubris and ended up losing after pressing Autoplay. Still, just territory wasn't enough since it didn't give the kind of strategic advantage I was looking for if you capture narrow mountain passes, block off a plain, things like that. So I added the concept of "enclosures", that is, completely surrounding an area with your pieces and barrier land, which then automatically become filled with your own pieces. Not only did this add the strategic aspect, but it also sped up the game. Now, it did end up being the most difficult, time consuming, and bug filled piece of code I had to write for the whole game, but doing the enclosure calculation was not only intellectually satisfying, it ended up substantially improving playability.

There was a lot of iteration during this week of playtesting. I don't want to say agile, because I've heard that term ad naseum until it now has the same amount of meaning as "achieving key objectives with maximum leverage", but there was a lot of tweaks to the graphics, the runtime, the sounds, the rules. As the saying goes, 1% inspiration, 99% perspiration.

Week Four: Refinement

“My ambition is not to be just a good fighter. I want to be great, something special.” - Sugar Ray Leonard

Lots of good game ideas die a premature death because their authors give up towards the final stretch. That's what week four is all about - refinement. Getting your game over the hump from something that resembles a college compsci doodle, to a professional looking game. Now we're not aiming for Bungee-level storyline, thematic videos, and a model-staffed convention booth.

Refinement is what separates the men from the boys, the women from the girls, the mature transsexuals from boytoys. It's the roadwork that you have to put into the game if you want it to succeed. It's not fun, but it must be done. Do you have a splash screen? A score screen? Rules? An About page? How fast does it scroll? Does it flicker? Are the graphics lined up perfectly, or are there gaps? Does it work on different targeted platforms: iPad, Firefox, Chrome, Internet Explorer?

I had to work on all sorts of little details for the game in the refinement stage, most taking longer than I thought. I had developed in Chrome, which is the fastest browser with the best support for most HTML5 features, and it worked fine. Then I tried Firefox and it didn't work at all. I was using the jQuery rotate plugin, which doesn't work on Firefox, so I had to rethink the way I was handling tiles. Then I tried to view it on iPad, which looked horrible, so I spent a day redesigning my top-level div structure until it displayed properly. Multiple sounds had trouble on the iPad so I had to disable most sounds there, touch didn't work so I had to get the jQuery iPad plugin working properly. I didn't have a splash screen, so I had to write one, which was harder than I thought given that it has to appear before the game, after a level is completed, after the game is won or lost, with the rules, all at the right time in the right order. Scoring was even more difficult since it involved using some google APIs I wasn't familiar with, required me to upload a datastore index file, heck I even had to write a custom thousands-separator method for python since one isn't built in.

I thought about efficiency. There's a lot you can do to make a game load and run faster. I looked at the images I was using, switching to jpg instead of png for photographic-type images due to its better compression in this area. I consolidated all my javascript files into a single compact, minimized file with Google Closure Compiler. I made my CSS smaller and faster with the online YUICompressor and then switched my index.html to use the optimized versions. Some things I was using custom images for I found I could instead use existing CSS effects and jQuery functions. I was able to load public domain images off of existing sites like PicasaWeb instead of overloading my app engine. Smaller tile sizes took up less image space and ended up being easier to play with as well.

The refinement step is the biggest pain, the most frustrating, the least fun, but also the most necessary. Your users will appreciate it, and so will you.

Week Five: Release

“A fighter never knows when it's the last bell. He doesn't want to face that.” - Sugar Ray Leonard

You're game is done. Thirty days have passed - or in my case, thirty-three, because I couldn't get scores working. My fault for "leaving it to later". Next time, I'm including all elements of my game before starting playtesting, no matter how "easy" it's going to be so I don't shoot myself in the foot. But finally it was done, uploaded to google appengine, and ready to go. The game had been "knocked out", and like a boxer I was rather exhausted at the end of it all. Quite a relief.

But even being done isn't being done. I got a suggestion to add the rules section so it was clear how to play the game. I showed it to a few close confidants to get feedback. I submitted it to an HTML5 game site for inclusion on their index. And I wrote this blog post. Marketing is the fifth week in a nutshell. Let the games begin.

UPDATE: by popular demand, here is a link to the playable game: Towers of Wolin Playable Game. And here is a link to the complete sources: Towers of Wolin Source Files.

33 comments:

  1. where is playable game?

    ReplyDelete
  2. Its at: http://towers-of-wolin.appspot.com

    ReplyDelete
  3. Anonymous, once you are on the so called internet, try going for the blue text. Hover your pointer over it and apply pressure to the button.

    The first blue text should do.

    ReplyDelete
  4. meh. where is code snippets/source dl?

    ReplyDelete
  5. i'm the guy with the 1,090,200 score, currently #1 ^^
    this game can become quite fun if you take out the lucky factor a little bit because "unbeatable maps" are not so fun and not so fair of course :P

    ReplyDelete
  6. Okay by popular demand, I've just posted the sources online at: https://docs.google.com/leaf?id=0Byb_6xqE_1ZxNmViODQ1M2ItZGQxOC00NjlhLWI1NDYtYzg3NDQyNmMyYjkx&hl=en

    ReplyDelete
  7. Do you know you've basically made a hexagonal Go? http://en.wikipedia.org/wiki/Go_(game)

    That's not a complaint, Go is a good game, and your version is pretty fun itself. I just find it amusing.

    ReplyDelete
  8. Yes, I was noticing a similarity to 'Go' too. If you can get a good AI for Go, you'll win a hefty prize!

    ReplyDelete
  9. An AI for this game would not be nearly as impressive as one for Go. These boards are much more constrained than Go, and the positions are simpler as well, what with no capturing of stones allowed and the vast restrictions on where you can place towers. (ie only near coast or other stones)

    ReplyDelete
  10. I've beaten the game and am currently in 5th place on the scores with 1,637,150 points. It was definitely worth the playthrough, but there are quite a few little issues that need fixing. Here's my exhaustive list of every problem I noticed with the game in the order I noticed them:
    1. Center splash screen box doesn't recenter when maximizing window.
    2. Rules screen has repeated word "will will".
    3. Rules screen text doesn't quite fit in box.
    4. Splash screen background needs to be blurred to make splash screen text more readable.
    5. Cannot click on bottom tiles because the score bar gets in the way. Rotating the board 30 degrees would make it fit better.
    6. Zooming out to make more of the game clickable ruins the seamless edges of the tiles.
    7. The tips each level keep repeating after a bit.
    8. In later levels the enemy takes too long to set up its towers.
    9. The AI over-values coastal lands so I can usually just grab everything by staying one or two spots away from the coast.
    10. I didn't notice until level 19 that I could click and drag to move the board. I was going to say that there should be a tip for that, but then I got that tip during the splash screen before level 20.
    11. Click-dragging the map is too CPU intensive.
    12. There should be an option to enter a nickname to post scores under instead of posting my email address minus the "@gmail.com".
    13. There's no way to restart a level without losing, so the most effective way I can think of to get a higher score would be to intentionally lose until getting a layout that is particularly advantageous.
    14. The "About" button in the main menu should say "Credits" because that's what it shows.
    15. The splash screen at the start of a new game shows the highscores; it probably shouldn't.
    16. Click-dragging makes clicking to move unreliable if I've zoomed out.
    17. Another typo in the rules: "Thus is becomes harder" should be "Thus it becomes harder".

    Out of all those issues, I think the closest ones to being game-breakers are the ones involving map size and navigation. Also, I have some ideas to add more replay value to the game, mostly focused on a sandbox feature.

    1. Make a sandbox mode that unlocks after beating the game. The sandbox mode would allow us to set things like map size, number of enemy towers, percentage land vs. sea vs. mountain, and maybe even hand-made custom levels.
    2. Make the AI more challenging. Not knowing how it's implemented, I guess that making it identify and prioritize taking of small stretches of land in between barrier lands. If you decide to build the sandbox, the AI's priorities would be fun to edit.
    3. Adjust the default game parameters according to what sandbox testers say is more fun.

    Overall, it's a fun game and a neat idea, but it's still got a ways to go before reaching its potential.

    ReplyDelete
  11. Okay I've just uploaded a new version of the game. You may need to clear your browser cache to pick up the new css and js versions. Improvements are as suggested by Mark:

    * Splash now recenters properly
    * Splash goes to intro screen instead of scores
    * Rules had typos fixed and rewritten to fit
    * About changed to Credits
    * Simplified initial AI moves to be faster on higher levels
    * AI rewritten to be smarter regarding coastal lands and forming enclosures, prioritizing as per suggestions
    * Click-drag CSS adjusted to be faster
    * Nickname option added for posting scores
    * Restart button now allows level restarts

    The sandbox idea is interesting. The map size is a parameter that I adjusted to work on smaller browsers. Initially it changed with each level, which was okay on chrome up to huge maps but killed iPad past 10, so I set it at fixed 10 size. Number of enemy towers, land-percent is also easy since it's all parameterized in the code. Hand-drawn maps are a little harder since I'd need to write a level editor. I'll see if I can figure out how to do an unlockable parameter screen.

    Also suggest trying Chrome if possible, as it was the fastest browser in my test.

    ReplyDelete
  12. Over half the problems I noticed fixed in under 12 hours and the game runs much smoother now. That was quick!

    Some of the issues remain, however:
    * The rules screen text still does not fit perfectly in its box and needs to be moved up about 3-5 pixels. This shows what it looks like for me.
    * The ability to click-drag to navigate needs to be mentioned before playing, not randomly during a tip.
    ** Removing the randomization of the tips and setting the click-to-drag tip as the first one would work.
    * Zooming out still breaks click-drag navigation and tile edges.

    I also found a few new issues:
    * I did not get the nickname option, though that could be only during login.
    * Finishing the game again didn't show my latest score being submitted until I refreshed the highscores.
    * Restarting a level keeps the points earned on that level before the restart.
    * It's possible to move while the AI's still setting up, causing it to give me the extra towers instead of itself.
    ** These last two issues allow for ridiculous scores when repeatedly abused on the last level. My two highest scores (2,158,850 and 1,825,800) are because of these glitches.

    AI: The AI seems to have been a bit over-adjusted. Where it was once too easy to take everything by taking spots one cell away from the coast, I can now simply take the coast itself. It seems to be sort of a rock-paper-scissors problem where any chosen AI strategy has a decent counter-strategy. As far as I can tell, moving inland beats cutting off the enemy which beats taking the coasts which beats moving inland. The challenge is making the AI mix strategies to counter the player's current moves. Perhaps randomly choosing between strategies each turn would work without making it too hard.

    Sandbox: A parameter screen would be a good substitute for a level editor. It could also have an option to submit a list of favorite parameters to give you ideas on balancing difficulty.

    Map size: What was the bottleneck in iPad performance after size 10? If it had anything to do with the CSS you just optimized, it might be able to handle more now. Also, smaller cell sizes might help performance while also making it easier to see everything.

    Browser: I'm already running Chrome 9.0.597.98 on Linux Mint 9 KDE edition on a system with 1 GB RAM and a 3 GHz Pentium 4. I think performance problems specific to my system are more related to the processor than the browser.

    ReplyDelete
  13. Okay another update (cache must be reloaded to pick up), addressing the following:
    * rules should now fit in text
    * mention click drag as first tip
    * zooming i could not get to work, although it works if you zoom out then reload the game, a little flaky though
    * nickname only works when you are logged out currently
    * restarting a level now zeros-out the points properly
    * moving while AI is setting up now disabled
    * AI now enhanced with a combination of coastal blocking, also now remembers where it last moved so it has more self-direction
    * Custom screen now provided where you can create your own level based on fractal parameters and board size: for instance running with a board size of 20 and persistence 0.6 creates a very large rocky map; AI and playing still seemed to work fine, just a bit slow

    ReplyDelete
  14. Another bunch of excellent fixes! Of course it's still not perfect, but it's getting closer each update.

    Current bugs:
    * I'm still able to get the AI to give me free moves by restarting the level during its setup and clicking the "OK" and "Yes" buttons really quickly. I can manage this at least as early as level 5.
    * When starting a new level via the custom screen, the pre-level splash screen flickers once per custom level previously played during the current session.

    Enhancement requests:
    * Please add a warning about how slow larger level sizes are to load. At least it's only CPU intensive and not memory-hungry so it didn't freeze my system, just the one tab.
    * It would also be neat to be able to set the AI's starting towers.

    AI:
    * The AI only tries to block me when I build next to somewhere that it can build. When I build on a coastal cell adjacent to at least one other coastal cell, the AI will build next to me every time.
    * When the AI is not busy blocking me or going around obstacles, it always builds walls of towers one cell away from the sea. By building a wall of towers 3 cells from the sea and one cell from the AI, I can slow it down greatly as it alternates between its original plan and trying to annoy me. Picture.
    * It's probably not worth the time trying to make the AI perfect; if it was every level after the first would become impossible. However, a bit more randomness would make it more interesting.

    Other:
    * You haven't removed the highscores I got from abusing glitches. Personally I would probably clear all highscores after finishing making difficulty-influencing updates.
    * I noticed you put me first in the "with thanks to" list. I appreciate that token of your appreciation for my feedback, but I do not wish to be listed first. All else being equal, I think alphabetical sorting would be the fairest. Also, I'd prefer the link to point to my website (refola.com) instead of my Blogger profile.
    * With all the improvements you've made, it feels like the game's gone from beta to version 1.5 in 5 days. If you want to continue at this rate and make this into a bigger project, you could make version 2 within a week. If you want I can come up with a big wishlist of new features, but there should be feedback from other people to balance mine.

    ReplyDelete
  15. Okay updated a new version, fixes:

    * Appears the click-during-higher-levels bug is fixed, at least I couldn't get it to do it
    * Tried to fix flicker on screen
    * Added warning on large sizes
    * AI adjusted to have semi-random strategy selection for greater variety
    * Updated thanks-to with new address and alphabetical order
    * Could not figure out how to delete old scores - will need to test data export/import
    * Researching how to allow custom towers for custom level

    ReplyDelete
  16. I really like the background pattern on your web station.

    ReplyDelete
  17. This time I could only find two problems with the game.
    1. If I use a spot that I can move on to click-drag scroll, it counts that as a move.
    2. Thanks for updating the thanks-to link you gave me, but I didn't specify my preference clearly. I'd prefer it to have my name as its text; Mark or Mark Haferkamp would be ideal, whichever you prefer.

    Any improvement beyond fixing these minor issues is the metaphorical icing on the cake. In fact, the second issue is merely one of the icing being the wrong shade of white.

    ReplyDelete
  18. Nice article, I like the timeline organization! I just created my first HTML5 "learner" game, Mutant Zombie Monsters, http://www.mutantzombiemonsters.com/ , using ImpactJS in 3-4 weeks. Not bad!

    ReplyDelete
  19. Okay Mark, I've updated the link to say "Mark", you may have to empty your cache to see the new html link.

    For the click-drag problem, I haven't figured out how to fix that, I'm going to ask one of my jquery buddies. Somehow I need to catch the click on the drag event and do a prevent default, but still allow the click if dragging isn't initiated. I'm going to need this for future dragging games, so if you have any ideas how to fix, let me know.

    ReplyDelete
  20. Thanks for updating the link.

    Regarding the click-drag, I do not know JavaScript, but I have an idea. Is it possible to have one function catch the mouse-click-down event and then save the mouse coordinates, while another function catches the mouse-click-up event and compares the current coordinates to the saved ones? If so, that second function could call either the map-scrolling or cell-activating function based on whether the coordinates changed.

    ReplyDelete
  21. Good idea I'll try something like that.

    ReplyDelete
  22. Does your book discuss realistic expectations for network latency? Client-server throughput vs. HTTP overhead? WebGL? HTML5 Sound?

    ReplyDelete
  23. I have no words for this great post such a awe-some information i got gathered. Thanks to Author.
    Android app developer| Android apps development|

    ReplyDelete
  24. I'm naive in programming and I had question about:

    If Javascript/HTML5 is the key trend for app development. Why should I learn Python (on) Django / Ruby on Rails?

    I read your post and "feel" the answer now. But I'm still not sure about it.

    Would you please advice me?

    p.s. I would suggest you to write a book about your experience like this post, with some tutorials for beginners. It's really awesome!!

    ReplyDelete
  25. Interesting one. Thanks for the share. Keep posting such kind of post on your blog. I bookmarked it for continuous visit.
    html5 media player

    ReplyDelete
  26. Thanks for sharing your info. I really appreciate your efforts and I will be waiting for your further write ups thanks once again.
    html5 media player

    ReplyDelete
  27. wonderful information, I had come to know about your blog from my friend nandu , hyderabad,i have read atleast 7 posts of yours by now, and let me tell you, your website gives the best and the most interesting information. This is just the kind of information that i had been looking for, i'm already your rss reader now and i would regularly watch out for the new posts, once again hats off to you! Thanks a ton once again, Regards, Html5 online trainingamong the Html5 in Hyderabad. Classroom Training in Hyderabad India

    ReplyDelete
  28. Famous game, after I understand that princip :D Make for me about hour of playing! Thanks my logical thinking :D

    ReplyDelete
  29. I'm a real beginner so my question might be too obvious.
    i would like to make a mobile app that uses python and for which users can download plugins written in python.
    The other requirement would be that the UI would be written as html 5 web pages maybe with some javascript.
    So you would have in a way very customized browser with a webserver integrated.
    So the application would work even if the user is offline.
    is this possible?
    do you know any libraries or sdk-s that I might use for this.

    ReplyDelete
  30. great explanation of Dijkstra, could I ask you how you made the JS simulation, looking for a simple network simulator like that since a while html5

    ReplyDelete
  31. Hi John,

    Thanks for this post and Tower of Wolin. I really enjoyed playing the game - both on desktop and mobile browser.

    I appreciate that you thought carefully through your distribution options back in 2011. I'm with TreSensa, a distribution platform focusing on mobile-optimized HTML5 games. Since you've written this post, we've made some great strides on growing our platform and addressing the distribution concerns you raised in this blog entry. We've completed back-end integrations with Apple, Google Play, Amazon, Firefox, Tizen, MocoSpace, Kik, (75 total) and many other gaming destinations and portals. So we offer best-of-breed distribution and monetization for HTML5 game developers, who need only to integrate with us once and get their games played everywhere.

    I think Tower of Wolin can succeed on our network. I'd love the opportunity to talk with you more about our services and see how we can work together. Let me know if you're interested!

    Best,
    Jamie Lee
    jlee at tresensa dot com

    ReplyDelete