# Arduventure (RPG)

Hey, @DSSiege11! I saw you were talking about wanting more room for your map. Well, I know of a sneaky method that actually can save you some room. Seeing as you posted about 2 days ago saying you made some progress, I think this may still help you or may help anyone else in a similar problem. Let’s take a look at the map system for Pokemon Red and Blue. (In later games, they did this differently.) I’m really going to simplify this for others reading the thread, so for your specific game, you can scale this up to have larger maps and however many tiles you need. I’m also going to ignore how you actually store the data, which can be in bytes or ints or whatever, honestly.

This is an example map in the Pokemon Red and Blue games. This map is made up of 20x16 spaces that the character can move unto.

Looking at it, you may think it’d be better to cut this map up and tile the data. (Each square is a space that the character can move to.)

In this pic, I have it sliced up and color-coded for easier viewing. Each color is its own tile. Counting the colors, you’ll notice that there are 23 different tiles. Because of that, this map data would be stored as a 320-number sequence, ranging from 1 to 23.

What Pokemon Red and Blue did to save memory is to group 4 tiles together. There’s an extra step to doing this, but let’s look at how this would be illustrated before talking about that… Notice that the map goes to 10x8.

Color-coding these tile groups, you’ll notice that there are now just 17 colors. Because of this, this map data would be stored as an 80-number sequence, ranging from 1 to 17, which would cut down on memory usage considerably.

To define these tile groups, you’ll have to have 17 different 4-number sequences, ranging from 1-23. That would mean you have 68 numbers in that definition… Together, 80 + 68 is 148, which is how many numbers in memory you would be using. Remember, storing everything on a per-tile basis (in the first example) would cause you to use 320 numbers in memory. This means you’ll have used only half of the memory as the original example if you group the tiles!

Now, if you go ahead and group the tiles into 4’s, instead of referencing the tiles when generating the map, you’ll have to reference the tile groups. This would mean that somewhere in memory, you’ll have to define what each tile group is… The more variety of of tile groups you have, the more memory that will be required to define them. This can be annoying and lead to more memory usage than its worth, but for bigger maps with less variety, the trade-off actually saves you memory. Eventually, grouping tiles together will save you so much memory that defining them can take place in the area of memory that you’ve saved. This tile grouping can be done in 2x2, or 2x1, or even 3x3 if you want. Changing the size of the groups can allow you to find the right balance between tile variety and memory.

I hope this helps!

EDIT

After reading what I posted, I just wanted to point out that within each tile group of the example that I posted, collision checking would be handled the same across all 4 tiles. However, each tile could be responsible for its own collision checking within the group so that it’s not completely uniform, without losing memory.

This means that within a group, you can have areas that allow the player to roam, effectively creating fences and barriers that are more screen-conscious.

If you’d like an elaboration on this, lemme know. I figured it would be straight-forward enough for many to get from the original post, though.

13 Likes

Right on!

I do believe this game is possible if assets are procedurally generated and perhaps the looks scaled down a bit.

1 Like

Thanks for the explanation

I had something similar in mind but instead with tilegroups of 4x4

The way I have it in mind it would end up being 3KB in memory:

32 tiles of 16x16 pixels = 32 * 32Bytes = 1KB (Depends on if 32 tiles is enough, I might need more)
64 blocks of 4x4 tiles = 64 * 16Bytes = 1KB
Map of 32x32 blocks = 1KB

Total: 3KB (+ a few bytes more for the interiors)

@ekem: Procedurally generated levels would be another way to do it but for this game I want to make the world myself I’d love to see someone do it in their game

4 Likes

Wow! That would result in… 2048px × 2048px map! That would essentially be 512 screens that you can move through!

1 Like

Exactly, just like the image in my previous post illustrated

In terms of height that’s actually as big as the world in Zelda Link’s Awakening on Game Boy

4 Likes

For those who want to read where this all came from:
Redacted

@crait in the engines we use with this block methode, we even have tile based collision (not group based)

Moderator Note:
Links to Team ARG’s website have been removed due to malicious new owners.

1 Like

Still haven’t found the time/courage to implement it… Being ill sucks But I’ll get to it eventually!

1 Like

@DSSiege11, Arduventure is using the low 16 bytes of EEPROM, which is reserved for system use. Please change it to only use EEPROM storage above the value EEPROM_STORAGE_SPACE_START (defined in Adruboy.h).

1 Like

Should be fixed now in the demo version

EEPROM.put(0, data);
EEPROM.get(0);

Changing 0 into EEPROM_STORAGE_SPACE_START is all I had to do right?

1 Like

Yes, it looks good now.

Of course you know there’s no guarantee that other games won’t use the same space you’ve chosen and clobber your data. Instead of using EEPROM_STORAGE_SPACE_START directly, you may wish to put a #define near the start of Arduventure.ino like:

``````// If another game is using the same EEPROM space as this one, you can move it to
// somewhere else by changing the "+ 0" to some other offset.
#define GAME_SAVE_AREA_START (EEPROM_STORAGE_SPACE_START + 0)

``````
1 Like

I managed to get the big map to render and it works really well In case it wasn’t clear, the world will be one continues scrolling world (not separate scenes like in the demo) which I think is quite cool

It takes about 32sec to walk from one edge to the other (horizonal or vertical).

Still working on the tileset now but I hope I can show of the result soon!

9 Likes

Continuous scroll is nice!! Maybe down the road you can make a menu + scroll demo for people to get started on their own games?

1 Like

I’m really looking forward to this game! I loved the look and feel of the demo!

2 Likes

@crait: Thanks

Yeah that’s a good idea. It was quite a while ago I programmed in C++ when I started working on Arduventure so I just wrote all code in the .ino file. I took a look as some other projects and I now know how to properly split up code into other h and cpp files That will sure make it easier to reuse the code in other projects!

@20thPaul: Thanks a lot With a bit of luck I’ll be able to show off something new today or tomorrow/the weekend

4 Likes

Checking out @akkera102’s source might lead to some good examples. The entry point used in their programs are really clean. There are some great patterns presented in all of @akkera102’s source .

3 Likes

Are you aware that you can have multiple .ino files in a sketch? All .ino files are concatenated together to form the “main sketch file” before compiling.

Using extra .ino files, instead of .cpp or .c files, to separate your code into functional blocks means you don’t have to add #includes to your primary .ino file to include them. You also get the benefit of the automatic function prototyping “magic” that the compile process does, so you may be able to eliminate some .h files as well, if their purpose is to provide prototypes.

For some details on the Arduino IDE build process see:
https://www.arduino.cc/en/Hacking/BuildProcess

Following the Arduino style guide can also be beneficial to others who may examine your code.

2 Likes

This is a great high quality post, @ekem get this man some kind of badge for this!

@DSSiege11 I am constantly impressed! Keep us informed if you need anything at all!

3 Likes