Recent community posts
I've got other reports of crashing. Unity is broken.
I've already tried downgrading the project but it deleted a ton of assets doing so. I can only try installing a newer version and I'm practically on the latest version. I'll try downloading another version of Unity. I have bad internet so this will take a few days.
These are the only pages on the internet I can find with solutions:
I don’t recommend playing Red Rogue in the browser. Flash is obsolete and I don’t have the tools, knowledge, or money to keep a free game working. This project has not covered its own development costs in all the time it has been available (2012) so there’s only so much I can do.
Flash has limited storage space. You have to click the flash player object on the page to open the storage settings and increase the amount of data Flash is allowed to save. I cannot do this for you, this is the price of playing Red Rogue in a browser.
I recommend downloading the desktop version instead.
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.