Mapping the World

This week for So Play We All the topic was “core game objects” and the time budget was 3 hours. The core of Oaqn is the world, so I spent my time working on mapping code. I added a beautiful little demo, but it wasn’t without a lot of frustration.

Also, did you catch that link in the first paragraph? I threw together a website for So Play We All to house the rules and track the progress of blog posts and polls.

Speaking of which, let me link to my response from this week about Luke’s miss and Jim’s wheel-reinvention, and to Jim’s response.

On to Oaqn.

The Oaqn world will be a cylinder broken down into regular-sized sections called plats, so the first thing I did was add a Plat model to my project. Each plat has an x and y coordinate to figure out which other plats it adjoins, but at the moment I only have a single plat. Here’s what it looks like:

Well, this is more like what it will look like in the future. This image is the textured and lit heightmap generated by fracplanet, the first simple terrain heightmap generator I could find. I’m going to have to find a much more robust one for generating the full world, fracplanet can only generate a single plat by GUI. A couple minutes’ looking around told me this is probably going to be a commercial product.

The Player and (brand new) City models track their location by plat id plus x and y coordinates. I wrapped up this related code in a concern:

module Plattable
  extend ActiveSupport::Concern
  included do
    belongs_to :plat
    attr_protected :plat, :x, :y
    validates_presence_of :plat, :x, :y
    validates_numericality_of :plat, :x, :y

At the moment that’s limited to the model relationships, but eventually it’ll include things like A* pathfinding. Future “Plattable” models will include campsites, farms, and resources.

Speaking of which, let’s take a first glimpse at player caravans and campsites:

My previous post was about looking for pixel artists, and I found one who’s already generated some wonderful sprites.

Sprites need a home, of course, so I took the first rough pass at integrating Steppe, Andrew J Baker‘s canvas-based voxel terrain renderer. This accounted for fully half of my budget, mostly as I learned about the code by breaking changing things to learn how it worked. I added the heightmap for the terrain I generated and bundled it up as a demo on the Oaqn homepage:

The sprites haven’t yet been integrated. A much earlier version of Steppe had a proof-of-concept for displaying sprites, but unless Andrew feels like dusting it off I’m going to have to write sprite support from scratch (so… Andrew… pretty please?).

I had a big fight with JavaScript’s same origin policy about Steppe. I’m hosting the Oaqn website on Heroku for easy deployment, but it’s not a good place to host big static assets like my (eventually) thousands of plat heightmaps and texturemaps, so I uploaded them to Dreamhost alongside this blog. Unfortunately, the browser’s “same origin policy” prevents the JavaScript hosted on Heroku ( from reading the image data on Dreamhost ( After some investigation, I had four options:

  1. Leave Heroku and create a single server to host both my app and static data, which would be an eventual scaling problem.
  2. Have Heroku proxy images, loading them from Dreamhost and serving them to users. This would be terrible for app server performance, bandwidth, and speed.
  3. Use CORS to have the static server instruct the browser that it’s OK for the JavaScript to read image data. This would be perfect and has decent browser support (Safari 4, Chrome 3, FF 3.5, IE8, but not Opera)… except that most of those only support it for JavaScript data, not the canvas elements that Steppe uses. I could hack around, but better to wait until this grows up.
  4. Finally, I could copy the canvas and JavaScript up to the static server and load them in via an iframe. This means I have problems in the other direction when people (eventually) click on sprites on the map to interact with them, but easyXDM provides a well-supported (if slightly laggy) workaround.

So I’ve gone the iframe option as it had the least bad set of tradeoffs and in the nebulous future there will be proper browser support for this sort of thing. This ended up being a rush hack, so next week I’ll be spending 15-20m automating the process of pushing the iframe code up to the static server each time I deploy the game.

Speaking of cleanup, before I got to Steppe I spent a half-hour touching up things left over from last week. I’m glad I had the loose ends, they gave me a nice series of small accomplishments that I put me in a good mood to deal with the same origin policy frustration. So, here’s the final list of what I did with this week’s coding budget:

  1. add model with x and y coordinates
  2. add location data to player model
  3. add city model
  4. create Plattable concern for player and city
  5. create a plat object in production database
  6. add some cities to the plat
  7. use fracplanet to create a map
  8. convert the fracplanet output to heightmap and texturemap pngs
  9. create s3 bucket for plats and upload — but then I realized I shoud:li>
  10. delete s3 bucket, host static content on spare Dreamhost space
  11. create city objects in production database
  12. set up database backups
  13. set up cron to take daily database backups (will increase frequency as playerbase increases)
  14. edit player signup to give out the limited-time only So Play We All and Founding Player badges (sign up now to get them!)
  15. give those badges to the players who didn’t automatically get them
  16. give badge descriptions in tooltips (see previous link)
  17. when player logs in, give them a cookie to remember them indefinitely
  18. replace the stock top nav of the theme to link to player list and blog
  19. redirect all 404s on to
  20. add steppe
  21. fight hugely with same origin policy
  22. host steppe in iframe on

As I said, lots of little stuff. It adds up, though, and I managed to get everything done without resorting to many ugly hacks — and the ones I did will be easily cleaned up soon.

Last, the Oaqn ledger (which was in the black after Luke missed his hours and blog posts returns to the red with the art expense of $12.

Please vote for Oaqn in this week’s poll on BBGZ.


  1. Peter won (again), but I’m still not bitter « Fantasy Adventure (So Play We All) - June 17, 2011

    […] made some really good progress on Oaqn this week it seems – according to his blog post¬†anyway. Because his game is so graphical, there’s a lot of interesting design work that he […]

  2. Now Featuring Monsters - Push cx - June 18, 2011

    […] We All theme this week was “core game objects” and the time budget was 3 hours. I did did well for myself, time to review the others’ work — both of which included […]

  3. A Whole New World | Oaqn - June 22, 2011

    […] mentioned last week I left myself cleanup of the Steppe demo code. That took about 15m to get it automated and neatly […]

Leave a Reply