This project is read-only.
The Overworld Map is a component in most 2D Mario games. The player stands on a representation of the current world he's in. Level markers appear on the map, and the player can navigate to them via path tiles. The player can enter these level tiles which starts the corresponding level.

The Overworld in SML

The overworld is a work-in-progress being coded by Celarix. The most recent versions can be found in his weekly builds of Version 0.04a. The information in the page is current as of Alpha Version 0.04a build 6, released June 2, 2012.

How it works: the basics

Essentially, the world is a collection of static and animated tiles with players being drawn and updated. Here is a quick rundown of the classes used in the overworld:

This is the main class where all the loading and updating and drawing takes place. In order to use it, you must first call the Load method with a valid world file (more on that in a minute). Then Update and Draw are called normally.

WorldScene.cs and WorldScreen.cs
These are just the basic classes that allow the game to access the world; there's nothing to note here.

A static tile with only one Texture2D and a position to draw it at. It has no update logic. This is a reference type, so be sure to use Clone() to make a deep copy.

An animated tile with a List<Texture2D>, a position, and a frame counter. This frame counter increments once per drawn frame until it hits a predefined number. At this point, the counter is reset and the texture used is incremented. It has no update logic. This is a reference type, so be sure to use Clone() to make a deep copy.

A player that can move about the world. It can have either one or four "poses". One-pose players use one set of frames, whereas four-pose players use four sets of frames, one for each direction. The frames are changed the same way as WorldAnimatedTiles.

Loading Logic

Perhaps the most complicated part. All tiles and worldplayers (and other things eventually) have configuration files that determine attributes such as size, name, and ID number. Here are sample configurations for each element with comments describing what each field means:

These config files are stored at "%whateverthecurrentdirectoryis%/resources". Tiles are named "wtile-#.cfg" and players are named "wplayer-#.cfg" where # is the ID.

The world file format is defined in depth here:

Loading logic
First, a filepath is sent to a new World instance, which checks that it exists. The header values are sent to fields, and then static tiles are loaded.

First, the tile's entry is loaded and parsed. Because there are going to be a lot of repeat tiles, a Dictionary, using the ID as the key, is used to store preloaded tiles and copy them as needed. If the tile is already preloaded, it is merely copied.

If it isn't, the first thing that happens is that the tile's config file is loaded. Because SML will work with spritesheets, the config tells the game where, on a given spritesheet, the tile is. The game loads in attributes such as name and size, and then crops the spritesheet using SpritesheetManager (todo: write page on this and link). A new tile is returned to the loading method, where it is placed in the preloaded tile Dictionary.

After all the tiles are loaded, they are added to a List of tiles. Then, to free memory, the preloaded tiles are cleared. The animated tile loading is much the same way.

Loading custom tiles
A custom tile uses a custom config file and a custom PNG file whose path is included in the config file. The loading occurs much the same as normal tiles. In the world file, the tile ID is replaced with a path to the config file, and the "source" attribute in the config file points to a PNG. Both the config file and the PNGs for it should be in the same folder as the world file (or in a folder in the same folder).

Notice: This format is likely to change to become as much like standard INI as feasible. This information is subject to change.

Updating and Drawing

Drawing is simple; it merely iterates through all the tiles and players and calls their own Draw() methods.

The Update method (for now, at least) checks the input every frame. If one of the arrow keys is pressed, the currently focused player will move around the world. Pressing the J key will jump between the players in a smooth scroll that lasts about 30 frames.

The update also updates the camera, which is always centered on the current player while not jumping.

Just a note: this feature is still in development and there are parts of it I'm not too satisfied with. Just remember that things may change and if you have any questions, ask me on IRC or by e-mail.


Last edited Jun 4, 2012 at 5:36 AM by smcgamer, version 1


No comments yet.