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-)
row expression defines a row of tiles.
--- means empty space, and other three-character strings describe tile types:
GR- (Grass/Right), and
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
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.