Archive: 8 posts

---

Say you've created a competitive top down racing game (or shooter, or anything else) in LBP2. You have allocated seperate cameras for each player and it would not work otherwise. Now, you decide to give each player a HUD (Vacuum Material). You decide that you would like the HUD to display the player's current weapon, current lap, and current position in the race. FIG.1 http://img193.imageshack.us/img193/444/lbp21.th.jpg (http://img193.imageshack.us/i/lbp21.jpg/) This is the HUD you come up with, and it follows Player 1 (P1) perfectly etc. Now let's look at the viewpoint for Player 2 (P2). FIG.2 http://img441.imageshack.us/img441/8170/lbp22.th.jpg (http://img441.imageshack.us/i/lbp22.jpg/) Because the HUD is not displayed on a Per Player basis, you can see P1's HUD following him around. This, obviously, is messy and not at all what you want. My idea is that each object can be designated as being: Global: Will show up the same on everyone's seperate camera. This is what normally happens, and how it would look in FIG.1 Per Player: Will show up the same for everyone but will be reflect ONLY what the current player has done/is doing. This means you can display the same HUD for everyone, but using each player's individual statistics (current lap, weapon, poisition, etc). The HUD would only be shown/created once for each individual player; P1's HUD would not show at all for P2, as it does in FIG.2 Player Specific: Will only show up for the specified player. For example, when the game begins, the option to choose the amount of laps is shown. This option is Player Specific to whomever is Player 1 (P1). The means noone else in the game gets to see the shown option, only Player 1; the associated objects are not even created for any other player. This could easily extend to any object, HUD, etc --- The implications of this are far further reaching than just a HUD. Making a coop Action RPG like Diablo would be a mess when everyone can see everyone's HP, MP, Potions, Inventory, etc. Good luck making a deathmatch shooter actually competitive when your HP and ammo is shown to absolutely everyone. There is no way you could show individual effects, like say you want the player's screen to be blurred when hit by a particular weapon, or if you want to switch to a different graphic filter when your Night Vision goggles are equiped. Bottom line is, seperate cameras by themselves are not enough. There needs to be Player Specific and Per Player tags for objects. This is how every LAN or internet based multiplayer game (where the camera is per person) has been doing it since as early as, well, since LAN/Internet gaming began.

2010-06-17 19:54:00 Author: Unknown User

---

This sounds like a great idea! Optional viewing of other player's HUDs. Great! I cannot think of any reason this should not be implemented at the moment.

2010-06-17 20:07:00 Author: Jedi_1993 Posts: 1518

---

Alternatively, you can attach a little HUD to each vehicle. This works really well, as shown in the levels we made at the Game Jam, and then you can just ignore the fact that each player can see the other person's.

2010-06-17 20:50:00 Author: comphermc Posts: 5338

---

Alternatively, you can attach a little HUD to each vehicle. This works really well, as shown in the levels we made at the Game Jam, and then you can just ignore the fact that each player can see the other person's. While I will agree with this, I must say it really is only for projects which involve minimal statistics (and it is also clearly a workaround; your typical HUD in basically every game today is not attached to the character, but skirts the borders of the screen). This is no insult to you guys that made those demos at the Game Jam of course, you couldn't have gone into it intending to make any long term, complex, game concepts with only 24 hours hands on. The main concern I have is that not having the Per Player/Player Specific objects will force me to do complete programmatic backflips creating a workaround (having a HP bar, MP bar, Potion Bar, Equiped Spells, Experience Bar, and Inventory hanging off each character is not a viable option by any means). The reason I never much used the level editor in LBP1 is because I could clearly see it was far too constrained for what I wanted to do (for reference, I've been doing game programming as a hobby for more than 10 years). To be honest, the main reason I suggested this is because, from a programmers point of view, it is easy. Not only is it easy, but it would save thermometer space and PS3 processing power by deligating those objects to the client machines, instead of having the server machine (and by extension the clients in this case) display everyone's HUD and other objects/effects/prompts that should ideally only be there on a per player (or per camera, as it were) basis.

2010-06-17 22:00:00 Author: Unknown User

---

it would save thermometer space and PS3 processing power by deligating those objects to the client machines, instead of having the server machine (and by extension the clients in this case) display everyone's HUD and other objects/effects/prompts that should ideally only be there on a per player (or per camera, as it were) basis. Actually, no. Because you'd have to mapa ll logic systems etc back to that and then the whole thing gets really hazy, it's not just a case of simply displaying or not displaying the objects. It's a far more subtle issue than that, so you wouldn't save any kind of thermo. However, other than that, I kind of agree, although I think it's goig to be rare that you actually need complex stats, that would require extra-complex HUDs for multiple players in LBP2. You can do plenty without it. And quite a lot of the effects you talk about - i.e. camera blur / shake / visual effects are perfectly possible without separate HUDs.

2010-06-17 22:54:00 Author: rtm223 Posts: 6497

---

Actually, no. Because you'd have to mapa ll logic systems etc back to that and then the whole thing gets really hazy, it's not just a case of simply displaying or not displaying the objects. It's a far more subtle issue than that, so you wouldn't save any kind of thermo.Truly? I though it would be possible to have variables independent of the actual objects themselves, and emit as needed. [Edit: In your average network game, the server only tracks the particular variables integral to the working of a HUD, inventory, etc. It could, feasibly, be set up in this fashion, but I do understand what you're saying now] By saving themo I meant that in a four player game, you have only one HUD, but it is player specific [all the processing and displaying is client side, the other machines don't know nor do they care about it, but the server keeps track of the variables involved when specified]. This would be opposed to having four individual HUDs being tracked, processed, and displayed on all four systems at all times. However, other than that, I kind of agree, although I think it's goig to be rare that you actually need complex stats Rare for some I guess. I really think if the option is there, it'll be more common than you think. The potential scope for the games is going to be worlds apart compared to LBP1. I fully expect some people to produce works closer to the current UMS maps for Warcraft III, providing the options (like this one) are there.

2010-06-17 23:19:00 Author: Unknown User

---

Woah! That post had some awful typing in, even for me Wel what I'm saying is the logic for the hud is going to feed in and out of those objects that are client-specific and the system is going to need to understand where exactly the client-specifics lie, logic wise. At some point, aspects of the HUD are going to be required to interact with non-specific parts of the level, else they are worthless. If you think into it it's quite a huge change to the current system if you want to actually glean significant thermo savings from it. Obviously if you were coding your game from scratch it's easy to design in such a thing, but you are talking about developing a free-form client-only system and making that intuitive to the non-technical LBP audience (that last bit being the clincher really). Now, if they were to create an actual HUD designer, then the intuitiveness of the system would be far greater. But this is even more work. Alternatively, make it so it only shows up on player X's screen, but have no thermo savings, and you've got yourself something very simple and easy as it's just a few flags in the holograph material data and a branch Oh, and I do agree that if you provide specific tools people will use them more, I'm just thinking that it's not that often that people will NEED such a thing (i.e. you can still make pretty good display systems for most game types using work-arounds)

2010-06-17 23:35:00 Author: rtm223 Posts: 6497

---

Alternatively, make it so it only shows up on player X's screen, but have no thermo savings, and you've got yourself something very simple and easy as it's just a few flags in the holograph material data and a branch That is pretty much what I'm getting at. Though I don't see how showing 1 HUD per player compared to 4 HUD per player wouldn't be a thermo saving? Even if the server tracked all the variables involved, the GPU is only displaying one copy, so there is saving on that front. Anyway, I agree with most of your points, I just cannot picture any workaround that will work with my planned project(s). It isn't even as though this is complicated; you explained what I was getting at in a quarter of a sentence ("make it so it only shows up on player X's screen"). Anyway, I can only hope they put it in. I would hate for something so simple to code to be ignored because your 'average' person won't care. That seems like the worst reason not to put it in.

2010-06-17 23:55:00 Author: Unknown User

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.