Any possibility of local multiplayer for Starward Rogue?

[Wingflier]

I know it's a long shot, but this seems like the perfect game for it. Would love to play with my friends someday.

[Misery]

Probably not happening.  This one would be a "Chris & Keith need to do it" sort of thing, and they've just got too much to do elsewhere.

[keith.lamothe]

Yea, it would involve two things:
1) Rewriting the game.
2) Inventing an FTL internet to get the latency low enough to work.

Other than that, no problem!

[Pepisolo]

Yea, it would involve two things:
1) Rewriting the game.
2) Inventing an FTL internet to get the latency low enough to work.

Other than that, no problem!

Actually, this seems to be in reference to online multiplayer? I believe that Wingflier was asking about local multiplayer. Couch co-op, that sort of thing. I recall from back in the day that the possibility of local co-op, while still probably unlikely, it was at least in the realms of possibility, unlike online multiplayer. Still, though, even just couch co-op is super unlikely due to the resources required for its implementation.

[keith.lamothe]

Actually, this seems to be in reference to online multiplayer?

Oh, right. Sorry, I fail at reading comprehension.

Adding input support for a second controller would be reasonable.

Having said input control the aiming and firing of a familiar (or familiar-esque entity) wouldn't be too awful.

Having an entirely separate second "player entity" (regardless of what controls it) would be like nervous-system-transplant surgery for the engine. (Q: "Which part of the nervous system?" A: "Yes.")

And that doesn't even touch the UI problems of where the camera goes when the players split up; most approaches are simply un-fun, and the ones that might possibly be fun (splitscreen) would be a ton of technical work and significantly increase the minimum system requirements (monitor size, cpu for double-the-draws, etc).

All that said, going back to the familiar-esque approach, I think it could be very fun to have one player play the "normal" mech and have the second player play the "gunner", composed of a fleet of familiars. Since they would have a lot more buttons available (not needing to move and do various things) we could give them a lot more guns >D Remember all those weapons you leave laying around because you've swapped them out or because you don't want to swap out what you have? Just put them into orbit around you and let the second player fire them (with some kind of capacity limit and perhaps a progression system). Personally, I'd enjoy that. But maybe I just want moar dakka.

So that's fine on the input side, and feasible on the engine side, and reasonable on the fun side... but a disaster on the balance side. It would require a totally different balance to account for all that extra firepower. In many ways it would just be a different game. Otherwise the fun would collapse after a run or two of steamrollering everything.

Does anyone have a design that avoids all of the above pitfalls?

[Pepisolo]

Having an entirely separate second "player entity" (regardless of what controls it) would be like nervous-system-transplant surgery for the engine. (Q: "Which part of the nervous system?" A: "Yes.")

And that doesn't even touch the UI problems of where the camera goes when the players split up; most approaches are simply un-fun, and the ones that might possibly be fun (splitscreen) would be a ton of technical work and significantly increase the minimum system requirements (monitor size, cpu for double-the-draws, etc).

I'm still thinking on the familiar approach, but for the entirely separate entity approach, what about an edge of screen zoom out? For example, the camera would be set at a certain distance, but as one of the players were to approach the edge of the screen the camera would zoom out? I'm guessing that you're considering this approach to be one of the unfun ones, but it doesn't sound too bad to me, especially for a game like SR where each individual room isn't super big anyway.

[tombik]

I have another idea for local coop.

Boss versus player. One player uses the mech, the other one uses the boss, with different buttons corresponding to different shot patterns. The mech player can equip anything they want before the fight. And the boss player can pick any stationary boss.

Something like a 1 v 1 figthing game, I know this will not be interesting for anyone, but I still would like to share my idea.

[Logorouge]

Opinion time:
I think being a mere turret would get bland pretty fast for player 2.

My ideal local-coop would be like this:
-Player 2 is a familiar of Player 1 and can move & attack independently, but Player 1 has the priority camera and UI-wise.
-Player 2 follows when Player 1 uses a door or a teleporter.
-Player 1 does the buying and picking up of items/upgrades, but both players can pick up credits/missiles/health/shards for the team. (Separate effect for health/missile pickups?)
-Player 2 can use the form of one of the mechs, locked to the starting equipment.
-Player 2 inherits Player 1's upgrades and perks. Not the equipment changes though.
-Possibly some sort of revive system for Player 2. (One-time deal after Warden?) You don't want to just sit there for an hour while Player 1 finishes the run.

Balance-wise, it will lower the difficulty for sure, but this game has the advantage of having numerous difficulty levels. Attempting an higher difficulty setting with a friend could be a lot of fun. Or just blasting through your regular difficulty level with a pal is a worthy experience I think.

[keith.lamothe]

I'm still thinking on the familiar approach, but for the entirely separate entity approach, what about an edge of screen zoom out? For example, the camera would be set at a certain distance, but as one of the players were to approach the edge of the screen the camera would zoom out? I'm guessing that you're considering this approach to be one of the unfun ones, but it doesn't sound too bad to me, especially for a game like SR where each individual room isn't super big anyway.

That would be a reasonable way of handling the display, but the second-player-entity means rewriting probably 25% to one-third of the engine when all's said and done.

Also, that display mode would require a fairly beastly computer to run decently in many rooms, if the players got far apart. The scaling is bad enough, but the wider area-of-things-to-show would magnify the issue (no pun intended).

I think being a mere turret would get bland pretty fast for player 2.

Fair.

My ideal local-coop would be like this:
-Player 2 is a familiar of Player 1 and can move & attack independently, but Player 1 has the priority camera and UI-wise.
-Player 2 follows when Player 1 uses a door or a teleporter.
-Player 1 does the buying and picking up of items/upgrades,but both players can pick up credits/missiles/health/shards for the team. (Separate effect for health/missile pickups?)
-Player 2 can use the form of one of the mechs, locked to the starting equipment.
-Player 2 inherits Player 1's upgrades and perks. Not the equipment changes though.
-Possibly some sort of revive system for Player 2.

The green would fit decently within the controllable-familiar idea, or a reasonable extension of it (picking player 2's mech and propogating the upgrades/perks, as well as some kind of basic movement).

The yellow is because a basic non-colliding movement would be fine but if it's full movement that gets into a ton of code that's very specific to the single player entity for what happens when you touch certain things (including walls).

The first red chunk would be painful since so much of the pickup logic is welded to the single-player-entity (though I seem to recall there being some current exception in the game where you can collect stuff through another entity; is that the case?).

The second red chunk isn't the problem in itself, but it implies that Player 2 can be hit, and thus should presumably be targeted by enemies as a player, and can interact with the various things-that-do-damage.

[Logorouge]

The yellow is because a basic non-colliding movement would be fine but if it's full movement that gets into a ton of code that's very specific to the single player entity for what happens when you touch certain things (including walls).

The first red chunk would be painful since so much of the pickup logic is welded to the single-player-entity (though I seem to recall there being some current exception in the game where you can collect stuff through another entity; is that the case?).

The second red chunk isn't the problem in itself, but it implies that Player 2 can be hit, and thus should presumably be targeted by enemies as a player, and can interact with the various things-that-do-damage.

Sounds tricky.
If you can move but can't be hit/targeted, then Player 1 can just hide in a corner and it's gameover for all enemies. Otherwise, it's back to being a turret.
But for enemy interactions and ressources pickups, I was hoping the familiar status of Player 2 would facilitate those parts. I guess not.

[Misery]

I imagine there's probably no true way to keep the game's balance with two players.  That seems to be the case for any of these games.  Even Enter the Gungeon, with all of it's difficulty, becomes dramatically easier in co-op.

Isaac got away with it by doing something like this familiar idea, but it also means that the second player ends up feeling pretty sad and weak compared to player 1.

Another thing occurs to me though:  What about enemy targeting?  Having them constantly changing targets between player 1 and 2 would cause LOTS of things to break, but having them ignore one player in favor of the other would also cause a lot of things to break.  As in the "I cant even guess how to fix that" sort of breaking.

[keith.lamothe]

As in the "I cant even guess how to fix that" sort of breaking.

Yea, ultimately the problem isn't programming the solution, it's "what on earth is the solution?".

I keep coming back to assymetrical models, i.e. "don't solve the problem, make up an entirely different problem and maybe they won't notice". That's basically how AIW does a compelling AI opponent in a genre (RTS) with basically no compelling AI opponent: it ignores the problem everyone else is trying to solve (an AI that plays the same game you do) and solves another one.

So there's the turret thing, there's the "ghost" thing (basically a turret plus movement), etc.

Another possibility, as alluded to in the player vs boss idea, is having the second player influence the opposition rather than the "player".

Which is a very fun concept to think about, but how could it be made fun as an actual game or mode?

For example, giving player-2 even the slightest influence on a boss's behaviors or timing or targeting or whatever would very likely mean an automatic loss for player-1 unless player-1 was playing some kind of "I don't care how many hits I take, I'm still going to kick your face in" build (Warhog, etc).

It comes back to: yes, a totally different balance (or mode, or entire game) could be made to make that premise fun. But it wouldn't be SR co-op, it would just be a different game.

[Logorouge]

Another possibility, as alluded to in the player vs boss idea, is having the second player influence the opposition rather than the "player".

Kinda like Crawl where you would run around as a ghost and take control of enemies to hopefully kill the other player.

[keith.lamothe]

Another possibility, as alluded to in the player vs boss idea, is having the second player influence the opposition rather than the "player".

Kinda like Crawl where you would run around as a ghost and take control of enemies to hopefully kill the other player.

Yea, something like that.

Or something like a little side display that lets the second player pick one of the next enemies (or enemy groups) to spawn. That would actually be balanceable to a large extent (as opposed to direct control; certain enemies would be auto-death if a second player used them "intelligently"), though by itself it's obviously not enough interaction.

[Pepisolo]

Ok, so I haven't thought this through enough yet, but one idea I had was to roll the 2 player stuff into a new mech.

So, let's say that you have a new mech called Gemini.

If you select it when no 2nd player is detected it will just act as a regular mech, albeit probably with new fancy weapons and stuff; however, it has a special ability. If the second player presses E (or whatever) a 2nd version of the mech will spawn, which is controlled by player 2. If the 2nd player is spawned then a damage multiplier reduction will be applied in order to help balance it. Then for added fanciness you could allow the ability for Player 2 to recombine with Player 1, restoring the regular damage power.

Both versions of Gemini share everything, health, missiles, perks etc. Oh, for an extra bit of added fanciness you could also make it so that both players have to choose the same perk to level up -- this would cause some co-op chaos!

Now, this implementation doesn't really solve many problems, I mostly think it'd just be cool, heh. Although it does at least contain any balance issues to a specific mech experience, which can be more easily controlled, and it does also solve the problem of needing a revive system -- health is shared so when player one dies, the second player also dies. This might actually add some extra problems due to some of the potential fancy features like mech splitting, although the fancy stuff isn't essential. So, that at least fixes Possibly some sort of revive system for Player 2 although the solution might add extra problems overall!

Then you just have but both players can pick up credits/missiles/health/shards for the team. (Separate effect for health/missile pickups?) and the targeting thing. For the targeting wouldn't just having the enemies target the nearest player work?....maybe!?