The birth of Mappy

After much experimentation and banging my head against a wall, stuff started to click. A number of months ago I started working on a random script  called Mappy (those that follow my twitter will have likely seen Mappy in action), well its starting to take shape, and work pretty well.

Basically the idea behind Mappy was to make content creation super easy, and quick. Therefore I decided to implement a heightmap based map generator, where by I upload a black and white heightmap and Mappy generates me a ton of content. The problem with this was that any image larger than 20px-20px would take minutes to process, which is totally unrealistic for a PBBG, so I hear you asking how did I solve this tiny issue.

Well I took the processed tile information and processed it into serialized php arrays, and json objects, these are then stored on disk in blocks of 20×20 tiles or 400 cells. This data is then either unserialized or served directly to the client. Once the content is active on either the server or client it is then rendered out into HTML. Great now I have a system that takes a simple black and white image and builds me nice a complex 2d map, only problem now is that its not  very usable, because of the amount of DOM manipulation going on scrolling around the work takes a good deal of processing, so I had to come up with an optimisation that would allow suppoerting browsers such as Firefox, Chrome and Safari to render the mapping data into a Canvas element. As moving 10-20 large images is much less problematic than moving 1000s of div tags.

So now I have a system that lets me automatically generate and view complex mapping content, all at the click of a button, great, now I need to start building a game, right… wrong still tons of backend hackery that is required.

The next task was to workout where the user had clicked in normal 2d space, then translate that coordinate into isometric space, then poll the server to see if that location is available for building, if it is then it returns some json informing the client that it may indeed build at the selected location. Once I had the ability to click of specific tiles it was time to start thinking about what Mappy could be used for, this for me was and still is the hardest bit of the project.

Having grown up playing games like Command and Conquer it was the natural choice, but as far as I am aware no one out there in internet land has created a PBBG implementation akin to Real-Time-Strategy games, the closest I could find were people implementing games that work on real time, as in it takes 10 minutes to build a hut, and 3 hours to walk over to an opposing village and lay siege, all happening in a textual manor, now I dont know about you, but as a kid I got board of DnD, and got hooked on Warhammer, I think it was due to the whole visual aspect. Either way games that are “real-time” but none-visual in my mind fall short.

So wanting to make a RTS, but not wanting to compromise on the visual aspect of the game I needed to come-up with some solutions to how I can build buildings, move units around the map, and do it fast enough to be usable. Luckily I have Mappy that does the whole visual thing, and allows the building of buildings, but what to do about the moving units around issue.

Looking back though this blog, and my old code folders I found my pathfinding code, and even though it was designed for a different kind of environment (the path finder was for a real-time server system, so it would load the pathing data once) I started to port it over to the Mappy paradigm, this took about 4-6 hours to port, and once complete I was left with a block of code that took about 50 seconds to generate me a ton of paths, this obviously was not suitable for a PBBG so I dropped the data into a database, resulting in about 2k records that returns optimised paths in 0.0005 seconds, Win.

So now I can path-find from any one area in poly space to any other area, the problem now is that Mappy isn’t polygon based, its just a bunch of 2d tiles positioned using css, I need a way to build a polygon version of my 2d tile based world, luckily again my bag of failed programming projects came through again, a prior attempt left me with a pretty handy bit of Javascript that lets me draw polygones on a canvas, this will do nicely, another evenings worth of work and it was alive, and that brings you up-to tonight, right now in fact :)

I’ve uploaded a video of Mappy inaction to youtube, take a look and post a comment letting me know what you think.

Right hope you enjoyed that, my next task is to link up the polygon drawing code to the pathfinding backend and then I’ll have the ability to build complex 2d maps, and allow pretty much instant pathfinding from any location to any other location for close to zero CPU load. Once that is all working I’ll need to implement a unit type into Mappy, so I can test all this is actually working correctly and once thats done start thinking about how multiple units will attack one-and-another.

I’m just hoping because I’ve been able to get this far without any major issues I can pull off a real RTS, and not join the ranks of people with real-time textual gameplay, not that I dislike textbased games, I just feel most things should be visual.

Iain out.



This entry was posted on Tuesday, February 2nd, 2010 at 11:47 pm and is filed under Uncategorized. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

2 Responses to “The birth of Mappy”

  1. Vincent Voyer

    Will you opensource the code ?

    nice work

  2. admin

    I was thinking about open-sourcing the rendering client, but the backend php will likely stay closed, unless this project goes nowhere commercially, then I’d consider it.

    Though the issue with open-sourcing only the rendering client is how to feed it data to render, so currently I’m not 100%. One possibly solution would be to host a content generation service, where you can use a site to generate mapping data for your own game.

Leave a Reply

Your comment

google google
  • google43412
  • google43412
  • google43412
  • google43412
  • bu pos
  • google43412
  • google43412
  • google43412
  • google43412
  • ueio soius