The Making of Elventure

Code by Trodoss

Art by Trodoss

Trodoss started on Elventure in September 2011 as a way to learn both the Arduino and about the Video Game Shield.  Experience with other microcontroller platforms made the learning of the Arduino environment easier.

The first step was learning the specifics of the Arduino IDE, and adapting some of the code that was given as examples.  The TVOut library had a lot of good documentation however there were a few things that had to be learned by trial and error.

When building the game, the first large hurdle was coming up with a way to store the map data so that a relatively large map could be created for the game.  For more information on this see the “Elventure Map Explanation” documentation.

The next major hurdle was coming up with a way for basic audio to be incorporated in the game.  TVOut supported it’s own version of the “tone” command, however a small 1-voice sound system was needed for the project.  Minimal code was put together using RTTTL (or “Ring Tone Transfer Language” markup) and converting that to a format that could be used for basic music/SFX.

Once the code was working,  the Video Game Shield code was ported to the Nootropic Design’s Hackvision platform.

Elventure Map Explanation

The map for Elventure is a 128 room map, divided into a 64 room “over world” and a 64 room “underworld” that are linked by portals.

Map (Room) Data

An individual “Room” in the data is made up of 12 x 8 tiles. 

The physical data of the room is made up of 12 columns of vertical “Pattern” data, each 8 tiles in size.

Each byte (char) of data in the pattern data corresponds to a particular tile in the “map_bitmap.cpp” data.  Each of these entries is an 8x8 “tile.” (From left to right, the numbers on these would be 0 to 6, and the highlighted tile is 1 – a tree bitmap)

As the map data is being built, the “patterns” that are present in the map into a sort of dictionary, and only “adds” a pattern if it is unique.  This acts as a simple form of compression of the data.

The physical data that makes up a room looks like the following:


        //map room data

        PROGMEM prog_uchar map_room_data[] = {

        0, 1, 2, 2, 2, 3, 3, 2, 2, 2, 1, 4,

        4, 1, 2, 2, 5, 2, 2, 5, 2, 2, 1, 4,



Each of the bytes (uchar) in the data corresponds to a particular pattern present in the pattern data, and there are 12 patterns (from left to right) that compose a room.


Room (Item/Monster) Data

In each room there can be multiple “Elements” present.  These can be either an item, a portal, or a monster.


The element data is structured in the following format:

[Type], [X Position], [Y Position], [End of Record]


        //room element data

        PROGMEM prog_uchar room_element_data[] = {

        0, 72, 16, 255,

        3, 64, 16, 255,



The table below lists the element types (and their corresponding number value) used in the data:

Linking the Elements to the Room Data

In the “room_data.h” file you will see “prog_uchar room_element_index_data”.  In this data, there is an entry for every room:

        //room element index

        PROGMEM prog_uchar room_element_index_data[] = {

        255, 255, 0, 1, 255, 255, 2, 3, 4, 255, 255, 255,



An entry of 255 indicates that there is no element data used in the room.  Any entry that is less than 255 indicates the “start element” entry to look for in the room.  Multiple element entries can be read for the room (see previous information) until a value of 255 is reached.

The map data is being stored in such a way as to compress the data.  If the map data was not being “compressed,” the data for 128 rooms of 12x8 data would be 12Kb in size, which would leave less room for the actual game.

For each room there are multiple “sets” of data that are present:

    1)      Map (Room) Data

    2)      Room (Item/Monster) Data

    3)      Map Bitmap Data

In “map_data.h” you would see something that looks like the following:

        //map pattern data

        PROGMEM prog_uchar map_pattern_data[] = {

        1, 1, 1, 1, 1, 1, 1, 1,

        1, 1, 0, 0, 0, 0, 1, 1,


The X and Y positions in the data correspond to where the element would be placed in the particular room (How the element links to the room will be explained later).

The “End of Record” will have either 0 (indicating that there is another element in the room), or 255 (we are at the end of the element data for the room).