7DRL-like ⚔

I had planned to participate in 7DRL this year by making a roguelike for Blinks. However, I have a really difficult time doing game jams due to my day job and other family commitments.

I’m still going to try to do it, but it will be unofficial and using a modified schedule. I’ll start now and keep track of the time I spend on the project. I’ll keep my total time under 56 hours (7 days * 8 hour/day) and try to get it done by the 7DRL deadline of March 14.

I’ll use this thread to post progress.

1 Like

lol of course I’m getting compile errors with simple programs
Interestingly, compiling with Bruno’s custom blinklib works fine, but the standard lib gives me this:

“C:\Program Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.42.0_x86__mdqgnx93n4wtt\hardware\tools\avr/bin/avr-gcc” -Os -g -flto -mrelax -fuse-linker-plugin -Wl,–gc-sections -mmcu=atmega168pb -T “C:\Users\Scott\Documents\Arduino\hardware\Blinks-SDK-1.1.0-GM\avr/linkscripts/avr5.xn” -nostartfiles -o “C:\Users\Scott\projects\build/roguelike.ino.elf” “C:\Users\Scott\projects\build\sketch\roguelike.ino.cpp.o” “C:\Users\Scott\projects\build/…\…\AppData\Local\Temp\arduino_cache_650348\core\core_Blinks-SDK-1.1.0-GM_avr_blink_f5b85855fa65c8e0ef1a5ed67936d89d.a” “-LC:\Users\Scott\projects\build” -lm
C:\Users\Scott\projects\build/…\AppData\Local\Temp\arduino_cache_650348\core\core_Blinks-SDK-1.1.0-GM_avr_blink_f5b85855fa65c8e0ef1a5ed67936d89d.a(startup.S.o):C:\Users\Scott\Documents\Arduino\hardware\Blinks-SDK-1.1.0-GM\avr\cores\blinklib/startup.S:71: undefined reference to `mainx’
collect2.exe: error: ld returned 1 exit status
exit status 1
Error compiling for board Blink.

Did you modify any files in the blinklib source tree? because it looks like that. :slight_smile:

Hm, yes I had, but it was limited to another project. Even that other project wasn’t compiling.

Strangely, I just tried again and it works. So probably related, but I don’t know what causes it for sure.

Thanks for the suggestion.

Time elapsed: 5h

Not a ton to show at this point so I figured I’d go over some design choices.

The game will be played with seven Blinks: one center surrounded by six in a ring. It just seemed like the simplest thing to do given the time constraints.

The player will always be in the center tile. The tiles will display the current room and the six surrounding rooms. If there is an exit, you’ll be able to click a surrounding tile to move your player into it. The view will then shift so that tile becomes the center and the other six update to show the new surroundings.

So tiles need to have assigned roles. There is the player tile, the six adjacent tiles, and any extras you might have attached during programming.


When the tiles start up they are in the init state (white). Clicking one will assign it as the player tile (red), which will tell its neighbors that they are the “adjacent” tiles (blue). All others will then turn off to signify they are not needed.

Of course, I need to support removing/adding tiles. So you can see where the tiles dynamically update as they are moved around the cluster. Any tile next to the player tile (red) turns blue. Any tile further out than that turns off. Things will break if you have two player tiles, but I’ll consider that user error since it shouldn’t happen by accident.

In the first five hours I have also started setting up data structures to define the room types as well as the level generation algorithm.

At the start, I decided to use @BGA’s custom blinklib to remove as many constraints as possible. In addition to the code/data storage gains, I plan to take advantage of the increased number of bits you can send on face values. More on that later.


Funny enough, someone pitched an idea like that to me but I did not get around to implementing it. Are you doing a persistent map or will it always be generated like in thalassophobia? I think that doing a persistent one (so you can backtrack) would be more interesting but then you are limited by the memory available. If you disable datagrams, you might be able to have over 200 rooms with some memory to spare for room specific data.

1 Like

Yeah persistent map. I’m trying to keep this close to traditional roguelikes. I’m using 4 bytes per room so I won’t get that many rooms on a given level, but that’s okay as long as it doesn’t feel short.

I definitely have datagrams disabled. That reminds me that I haven’t removed the dim() function yet, but maybe I’ll keep that for later when I’m getting short on space and need to eke out a few more bytes.

1 Like