Sure. Added the download thing.
Recent community posts
Thank you. But I must be that guy and remind you that the original game is called Rogue. Not “rouge” which is a colour.
Each time you use the word rouge instead of rogue, a fairy spontaneously combusts. Please think before you speak. Careless talk costs lives.
100k upwards is good. A multiplier of x50 is generally essential, it turns normal rocks into gem-rocks.
I'm trying to add another hard enemy to the end game at the moment. Based on the "+" from Ending - it starts off in a wall and will push you to death. Hit it (1000pts) and it breaks down to a 4 sided spike you can only kill with a bomb (2000pts). Currently it's better to run away than engage so I have to add another monster - a friendly rock that's also a bomb. Aiming for high risk / reward, hopefully will make time outs a bit harder but not impossible.
Most people don't like using a phone in landscape mode - we make mobile games at my place of work. Offering a choice is best.
Stating "choose exit to move" conflicts with the exit text not always being "exit". Sometimes it needs to say other things. I'll need to ask others how they feel about the exit option.
Stamina is meant to be a boring cost to exit a room. I describe that cost in many ways, but it's basically what it says on the option. If it costs less, you were lucky. There is no strategy, you are meant to treat it as a timer. Sometimes I try to make the timer go down slower because I want to tell a story. And ultimately, telling a story is all I want to do. I don't know how to make a room sound scary or telling surprising encounters without the ability to misdirect. If a particular room feels unfair, then maybe that's something I can address, but I don't want to create an RPG system that you can pull apart and cheese. It's just meant to be a hunger clock, I don't want to write a deep system for this particular game.
I'm going to switch to numeric soon, it would look a lot neater in the corner on the map. The side by side layout is just for PC, I need to set up adapting to different screens.
A bullet point means an option is being executed. The arrows are actually options and have the same currency as a choice, so they must have a bullet point near them. Without the word "exit" the player has no context for the arrows - do they scroll the text or move the player within the room? Some rooms don't use the word exit, giving further context to how you leave. I understand the problems with it, but if I redesigned it there would still be the need for a bullet and text.
There is no stamina "check". It is a resource you spend to solve rooms. If an option says it costs stamina points, that is the maximum amount of stamina the action will cost - that is the rule. The reason is that there are many ways in which an option could cost less:
- The game might spend your luck for you to remove the cost.
- The option might be a trick, to convince you the option is more dangerous than it appears.
- The option may lead to a purely random outcome (costing the amount of sp or less).
Therefore if the game says 2-4sp, it may be mitigated by luck, it may be a trick, or it could even be a series of costly actions (eg: the chugging the barrel of beer challenge in the drinks room).
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.