Mission Stats Gui

[Ishtvan]

Mission stats are now stored, but we have no GUI to look at them. Also, what is the best way to store integer variables in the SDK so that GUIS can load them and look at them? Do GUIs need to access things with something like a scriptfunction, or can you just set a type of variable that GUIs can access directly?

[sparhawk]

You can look up the health code from original Doom. It has to be stored on the GUI somewhere.

[Springheel]

Mission stats are now stored, but we have no GUI to look at them

 

I don't have any particularly clever GUI ideas right now for a Mission Stat screen. I think once upon a time we had talked about doing something similar to a pirates-style summary, complete with graphics:

 

http://forums.thedarkmod.com/index.php?showt...=618&hl=pirates

 

That might be a little overly ambitious now.

 

edit: Actually, scratch that. I DO have a clever idea. I'll put a mock-up together shortly. Ish, what mission statistics do we record?

[sparhawk]

The major thing is that it should have a scrollbar, or pagebuttons, because we can expect that additional entries will be added over time. So don't make the layout to strict by assuming a certain number of stat elements.

[Ishtvan]

Pretty much the standard: loot overall, we could do loot by type as well (gold, gems, etc) but I'm not sure that's necessary to display.

 

Damage dealt, damage received (I forgot about healing received, but I guess we don't have that yet anyway)

 

AI stats, separated into "innocents" and "others" : KO'd, killed, alerted. AI alerts are counted and broken down by alert type. Not sure we have to display this in the stats, but we could because I have to count it anyway for objectives.

 

Don't have backstabs listed, not sure if we were going to count them in stats or not.

 

One could also separate them into human/beast/undead/bot/etc... not sure if we should list both that and innocence or just one or the other.

 

(not yet implemented:) bodies found, suspicious items found

[Springheel]

I didn't spend much time on this because it might not work, but here was my basic idea:

 

 

 

 

The term, "Master Thief" would actually be variable, depending on the statistics themselves. We could have different titles depending on how the player played the mission. For example, if the player dealt a lot of damage and killed innocents, they could be called a "Common Thug". If they killed people but were never spotted, they might be, "Cunning Assassin". Other possibilities are Skilled Burglar, Common Cutpurse, Etc.

 

As well, the Reward at the bottom would be variable. It would almost be like a 'High Score' setting--something people could brag about. The better you did, the higher the reward for your capture.

 

 

(Oh, if the player failed the mission, the term "Wanted" would be replaced with "Captured")

[Ishtvan]

Yeah that's an interesting concept. I like it, and it also reminds me that I guess I have to track "AI's assaulted" also. I guess code-wise, that would be a one-time event the first time the player damages them, so that the player doesn't get another assault added on every time they hit someone.

 

Logically, I'm not sure about the overall "wanted amount" score going higher the closer you are to ghosting the mission. The police might not devote as much resources (hence less reward money) for a thief that just takes the items and didn't assault or murder anyone. I would think the reward would be higher for playing worse (mass murderer) style. That's kind've why not murdering makes sense from a selfish perspective, because you know the police will spend more to catch a murderer than a thief.

 

This is probably over-thinking the issue, and I could suspend disbelief on this easily, but in some missions it may not make logical sense to have a wanted poster put out for you, like missions that occur in the middle of nowhere against pagans or creatures. Logically if you were in the middle of nowhere among a small, isolated tribe, or an alternate dimension or some other isolated place a mission might put you, you could probably do whatever without worrying about being locked up by the City Guard. It makes sense for most missions though, so maybe I could suspend disbelief when it comes up after a pagan mission or something.

 

I guess a generic stat breakdown would be applicable for all missions/campaigns, while the wanted posting might not always, but the wanted posting adds more fun character to the stat breakdown.

[sparhawk]

I don't really like it. The stats screen is a metagame object, so it shouldn't act as if it were still part of the game, because it isn't. Especially that "Rumored to be active for 2:43hrs" sounds plain stupid to me. In these particular cases it might even work, but how about the other stats?

He was rumored to be seen 3 times.

He was rumored to be heard 5 times.

He was rumored to have reloaded 7 times.

He was rumored to have stayed 70% in the shadow.

He was rumored that his loudest soundpropagation was at 23.5Db.

 

Nah! Just make it a simple statistic with some nice graphics as background. We also don't treat the loading/save screens and other menus as if they were still part of the game, so why suddenly here?

 

The wanted poster, makes sense in the context of a mission or campaign, but not really as a generic information. I think this should be left to the mission author to utilize it if he needs it.

[Fingernail]

It's good but you spelt "Thief" wrong which makes it look terrible!

[SneaksieDave]

I do like it, but hmm. Sparhawk has some good points with 'other' stats. They would look strange, if included in that design.

 

Maybe simpler, non-stylized is better in this case.

[Springheel]

I guess I have to track "AI's assaulted

 

Actually, I was just using that term for 'KO'ed', which didn't sound as good.

 

Logically, I'm not sure about the overall "wanted amount" score going higher the closer you are to ghosting the mission

 

I agree--the whole concept doesn't necessarily fit logically, it's just an interesting and more fun way of presenting the information and giving an overall 'Mission Score'.

 

The stats screen is a metagame object, so it shouldn't act as if it were still part of the game, because it isn't.

 

That's a valid criticism, and it's why I didn't spend a whole lot of time on it (thus the typo). You can't make it fit 100% into the game, but at the same time we're trying to design the Purchase and Objective GUIs that way, so there is a precedent. It's really just for flavour. I'm actually in favour of trying to make things look a little bit like they're from the game world when possible, even if it can't be done fully.

 

Nah! Just make it a simple statistic with some nice graphics as background

 

Well, like I said, I don't have any other good ideas for appropriate graphics or designs for a stat screen. If you just want a blank parchment with some text on it, that's easy enough. Or we could just use the regular menu design and put the stats where the menu options would normally be.

[sparhawk]

That's a valid criticism, and it's why I didn't spend a whole lot of time on it (thus the typo). You can't make it fit 100% into the game, but at the same time we're trying to design the Purchase and Objective GUIs that way, so there is a precedent. It's really just for flavour. I'm actually in favour of trying to make things look a little bit like they're from the game world when possible, even if it can't be done fully.

 

Personally I wouldn't count our current shop design a game object either, because it isn't. The fact that you have to decide your equipment doesn't mean much, because we can assume that our thif had to get his equipment SOMEWHERE. It is of no consequence where this really is, and this is the reason why it works for all maps. In the case of Seventh Crystal (I think this was it) it's different, because the shop is a real shop and part of the game, which is clearly different.

 

Well, like I said, I don't have any other good ideas for appropriate graphics or designs for a stat screen. If you just want a blank parchment with some text on it, that's easy enough. Or we could just use the regular menu design and put the stats where the menu options would normally be.

 

That's enough IMO. Just a list of the stats one after the other. Like the main menu and the others.

[Springheel]

That would basically be something like this. Extremely easy to do, we'd just use the same template drumple will use for the other menus.

 

[Dram]

Yeah I think that's the best solution Spring.

 

I think we might want to put more info, such as the loudest heard volume, how many AI you injured etc.

 

I think we also should have "you lost X health overall" or something rather then an RPG "you took 21 HP of damage" but that's a personal preference and can be changed for oneself in the gui. Also, KO'd should be "you knocked out X innocents and X armed guards" or something. I guess we could put stats for things like monsters etc, so "you killed X monsters" etc. But referring to the AI as AI in game is bad imo.

 

Just constructive criticism.

[Springheel]

I just cut and pasted those phrases; I wasn't suggesting that be the actual wording or order.

[Ishtvan]

Yeah the generic breakdown works for me too.

 

Re: Recording the volume heard.. that means an extra logging and comparison step for every single soundprop event, that could slow down performance significantly. It already slows down a lot when I put it in debug mode and record that stuff, so I'm not sure I like the idea of doing that, performance-wise. Also, does "24.5 [dB] SPL" really mean that much to you?

[Dram]

Yeah the generic breakdown works for me too.

 

Re: Recording the volume heard.. that means an extra logging and comparison step for every single soundprop event, that could slow down performance significantly. It already slows down a lot when I put it in debug mode and record that stuff, so I'm not sure I like the idea of doing that, performance-wise. Also, does "24.5 [dB] SPL" really mean that much to you?

 

If it slows down then of course we should'nt. I just thought that the AI already have to calculate how loud the sound is, so you can just take thevalue from them.

 

Oh I see, you thought I meant player wise. No I meant the loudest volume at which the player was heard

[sparhawk]

Yeah the generic breakdown works for me too.

 

Re: Recording the volume heard.. that means an extra logging and comparison step for every single soundprop event, that could slow down performance significantly. It already slows down a lot when I put it in debug mode and record that stuff, so I'm not sure I like the idea of doing that, performance-wise. Also, does "24.5 [dB] SPL" really mean that much to you?

 

I don't know if we should include something like that, but it makes a good example, why the other one will not really work. Because at least some of the stats will not have some direct relation to an ingame content.

 

I don't see why this should be a slowdown for the system. Whenever an AI reaches sound, you just compare it against a globabl value where the loudest sound is stored. Simple enough.

 

Spring, that looks better imo. For the wording I would just write a clean list:

 

Number how often seen by AI:  12
Number of enemies killed:	 12
Loot stolen:				 350
etc.

 

This way it is easier to digest as if you had to read a real text.