Archive: 14 posts

---

Hello everyone! I am in the process of working with very important LBP 2 project, in which the player must navigate complex maze rooms with multiple solutions and paths while hitting switches to rotate them. Naturally, such a level is unsuitable for additional players, who would indubitably wreak havoc and make the level impossible to play. Thus, I have a conundrum to solve. What would be the best way to appease the inactive players while the first player goes on his journey? I will be using a sackbot. Keep this in mind. I have a few ideas: 1- Have the extra players control rotatable shields, deflectors, or cursors (move cursors included) This would allow them to take part in the level in some way, while facilitating the creation of bonus multiplayer rooms and the like. 2- The players do absolutely nothing but watch the leader and be bored. While this isn't the ideal solution, I would much rather concentrate on making the best single player experience possible than adding half-baked extras such as those described in option 1. 3- Swap players after every death or every checkpoint. I am actually very fond of this idea, but I am not at all sure how I would implement control-seat switching, as I am not extremely experienced in control seat logic. I can only picture this flaw: the three inactive players become bored and uninterested with the active player's endeavors, thus making them completely confused when it's their turn to play. This may or may not work. Please correct me if I'm describing something that isn't feasible. Have four control seats, each with another control seat inside of the control seat chip placed on a chip. By default, wire a global selector output (4 outputs in total) to each of the four player-specific chips. Now, whenever the sackbot's tag disappears after a death, a tag sensor will activate the cycle input of the selector, thereby giving the controls to the next player. Would this work, or is there some hidden technicality that has eluded my thought process? 4-Everyone's alternate ideas. I'm adding a poll here in order to provoke discussion. Not only does my question apply to my own level, but also it applies to others' levels, I'm sure. I'm looking forward to responses. Thank you all!

2012-07-15 02:46:00 Author: synchronizer Posts: 287

---

One flaw of your design to switch players, what if there are less than 4 players, and more than 1? You need to hook something up that automatically switches to the next player if the controlinator isn't occupied. This isn't too hard, I believe. Also, just to avoid the whole multiplayer situation itself, make the level unplayable if there is more than 1 player. For example, having a permanent screen that says "1 Player Only" if more than 1 player enters the level, making the level unplayable. You can also make it so that is a player leaves or if a controller is turned off during this screen, leaving 1 player behind, the level will continue. Also, as soon as the players enter the level, have one of those player gates that blocks anyone from joining the player after they enter the level. This way, no matter what, only 1 player can play the level. I think that's how that works, at least.. Please correct me if I'm wrong

2012-07-15 03:36:00 Author: Wolffy123 Posts: 406

---

How would I switch players if a certain control seat is uninhabited? Perhaps I could use an OR gate to cycle the input if the player dies OR if there is no output from the controllinator (that is not on the chip). This may be sloppy though. Would there be any latency involved? I'm curious about the possible methods. As for making the level unplayable, that would simply prevent people from playing or WANTING to play my level because of the hassle of kicking players. It would make much more sense to let the extra players be idle or do something productive. I'll probably add one of the "no-player past this point" gates though. Anyway, this thread was started to see what people think the players should do. I'm also looking forward to discovering different methods for cycling players.

2012-07-15 03:52:00 Author: synchronizer Posts: 287

---

Have an AND gate for each selector output that has the inputs of the designated selector port, and a NOT gate coming from each activation output of each controlinator. Have all the AND gates hook into a 5 port OR gate. The last input from the OR gate would be for the player dying output. The OR gate hooks into the Cycle on the selector.. I think that would work. I'm brainstorming off the top of my head, however.

2012-07-15 03:55:00 Author: Wolffy123 Posts: 406

---

That doesn't seem to make sense sorry. Does anyone else have any ideas while Wolffy123 is thinking?

2012-07-15 13:00:00 Author: synchronizer Posts: 287

---

Could you not just limit it to 1 player only?

2012-07-15 16:40:00 Author: Ali_Star Posts: 4085

---

That's what I said. And my idea makes complete sense, although my description wasn't very clear. To simplify what my solution to the player switching idea, it checks to see if a controlinator is un-occupied, and if it is, it skips that controlinator and goes to the next one. If it is occupied, it waits for a death signal to jump to the next player.

2012-07-15 16:45:00 Author: Wolffy123 Posts: 406

---

I'd need to see a diagram, but I'm not interested in kicking the player out of my level if he has friends. He may decide to play it later if he can't leave his friends.

2012-07-15 17:00:00 Author: synchronizer Posts: 287

---

*le diagram http://ia.lbp.me/img/fl/d7a33a8a26c52f0c826ae160bef703817e2cb434.jpg All counters are set to count up to 1, the controlinators are not to be on the microchip, they are in this pic to keep things simple. The inverted NOT gate at the top of the microchip is not needed, it is just there to test and see if the logic set-up works. (Which it does). This set-up here is different than the one I described earlier. I added in the counters so it would work. The selector outputs are used to activate the correct controlinator. This isn't shown in the diagram. The Logic at the top of the microchip is for the Death of the player. A tag sensor that senses when the player dies can hook into this and switch it to the next player, for example. I tried my best to colour-code everything to make things easier to follow. I hope this helps.

2012-07-15 17:46:00 Author: Wolffy123 Posts: 406

---

Thanks for the clearer explanation!

2012-07-15 17:49:00 Author: synchronizer Posts: 287

---

Interersting problem... Funny enough I have a multiplayer-single player bot which will periodically change players around... player 1 (or whoever it switches to) has full control while players 2 - 4 have access to a snapshot camera to capture awesome moments... It's a win win

2012-07-15 18:39:00 Author: ForgottenEnigma Posts: 1414

---

Maybe the spectators could place waypoints to help the person playing solve the puzzles. Maybe they could do things to make it easier or harder for the player like open/close extra traps.

2012-07-15 18:52:00 Author: Ayneh Posts: 2454

---

I like Ayneh's idea.. That's pretty neat. Kind of like the "PING" tool from Portal 2

2012-07-15 19:43:00 Author: Wolffy123 Posts: 406

---

The ping tool from Portal 2 is something that is unfamiliar to me, but I'll try to find it on youtube. As previously stated, my level will be rotating, so leaving behind markers in their proper positions would be difficult. Do you mean to say that the extra players could each have cursors, and if they want, they can turn their cursors into "jump" symbols or arrows? I'd need help implementing it but it's a good idea. I'll concentrate on the single player experience first of course. EDIT: Yes, the ping tool seems to be exactly, if not almost exactly what I described. So, how would I implement this?

2012-07-15 19:59:00 Author: synchronizer Posts: 287

Posts: 1077139    Threads: 69970    Members: 9661    Archive-Date: 2019-01-19

Aus dem Archiv wurden alle persönlichen Daten wie Name, Anschrift, Email etc. - aber auch sämtliche Inhalte wie z.B. persönliche Nachrichten - entfernt.
Die Nutzung dieser Webseite erfolgt ohne Speicherung personenbezogener Daten. Es werden keinerlei Cookies, Logs, 3rd-Party-Plugins etc. verwendet.