Hello All! I just want to introduce myself and kind of come out of the shadows a bit. I participated in the second Kickstarter, and I’m super excited to receive my Blinks in September! In the meantime, I’m working on a game idea. I hope to have it mostly done by the time I receive my Blinks. I considered waiting to share my idea until I was done with it, but I’m just too pumped up about it.
I was curious what people’s thoughts are on a static play setup with a set number of Blinks for this very dynamic platform. Bad idea? Intrigued? Let me know! Rough details are in the readme. I would greatly appreciate any / all feedback!
Welcome to the forums! Make sure you stop by the New Member thread and introduce yourself to everyone
Liking the sound of your concept so far! It sounds like you’re aiming for this to be more of a cooperative game. Do you have an idea for a “Win Condition”? Or will it be mostly about keeping the trees alive as long as you can before they die? I’d be glad to playlets this for you but I’m currently only rolling with 6 blinks… Hopefully someone else on the forums can give it a try!
On a side note, there is someone on the forums exploring a similar concept, though it’s less of a game and more like a simulation (Terrarium). Might be worth taking a look at!
These are some great questions. The closest idea I have for a win condition is that the team who can keep their half of the tree alive the longest wins. I like the idea of being cooperative to keep the whole tree alive, though! Maybe there can be two play modes? Thanks for the offer to play test, but right now the idea is for 18 Blinks. I don’t know how my game could work with 6, but I might explore that eventually.
Terrarium looks amazing and intimidating from a coding perspective! Wow! I’ll keep my eye on it for sure.
Welcome Alfred! It’s always exciting to have another developer join the community. I think your game idea is pretty cool! While there are some theming similarities with Terrarium, I think that the scope and gameplay mechanics of your game will definitely help to differentiate the two.
One aspect that I think has a lot of potential is the multi-phased gameplay with a “planning/setup” phase involving the trunk and the “gameplay” phase involving the leaves. It would be awesome if you could find ways to make trunk design/layout materially affect the gameplay portion. That way players can make tactical decisions during the setup phase that might give them advantages/disadvantages during the game phase and allow for different strategies.
Another idea would be to give the game a sort of tug of war mechanic. If one side let’s enough leaves die they loose a branch piece and the other team connects it to their side to sprout a new branch. Eventually one side will completely die out and the other side will be flourishing.
Feel free to use or discard any of these ideas as you see fit. It’s your game, so the important thing is that it meets the vision that you have for it. Best of luck in your development, and I look forward to seeing how your game grows going forward.
Love the idea. I’m always into gameplay involving plants
Before visiting your github page and reading the README I was trying to envision what a competitive tree growing game might look like.
My first thought was for 2 or 3 players, or 2-3 teams. There would be a central “soil” tile and each team would place one tile as an initial trunk sprouting off of that towards them. For 2 players/teams they would be placed on opposite sides of the soil. For 3 players/teams they would be evenly spaced around the soil.
Gameplay proceeds from there to grow your tree. Having everyone connected to the same constellation of tiles makes win conditions easier and allows for one team to directly impact another team.
The downside is that you are growing your tree towards yourself, which is totally upside down relative to what you’d expect. So maybe not the best idea!
Can’t wait to see what you come up with.
[EDIT] Also, the plant growing algorithm in Terrarium is somewhat simplified in order to conserve code and data space. I’m excited to see what a game dedicated to the idea might add gameplay-wise.
Thanks for the feedback everyone. I’m starting to hit a wall as to what I can simulate in my brain based on what I’ve coded. I’ll need to have my blinks in hand before I can do more of the timing and complex stuff.
Question if anyone is reading this: How quickly does a handshake occur between two blinks for the following scenario?
Press Blink
Send message
Read message
Send ACK
Receive ACK
Stop sending message
Let’s say I have a different color for each step 2-5 and off for steps 1 and 6. Would it be imperceptibly fast? My gut says I need to artificially slow it down, but I won’t know unless I see it or if someone can tell me. TIA!
I think it’d be pretty fast, but maybe not imperceptibly.
Take a look at the first gif in my update here showing the bug flying between tiles.
That is done with a similar handshake to what you describe. The original tile has a bug that reached the “edge” of the tile. The tile sends a request to transfer the bug to its neighbor. The neighbor receives this, decides it has room to accommodate the bug, and turns on its bug code. It also transmits a “I took the bug” message back to the originator. That causes the bug in the original tile to turn off.
The gif isn’t the best quality, but you can briefly see frames where the bug appears in both tiles while the transfer is in progress.
I’m making slow progress without my dev kit, but progress nonetheless. Most of the animation and effects I’m saving until the end, but I’m excited to see what kind of effect this might look like.
This heavily depends on the size of the message and any other work being done in your nation loop. Messages are only sent after the main loop returns. Assuming you are sending small messages, you should be able to do this at least a handful of times per second, so it is pretty fast for most cases.
Just read the game concept, this is very cool. It’s well thought out and sounds like fun.
Not sure if you’re open to any more design cycles, but what if you incorporated water? Maybe toggle the soil on and off to turn on the water source? It could add another level of complexity for things you have to juggle while playing. Too much or too little water and the leaves die more often? I didn’t really think about this for more than 3 minutes, so maybe it wouldn’t fit in your design. If not, don’t mind me, just trying to add scope for other people
Thanks for the ideas! I’m always open to them, especially since I have a) no formal background in game design, and b) have no real way to play test this outside of my family.
As it stands, my current design definitely doesn’t employ clicking enough and under utilizes the trunk and the soil, so I will see what I can do to adopt that concept. My current goal is to get to my original idea and expand from there. I also want to see if I can somehow accommodate dynamically sized trees for players with fewer than 18 Blinks. But that might be a v2.0 thing.
Thanks for taking the time to read about my game! Cheers!
I think some fragmentation data of the user base would be helpful for those kind of concerns. I’m an Android developer, and every time you start a new project, you can see what version of Android to target to cover the % of the user base you think is acceptable. If you only need to cover 80% of the users, then you don’t need to go all the way back to KitKat for example.
I think Jon posted something in the past about this, but I think 18 is actually getting more and more common. I know it sounds bad to target more than the core set, but if you saw how many users buy more than that, you wouldn’t worry as much.
I read that too. I think the number was +/- 70%? Also, I felt like it would be cool to be (one of the) first games that require 18 Blinks (or more potentially in the future). It might also make a good value add / proposition for buying more Blinks assuming the game turns out to be fun.
Oh for sure. There’s value in targeting both a core set, and people that have multiple sets. Having games that work with 6 or under is nice as it helps get people into Blinks. I’m guessing here, but I have a feeling that the price point is the biggest hurdle in expanding the user base of Blinks. So the more games that work with just 6, the more people will buy a single set and then get hooked and buy more later.
That said, if you bought multiple sets, you want an added experience, too. Having games targeted or scaleable to high numbers of blinks (like Raid, Paint Brush, Dark Ball, etc.) encourages people to expand their sets and honestly makes for better games IMO.
I can’t believe it’s been nearly two months since I posted this! Right now, I’m eagerly awaiting my KS2 Blinks and dev kit. I’ve been coding this blind, and I can’t wait to see just how far off my code is .
I’m curious if anyone has tried loading this up. I think it’s about 90% complete (not counting play test iterations). I changed the requirement from 18 Blinks to allow a variable amount of Blinks so I can test different permutations and tree configurations. Basically, when you grow the trunk to a height you’re happy with, you double click the Blink and it will split the path for the branches. When you’re done growing the branches, you double click the ends of the branches to trigger growth cycle. At least, that’s how I hope it will work!
I know this kind of a nothing post, but the forum was quiet, so I figured why not? Cheers!
This is one of the games I’m eager to try out, but I’m only rolling with 6 blanks right now. Whenever I manage to get my hands on my next set I’ll definitely load it up!
After that livestream, I got pumped - but I also got it in my head that I needed to hunker down with my game. So that’s what I did for the last three and a half hours; I refactored and rewrote a bunch of my code. Much of it - to my honest surprise - was just straight up broken and would never work. It’s ostensibly less broken now? I think? The take away: coding after midnight in one hour chunks over the course of months without a solid design is a recipe for disjointed and terrible code. Surprising, right?
It’s come a long way since I started. It no longer requires exactly 18 Blinks, but you will need many to enjoy it. I still recommend 18 or more, but I’ll have a better idea after play testing. I also updated the README with how to set up the tree dynamically.
Anyway, if anyone is feeling saucy, please load it up and let me know how broken it is! Otherwise, just stay tuned into this thread; I’ll keep updating once I get my dev kit! Cheers! Now if you’ll excuse me, I’m going to make like a tree, and get outta here.
I just got GitHub actions working with arduino-cli and artifact uploading if anyone wants to take a look. It took a while to get the compile commands right. Lots of googling
I removed the cumbersome setup phase of the game over the weekend. I think it was an unnecessary vestige of my newness to the platform.
The code is getting more and more trim. I’ve been adding more inline comments, too, as I believe this is a requirement for acceptance (and just generally good practice ). Excited to try it out!