Apparently they sell your data (your house floor plan). You might want want to get a different brand. It's not going to be much use once it becomes conscious anyway.
Recent community posts
I think the main issue with tail 1st decay is the weird effect on range. Without the head decaying you get this weird marching ants effect as you decide not to add to a worm because you don't want it to be infinitely long. Then it also creates a weird worm farming mini-game as you keep worms alive - which although fun, is a waste of fuel.
I would prefer a different type of block to the worm gun for something like this. Either something that unpacks itself, so tail 1st decay has less weirdness, or perhaps make a bullet based on bugs that has a weird effect on rocks (astro-fac could redeem itself).
What happens when something hits the middle of the worm? Why wouldn’t giving the other segments a timer that is relative to the head achieve the same effect? How is it possible to feed the worm with the worm gun to make it grow when its tail is disappearing first?
I get the intent of this suggestion, but I don’t see how to put it into practice. There would be no way to limit the snake that makes sense to the player. Even with a length cap you could keep the worm alive forever - how is the player supposed to understand they’ve reached maximum length? It would require more special animations - that would probably take me a few months to complete. Is it really worth all that effort?
Perhaps this would be better as a different kind of weapon.
At the moment it's super easy to just rez in anything without bugs (mostly). There's only an active area around the player - everything leaving that area is destroyed and keeps the game running smooth.
Saving stuff gets super tricky when anything moves out of bounds - you have to manage the enemy leaving active space and then being saved without overlapping saved map.
But yeah, you raise a good point because if I go into Junkyard, find a power cell and then march to the station to free up a slot, I'm going to be super sour when I get back and it's gone. I think I will work on the zone recipes first and then see about moving the current system from spawning quick chunks to static zones.
* This could also mean fun stuff like coming back for blocks and the game could see about spawning an enemy ship that's stolen them.
The game now has more content than we need to see in a single sitting. Moving forwards the game be split up into zones and will spawn from a menu designated for said zone. This thread is about what menus could be created from the game as it is. But it will also segue into new features because we can now balance zones instead of balancing the entire game. I'll start:
Junkyard. An asteroid field with some detached crappy 1hp blocks lying around: bulk, gauss, and astro-fac. If the player searches well enough they might find a power cell. Could be on the border of hostile space.
Astroid Belt. Thick with rocks, bugs, and astro-fac ships. Enemies in this area have many drills and basic guns to help them navigate.
Worm Country. Overlaps with Asteroid Belt as many worms feast on its edges. Enemies here have adopted wormer guns, inspired by the hazards around them.
Haven. Surrounded by dense rocks and friendly fighters is a cache of fuel and a friendly space station. It should have some kind of arm that delivers gauss, and another arm that delivers heal. Trading would be cool but will have to wait till more of the game's UI is done.
Slicer Dominion. A new kind of fast moving swarm enemy that can tear through blocks like a drill. The slicers are smarter than fighters and hostile to everything. Trying to navigate their zone is a death sentence. Deep in their space are slicer hubs that are basically slicer-facs.
OP Research. The enemy has an outpost where it is developing an OP block. Enemy encounters in the area will be able to spawn with this block until the player destroys it. Leaving only the player with the advantage.
Comet Field. The player enters an area of space that is eerily empty. Then a hail of comets comes at them. Enemies here are using small ships and mines as well as adding to the chaos with comet blocks.
All shot-types will have a life timer. Can't balance them otherwise.
I'm already planning on a cap animation for the beam. It's a bit unfair getting lazored off-screen and without a range limit I can't balance it against other weapons. It might be cool to see it earlier but at the moment it's OP and has a massive AI presence.
Plan is: Fires something like a homing shot - firing into an existing worm shot makes it grow from the head, only one growth per turn allowed.
It's mostly set up. There's quite a few animations still to do. It will be quite helpful if it works because it will allow Tholian Web style weapons to exist. Other types of shot could expand into nets or create structures.
I know this isn’t a priority, but when I’m ill or travelling it’s been nice to make games in stuff like Twine or other editors that work on mobile.
On iPad I’ve tried to turn on as many experimental settings as possible, but the windows all appear bugged out (the sprite editor window is black, as is the room editor). I suspect it just crashes on initialisation due to some Apple silliness. Does anyone know why? If one of us exported the Bitsy editor via phone-gap or something, could we get it to work?
On my big Android phone, everything seems fine in the Chrome browser. I’m super zoomed in, which makes things hard, but I can still tinker away at stuff (even if I can only see a corner of it).
Again, it’s a big ask getting something to work on phone as well as desktop and I’d rather see Bitsy add features and fix other things instead of supporting something like mobile that constantly changes. But if there’s a quick Borksy style hack one could apply to make your own portable editor, that would be super cool.
Okay, I've just tried to reproduce this and it's not crashing. Not in the browser or on my machine. And I can still move afterwards.
I'm probably misreading your directions. If you remember any more details or can reproduce it by opening the editor (press P) that would help a lot. I'll keep an eye out for anything like it for now.
1. Fighters fixed for next update.
2. I don't mind that you can use mouse to look through a holo, you still have to guess it's a holo - even though ship designs are currently too basic to hide it. I still find it interesting to fight against and can make use of the AI effect. I don't intend to have every block available in the full game, and this block is unlikely to make it into the opening selection. But I see no need to cut it.
3. The enemy nanites can stack, it just happens rarely. I've added a condition preventing clouds from moving into an area with a trigger already in it (bullets / clouds / fuel). This should make things clearer. Adding a time limit means natural clouds can't exist. Adding even more variants of clouds is confusing. If a way to shoo clouds around becomes available I will add it, but currently the code doesn't support this.
If there is a block that is not on the editor palette then it's because it's not a simple as clicking it into existence. If adding enemy ships at random become simple and definitely not the cause of a bug, I will add it.
Figured out how to do a worm-gun. The worm would be like a chain of homing bullets. Splitting it just makes break up into smaller worms. Firing into an existing worm-bullet makes it grow. This would be distinct from wild worms, but I think I might change them up a bit to make this crazy idea possible.
I think I would like a second resource for trading. I can imagine green trading ships that spawn blocks on payment pretty easily. Ram them to pay them and they spit out a block on the other side.
Making it depend on fuel wouldn't be much fun though. It would force you to spend all your time mining. Cash should be dropped by something interactive like blocks - letting you crush them for resource instead of just abandoning blocks you don't like. Or perhaps you have to hunt worms or something bigger.
Tested the laser thing. I got it slightly wrong: It's the most recently added block that acts first. This was done to help the code remove blocks that killed themselves, but that was before I realised that some blocks tear the ship in two - it's safer to count the dead afterwards.
Looks like the laser is obeying attachment order so I'll have to call that one wild for now. Though this does make me wonder about which way the blocks should iterate. New blocks or old blocks first?
Astro-fac is behaving normally after I've added some more rules for pushing. Also putting an end to pushing a core block hit by gauss. It's amusing but it's gonna break stuff.
Cheers. The bomb fac is probably multiple push effects on one rock. The laser is odd - blocks execute in the order they were placed on the ship, will investigate. Should be able to fix for next update.
It's only a visual bug. There's no crash and the block still docks on the right side. The logic for the tractor beam needs a look at but I have to do a load of work on Six Match for GDPR. I'll try to fix this for the next update.
Most of AI is about assigning a score to your goals. You need to know what that score is before you can apply a solution to it.
The game currently uses several heat maps generated by "threats" and acting entities. The ships poll their blocks and react to immediate threats and opportunities.
The main flaw is that they act from the core and move towards your core. I need to add getting the whole glom to look at each direction it could move as well as what advantage is gained by firing. I'm thinking of a democracy. That's more or less what's currently happening but a lot of blocks have veto, and just override any other concern. By building a score for each block's possible actions, I could then adjust the vote based on which blocks have the best utility.
This is something I'd have to do before even considering a neural net because I need data to put into that neural net. I doubt I'll use a neural net, I wouldn't know where to start - and I say this having programmed several classic neural nets in the past.
Sounds complicated. How would you figure out what it does and how would the enemy AI be able to predict several turns in advance to use it? What happens if you just spam it?
As an example: The ships spam astro-fac for two turns when they use it. I found that simply reacting wasn't enough to block a threat - the gun that made the bullet is still aimed at the ship. But add a load of other blocks and the ship starts tooting it's guns like crazy, just to feed the astro-fac's demands.
I'm probably misinterpreting your idea, but factoring multi-turn events into an AI that's looking after a group of weapons that do different things is a world of nope.
This parry effect you're describing sounds like some kind of force wall you're lumping in front of you. I think it would have to exist on the solid layer so it can absorb effects and operate independently.
Someone on reddit mentioned an energy shield and reflective blocks. I said, what about a block that can parry bullets and send them back?
Dunno how to approach this. Perhaps it has 1 hp of reflective layer it gives to surrounding blocks and you can pump fire to restore it? Or does it bat in front of you? It would have to hit a decent space in front of you but is that OP?
I feel what you're getting at, though the solutions make things a lot harder to understand for new players.
I want bullets to basically say - "I destroy". It's easier to read. Gauss doesn't do that, hence the melee approach. I've added the ability for gauss to feed the new gauss clouds I'm adding. They are small benign clouds that will detach blocks, so you can use them to rearrange your ship. This lets you create a defensive net or disassemble your ship completely. Perhaps the block could also have a 2 tile range and use the new pushing code to instigate a pull, I will experiment with this. I agree the block needs support but projectiles is too messy.
The astro-fac has its uses. When the fac is pointing at your rear, it provides the perfect defense against pursuers. Hopefully, the new opportunities to rearrange might make this block a bit easier to use. Perhaps a charged state for rocks would let them glide for a turn - but I want to keep it consistent with the bomb-fac, which is hard to do when the top use for bomb-fac is pump-and-bump. I think the block is more situational than outright bad, but the situations definitely insist on one direction only. For now, I'll keep an eye on it, perhaps try to come up with new synergies with rocks so that they can have more utility.
Sorry about the switch to the forum. I felt the comments were getting a bit long and it'll be easier going forwards to keep track of bugs and whatnot as topics.
I'm a bit miffed it won't let me have comments and a forum. Maybe I just haven't figured out what setting to use.
Feel free to comment here from now on if you've got something to say.
S.S.Bagel went through many revisions in its former form as East Bagel Ship. Certain weapons like the Launcher were ridiculous. The repair block required adding cool downs to the engine because no matter how I tried I couldn't nerf the damn thing.
You might have your own ideas about:
- Cool down timers - from bullets to how often bugs lay rocks.
- When you should encounter a block (bear in mind a game should progress not as a slope, but with spikes of activity and recovery).
- The availability of fuel.
- Better tactics from large enemy ships.
- Bizarre wild life.
- A new type of block or better version of an existing block.
Be as ambitious as you like, some ideas might just be crazy enough to work. I will also post ideas - more mechanics generally involves a lot of nerfs and boost to other systems (I've just added mines at the time of this post and you can totally confuse the AI with them).
Bugs come in two categories:
- Hard Bug. Doing X causes Y, every time. This is a reproducible bug. It could be a flaw in the code, or it could be a flaw in the design. But it can be addressed.
- Wild Bug. Something weird happened or the game crashed. The best thing to do in this situation is not to come up with theories, the cause of the bug could have happened long ago, and we are only now catching up with the effect. What we need is data. A watch will be placed for future occurrences. Then we can look for patterns in that data and solve the problem.
I can't promise fast resolution, but rest assured I do want S.S.Bagel to be an exploding chess game where logic prevails. The data shall light the way.
This is cool. Though you should press P to open the palette and experiment with the Tractor block. It's way more powerful than you think, you can build ships with gaps - this increases your surface area (more guns).