Creating a computer-aided version of WCTO

[Jason_Ryock]

From what I understand (which may not be necessarily accurate, I'll admit), IE7+ will correctly render PNGs with transparency. IE only falls over when PNGs include gamma/colour correction.

This is excellent - I've been looking for more details on these issues but I've been unable to find any. Thanks for the in-depth information, I can honestly say that's going to help me a great deal with my current project.

They did in the past, but since IE7, they've actually made some good progress in the direction of standards compliance. Trident is still far, far behind the other major browser engines, but you can't really say Microsoft refuses to adopt web standards any more.

And since the majority of the Internet use IE, the standard practice is to write according to web standards first, then selectively patch for IE.

Yeah, but this is why it's so frustrating. A majority of the Internet uses this browser, but the browser doesn't use the standards they were developed specifically to avoid problems like this. :/

I don't know what else I expected really, certainly not that Microsoft would be more responsible about their duty to end-users.

but as Jason put it, writing for and testing five sets of browsers is a 'freaking nightmare'. Even if you choose to only check Trident, Gecko and WebKit, that's still a lot of work.

Speaking from professional experience, where I have been asked to do exactly the above.

 

[Ironduke]

I honestly don't care that much about things like fonts, so if you guys can, as a collective community pick a few "standard" fonts that "everyone is likely to have" I can get the layout to work for those fonts in particular, but as I stated at the outset, CSS is *not* my forte, in fact, I'm learning most of that side as I go. The php/mysql/etc. is where my own skillset lies, web-wise. If anyone else who has time and better CSS skills wants to jump in, I'd be happy to work with them.

Actually, I'm fine with Verdana. I wouldn't want you to get side-tracked by aesthetics at this early stage in development... We can still play around with the look of the game once the hard work is done - and since all the hard work is done by you at the moment, you won't hear me complain a bit.

Sounds good. I can size-down the 3D picts, or we could make *those* part of the background, or any number of things.

Yes, I've already thought of using the 3D shots as background, but I think it would be too distracting. I hope I'll come up with something reasonable soon, though!

we're just going to absolutely ignore IE for the time being.

I totally agree, for the same reason as above. You already have a lot of work ahead of you as it is, so you better concentrate on the basics and - if we're lucky enough - leave the rest to someone who's more proficient in that field.

now in a completely unrelated note, the window-demo has been updated with my first cut at the 'Movement-Phase Order Submission Window'. It doesn't actually do anything, but it should be fully navigatable. I've shown it with the terran colour scheme.

Interesting! To make the GUI more intuitive, I think I'd prefer something along the lines of strictly separate "Regular Movement" and "Special Maneuvers" tabs, but I do like it a lot! The blue grids in the background are a nice touch, too.
Guess it might be a good idea to leave some room for a textfield at the bottom, where a short description of the maneuver could go. (Or would a maneuver-specific help button with a pop-up window be a better choice...? Or just simple tooltips? Hm...)

 

[Avacar]

Interesting! To make the GUI more intuitive, I think I'd prefer something along the lines of strictly separate "Regular Movement" and "Special Maneuvers" tabs, but I do like it a lot! The blue grids in the background are a nice touch, too.
Guess it might be a good idea to leave some room for a textfield at the bottom, where a short description of the maneuver could go. (Or would a maneuver-specific help button with a pop-up window be a better choice...? Or just simple tooltips? Hm...)

Tooltips "should" be doable using html's alt= text field. That said, I also know I could implement some 'on-mouseover' hints that would appear in an area below. I can prototype this next if you desire.

I divided it up this way based on what parts of the ship you're using (aka afterburner cost, or not afterburner cost). If you would prefer, I can instead make it split 'regular' and 'special'. In that case, do you consider even a normal afterburner manoeuvre to be special? Are we in agreement that the barrel roll needs to be an always-present toggle?

I should also clarify that you're seeing "the full" control. For ships that are less capable, the appropriate buttons simply wouldn't appear. This is something I need to do using php and the database, which this demo doesn't yet handle.

One additional point, you may start to see some patterns, especially when I am using buttons or pop-ups. That's because their styling and controls are coming from the jquery ui. If you go look at their "theme roller" you can see exactly what I mean. As a reference point, ours is currently a variant of dot luv. You guys are welcome to try to make your own themes and I can demo them. Realize, however, that this theming *only* affects the buttons/windows/etc. The rest of the CSS is still hardcoded by me, with my best attempt to make colours match and such. While I haven't tried it, theoretically their 'bookmarklet' would let you mess with the theme directly on my demo if you wanted to. (The ship entry program also makes heavy use of it, especially on the weapons controls)

 

[Wedge009]

• Javascript Enabled
• Possibly Cookies (for session-to-session login memory, not yet in use)
• NOT using IE

I laughed at the last point, but again, I think this is reasonable given that it's not for general Internet community consumption.

I honestly don't care that much about things like fonts, so if you guys can, as a collective community pick a few "standard" fonts that "everyone is likely to have" I can get the layout to work for those fonts in particular, but as I stated at the outset, CSS is *not* my forte...

Fonts is another thing that's difficult to work with in web-design. Fonts aren't consistent between different operating systems, or even between different versions of the same operating system. I generally try to get things working on a Windows system (for the sake of getting it working for the majority), and doing my best to find similar fonts for other systems. Basically, just avoid using esoteric fonts in web sites or use images as substitutes.

I don't know about the current HTML5 development, but I heard something about cross-browser/system font standards in the works. Should be interesting.

Um, maybe... I could use a fixed, correct-sized background image, but then if we wanted to change the window in the future, we'd need to change the image. I'd prefer to keep it as much done on-the-fly as we can.

Of course, I'd prefer everything to be generated automatically as well, but images are probably the best thing to work with for compatibility's sake at the moment. We work with what we have available. :/

Yep, I'm well aware. I hate to sound a bit elitish, but I have honestly *never* used IE.

Heh. The funny thing is that though I prefer Firefox to IE now, before web standards were established I always preferred IE to what I (admittedly childishly) called Nutscrape.

I will, however, try to look into making sure it does run in Opera and Safari as I expect it to, in addition to Groove and Firefox.

If you're testing in Chrome/Chromium, that should be enough to cover WebKit, so Safari shouldn't be necessary. But what's Groove?

Yeah, but this is why it's so frustrating. A majority of the Internet uses this browser, but the browser doesn't use the standards they were developed specifically to avoid problems like this. :/

I don't know what else I expected really, certainly not that Microsoft would be more responsible about their duty to end-users.

As I said, Microsoft is still lagging far behind, but they're definitely improving. And I'm sure you know that even more frustrating is being forced to cater for IE6. I had to do this as a requirement for my previous job (the client's IT policy meant that users were stuck with the broken browser) and for my own web site where I'm still getting a significant proportion of visitors using IE6. >.<

Speaking from professional experience, where I have been asked to do exactly the above.

...and I agree, speaking from personal experience.

Tooltips "should" be doable using html's alt= text field.

No. The correct practice should be to use the title attribute. The alt attribute should be for specifying a text description as a fall back.

 

[Avacar]

If you're testing in Chrome/Chromium, that should be enough to cover WebKit, so Safari shouldn't be necessary. But what's Groove?

Right, I actually did mean 'Chrome' but by the time I noticed the error, my ability to edit had timed out. Groove is a really annoying, but occasionally useful-for-niche-applications piece of software that was bought by Microsoft and allows direct peer-to-peer folder sharing over the internet... but *only* works for 32-bit windows systems, which means it only works for 25% of the people I work with daily (who all use 64-bit systems at a minimum since we do advanced computation, and often on linux). No idea why my brain swapped Chrome for Groove; I'm definitely doing the testing on Chrome.

No. The correct practice should be to use the title attribute. The alt attribute should be for specifying a text description as a fall back.

Er, right, the title. I hate to admit it, but I was trained back on HTML 3.2, but I've learned "most" of the new tricks. This particular project is currently cemented strongly in HTML 4.x stuff, although I *am* using a fair bit of the new CSS3. I also heard about the HTML5 open-font initiative, and we may adopt it down the line.

Any other comments out there about the actual forms in question though? I've only heard from Ironduke so far about the movement command interface.

 

[Wedge009]

It's fine, I thought that's what you meant. I did try to look up Groove, and the only thing I came up with was (what is now called) SharePoint. I've yet to use it at my own work because I still haven't been properly granted permissions to access stuff on it. x.x I didn't know it only works with 32-bit systems - we're all on Windows 7 64-bit.

As for the alt/title attribute, my understanding is that both were introduced back in HTML 2, but people kept using alt because that's what was (improperly) used for tool-tip windows in Internet Explorer. I wasn't having a go at you - I dare say you probably know far more about web development than I do.

As for the content itself, sorry, no, I don't have an opinion either way. I only chipped in for the browser discussion.

 

[Avacar]

Well, I learn something new today. Apparently 'title' does make auto-tooltips! I tested it out, but after seeing the result, I decided to use jquery to add tooltips to the demo in a slightly non-traditional way, but one that will, I think, be easier on users playing a game. Thoughts on look-and-feel?

As for groove: it is not sharepoint, and although the two pieces of software can 'play', I wouldn't recommend it. I have no idea why groove hasn't been recoded for 64-bit; that was the single-main largest reason why we migrated away... and for some reason, not only is groove not 64-bit, it is *anti* 64-bit, meaning it won't work installed on a 64-bit system running in 32-bit emulation mode (something 95% of software does automagically without you evening knowing or caring).

 

[Wedge009]

Yeah, most browsers today give tool-tips with a title attribute, but I'm not so sure if that was the case in previous releases.

Very bizarre thing about being anti-64-bit.

 

[Avacar]

The window demo has been updated with a crude version of the combat controls. Functionality (as far as menus go) is mostly there, minus tool-tips. Formatting still leaves something to be desired with all the defaults more or less as-is. (Definitely need to shrink the buttons down).

That said, does anyone have a nice looking 'missile schematic' or 'cross-hair' I could use as a background image for the standard weapons and missile area backgrounds?

I'll try to get to the tooltips tomorrow, although non-WCTO commitments are piling a bit at the moment.

 

[Ironduke]

Tooltips "should" be doable using html's alt= text field. That said, I also know I could implement some 'on-mouseover' hints that would appear in an area below. I can prototype this next if you desire.

The current maneuver descriptions look good enough - we can still tweak them later on if necessary. It's just that I thought most people would like to be able to play the game without having to double check the manual every other moment...

I divided it up this way based on what parts of the ship you're using (aka afterburner cost, or not afterburner cost). If you would prefer, I can instead make it split 'regular' and 'special'. In that case, do you consider even a normal afterburner manoeuvre to be special? Are we in agreement that the barrel roll needs to be an always-present toggle?

This is clearly open for discussion, but apart from afterburner charges, my thoughts were to distinguish between regular movement and maneuvers that require a Target Roll to be successful. So my approach would look like this:

Regular Movement:
- display: current speed and bearing
- actions: maintain speed/accelerate/decelerate
- actions: straight/turn/bank
- actions: toggle afterburners (possibly with a text warning that this will consume 1 afterburner charge; speed display will have to go up accordingly)

Special Maneuvers: Just as you have them worked out. As for the barrel roll, I agree, but would put it in this section as well (due to TR and possible failure).

Does this make sense to you?

I should also clarify that you're seeing "the full" control. For ships that are less capable, the appropriate buttons simply wouldn't appear. This is something I need to do using php and the database, which this demo doesn't yet handle.

Yes, I assumed that much...

Btw, can I go on processing the top-down ship graphics, or do you want to do some testing before? (Since we're having that little offset issue right now...) If it's something related to the ship pics, I'd rather try to fix this now and work from there.

Can't tell you how great it is to log on to the CIC and see all the progress each day!

 

[Avacar]

The current maneuver descriptions look good enough - we can still tweak them later on if necessary. It's just that I thought most people would like to be able to play the game without having to double check the manual every other moment...

Do you like the look-and-feel of them as well? Also, if anyone else out there (especially people who have-not played and read them) has a recommendation for how to improve the wording, that is the kind of thing I can always update, regardless of the phase of coding I'm at.

This is clearly open for discussion, but apart from afterburner charges, my thoughts were to distinguish between regular movement and maneuvers that require a Target Roll to be successful. So my approach would look like this:

Regular Movement:
- display: current speed and bearing
- actions: maintain speed/accelerate/decelerate
- actions: straight/turn/bank
- actions: toggle afterburners (possibly with a text warning that this will consume 1 afterburner charge; speed display will have to go up accordingly)

Special Maneuvers: Just as you have them worked out. As for the barrel roll, I agree, but would put it in this section as well (due to TR and possible failure).

Does this make sense to you?

Well, this is where, as a player, I guess I categorize it differently in my own head. I usually think more in terms of what I can make the ship do, not how difficult it will be to do it (which is why I probably fly off the map and/or fail special manoeuvres so often). Now, talking functionality, I do want to insist on one point: once you've "selected" your order, you should be able to see all of it at once. With this in mind, something like 'barrel roll' which is available in combination with any other order, needs to be visible at all times. That said, I could remove the show/hide stuff, and just make the various tools enable/disable based on your selections. Then I could section it off with borders or something.
What do the other players/readers think?

Btw, can I go on processing the top-down ship graphics, or do you want to do some testing before? (Since we're having that little offset issue right now...) If it's something related to the ship pics, I'd rather try to fix this now and work from there.

With respect to the top-down ship pictures, please send me at least 1 ship in each class, and make sure those are in the database using the ship entry form as well. Once I start coding phase 4, I'll need access to capital-class ships so I can test out their shields and weapons.

Also, send me all the 3D pictures for the ships that you've already sent me the top-down's for. These should be named "ShipName_3D.png"

Otherwise, no, there isn't a rush on the rest of the ship pictures. That said, if they are all consistently offset to the right in position 1 like we discussed, I can just throw in a judge-factor to correct that.

 

[Ironduke]

Do you like the look-and-feel of them as well?

Personally, I felt at home, but I wouldn't want to speak for others who have never played the game. We'll probably have to wait for the first public beta test to find out what others think, though.

With this in mind, something like 'barrel roll' which is available in combination with any other order, needs to be visible at all times. That said, I could remove the show/hide stuff, and just make the various tools enable/disable based on your selections. Then I could section it off with borders or something.

Not a big fan of borders, since it'll presumably bloat the movement window... Also, if the barrel roll is always visible as a maneuver, there's not much sense in "hiding" the other maneuvers. I still think there should be a warning of some kind to alert the player about everything requiring a TR... (Maybe a target reticle with the appropriate TR for the selected maneuver that pops up on the right side of your selection?)

As for the rest, I've sent you an email.

 

[Avacar]

Not a big fan of borders, since it'll presumably bloat the movement window... Also, if the barrel roll is always visible as a maneuver, there's not much sense in "hiding" the other maneuvers. I still think there should be a warning of some kind to alert the player about everything requiring a TR... (Maybe a target reticle with the appropriate TR for the selected maneuver that pops up on the right side of your selection?)

It occured to me that there's no reason why I can't dynamically list off the exact difficulty of any given manoeuvre at a given time, taking into account speed, pilot skills, etc.

If I did this, would you want it in a tooltip, or as part of the button, or as side text to the button?

 

[Ironduke]

My first reaction was "side text to the button," but why not placing it at the bottom of the box, right above the "Execute" button (or whatever it'll be named)? That way it'll be always in the same position, and if we call it "Maneuver difficulty," it should be clear enough. (Of course, it would be "0+" or "n/a" for all regular maneuvers.)
If you put the afterburner charge cost right next to it, we'd be all set!

Maybe we should also think about a heads-up message if any given maneuver will (or could potentially) move the player's ship off the map... (Could even be an "Are you sure?" window.)

 

[Avacar]

Just an FYI to all WCTO followers out there: progress has slowed not because of it becoming harder, but because I'm moving IRL, and have been madly packing all this week and part of last week. The process will reverse next week, but I do hope to finish up the last of the screen prototypes, and then finish off phase 3 sometime over the weekend or early next week. Phase 4 is the meatiest, but I'll be able to release semi-playable trials for you guys to help me debug at various points throughout that phase.

 

[Avacar]

Okay, so still only a very slight bit of progress, but if you go check out the window demo page, you'll notice the new, and improved 'reduced profile' ship info window. Additionally, the last prototyped window, the 'end phase' is available at the very bottom.

Yes, I realize some of the windows interact; that's probably because I'm reusing names, but all the command windows will never be open at once (since even if you have multiple ships, you'll never have them at different turn phases at once). Also, right now, the 2 ships have their slide-out linked; I haven't decided if this is how it will remain, or if I need to add a last bit of unique identifyer code in there.

As of right now, there are no tooltips for the other command windows, however the code to do so need only be duplicated with the new text added in. If you guys want to open a new thread and start hashing out good tool-tip wording, that would save me trouble down the line.

Any obvious problems/issues/missing controls here?

Anyway, I'll prettify-these later based on user input, as necessary.

 

[Avacar]

We're sort of back on schedule now, as my 'real life' concerns are clearing up. Mostly unpacked at my new place.

I need to do an update to the weapon class initialization and tie it into the ship class, and then I can finish up phase 3 with the self-generated display of a ship pop-up in the context of the phase 2 end demo. All ships will currently be piloted by me, since I haven't even written the pilot class (and don't really intend to until phase 5, if I recall the plan correctly).

 

[Ironduke]

I'm back from my seminar as well, so you'll have to put up with my comments again...
As for the new ship info screen: Kinda like the tab thing, and maybe we can even squeeze in the 3D pics again this way. Or downsize the pop-up even more if you put the ship armament in another tab... Just thinking, instead of "Details:"
- Info: shows the 3D pic and additional info like fighter compliment, jump capability/capacitors, possibly even shield recharge rate
- Arm (Armament): shows gun and missile loadout, chaff pods, targeting and incoming (although I think I'd like to see the loadout on the "front screen" as it is)
- Dmg (Damage): shows internal damage (later...)

Oh, and congratulations on your successful move, of course!

 

[Avacar]

I'm back from my seminar as well, so you'll have to put up with my comments again...
As for the new ship info screen: Kinda like the tab thing, and maybe we can even squeeze in the 3D pics again this way. Or downsize the pop-up even more if you put the ship armament in another tab... Just thinking, instead of "Details:"
- Info: shows the 3D pic and additional info like fighter compliment, jump capability/capacitors, possibly even shield recharge rate
- Arm (Armament): shows gun and missile loadout, chaff pods, targeting and incoming (although I think I'd like to see the loadout on the "front screen" as it is)
- Dmg (Damage): shows internal damage (later...)

Oh, and congratulations on your successful move, of course!

I was debating more pop-outs too, and simplifying it further. If anyone wants to sketch out (even in paint) how the info should be divided and how/where it should slide out, I'd appreciate it. I can do pretty much anything. (multiple sliders on the same side with tabs, etc.)



Meanwhile, after much delay (do to personal life) Phase 3 is complete! I know it looks a lot like phase 2, but that's the point. Under the hood, we now have the pop-ups generating themselves based on the turn info. I haven't 100% debugged it (i.e. I think on the far right of the map, the slideout will pop off the screen, for instance) but it covers the fundamentals so I can move into phase 4 and start coding the order resolution engine, and then finally put in those order-submitting screens that were prototyped (which involves creating a pre-solver for the orders so it can determine appropriate valid target).

 

[Avacar]

FYI: Looks like my last minute changes to get the phase3 final stuff working broke the window demo for the pop-ups, but they work just fine in the actual phase3 work, and that's what matters.