Seems like people would really enjoy seeing this game come to light @DSSiege11. You demo looks pretty slick. Maybe it can be procedural as all get out! Who knows, maybe… well whatever here’s a tweet for your demo : )
2 Likes
While optimizing the code I’m also reworking the graphics a bit :3
OLD
NEW
6 Likes
I’m excited to see this come to light, and to play it:)
1 Like
I’ve played the demo quite a lot and I really like it. Arduventure looks great. Would love to play a finished version one day. 
1 Like
Wow! I just received my Arduboy yesterday and came in looking for something to try, this demo is incredible. Simply amazing. Can’t wait to see it finish 
1 Like
Thanks guys 
I’ll try my best to turn this into a small but fun little rpg
Btw, for those who want to try it and can’t find the link: http://siegfriedcroes.com/arduboy/arduventure
4 Likes
So I’ve been talking to @JO3RI about map compression and I’ll probably be able to make the world larger than I previously thought! I’m not sure yet if I’ll be making the map this big as I might want to add some audio too. Anyway, this is the size I’m thinking of right now:
Every rectangle is the size of the Arduboy’s screen and the black cube is the size of the playing 
Let’s hope I can make this happen!
also: 10,000+ topic views, wow! 
11 Likes
That would be very cool, I was having a rummage through your old source code and trying to think of how to expand it, will be interesting to see what you both come up with as interested in (eventually) making a pseudo Rogue/Zelda like game, just need to learn C first lol
1 Like
Great minds come from the same country 
3 Likes
This is bar none the game I’m most anticipating. RPGs are my jam
1 Like
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