Add non-existing players to levels

Got a cool idea that should be in R'n'D? Let's hear it!

Moderators: Flumminator, Zomis

Post Reply
BrownSky
Posts: 19
Joined: Mon Sep 24, 2018 4:04 am

Add non-existing players to levels

Post by BrownSky » Mon Oct 15, 2018 1:10 am

Can I suggest that there be some way of automatically making single-player levels multiplayer, without actually editing them? e.g. a game setting which automatically adds 1, 2 or 3 players if not present. The devil would be in knowing where to put them. Just next to or near to the yellow player ought to be good enough. In dirt or space if available, if not then taking the place of whatever element is there. If it was done randomly and the level started with the players in a bad or impossible position then the level could be restarted in the hope of getting a better random arrangement. Obviously the character wouldn't be randomly placed if it was already on the level.

- Actually you could generalize this idea to all caves, even singleplayer caves, which is that if the setting is set to '1', '2', '3' or '4', you add that number of characters less the number that is already placed - so in the case of a level with no characters pre-placed, all players are randomly placed.

One problem would be that if the level is being played multiplayer NOT networked, the characters would need to be all placed on the same screen, which requirement would not exist for networked multiplayer.

It could be heaps of fun, as it would make levels much more variable. Of course for carefully constructed levels it would probably wreck them, so it would be more suited to 'random' levels.

filbo
Posts: 348
Joined: Fri Jun 20, 2014 10:06 am

Re: Add non-existing players to levels

Post by filbo » Mon Oct 15, 2018 10:41 pm

Hmmm, that might be fun for a LAN party or something.

I would caution that probably a large fraction of levels will not be completable with multiple players. e.g. there's likely to be only one of each color door key, unless intentionally setup for 2 players. Timings, sequences in which you have to get through [whatever] before the huge pile of rocks falls on it, etc.

Many levels would work, many would not. I guess that could be fun or frustrating, depending on the mood of the party...

Perhaps, in this 'forced multi' mode, key possession could be collective. That is, if *any* player has a green key, all can pass green doors. One could think of a few other such hacks, which would make single-player levels 'more likely' to be solvable in forced multi; no mechanical modification would guarantee it in all cases. (In fact, I think that problem is 'NP Hard' at least...)

BrownSky
Posts: 19
Joined: Mon Sep 24, 2018 4:04 am

Re: Add non-existing players to levels

Post by BrownSky » Fri Nov 09, 2018 1:17 am

Filbo, your idea:

"in this 'forced multi' mode, key possession could be collective. That is, if *any* player has a green key, all can pass green doors"

is such a good one that it warrants being added as an option to the game in any case; that is, in any multiplayer game (different PCs, same PC) key possession could be collective. This could be done as a game setting (but what happens if the setting is different for different instances of the game on different computers?), or perhaps a levelset setting.

Another thought on this matter: As well as the ability to add characters close to the existing character, add the the ability to add characters far from the existing character, i.e. not in the same screen, or playing field - this option being available only in multi-computer mode, when it makes sense (wouldn't really make sense in single-computer mode).

User avatar
Holger
Site Admin
Posts: 3133
Joined: Fri Jun 18, 2004 4:13 pm
Location: Germany
Contact:

Re: Add non-existing players to levels

Post by Holger » Fri Dec 28, 2018 1:00 am

Thanks, BrownSky, for pointing out in another post that I haven't answered this one yet -- here we go!

First of all, I think this is indeed a goot idea, maybe even a very good one!

In fact, such a "special multi-player level modification mode" would work better on some and worse on other levels -- but as you said, there are very different levels and sets out there. While your idea probably won't work that well on puzzle style levels, I could imagine that it works great on some of these "collect tons of gems without being killed by monsters" levels from some of the "Contributions" level sets! :-)

And yes, differently handling keys would probably help a lot for such "forced multi-player" levels.

Regarding network games and local settings: These could be transferred to the other players from the computer that started the team mode level. (Some things would just be changed in the level itself that is then transferred to the other PCs.)

I think it would be worth playing around with some such additional setup settings in an "experimental" sub-menu, and see how it works (later maybe moving them to the "normal" game settings). This would also allow for quickly implementing it without having to worry too much about future compatibility when having to change some details a few times later on...

filbo
Posts: 348
Joined: Fri Jun 20, 2014 10:06 am

Re: Add non-existing players to levels

Post by filbo » Fri Dec 28, 2018 6:12 am

Now wondering about an intermediate between separate keys per player, and globally shared keys: key contagion.

Any time two players 'touch', merge their key lists. As if each is carrying around a set of key blanks and key duplicating equipment (all of which is automatic and instantaneous :)

This seems like a more plausible mechanism [ because, of course, all the rest of the game is so real-world plausible :) ]

One could conceptualize that these aren't actually physical keys but keycodes graffiti'd onto that cel's floor. Whenever you meet one of your co-explorers, you of course exchange keycode lists.

It would be a 3rd option on a menu of (key-per-player, key contagion, globally shared keys).

No idea how either idea might be applied to white keys (or DC3 green doors)...

Then there are other 'items' like dynamites (maybe not needed to share because their effects linger?); dynabomb capabilities; probably many others. So maybe it's better to define just one master switch between a 'strict' (current) state and a 'relaxed' (shared keys, shared dynabombs?, whatever else). Don't really know...

Post Reply