CCP MC Peanut is so new he's still in an NPC corp - and a primarily Eve-side one at that!

Get this man in corp, CCP, you need more posters like him!

I'm on it! Must assimilate him in to the CCP Alliance...

- snip -!

Please please please add N,S,E,W onto the minimap as well as the "compass" you have on the top of the screen. PLEASE!

I assume that compass on the top will eventually rotate, but wanted to ensure you are actually placing the nautical directions onto it.

Also putting the grid coordinates somewhere on the HUD would be nice (EX: B5). So its not only easy to reference for technical problems, but also to give those supplying OBs a more definitive target. Match the grid coordinates with the ones already published in the "map feedback" section of the forums. Place these grid coordinates on the full screen map as well.

Would it be possible to get a spotting feature in Legion or is that a game design issues that you would need to talk about / do not want?

I'm on it! Must assimilate him in to the CCP Alliance...

By assimilate you mean something like this?

Also would the community like that people who fire their (non-silenced) weapons to cause a red "blip" on the radar? Depending on the range and weapon used the "blip" would stay longer, for example shotgun at 2m would cause a blip lasting 1sec and a pistol at 50m for 0.1sec, and as always times are just examples.

(confession: I didn't read the thread)

This is a good idea. But it belongs in a EWAR Ideas thread. By the way, did anyone make an EWAR thread yet? EWAR needs an overhaul too.

(...)Core capabilities:
GÇó Monitor network data feeds to alert Soldier to mission-critical information (semantic
data bot)
GÇó Monitor ammunition and other stores and automatically call for resupply
GÇó Provide reminders (memory joggers)
GÇó Anticipate information needs and facilitate data access and retrieval
GÇó Handle routine communications based on minimal input from Soldier
GÇó Monitor the SoldierGÇÖs mental and physical state, shaping information flow, suggesting
mitigations, alerting leadership
GÇó Communicate with other PIAs to optimize data integration and sharing across unit
members
GÇó Adapt to an individual SoldierGÇÖs personality, strengths, and weaknesses
GÇó Communicate with Soldier via a natural language interface and heads-up display(...)

(...)The idea -- to grossly over-simplify -- is that people have more than one kind of working memory, and more than one kind of attention; there are separate slots in the mind for things written, things heard and things seen. By monitoring how taxed those areas of the brain are, it should be possible to change a computer's display, to compensate. If a person's getting too much visual information, send him a text alert. If that person is reading too much at once, present some of the data visually -- in a chart or map.(...)

Hey Everybody, CCP MC Peanut here--new to the forums (and this is my first post). I'm a Technical Artist here in Shanghai and was mostly involved in the HUD upgrade for the Project Legion Prototype you saw at Fanfest. I'm excited you guys noticed the work and are discussing it. The feedback is super awesome too (so awesome I forwarded the post to a lot of other devs). I thought I would jump in and give a little further explanation about what we did and potentially where we can go from here.

The HUD that you see in the Project Legion Prototype showed at Fanfest is now being rendered inside the 3D Scene. This is a significant change. While what you saw in the demo isn't incredibly different to what was there before, I want to emphasize that we have completely changed the underlying system for creating HUDs and have built a pipeline that puts the artist and designers much closer to the implementation. What you saw was the first implementation with the new system. And while the demo doesn't demonstrate it all--everything is working. In a very short time (a few weeks maybe), a few of us rebuilt the HUD, recreated all the logic, and tuned it to a slightly new visual design.

I'd love to go a little more in depth and explain some of the cooler benefits we are finding with this change:

Artist and Designers can iterate like crazy:
Unreal already has a lot of robust tools available to it, so why not take advantage of them. One of the things the artist love the most is being able to play the game with the editor open and update their material parameters in real-time. The 3D HUD is heavily utilizing the Unreal Material system. For example, all the 'bars' stem from the same base material, which has parameters to control the scale of the ticks, space between, color (including switching the color over position), flashing (speed and color). Tuning these parameters in-game is pretty awesome and very easy. Another example, the most obvious one probably, is that since it is 3D, we can change the position and layout very easily--it is as simple as moving it in the 3D package (Maya) and re-importing the geometry.

Logic outside of code
This was an interesting choice, but I believe it was the right one. We are exposing game data to the artist/designer through events in the visual scripting system, called Kismet (if you aren't familiar with Kismet, it is a node based scripting tool provided within Unreal that allows artists and designers to do more 'programmatic' things). With this change, much of the logic is in the hands of the content creators--the programmers are only responsible for providing the information when applicable. This sounds like it could become overwhelming, and we have been careful about not suddenly dumping everything in their laps. I can give one example. When your shield value changes, an event will be fired (a kismet event inside the HUD map file). This event will expose the current and max shield value. Luckily, our bar material has a max and current parameter input, so we just update the values (using a Kismet action) and all is good. While this is something that sounds like it could be completely programmatic, it is so much nicer to give the content creators the flexibility. If we wanted to, we could trigger a distortion animation every time the armor value changed, and as the armor got lower, the distortion could be more significant. This would require zero programmer support.

Lots of technology to utilize
Because we are in 3D we have access to all the rendering technology as other 3D stuff (suits, weapons, environments). We can also utilize the same tools (materials, modeling, an animation) that our 3D artists are familiar with, so the transition for workflow, was not so bad.

Capacity to be Dynamic
I can't make any promises about racial HUDs, but we are definitely in a much better position to be able to do them. It is very easy to create new 'visual' components without needing to rework the data hookup--and they would be lightweight and low cost.

There is more, and I could go on, but perhaps that is better for follow up posts. Our hope is that we have built a system the is flexible enough to give us more options to do the kinds of things you guys are asking for. Regarding these requests, I can definitely weigh in on their possibility within the system, but I am unable to comment on the likelihood (that is someone else's call). Please keep the feedback coming, and feel free to post follow up questions.

thanks!

Hey Everybody, CCP MC Peanut here--new to the forums (and this is my first post). I'm a Technical Artist here in Shanghai and was mostly involved in the HUD upgrade for the Project Legion Prototype you saw at Fanfest. I'm excited you guys noticed the work and are discussing it. The feedback is super awesome too (so awesome I forwarded the post to a lot of other devs). I thought I would jump in and give a little further explanation about what we did and potentially where we can go from here.

The HUD that you see in the Project Legion Prototype showed at Fanfest is now being rendered inside the 3D Scene. This is a significant change. While what you saw in the demo isn't incredibly different to what was there before, I want to emphasize that we have completely changed the underlying system for creating HUDs and have built a pipeline that puts the artist and designers much closer to the implementation. What you saw was the first implementation with the new system. And while the demo doesn't demonstrate it all--everything is working. In a very short time (a few weeks maybe), a few of us rebuilt the HUD, recreated all the logic, and tuned it to a slightly new visual design.

I'd love to go a little more in depth and explain some of the cooler benefits we are finding with this change:

Artist and Designers can iterate like crazy:
Unreal already has a lot of robust tools available to it, so why not take advantage of them. One of the things the artist love the most is being able to play the game with the editor open and update their material parameters in real-time. The 3D HUD is heavily utilizing the Unreal Material system. For example, all the 'bars' stem from the same base material, which has parameters to control the scale of the ticks, space between, color (including switching the color over position), flashing (speed and color). Tuning these parameters in-game is pretty awesome and very easy. Another example, the most obvious one probably, is that since it is 3D, we can change the position and layout very easily--it is as simple as moving it in the 3D package (Maya) and re-importing the geometry.

Logic outside of code
This was an interesting choice, but I believe it was the right one. We are exposing game data to the artist/designer through events in the visual scripting system, called Kismet (if you aren't familiar with Kismet, it is a node based scripting tool provided within Unreal that allows artists and designers to do more 'programmatic' things). With this change, much of the logic is in the hands of the content creators--the programmers are only responsible for providing the information when applicable. This sounds like it could become overwhelming, and we have been careful about not suddenly dumping everything in their laps. I can give one example. When your shield value changes, an event will be fired (a kismet event inside the HUD map file). This event will expose the current and max shield value. Luckily, our bar material has a max and current parameter input, so we just update the values (using a Kismet action) and all is good. While this is something that sounds like it could be completely programmatic, it is so much nicer to give the content creators the flexibility. If we wanted to, we could trigger a distortion animation every time the armor value changed, and as the armor got lower, the distortion could be more significant. This would require zero programmer support.

Lots of technology to utilize
Because we are in 3D we have access to all the rendering technology as other 3D stuff (suits, weapons, environments). We can also utilize the same tools (materials, modeling, an animation) that our 3D artists are familiar with, so the transition for workflow, was not so bad.

Capacity to be Dynamic
I can't make any promises about racial HUDs, but we are definitely in a much better position to be able to do them. It is very easy to create new 'visual' components without needing to rework the data hookup--and they would be lightweight and low cost.

There is more, and I could go on, but perhaps that is better for follow up posts. Our hope is that we have built a system the is flexible enough to give us more options to do the kinds of things you guys are asking for. Regarding these requests, I can definitely weigh in on their possibility within the system, but I am unable to comment on the likelihood (that is someone else's call). Please keep the feedback coming, and feel free to post follow up questions.

thanks!

First things first, great dev name.

Second, thanks for basically writing out a dev blogs worth of cool info.

Customizable opacity for individual HUD objects. I say individual HUD objects because I want to be able to tune certain things to make them less obstructive without making thins like the radar harder to see.

In terms of system resources, how does your implementation compare with what we currently have in DUST?

This is US Military, unclasified report (PDF), called Future Soldier 2030 Initiative

More cool stuff

You could use an abstract method to set up all bars the same, then wrap dynamically created classes.
I.e Class name: Armour Bar (contains instances of Armour Bar Segement)
This way with a little clever logic you can

1) Standardise a behaviour method for all bars, so they all react in the same way
2) Overload the behaviour method, so there is only 1 method call with multiple effects
3) Inherit these methods for over writing.
.

Actually you pretty much hit the nail on the head with what we were doing with the Bar setup and other HUD functionality (although it is pretty Bar-stuff heavy). Rather than creating actor classes, though, we've put everything in a hierarchical material setup. It is 'fairly' object oriented, in that I can define parameters (barValue, barScale, barColor) on the parent material that can be overridden on the child materials. It is by no means as robust as driving this with classes, though--so your suggestion still makes me consider the alternative. Another benefit to keeping things in materials is that we can do upgrades and changes on the content side. I can edit the shader to have distortion, expose the parameter, and set it (on the root material) in kismet. Pretty nifty.

I do think if we try to implement a standardized 3d icon system, that this is the way to go (as we will have more complexity with states and such)

MC awesome Dev to community communication

You could move even further with the minimap. Just show the "current" fragment of the already present map (the one you can access with D-Pad in DUST )

We had this in Mordu's Private Trials ;)

MC Peanut,

Is it possible to make the health bars more dynamic based on shields vs armor? So that when you are shooting someone you have an idea where their "tank" is?

So for example the armor bar would be red and the shield bar would be blue. Each would be proportional to their total HP.

In the DUST Keynote Legion demo one can see a bearing (compass) readout and a pair of "000"s (placeholder for coordinates?) separated by a "diamond shape" figure (what's it's purpose?) at the top of the screen. But its all static in the course of the video. Would you shine some light on it?
http://www.youtube.com/watch?v=z_GRjNL7l40&list=PLldrBIEnJ5hMIXwk_e8-VZb0EldJqXmg_#t=1314
Maybe its just MCC HP bars and clone counters?

Question: Since this new method is memory efficient, would this work on DUST and the PS3?
Considering it has 256mb of VRAM, I would assume every little bit counts, and could somewhat improve performance.

I might not be understanding your question correctly, so feel free to bark back if I answer it wrong. Health and Armor bars could have a bar 'tick' (or do we call these cells?) for each unit of armor/health. This is the basic setup on our material: there is a 'barScale' parameter that will tile/repeat the bar texture (which is always a texture of 1 cell/unit/tick) by whatever the numeric value is. But in the case of Health and Armor, we have pretty large values, so repeating the ticks so much ends up kind of ugly, so we need to set the barStep parameter, which represents the number of numeric units that each texture 'tile' stands for. So if I set the barStep to 2, and the scale is 10, I see 5 cells (when full). Currently on the suits we are dividing their maxAmmo value by a constant scalar value so that they end up having the same number of texture repeats, but we don't have to. In the ammo department we are actually representing them more accurately, but once the ammo count gets high, we start setting the barStep.

Part of me thinks you are asking the health bars of the person you are shooting, though? This could happen--it would have to be part of the targeting info, or the data would at least have to be provided by the same system that grabs the target info data, but we could put it somewhere else.

And the bar colors can be whatever we want--that is just up to the designers.