From StrategyWiki, the video game walkthrough and strategy guide wiki
Jump to navigation Jump to search
Archive
Archive
This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current staff lounge page.

June 2016 | July 2016 | August 2016

Archive

Archives


2006

Worldwide SNES buttons

Those faded-out US-only SNES buttons are so ugly! Let's get the original version: they're used worldwide (in Asia, Europe, and Oceania)!

Let's remember that citizens of the United States are just 20% of world native English speakers, not to mention all those who are not native speakers (like me). Therefore, the faded-out US-only SNES buttons are useful for way less than 20% of potential users of this website. ---Abacos (talk) 08:48, 2 June 2016 (UTC)

Control selector Select controller:
SNES

I propose to add one option to the { {Control selector} }, that is
to differentiate between "SNES" and "SNES (US-only)". --Abacos (talk) 08:59, 2 June 2016 (UTC)

There's no point of having two different sets of buttons. We should either use the blue ones everywhere, or the other set, but not both. If we choose to go with these images, they should be uploaded over the existing ones. Can you fix the transparency and remove the excess padding so it's just the buttons? Personally, I prefer the current colours, since they're less distracting, but it does make sense to use international colours. -- Prod (talk) 14:05, 2 June 2016 (UTC)
I get the argument being made here, although I don't think the expression of bias against the US colors really helps make your case Abacos. There are legitimate arguments for using the international colors. Your finding the colors ugly isn't really one of them. If you want to alter the colors to the international version, that's fine, but like Prod said, they have to be at the same standard and quality as the existing images. Fortunately, this is really the only system where this is an issue... Procyon 17:38, 2 June 2016 (UTC)
This diagram was made with the true SNES controller in mind. The game said: "8 steps to the B, 7 steps to the Y, 6 steps to the X..."' etc. Imagine doing it with the US-only buttons in mind.

I removed the excess padding. I couldn't learn how to fix the transparency, though... Let me rephrase my originally biased argument in support of the original colors:

  • Less than 20% of potential readers of Strategywiki are familiar with the US-only colors.
  • Many users from outside the USA refer to the buttons through their color.
  • The original colors match the SNES logo (that, for some reason, was completely changed in the USA).

---Abacos (talk) 11:43, 8 June 2016 (UTC)

It's actually about 50% US traffic. I don't think that's as important as accuracy though. The n64 did colour-code their buttons, oddly with a different mapping from the SNES. I'd say let's go ahead with the new buttons once the transparency is fixed. Should they be the same size as the previous buttons (24x24)? -- Prod (talk) 02:26, 14 June 2016 (UTC)
I went ahead and fixed the transparency for you. Wanderer (talk) 01:06, 16 June 2016 (UTC)
Thanks Wanderer (talk · contribs)! I've moved these files into the templated names, so they should be showing up everywhere now. -- Prod (talk) 04:07, 12 July 2016 (UTC)

CSS-based button images?

So I had this idea. Maybe we don't need to use images for the control buttons anymore. Maybe some of the buttons could be replaced with just HTML fragments and CSS classes. The templates would still be used the same way, they'd just have to be modified to output an HTML fragment instead of the image. This would have several advantages over using images:

  1. Quicker pageloads. Fewer images would mean fewer requests to the server, so the pages would load faster.
  2. Less bandwidth. The added CSS classes and HTML code would take up much less data than the images, so the pages require less bandwidth.
  3. Resolution independence. Since these would be rendered in-browser instead of being pre-rendered images, they wouldn't have any fixed resolution. Even on high-resolution displays, or when zoomed in, they will always look clean and not pixellated.

This wouldn't work for everything, of course. The various D-pad and joystick images might be difficult to recreate in CSS. Irregularly shaped buttons, like the Xbox's triggers, would still have to be images. But for the simple circle and rectangle-shaped buttons, this might work. I set up a demo page here with just a few examples. See if it looks okay to you all. Wanderer (talk) 09:42, 12 July 2016 (UTC)

Ideally, I think these should be SVG images to get most of the same benefits while still using an image format. Unfortunately, mediawiki converts the images to png losing the svg benefits. The icons look pretty cool (slight tweaking required) but generally I'm not a big fan of using CSS for this. -- Prod (talk) 15:56, 12 July 2016 (UTC)
I'm pretty impressed that you were able to achieve all of that Wanderer (talk · contribs). If you could make them look spot on, I'd be willing to consider it. Prod (talk · contribs), why are you not a fan of CSS in this case? If Wanderer can make them look so close you can't tell them apart, what's the drawback of using CSS? Maintainability? Procyon 01:07, 13 July 2016 (UTC)
Cross browser compatibility, visual change history, ease of implementing new buttons, conflicts with other CSS. It's impressive what's done, but I do worry it'll be a lot more maintenance work than simple image files. -- Prod (talk) 05:28, 13 July 2016 (UTC)
For what it's worth, we've switched to using SVGs via CSS for all buttons and small images on PCGW 9 months ago, and we've experienced no complaints and no issues - and with image sizes under 500B, this was usually also a major improvement over raster graphics. It's fair to say that adding new icons is not as smooth a process, though I guess you can still get away with using MediaWiki:common.css for the images? Either way, how often do icons actually change to need daily maintenance?
There is one downside to all of this regardless - the user loads all this data every time, even if the classes aren't used on pages. Then again, that should be mitigated by caching (both sides), and speaking from our own experience, we did not notice any increase on load or times for ourselves. Soeb (talk) 14:49, 15 July 2016 (UTC)
I'd be ok with loading svg's through CSS, I'm just not as comfortable having images defined using CSS elements directly. -- Prod (talk) 16:46, 15 July 2016 (UTC)

When is a strategy too dumb or too obvious/naive?

For example, here it seems totally overkill and lame to say -basically- "hey, buy the fastest car in the game, profit".

While here.. It's not like -for "wallet sake"- I wouldn't prefer to recommend to forget about that race until you get this uber fast car (for free). But how much is this a real tip, and how much instead the stupid thing I mentioned above?

Besides, while I'am at it.. Some of the stuff written for GT5 mention online dealership, which isn't a thing anymore since.. I think like 2-3 years.

What's your policy about older patches (something something speedruns) or actually no longer achievable content (like any online games with dismissed servers)?

I can't really comment on the strategy for that specific game. If there's nothing better to add, might as well say the most basic info.
As for dealing with content that no longer exists, it can be kept/expanded to describe how it used to be. You could add {{Unplayable section}} to mention it's no longer available. -- Prod (talk) 21:02, 12 July 2016 (UTC)
Yeah, you can make a call like, "this text is so flat out obvious, it's not worth mentioning" and remove it if you feel strongly about that. I'm in favor of doing that whenever someone describes a cut-scene verbatim. It's like, the player can see it by themselves, you don't need to describe it. The same can go for fairly obvious strategies. However, if there's any nuance or deeper explanation that you can provide, that's helpful too. Sometimes the "why" is even more valuable than the "what". Procyon 01:07, 13 July 2016 (UTC)