A few simple newbie questions

I have only received my blinks (core set plus epic adventure) less than a week ago, but I’ve already got a custom game idea in the works. I’ve done some simple arduino coding in the past for some custom nerf blaster hobby related stuff, but am still relatively new to programming and arduino in general. I have a few questions that I need to have answered while I’m in the planning phase to avoid creating mechanics that blinks perhaps cannot do. I apologize if these questions are old-hat, but I haven’t been able to google search my way to answers for any of them, so I hope you are willing to indulge me.

  1. What is the absolute maximum program size for a blinks game?
    1a. Do you feel that this maximum program size is a significant limitation for most games, or is there plenty of headroom in your own experiences?
  2. Can a blink be programmed to recognize how many blinks it is away from a specific “hub” blink? In my specific case, I’m trying to design a game with a “hacking” theme where there are one or more “mainframe” blinks protected by layers of “firewall” blinks, but I need each firewall blink to know how far away it is from the nearest mainframe for several gameplay reasons. I have to imagine this is possible, but if it isn’t, this pretty much shoots down my entire game design, so I figured I would make sure.
  3. What is the best way for somebody in my position (new to blinks, somewhat new to arduino programming) to learn the basics of how to program a blinks game? In the past, my usual go-to is youtube tutorial videos, but since this game is still somewhat niche, that isn’t exactly a lush resource for learning. Additionally, a lot of the posts on this forum seem to be more advanced than where I currently am, so I need help learning where to go to start walking before I run, you know?

Hopefully you fine folks can help point me in the right direction here, and I hope to be an active contributor to this community before too long. Thanks so much!

Welcome. Answer to your questions inline:

5888 bytes is the maximum size for the resulting binary.

It is a limitation, definitely, but I would not say “for most games”. Games with more complex logic will suffer more with this but most games have a relatively simple logic (and are fun anyway, which is what matter). Personally I am constantly fighting against the storage limitation.

It is non-trivial as far as Blinks programming goes but it is possible, Hexxagon, for example, knows where every blink is located in relation to every other Blink (it keeps a game map). More specifically, Hexxagon has functions to compute the distance between 2 Blinks (trivial after you have a map :slight_smile: ).

In your example it might be a lot simpler to implement, specially if your game does not have to deal with holes in the board.

I would recommend going to Github and checking Move38’s repositories. Some of the games are very simple and might be relatively easy to understand even for someone just starting.

I think there are a number of ways to do this, some more efficient than others. Here is a sketch sharing one such method - My take on network messages - #10 by bigjosh Definitely worth trying out that sketch to get a feel for it.

What is the best way for somebody in my position (new to blinks, somewhat new to arduino programming) to learn the basics of how to program a blinks game? In the past, my usual go-to is youtube tutorial videos, but since this game is still somewhat niche, that isn’t exactly a lush resource for learning. Additionally, a lot of the posts on this forum seem to be more advanced than where I currently am, so I need help learning where to go to start walking before I run, you know?

This Saturday 1/30/2021 @ 10AM ET for Global Game Jam, @danking222 and I will be doing a beginner workshop, the recording will live on YouTube as well. We are also updating the developer resources and examples to keep it simple :slight_smile: :arrow_forward: move38.com/letsdothis

Looking forward to helping you make the next hit game :raised_hands:

best,
jb

Thanks for the info! Bummer that I’ll be working a pharmacy shift at that time, but if there are videos after the fact, I’ll be able to learn from them!

Thanks so much for the direct and informative response–I’ll definitely have to chew on that in my coming days off. I’m used to designing physical games, so the idea of “can this platform actually DO that” is a new thing I’ve been struggling with. Thankfully the blinks system seems to be robust enough to allow me to do what I imagine, though we shall see if the program size issue comes up. My next step is really getting the full concept and all of the edge-cases I might need to worry about down in both physical and digital paper, then I’ll have to learn how to make everything work in code. Despite this, I’m irrationally excited to join this community of makers and players, and can’t wait to contribute with my own works!

1 Like

My two cents.

The more ambitious your idea, the harder it will be to fit in the space provided. Definitely start simple with your first project. As you progress through that first project you will see your sketch size increase. You may or may not hit the limit, but at least it will give you an idea for what is possible.

Personally, when thinking about a new project I am also thinking about how to make it fit with the features I want. I might also consider what features I could cut if I start hitting limits. After making two projects I kind of have an idea how ambitious I can get, and it’s really a struggle.

For instance, my puzzle game Dispel! is pretty simple conceptually, but I still hit the limits for code and data and ended up cutting some features (notably, the ability to share RNG seeds so others can play the same puzzle).

To be honest, I think the Blinks hardware has tons more potential than what is currently allowed by the code space.

I’ll skip (2) as I’ve never done it (though one of the games in my head might need it).

For (3) I’d just jump into the simulator and tinker around. If you’re familiar with C you should be fine. I had zero arduino experience before this too.

With regard to Blinks knowing how far away other Blinks are, there’s probably several ways to do it - here’s how I’d approach the problem:

  1. Starting at the Mainframe Blink (in your case at least) ping the surrounding Blinks with “1”.
  2. Every Blink that recives a distance ping remembers it and, if the ping is the lowest it’s recived (in a suitably short time frame) it adds one to the ping and pings the surrounding Blinks with the new number.

…I expected that to need more steps…

There are a few more things you could do (for example, triggering the distance pings with some un-numbered request ping, whether that’s from the firewall that wants to know, or a random Blink you interacted with to start that phase of gameplay) but that should get you started.

Not sure if this thread is still active or not, but reading though this one, I felt compelled to chime in.

While much in the same situation as the OP I find that my ideas are at best aspirational for Blinks. I had elaborate systems that more or less had me converting values into a brand new number system, only because I felt the game needed it, either for theme, or facilitate what Blinks can and cannot do.

Yesterday, in flash of lightning, I realized that I would probably still be best served by simple math and multiplication of values I had on hand, than to convert everything over, and guess at how the new conversions should stack up to each other.

Finally, I found myself returning to a quote I have always liked, and I think is apropos to both the size limitations of a Blinks game, and the budding blinks programer.

“Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.”

-Antoine de Saint-Exupery

1 Like