Creating the Worldly scrollable map, part 1
Published 2 years ago
Creating the Worldly scrollable map, part 1
Hello everybody! I thought I’d write a quick blog post on one of the more interesting things I’ve worked on recently: the cool scrollable world map in my latest release: Worldly.
Worldly is an educational geography game where the player is guided around the globe by Sir Maxwell Worldly, explorer extraordinaire! The main play area of the game takes place on a stylised map of the world, and has the camera zooming into a particular part of the globe (i.e. France) and the player trying to correctly identify which part of the map they are looking at.
The concept of the game came from an idea of an expansion to Capitals Quizzer, another geography quiz game I built a few years ago now. Capitals Quizzer focused on the less tangible visual data (capital cities, currencies, flags), but I always wanted to build a game with a focus on the mapping side of things. When you’re looking at a map it’s much easier to get things across graphically, and it’s an entirely new area of geography which I hadn’t explored yet. Worldly was to be that game.  If you haven’t tried it yet, you can download the game here.
So the world map was to be the main draw of the game. It would be the area you’d spend the most time looking at, and it was also the area of the game which I’d spend the most time working on. It had several interesting requirements:
  • Lots of data! The map needed several “layers” which could be toggled on and off depending on the game mode. This meant that country borders, regional borders, city locations, seas and oceans, and others could be available to the game without having to reload a bunch of assets or process expensive amounts of data.
  • Needed to zoom. The game camera would be zooming in and out as the user travels the globe with Maxwell Worldly. That means that the tech needed to go from a really, really zoomed out view (i.e. putting all of Russia on-screen), to a really, really zoomed in view (i.e. one individual city). Importantly, it had to do this smoothly and without different layers of detail jumping in at any point.
  • Had to be stylised. I didn’t want to take an existing traditional map or satellite view, as Worldly was to be a fun and upbeat game. Boring static maps are pretty much the opposite of where I was hoping to take the game. I worked with an artist to build up a really interesting stylised look to the map, and we designed the rest of the game to fit that ’interesting colour palette too.
So before the project even started there was quite a strict set of guidelines which needed to be adhered to. I knew I would have to explore several different methods of map rendering before I found the one which would work. The first to try was a tiled bitmap approach, like (the old style) Google Maps. This basically involves getting a whole bunch of square tiles, and drawing them side-by-side to form a map. When you zoom in the system will subdivide these tiles into smaller, higher resolution versions which are then streamed in.
One big advantage of this system are that you can have different graphics to represent different levels of detail. So as you zoom in, suddenly roads and forests and other detail will appear. When you zoom out the system swaps in more simplified graphics to make everything more readable. The downside of a system like this is that you need a lot of tiles (growing the size of a downloadable app in terms of disk space), and you need to carefully manage how you load those tiles into memory. If you don’t pre-load enough data then there will be pauses as the system catches up. If you load too much then you’ll run out of memory and everything will explode. This was a particular worry with Worldly as we’re targeting several different mobile platforms that have varied (and transient) memory limits.
It was for these reasons that I ended up throwing away the bitmap approach, and looking at vectors. Vectors are mathematically representations of lines and shapes, and are made up of points and handles rather than lots of little pixels (like bitmaps). For Worldly, using vectors would have several advantages. Firstly, vector graphics remain sharp, even when zooming in and out at extreme sizes. This would mean that I could load a single map file into memory, and then not have to worry about loading additional data as the game was being played. Also, vector files are smaller (in terms of storage space) than bitmaps, so the downloadable file size would be more manageable.
Choosing vectors meant that we were under quite a few limitations in terms of art. Firstly, there couldn’t be too much detail. Rendering vectors is quite heavy on processing, so the simpler our map the better. Secondly, we couldn’t really use much in the way of textures. Things were (more or less) going to be drawn as flat colours. This influenced our colour palette and the overall style of the game. However, despite these limitations it was clear that using vectors was the way to go for Worldly!
Coming up in the second part of this blog post: how we designed and built the world map, and then implemented it in the game.
Ben Ward