Too ambitious, can't debug, keep getting stuck

Support
1

I have ground myself down to a nub, and my motivation to continue is really flagging. I think it’s time to [gulp] ask for help. I’m not sure what to say first, without spilling all the beans (yes, it will end up open source, but I was really hoping to have something functional first, at least, if not exactly how I want it).

I guess I should go for the big confession first: The concept is a suspenseful spelunking game, playable with as few as 2 Blinks (the more you use, the easier it is to play). Tentative title is Cavern Crawl.

While I awaited my dev kit, I worked on maze generation algorithms, and had a hex-maze generation algorithm that satisfied me. So, in my first attempts, I was trying to use that, ported, more or less. But I had so little experience with the way these li’l buggers work and communicate that I had so many problems that I just had to restart from scratch about four times before I got anything meaningful happening (not counting my very first, tutorial-level efforts to confirm that the rig was finally hooked up right).

I will explain more, but probably what I need is a pair programming partner. So, if you like the sound of the project (and aren’t completely disgusted by the rest of my story :sweat_smile: ), let me know, or feel free to ask more questions.

I’ve got a little bit of planning documentation I can share with you (such as a state diagram, which helped me finally get some semblance of the functionality I want).

Here’s the basic technical concept:

  • Initialize a Blink as the cavern entrance (for now, via double-click). Originally, this also generated the whole maze, but before I got anything working, I switched to an explore-as-you-go algorithm. So, not even the Blinks know the surroundings at first!
  • The entrance is thus also the “current” Blink (i.e. it’s where you’re standing in the cave, torch shining), and has to figure out which directions are open to travel (there are some simple rules for this, which you can play on a standard hexpack).
  • Any Blink that isAlone() and is not the current Blink goes into limbo: It forgets where it was previously placed in the maze, and is ready to become a new location.
  • A limbo Blink that gets attached to a valid passageway from the current Blink gets the map so far from the current Blink, and becomes the current Blink itself.

I’ve got long-term, and even eventual pie-in-the-sky features I want to add, but right now, I’m just trying to be able to walk around the cavern reliably (such that with enough Blinks, I can leave a trail of Blinkcrumbs to see where the path was, or I could map it on hex graph paper, and find my way back to the entrance).

Some more technical details:

  • Before I ever got my dev kit, I knew that memory and datagram size would be bottlenecks I’d have to consider, so…
  • For now, I am encoding the cavern map in a bitmap, and keeping the bounding dimensions to a 6 by 6 lozenge (in the geometric sense of the word: a non-square rhombus; a parallelogram with all side the same length).
  • The datagram sent to the neighbor blink is thus {cavernEntranceId, neighborBlinkId, cavernMap[]} and the cavernMap is 6 bytes, in case you didn’t figure that out already. Not much data, and it transfers quickly.

Currently, attaching a limbo Blink to a non-passage does nothing (yay!); connecting it to an exit moves you to the new Blink, and shows its exits (awesome!), and the old current goes “not curent” (lights out — well, at the moment, for debugging purposes, I’m just dimming the lights); however, the new Blink’s exits are not necessarily in the directions you would expect. In other words, the direction from which you came might not be an exit, and this is clearly wrong.

So, possible points of failure right now (any number of these might be true, too, sadly):

  • Maybe I’m writing the bitmap (which is the cavern map) badly.
  • Maybe I’m reading the bitmap badly.
  • Maybe I’m constructing the datagram badly.
  • Maybe I’m unpacking the datagram badly.
  • Perhaps I’m “copying down” the newly received bitmap badly (which could just be the first bullet, or something further).

I’m going bonkers not being able to debug things easily.

Obviously, I’ll get you access to the code and diagrams and such, but I want to see if anyone is interested. So, anyone interested in a little nearly-blind spelunking? Both in the game itself, and in creating the game? :sweat_smile:

I would be similarly thrilled for good debugging utilities/advice.

Thank you for reading all this! I’m weeks worn down, and so in need of help, tools, new energy, something!

3 Likes
2

That does sound like a lot. We’ve tinkered internally with dungeon crawl ideas in the past, and never quite settled on the exact method we felt would be best/most plausible. I would definitely be interested in seeing the code you’ve got so far, but also in maybe talking through how you could take the central concept and desired game-feel and find a design that achieves those things without the technical difficulties.

Either way, I think your best bet is to just make the repo public and let me and the rest of the community take a look!

2 Likes
3

Are you accounting for the fact that tiles can be connected in any orientation? If you have hardcoded tile indexes then that could cause issues like what you are seeing.

In my project, I have the concept of an up and down, which makes tile orientation critical. I can fix that code-side of course, but that eats into precious code space.

Anyway, I’m down to help.

3 Likes
4

:laughing: Oh man, I didn’t see notifications from the forum that people had responded, and just this morning, I figured out a debugging idea (finally!!) for my current situation. The display of cell IDs that I devised involved showing where Face 0 was, so I could read the value, and as soon as I saw two white 0 faces pointed in different directions, I realized I hadn’t considered relative orientation. So, that’s on the to-do list. Unfortunately, I could have realized that 3 days earlier if I’d seen these replies!! Thanks, @ScarPixel for what would have been a huge tip! (Orientation isn’t the only problem, because keeping them all oriented the same way showed strange behavior at the edges of the map, too.)

@danking222, I appreciate the input, and I thank you both for your offers!

The strange behavior at the map edges, combined with the occasional communication oddities you can create by molesting the connection at an inopportune moment have convinced me to go back to generating the map during setup() (time to go gravedigging through earlier revisions!), so I’m on a good track again.

I’ll keep you posted here as I progress. Hopefully I won’t need to trouble you for the help so generously offered, but it’s a huge relief to know that you’re here to help me avoid getting completely stuck for weeks again!

2 Likes