P.U.R.E. 0.8 RC3 - Page 41

P.U.R.E. 0.8 RC3

WolfeGames and projects headed by Argh.

Moderators: Moderators, Content Developer

User avatar
AF
AI Developer
Posts: 20669
Joined: 14 Sep 2004, 11:32

Re: P.U.R.E. 0.8 RC3

Post by AF » 21 Feb 2009, 22:33

Your points make sense if you've already been playing P.U.R.E but for new users however, they would help enourmously.

These improvements do not make an unplayable game playable. However, they drastically improve usability and reduce the learning curve enormously for new players. You can have terrible colors and typography on a page and the text is still readable but people wont read it for long and it'll be harder to read than a nice clear serif font on a white background despite being the same content.

Image

People associate blue and violets and purples with energy, lightning bolts follow this trend in nature, as does the EM spectrum.

Image

If you look at anime the more powerful energy weapons tend to be blue/purple or very bright yellows, plasma as shown to the public usually looks purple/violet/blue, infact the predominant colour on a google search for reactor is blue.

Blue has a powerful association with energy and electricity.

Red on the otherhand is a more earthy colour. Reds and yellows and oranges look more like raw materials. If anything the corresponding google image search gives a beige outlook.

Image

The nearest blue gets to materials is metalic stuff, which is more gray than blue, and in some cases neither

Image
0 x

User avatar
zwzsg
Kernel Panic Co-Developer
Posts: 7017
Joined: 16 Nov 2004, 13:08

Re: P.U.R.E. 0.8 RC3

Post by zwzsg » 22 Feb 2009, 00:09

If we take real world energy, and real word object, we can find them of any color!

Look, grey blue material!

Look, orange energy!

So, there's so much choice we can find any color, heck, I can even find you pink energy picture! (nah, seriously.)


So, instead, we ask the all-knowing google, that is, to agree on taking the overall color of the very fist image found by image.google when asked "energy" or "material".

Look, Look, the first picture of energy is a a woman in a YELLOW suit! I win! But then I utterly fall on material, which ofc I find unfair, so I'll say this method is way too random.


So, I say, let's look at what's the stance taken by other RTS. Well medieval-fantastic have several material (gold, lumber, stone, etc..) and no energy, so let's focus on today's or futuristic ones. according to RA, the energy is green yellow red. According to Dawn of war, energy is green, and requisition which I'll say is material because it convenes me, is blue. Can't find any other RTS which has material or energy resource with a clearly stated color, so for now I'll say that this mean energy must green. Which is wtf, because none of us ever wanted that.

There.
0 x

User avatar
AF
AI Developer
Posts: 20669
Joined: 14 Sep 2004, 11:32

Re: P.U.R.E. 0.8 RC3

Post by AF » 22 Feb 2009, 00:29

I was mainly making the point that human cultural conventions lean heavily towards blue for energy. Those pipes are not blue they just got blue reflections anyway, and that nuclear pic si just a computer sfx

Green is an artifact of color coded energy bars, where color isn't representing energy but how safe your supply is, red -> low, amber->med, green ->safe/surplus.

Anyways, your just attacking my points, your not actually justifying why they should stay the same.
0 x

User avatar
zwzsg
Kernel Panic Co-Developer
Posts: 7017
Joined: 16 Nov 2004, 13:08

Re: P.U.R.E. 0.8 RC3

Post by zwzsg » 22 Feb 2009, 00:41

Honestly my main reason is that I'm used to TA:


Image
0 x

User avatar
Pxtl
Posts: 6112
Joined: 23 Oct 2004, 01:43

Re: P.U.R.E. 0.8 RC3

Post by Pxtl » 22 Feb 2009, 12:08

AppLauncher 1.1 - the "enable maps as they're compelted" will be hard, thinking it over, because of the myriad places Spring could be dumping the file - how does AppLauncher know what folder the mod is working in? AppLauncher could find program files\Spring and the user folder, but not much else if, say, user is using a Spring folder. Will be tricky.

However, I've completed the "briefing" thingy.

New syntax:

Code: Select all

<Button Text="Beep" Target="Beep" WaitForExit="true" ToolTipText="This doesn't work">
     <DescriptionPage ExitText="<< Back   " AcceptText="Accept" AcceptPosition="8">
  	   <DescriptionRTF>
     	{\rtf1\ansi\ansicpg1252\deff0\deflang4105{\fonttbl{\f0\fswiss\fcharset0 Arial;}}
{\colortbl ;\red128\green0\blue0;}
{\*\generator Msftedit 5.41.21.2508;}\viewkind4\uc1\pard\f0\fs20 Test test 1-2-3\par
\par
\cf1 Foo\par
bar\par
baz\cf0\par
}
     	</DescriptionRTF>
  	 </DescriptionPage>
  </Button>
Scary looking, huh? Isnt' so bad, really. The new tag is the "DescriptionPage" tag. Put it inside a button. If the button has a "DescriptionPage" inside it, then clickign it will take you to a briefing window. DescriptionPage has all the usual exit-button attributes and the background/header/footer image stuff so you can style it however you like. It also set of attributes for the Accept button (same as Exit, but Accept - AcceptText, AcceptIdleImageTarget, yadda yadda), an attribute called "AcceptPosition" which says how many buttons far down the Accept Button appears (ie AcceptPosition = "8" means that the AcceptPosition button occurs in the 9th position of a zero-based list of button positions, the same spot the 9th button would be if it were in a full-out list of buttons).

Lastly, but not leastly, is the DescriptionRTF tag. This thing is a full-out RTF file embedded in your briefing, so you can use whatever fonts, styles, colours, and yadda yadda you choose. Just make an RTF file in WordPad (Word's RTF is hyper-verbose, use wordpad) open the file up in a text-editor like notepad, and copypasta the contents into the DescriptionRTF tag. It looks crazy, but is really simple to do.

Excuse typing, am insomniac tonight.
Attachments
AppLauncher.7z
(9.48 KiB) Downloaded 2 times
0 x

User avatar
Argh
Posts: 10920
Joined: 21 Feb 2005, 03:38

Re: P.U.R.E. 0.8 RC3

Post by Argh » 23 Feb 2009, 02:41

How's about if said file's in root/AppLauncher/NameofGame/mission_states.txt, or whatever?
0 x

User avatar
Pxtl
Posts: 6112
Joined: 23 Oct 2004, 01:43

Re: P.U.R.E. 0.8 RC3

Post by Pxtl » 23 Feb 2009, 02:48

If there's a specific path that's relative to applauncher, I can read it. My worry is that Spring can put files in many different places, and your Lua code might not get a say in teh matter.

Also, I was really sleep-deprived when I coded that, so the XML format for briefings will change, so don't get too enamoured with it yet. You can start working on art and RTF docs, the screen-layout will stay compatible (and it will stay RTF-based) but I might come up with a more versatile XML format.

edit: I might have an alternate approach. It puts more work on my table, but it would be more universal. I haven't tried launching Spring from AppLauncher much, so I don't know if I can capture standardout, but I'm pretty sure Lua can write to standardout, and I can read from it... so I could have AppLauncher read the StandardOut from Spring to search for a message you emit, which could be, for example, "enable button X".
Last edited by Pxtl on 23 Feb 2009, 02:56, edited 1 time in total.
0 x

User avatar
Argh
Posts: 10920
Joined: 21 Feb 2005, 03:38

Re: P.U.R.E. 0.8 RC3

Post by Argh » 23 Feb 2009, 02:52

Spring can put files in many different places
In Windows, root's root. Lua writing via file.io (erm, assuming that nobody severely screws with IO beyond some basic security, see Lurker's post proving that it is quite possible to do something nasty via IO currently) can very easily just write to root/whatever/blah every time. Anything lower than root, iow, it's trivial on my end, and should work correctly.
0 x

User avatar
Argh
Posts: 10920
Joined: 21 Feb 2005, 03:38

Re: P.U.R.E. 0.8 RC3

Post by Argh » 25 Feb 2009, 00:39

Ok, we've done the second-to-last playtest session. That means <gasp> that we're almost ready to launch RC4, at least the multiplayer part, to get people's feet wet.

Probably about a week and change, barring any major accidents or problems.
0 x

User avatar
Pxtl
Posts: 6112
Joined: 23 Oct 2004, 01:43

Re: P.U.R.E. 0.8 RC3

Post by Pxtl » 25 Feb 2009, 04:59

Applauncher with non-crappy implementation of text format. Description tag is gone, and nobody misses it. Forget all that crap.

New tag works like this:

Code: Select all

	<Button Text="Bar Child 1"/>
	<Text Slots="2" Format="RTF">{\rtf1\ansi\ansicpg1252\deff0\deflang4105{\fonttbl{\f0\fswiss\fcharset0 Arial;}}
{\colortbl ;\red128\green0\blue0;}
{\*\generator Msftedit 5.41.21.2508;}\viewkind4\uc1\pard\f0\fs20 Test test 1-2-3\par
\par
\cf1 Foo\par
bar\par
baz\cf0\par
}</Text>
	<Button Text="Bar Child 3"/>
	<Button Text="Bar Child 4"/>
As you can see, descriptive text is now just one more entry in the button list. So you can have a text field, then a button, then a text field, and so on. It works quite nicely. The "Format" can be Text (for plain black text) or RTF (for RTF text). The "Slots" says how many buttons high the text should be - 1 "Slot" = one button-height.

Also, there's a new tag that can be applied to a button-page called "AutoExit". When AutoExit = True, then clickign a command button or backing into this page will result in automatically backing out of the page. This AutoExit is useful for pages that are nothing but description and a confirmation box. The user only needs to see these pages when going forwards - when going backwards, they're pointless and redundant. So by setting the AutoExit=true flag on the briefing page, the user won't see the mission-briefing after they complete the mission, but will be bumped back to the mission list.
Attachments
AppLauncher.7z
(10.13 KiB) Downloaded 2 times
0 x

User avatar
AF
AI Developer
Posts: 20669
Joined: 14 Sep 2004, 11:32

Re: P.U.R.E. 0.8 RC3

Post by AF » 25 Feb 2009, 18:17

I would recommend the proposed changes to resource models be made before RC4 or not at all. If it doesn't change in RC4 then your going to cause problems for the existing user base which i expect for RC4 will be a lot larger than for RC3, at which point you end up with a loose loose situation over the debacle because you have to choose between your existing userbase or the future user base your trying to build.

I would also point out to refrain from using 'works on my machine' kind of justification, you are the creator, you are familiar, whether its broken or not your used to it and have learnt it already as a result the problem isn't obvious unless you really think about it, and as a result its extremely easy to simply say there is no problem despite feedback to the contrary.

Things as fundamental as resources need to be done right. So far you have totally ignored or dismissed the whole thing. I dont know if your trying to avoid it to save hassle, because if you had addressed this in RC1 in the private message I sent you then a tonne of discussion could have been avoided. So instead of praising your work I'm having to point out a major flaw you refuse to even acknowledge
0 x

User avatar
zwzsg
Kernel Panic Co-Developer
Posts: 7017
Joined: 16 Nov 2004, 13:08

Re: P.U.R.E. 0.8 RC3

Post by zwzsg » 25 Feb 2009, 19:36

Uh, calling switching blue and orange a major flaw that will kill the user base? Perhaps you're kinda exaggerating things maybe a liiiiiitle bit?
0 x

User avatar
AF
AI Developer
Posts: 20669
Joined: 14 Sep 2004, 11:32

Re: P.U.R.E. 0.8 RC3

Post by AF » 25 Feb 2009, 21:24

In TA its okay because the little blue bar has an even bigger text label next to it, whereas in P.U.R.E the resources are physically present on the map and there is more than one type of them.

Both of them are a hodgepodge of cultural conventions jumbled up and reversed that make little sense, and they were designed with aesthetics and unusuality in mind with little thought to how they were going to be interpreted beyond 'these need to stand out' and they even fail at doing that as a result of the los bug, and the fact they're most visible when they can be ignored, and least visible when you most want to find them, and barely visible at all out of los.
0 x

User avatar
Peet
Malcontent
Posts: 4381
Joined: 27 Feb 2006, 22:04

Re: P.U.R.E. 0.8 RC3

Post by Peet » 25 Feb 2009, 22:16

Hell there are examples of both ways in both games and real life...if intuitivity is *actually* an issue just make the materials darker and energy lighter without changing the hue!
0 x

User avatar
BrainDamage
Lobby Developer
Posts: 1164
Joined: 25 Sep 2006, 13:56

Re: P.U.R.E. 0.8 RC3

Post by BrainDamage » 25 Feb 2009, 22:21

The only intuitive interface is the nipple.
0 x

User avatar
Argh
Posts: 10920
Joined: 21 Feb 2005, 03:38

Re: P.U.R.E. 0.8 RC3

Post by Argh » 25 Feb 2009, 22:42

I suppose I should address this...

1. It's not possible to fix the issues with ghosted units, other than making them alwaysVisible.

The problem with ghosted units is that they are just using a really simplistic OpenGL hack.

There's nothing that I can do about that, and most Units look like crap when ghosted. It's just how it is, and it's an engine problem, not a game problem. And complaining loudly about it, at this late date, is hardly useful, considering that we have no real idea when the next version of Spring will be delivered.

Making them alwaysVisible totally fails, because it's entirely too much information. If your opponent can see when you've activated a building, that's a major problem, in terms of serious play.

DoW handled these issues by showing you the objects in their default states. You couldn't tell if they were flagged, towered, etc. at all. In Spring, this is an unusual situation, where what the engine can do is not entirely the same as what I'd like to see it do. I don't see a magical way to Lua around that one, other than forcing ghosting off, and showing them in their default state (which would be un-fun to get working).

IOW... finding the Ancients, and having to physically search for them... is a part of the game. It's a key feature, not a bug. If it's hard to find the Ancients, however, that's probably a bug, not a feature.

All of that said... on the maps made for the game, the locations of the Ancients are 100% consistent and balanced for each player's start location. I got rid of semi-random placement, basically.

On maps that weren't made for the game, it's going to be potluck, and I'm sure that a lot of maps will be totally unplayable with P.U.R.E.- and that's just how it is. I've done enough serious stuff with all of this that the game's not really going to fit into *A conventions, while trying to keep enough compromise that it's technically playable under those conventions. It's a rough road, but I've always thought it was the only one worth taking.

2. The color issues are entirely arbitrary, and do not represent a fixed ideal.

Nobody really does that stuff exactly the same way, because resources are not handled identically.

The key there, in an ideal world, is to be visually consistent, and I'd be the first to say that, for aesthetic reasons, I never bothered being all that consistent, because I expect that most RTS players who will pick up P.U.R.E.... aren't utter virgins to the genre, frankly. They'll read the description on the Fusion or whatever... be like, "oh, it's a power plant", and that will be that.

I'd be the first to say that it's different from object to object, visually, depending on what looked cool, and what made sense. My call on that is that where it's possible to fix without ceasing to make any sense, then orange / yellow can be Power, Blue is Materials, and that's that. My screwup in terms of not doing it in the UI the same way is already corrected.

But, like zwzsg, I feel like a game that I built at least in part to pay homage to OTA should stay near those conventions. There are a lot of places where I've deliberately steered away from OTA's design in terms of UI, but I don't think that this is one of them where it matters that much, frankly, and I'd prefer to leave it that way.

3. Having the resource generators be open at start would be a major CPU-sucker.

That said, a way to make them more obviously something you need to go capture seems like a reasonable thing to do. I'll put a simple glow effect on them while they're inactive but visible to a given player.

4. Ancients are clearly identified as being owned.

It's really hard to say that that isn't working, and in a competitive game, it won't be something where people are going to be clueless, tbh.

And if they are... so what? There are a billion things they're going to be clueless about at first anyhow, from how to get going economically, to how to rush, to how to capture buildings and use them to secure their flanks, to... you get it, there are a lot of things that people will be clueless about, it's just how it goes. Like any RTS, there's a pretty steep initial learning curve. Thankfully none of the AIs play the game well enough to be a giant threat from the start, otherwise tbh I would fear for players being able to handle things.
0 x

User avatar
AF
AI Developer
Posts: 20669
Joined: 14 Sep 2004, 11:32

Re: P.U.R.E. 0.8 RC3

Post by AF » 26 Feb 2009, 11:40

Regarding that I would suggest then you place an 'anomalous' marker on ancient objects where a ghost would normally be, a sprite drawn in lua akin to the markers in Starwars would suffice. This would hide the identity of the ancient objects so exploration is necessary while at the same time allowing ghost markers double markers or intermittent markers that don't always show up.

But for the moment its more the objects you saw that are now semitransparent and out of loss that are the problem, and you needn't fix ghosting to correct that. Lua has shown us the answer a long time ago.

Since you wont change the colours, I would suggest making it more obvious what the relationship is. Users will figure it out but it takes time which means learning curve, if your not going to rely on cultural mappings you need to devise something else.

So I propose a 'cheat sheet'. A dialog that pops up the first time that has very little text, and has a bullet point style method. A picture of a cube and a power symbol and the word energy, with perhaps a unit next to it with the label 'this capture this', something extremely simple that would literally take a maximum of 3 or 4 seconds to take in that almost entirely visual rather than textual all on one screen.
0 x

Warlord Zsinj
Imperial Winter Developer
Posts: 3742
Joined: 24 Aug 2004, 08:59

Re: P.U.R.E. 0.8 RC3

Post by Warlord Zsinj » 26 Feb 2009, 15:13

This thread is getting too wordy, I demand moar pictures
0 x

User avatar
Pxtl
Posts: 6112
Joined: 23 Oct 2004, 01:43

Re: P.U.R.E. 0.8 RC3

Post by Pxtl » 26 Feb 2009, 15:21

It doesn't seem to make sense to me that the ancients should be discovered by exploration if they're at pre-defined points on the map. I mean, if they were laid out randomly, then having to go hunting for them would make sense... but a pre-defined location seems inconsistent with that.

I'd think the simplest solution would be to add some sort of large resource-coloured alwaysvisible special-effect to them, whether they're active or not. Make them easy to spot. A huge diffuse ground glow, or something.
0 x

User avatar
AF
AI Developer
Posts: 20669
Joined: 14 Sep 2004, 11:32

Re: P.U.R.E. 0.8 RC3

Post by AF » 26 Feb 2009, 15:28

That could be fixed by literally telling the user they have to be found, though dawn fo war does tell you who owns what, it pops up messages saying xyz captured a critical point or a relic etc out of los which if clicked takes you to the spot on the map.
0 x

Locked

Return to “Argh's Projects”

cron