Lisp Game Jam Log #2

I am making progress on my game jam entry. Last night I was able to make the code to load a spritesheet from Kenney Game Assets, using spritesheet code I previously wrote for my eggsweeper example game. To test that the sprites were defined correctly, I arranged a simple scene, shown here in the screenshot.

I then started working on the data structures for representing a game level. So far I have a level type, which holds many individual tiles, each of which has a tiletype that defines the appearance and default properties of a tile. A level is not responsible for managing entities such as players or items; those things be managed by a scene type, which will also hold a reference to the level.

As I was drifting off to sleep last night (or rather, tossing and turning with my head full of ideas), I pondered different approaches to defining a level format. I want the level format to be pretty simple and text-based, so that levels can be created in a text editor, without the need for a dedicated level editor program.

One easy-to-implement format would be to simply have s-expression based list of all the tiles in the map. But that would be pretty hard to visualize and modify in the text editor. I also considered having two parts to each level: a s-expression file describing metadata and logic, and an PNG image file where each pixel color represents a different tiletype. This might be easier for people to visualize and edit, but harder to implement.

Right now I am leaning towards a simple s-expression format with tiles of three characters, separated by spaces, like so:

(prop title "My First Level")
(prop author "John Croisant")
(prop num-players 2)
(row --- --- --- --- ---)
(ids ~~~ ~~~ C1~ ~~~ ~~~)
(row --- --- PLT --- ---)
(ids P1~ ~~~ ~~~ ~~~ P2~)
(row GL- GM- GR- WT- GL-)

Here, each row expression defines a row of tiles. --- means empty space, and other three-character strings describe tile types: PLT (Prop/Ladder/Top), GL- (Grass/Left), GM- (Grass/Middle), GR- (Grass/Right), and WT- (Water/Top).

Each ids expression assigns three-character IDs to the tiles above it. The IDs can be used to assign special gameplay behavior to that tile. The ~~~ means the above tile has no ID, so the tile doesn't have any special behavior. This level has tiles with IDs C1~ (Coin 1), P1~ (Player 1), and P2~ (Player 2). Probably there will be many pre-defined special IDs for gameplay, plus the ability to define custom IDs. The custom IDs could be used to connect a button tile to a trap tile, for example.

This level also has a few prop expressions to define extra level properties. The title and author properties are metadata about the level. The num-players property indicates how many players the level is designed for.

I think this format will strike a good balance between ease of implementation, ease of visualization, and ease of editing.