StrategyWiki talk:Community Portal

This talk page is for discussion of general community issues. To start a new thread click here. Resolved threads are gradually archived; see the archives box below.

Key Issues:

License
Articles to delete
Others to be added...

Community Issues Talk Page

It is unclear whether or not this page is just for the listing of issues, or for the discussions of those issues as well. It might be better for the issues to be listed here and for them to be discussed on the talk page.

(That was FilthySwine again.) I would disagree, because that would just make this page pointless - it would be a list which would constantly need updating, yet serve no purpose because all the titles and content would be on the talk page anyway. This is the community issues page, and I don't believe the talk page here needs to be used. --DrBob 14:10, 2 June 2006 (PDT)

SVG file format

As of now, Strategy Wiki does not allow uploads of *.svg file formats as wikipedia does. These are very small XML based vector graphics. For an example, check out the flag icons on http://en.wikipedia.org/wiki/FF6

I'm also trying to copy over some very important templates from Wikipedia, importing its http://en.wikipedia.org/wiki/Template:Logo to our very own template:logo. This is important so that we can legally cover our butts when I add the copyrighted ESRB rating icons to the template:Infobox. I hope to eventually add an {{{awards}}} variable to that template as well and would like to use those individual awards graphics, in fair use, of course. I'm working on a replacement infobox with rating icon implementation, but this server needs to allow the upload of *.svg file formats so we can also use this current standard of small, simple and most important, scalable graphics..--Filthy swine 15:26, 28 May 2006 (PDT)

Did I also mention that when *.svg files are used for location maps, anyone can edit an inaccurate picture with out having the original photoshop layers? SVG should be implemented on the server ASAP.--Filthy swine 13:50, 31 May 2006 (PDT)

SVG graphics renderer implementations in browsers are also few and far between. IE (which is unfortunately by far the most commonly used browser) doesn't have one, and many people wouldn't want to download a third-party plugin such as the Adobe SVG Viewer to view the images. --DrBob 14:19, 31 May 2006 (PDT)

This doesn't apply to MediaWiki though; it prerenders a PNG version. Check out commons:Image:Red copyright.svg with IE. Garrett^Talk 14:40, 31 May 2006 (PDT)

I must apologise then. :-( --DrBob 16:03, 31 May 2006 (PDT)

Videos

Will there be support for any video files? Although I'm not for adding obnoxious videos of every level to your guide, there are instances when that could be beneficial. If you are going to enable video files, I would recommend Ogg Theora format for two reasons: it's patent-free, and it's an extra step to take and to worry about, which will probably keep vandals from uploading a lot of porn....

theEXIT ^talk 17:07, 17 May 2006 (CT)

This concept actually does interest me. Some problems that come to mind are bandwidth, overuse, redundancy, and quality. But if we could overcome this, I have no problem with video. Ogg format is definitely the most open one to go with. Another possible idea is streaming FLV to embed directly into the website. --echelon ^talk 23:51, 18 May 2006 (PDT)

I admit that this video business would have to imply certain guidelines. So far, in everything that I've thought about, you hardly need videos over a minute in length, and most of the time, the video is supposed to show a particular tactic that is easier to show than to explain. I know that with the use of images, there is a policy that "each image must serve a purpose," yet truth of the matter is: images help layout (like the little cartoony image of Link and Navi in the OoT guide...) and provide a minor decorative frame of refence. With video content, however, that simply is not the case. I have to say that FLV embedding sounds rather obnoxious, or at least I can immediately see how it CAN be extremely obnoxious in wrong hands. All I'm saying, I guess, is that peer review would be more important than ever in this. TheEXIT 05:40, 19 May 2006 (PDT)

Hmm, if there was some way to embed flash into pages, we could use google video or youtube for walkthroughs like that, without worrying about bandwith. The only problem is people could embed other flash stuff into pages, which would be annoying/destructive, so there would have to be some way to only allow google video/youtube/other video sharing site flash files. --blendmaster 09:55, 21 May 2006 (PDT)

That's a good idea, if their policies about outside linking allow that. It would certainly be possible to design a tagging format whereby {{youtube:mFQz98jAcg8}} would result in an embedded Flash with http://youtube.com/watch?v= already appended to the beginning. Garrett^Talk 13:51, 21 May 2006 (PDT)

Flash is good, but there are many people without it, so it would be good if the proposed "youtube" template also took in the name of an image to which it can fall back if the user's browser doesn't have Flash. --DrBob 13:59, 21 May 2006 (PDT)

I think that most of the video format here should be "the last resort" of communication. In that respect, I see nothing wrong with allowing upload/download of ogg-theora files. I can not say that I support the YouTube implementation of video into guides: it can be very annoying, and it also takes away from the polished visual appeal of the guide. Regardless, I do believe that video-based media ought to be allowed, but I'm also afraid that I've opened a can of worms that could make Walkthroughs here more obnoxious than anywhere else... --TheEXIT 15:43, 21 May 2006 (PDT)

Oh, definitely, inline movies would be awful. The way I see it the movie would instead be in a sidebar with a preview thumbnail. Clicking the YouTube option would unfurl an overlay containing the player, while the download option would link to the Ogg. Garrett^Talk 16:55, 21 May 2006 (PDT)

Hmmm... after experimenting with a quick sample I'm not so sure about using YouTube. The player forces video at 4:3, meaning direct emulator output (such as this) can't be used as-is. I haven't tried Google Video yet, but since they say content might be cut when the beta ends I'd still prefer YouTube. If everything else fails perhaps a custom FLV player supporting dynamic perspective could be made (maintaining the logo overlay, thus being technically identical and not violating their Terms of Use). Garrett^Talk 22:12, 21 May 2006 (PDT)

Google video now has the near instant uploads youtube has, and it has a nicer player that resizes dynamically. As long as they don't delete stuff when they go out of beta (which i haven't heard of until now), then they would be the nicer solution. To avoid unnessecary video, you could make it so embedded videos would require approval from an administrator before put on a guide too. --blendmaster 20:03, 22 May 2006 (PDT)

That's sounding good. And now that I've looked at it again it doesn't say what I thought it did, but instead that the videos have to be approved for inclusion at the end of the beta. To me Google Video looks to be aimed more at being an online video store than a place for your own random clips, but I may just be misunderstanding it. As for overuse, really disruptive videos can be added to the spam blacklist. Garrett^Talk 22:29, 22 May 2006 (PDT)

If we really want to be as open source-strict as Wikipedia, it's best we show our ownly bias into open source. Meaning, we will have to host our own Ogg videos that will be available for download, since hosting our videos on YouTube or Google Video implies the inclusion of closed source software. Remember, SW is the 100% open source alternative to GameFAQs and every other closed source video game site in the world. We need to show them that a video game site, such as a replacement to GameFAQs, can live off of nothing but non-propriety and free code.--Dan 08:36, 26 May 2006 (PDT)

I'm with Dan on this, despite the obvious problems that may arise from hosting the videos. In any case, sooner or later it would have to be implemented. As I've stated before, I don't think that inclusion of any 3rd party video hosting will do much to make this webspace appear more professional. --TheEXIT 02:27, 29 May 2006 (PDT) P.S. Don't hate me for this. :)

Actually, I have no problem with developing our own open source streaming FLV server akin to that of YouTube or Google Video. While the FLV file format isn't open (Macromedia owns it), the videos themselves would be. As would the player/server we use to broadcast and host them--I'd develop it and release it under the GPL. I actually need to develop the program for another gaming website project, so developing it would kill two birds with one stone. And as I stated before, I would want to have the videos hosted in FLV *AND* Ogg, and neither would be inline. ech elon 22:48, 31 May 2006 (PDT)

Well, look what i found. --blendmaster 20:41, 5 June 2006 (PDT)

Screenshots

What is the situation on screenshots. For one reason or another I know wikipedia doesn't like having a lot of screens in a page, but I think having plenty (although not a huge amount) of images in a guide is extremly useful. Is there some legal restriction which caused wikipedia's stance which is related to the GNU FDL license that you share with them? Or is it a site-specific decision?

I'm just wondering because I recently saw about a dozen (small) GTA images uploaded which will be used on a guide I presume, and I was thinking that I might want to break out my Super Mario World and throw in screenshots for the tricky parts of the game, and that's just one example. Since FFVII will probably be imported I won't be able to do a lot with it (although I did have several edits to it at wikibooks :)), but there are a bunch of other games I already saw that I could add to. And maybe I can help you guys structure the site a little better? I've had experience on a SporeWiki.com where I am a Bureaucrat, and when I first arrived there I completly revamped the organization scheme, so I think I can helpful in that as well. But I'm particularly interested on your ideas on screenshots, so let me know. Mason11987 17:55, 24 April 2006 (PDT)

Wikipedia's screenshot restriction was centered around the very touchy concept of "fair" use for educational purposes. A strategy guide is generally considered stronger fair use than an encyclopedia as the whole work is basically showing how cool the game in question is. As long as the screenshots have a clear purpose and aren't just to look pretty it should be fine. Anyway it's good to have others with experience around. Besides, I don't see any company complaining against fansites hosting quadrillions of images... :) Garrett^Talk 19:53, 24 April 2006 (PDT)

Awesome, thanks for clearing that up :). Mason11987 12:27, 25 April 2006 (PDT)

I'd definitely think that as long as the screenshot is relevant, and you don't overdo it, it'll fall under Fair Use. Hell, people have even done video walkthroughs - those're what, 24 screenshots per second? --aniki21 03:14, 27 April 2006 (PDT)

As I have come to realize, the only reason "fair use" is a problem at Wikipedia is because of the GFDL's restrictions on fair use. A Creative Commons or BSD project would probably render this problem moot. --echelon ^talk 11:17, 14 May 2006 (PDT)

Although this isn't directly connected with screenshots, I wonder if anyone would mind using their singled out images of manuals and/or boxes? Does credit need to be given in the first place, despite the fair use clause? To top it off, the copyright of the original image would belong to the company (whom as Garrett pointed out would be the least likely ones to mind), yet can any fan site legitimately claim that the box art that they've scanned is somehow theirs? If not legally, what would a gentleman do? --theEXIT ^talk 00:02, 17 Mat 2006 (CT)

Input needed

Input needed in three places: Category talk:Nintendo DS, Category talk:Game Boy Advance, and Category talk:Game Boy. -- Mason11987 ^{(Talk - Contributions)} 17:02, 25 April 2006 (PDT)

Intro Pages

In Favor of eliminating intro pages/merging them with the table of contents

For - The intro pages, while they look nice, serve no immediate benefit to the reader. They do not improve organization (as having multiple pages does) and they do not make it easier to find information. Everything in a wiki designed for strategy guides should revolve around the easiest and most complete way of guiding the users of the wiki. In that sense if a piece of the wiki would better benefit the user if it were changed, then it should be so, especially if it is no great burden to the editors (in this sense, it would take LESS work to make intro-less guides). So I see no reason for intro pages to exist and I think the first page of a guide should have a brief intro of the game, and a set of as many other useful links as possible, organized as well as possible. -- Mason11987 ^{(Talk - Contributions)} 13:14, 11 May 2006 (PDT)

For - Mason said it well. Having to click through intro screens is poor web design. You should scroll down to see more content, not have to navigate to another site which has the content you actually want to see. The first page of a guide should be like a portal, linking you to all the places you might want to visit, and providing some information to make that process easier.--BigCow 15:29, 11 May 2006 (PDT)

For - yeah, pretty but pointless. {{All Game Nav}} may become a little empty though... unless the game name and Table of Contents both link to the guide's main page. Garrett^Talk 23:35, 11 May 2006 (PDT)

I've made a slight adjustment to {{Template:All Game Nav}} in the form of {{Template:All Nav}}. It looks a little shorter, but it's not too bad. I guess if there's anything else that should be included on every multi-page guide, you could add it in. I can't think of any other "default" links at the moment, though. --aniki21 03:38, 1 June 2006 (PDT)

For - I never actually saw the point in them, honestly. Cosmo 07:29, 12 May 2006 (PDT)

For - works good for the super smash bros melee page: Super Smash Bros. Melee. --blendmaster 13:26, 13 May 2006 (PDT)

For - Not only have you proved to me that these are redundant, but I have just realized that we may actually want to host more than one type of guide. (I'll start a new topic for this in a moment.) --echelon ^talk 22:49, 13 May 2006 (PDT)

For - It used to be utterly painful to scroll through countless pages of plain text guides only to get to the beginning of the walkthrough. I utterly hated the ones that also include all the character bios, bestiaries, and whatever else BEFORE the actual walkthrough (the appendices are where it's at). It seems, however, that this sort of practice is standard, and I tried my best including some game information there that I would not be able to include otherwise. Perhaps we can include some sort of Appendices tag for {{All Game Nav}} so that people could use that to store side quests and whatnot instead? --theEXIT ^talk 00:15, 17 May 2006 (CT)

For - I've played around with the layout of the front page on my Shenmue guide, and I've come round to the idea of combining the TOC and "cover" page. --aniki21 05:59, 31 May 2006 (PDT)

For - I like the idea of merging the title page with the TOC. Not only will it help with navigation (and less clicks), but will allow the reader to access any section of the guide right away. -- Ryan Schmidt 17:21, 31 May 2006 (CT)

For - Agreeing with you. Anything else is just stupid and unneeded. --Sekoku 09:18, 4 June 2006 (PDT)

For - As a new user, I'm already tired of going through that splash page whenever I follow the main game link on top of an article. --Veldig 14:27, 5 June 2006 (PDT)

Opposed

Against: I like the flow that a "cover page" gives the multi-page guides. I can't think of any arguments that might convince all the For votes above that they're worth keeping, though. I just think it might end up cluttering the first page of the guides. If we're going to cut out the covers, what page should the guides start with? --aniki21 06:29, 30 May 2006 (PDT)

Lets take for example our "example" guide Z:OoT, at the moment the front page DOES look a little bland, but in the talk page we were discussion merging the rements of the cover page/TOC with the intro page for one page that briefly describes the game, has it's infobox on the right, and has the TOC running down the left. That way people click on Z:OoT and they get some small bits about the game, as well as some of it's infobox traits (both things that someone looking for a guide probably isn't TOO concerned about) as well as a TOC which I'm sure we can all agree is the MOST useful piece of navigation information a guide can have. If someone is coming here for guides (that's who we WANT to come here), they want to find their game, then quickly find the section they need help in. Having an intro page is a pretty addition, but it only makes someone pause for some amount of time before they get to the info they actually want. I think a page should be mildly cluttered if it is very useful. And of course organization is key in that kind of situation to make the clutter as mild as possible. -- Mason11987 ^{(Talk - Contributions)} 11:47, 30 May 2006 (PDT)

I've rearranged my Shenmue frontpage, and I've kinda come round to the idea of combining the cover and table of contents. Changing my vote to For. -aniki21 05:55, 31 May 2006 (PDT)

Undecided

~~As of right now, I must say that I am wholly undecided on this issue. I am awaiting arguments from both sides. --echelon ^talk 12:16, 11 May 2006 (PDT)~~
- My vote changed to for. --echelon ^talk 22:50, 13 May 2006 (PDT)

I used Template:Cover in NetHack because Zelda: Ocarina of Time is using it. It works somewhat well because clicking the image leads to the table of contents (TOC). I would like to just keep having separate covers and TOCs, but there are benefits to having one page as Super Smash Bros. Melee does, and if covers and TOCs do remain separate, we might want to add more links on the covers. --Kernigh 14:00, 13 May 2006 (PDT)

Multiple types of guides

I was just thinking about the possibility of hosting multiple guide types. Many at Gamefaqs have criticized this project for not supporting more than one type of guide. Though I still stand completely firm about no redundancy in this project whatsoever, I can imagine different types of walkthroughs being made. For example, there might be a speed run walkthrough to supplement the regular one. I do not see these as repeating anything, but simply "branching" from the main guide. What do you think? If we do implement this, it may require we change some things about our URL and article naming policy. --echelon ^talk 22:57, 13 May 2006 (PDT)

It'll be kind of an inevitability if the site gets popular enough that people will have more than one type of content they'd want to host, but I think that could still be handled with one main guide. Consider the typical types of guides featured on GameFAQs:

Boss FAQs/Strategy FAQs against the weapons in FF7 for example: covered under our system, since we have more sub-pages than just a walkthrough.
MiniGame Guide: Same thing, see the imported Final Fantasy VII guide.
Game Script: These would actually be nice to have, but they could work as sort of an "Additional Content" thing under the main guide, kind of like a Plot FAQ again.
Specific Character Guides for fighting games like smash bros, same kind of thing
Maps/Charts: Integrated into the walkthroughs or given their own section
Speed Run/Low Level Guides: these are the hardest since they're often a complete departure from a normal walkthrough, and they can be an entire walkthrough of the game with a specific goal in mind. I'd prefer to give them their own section underneath the main guide, as in something like Chrono Trigger/Speed Run/Introduction or something similar. Basically make them a subpage.

The main problem we might have is that people might have very conflicting strategies for a game like Starcraft, or even something like Final Fantasy VIII about the best tactics to use or way to build levels. In some cases we may just need to list multiple strategies or link to different pages which describe different approaches, a Starcraft Guide might have some sub guides on teching, rushing your opponent early, etc.

Our table of contents could read like a complete GameFaqs list of guides, with the advantage of having no redundancy. They would link Plot FAQs and Boss FAQs as separate guides, we'd just consider them to be a part of a single complete guide.--BigCow 00:30, 14 May 2006 (PDT)

Game scripts would be another good idea, but that's not possible under the GFDL (where all content must be either GFDL or the precarious "fair use"). Changing to CC-BY-SA would free up multi-licensing some. Garrett^Talk 03:39, 14 May 2006 (PDT)

I don't think there's any need for more than one guide hub though. Maybe a separate TOC for each walkthrough type, but certainly not a completely separate guide. Supages make that unnecessary. Garrett^Talk 03:37, 14 May 2006 (PDT)

Yeah, I so no need for something like Metroid Fusion (speed run) and Metroid Fusion (1% run) at all, when they can be subpages, as Garrett said. I was thinking of implementing those after I finished my work on MF, as optional quests towards the bottom of the TOC. Cosmo

(I've also added seperate map pages within the guide for things like getting 100%.) Cosmo

I am really new to wiki scripting, but since we have multiple pages with tags everywhere, is there a way to use a command similar to php "include" so that you could pull bits and pieces from a page? For instance, in a game like Zelda, a person may wish to create a little floating blue box page per every Boss (with strategy to beat him), and then simply include them in various files, sorta like the Category tags work. Except instead of providing mere links to a page, it would pull out every boss in order and put it in a nice guide (perhaps even with it's own navigation, etc.) Similar ideas could be applied to everything, so then the information would be stored as pure data, and then TOC would contain every viable option to view that information in a sorted manner... I don't know if that's possible to do with the way Wiki stores things, though. --theEXIT ^talk 00:24 May 17, 2006 (CT)

The easiest way is to transclude a page like a template, e.g. {{:Zelda: Ocarina of Time/Ganondorf}}. Note the : before the page name, without this it'll look in the Template: namespace. You can see this in action at BS Zelda: Kodai no Sekiban/Printable version. This page has no real content of its own, meaning it only has to be updated when an entirely new page is added to the guide.

For really fancy results you can tag parts of a page that are not to be included (<noinclude>) or else are shown only when included (<includeonly>). You can see this demonstrated rather confusingly at this source page vs. this target page. The first has all the text, but due to the mixed tagging each page has its own unique links.

Wikipedia's Navigation popups use a fancy Javascript method to extract a chosen section but I haven't looked into it. For most purposes the other two methods should be sufficient. Garrett^Talk 16:19, 17 May 2006 (PDT)

I've thought about that... But Templates are designed for something else entirely. Despite the fact that you can create {{{Template:GAME_NAME/BOSS_GUIDE/BOSS_NAME}}} it would get confusing quickly. For that very reason I chose to copy/paste my own 'custom' navigation bar with "elite" (pun intended) icons throughout my SQ3 guide. I guess there is no other way, really, to include such pages. Perhaps if the community could decide on a global format for certain data output (like for bosses), the Wiki could be better "suited" to fit our needs. Thanks for the JavaScript link, however... I'll investigate that. --theEXIT ^talk

Panoramic screenshots

I made a couple of panoramic screenshots using GoCubic for the Counter-Strike: Source pages. However, every time I try to upload them, I get given a '".mov" is not a recommended image file format.' error message, and I can proceed no further. I think it would be a good thing if people were allowed to upload .mov files, as then the wiki would benefit from panoramic screenshots for games, which really do help show the reader what the level's like. --DrBob 12:58, 17 May 2006 (PDT)

Actually ".mov" is only a container format for various "codecs" of video, audio, image, and text streams; it can contain everything from raw, uncompressed "digital video" streams and linear audio (which use huge amounts of storage) through to MPEG4 format (which compresses well but has patent issues). Thus any decision to allow .mov files would involve the question of which codecs to allow. --Kernigh 22:41, 17 May 2006 (PDT)

This then moves into the "videos" discussion below, but I do think it would be of real use to the wiki if panoramic screenshots were allowed. --DrBob 15:10, 19 May 2006 (PDT)

DrBob, I agree that this could be of a real potential use. If you wouldn't mind, do you think you could create a demonstration to show us exactly how it could be applied to Counter-Strike: Source? I am not certain whether "panoramic screenshots" or downloadable ogg videos or embeded FLV (like Google Video) is better, so it would be great if we could see a demonstration of each technology in use. It may be that we will come to use a combination of two or more of them. ech elon 22:01, 19 May 2006 (PDT)

Even if we do offer FLVs there should still be a downloadable equivalent. It would be great to watch part of a solution while the rest is downloading, and then refer to it later without having to return to the site and wait for the part you've already watched to load all over again before you get to something new. Garrett^Talk 22:47, 19 May 2006 (PDT)

I've put two sample panoramic screenshots up on my site: inside and outside views of Counter-Strike: Source/cs_assault. They're 512px by 512px, which is probably about the right size for the wiki (you can't easily make larger ones in Counter-Strike: Source anyway). :-) --DrBob 06:10, 20 May 2006 (PDT)

This is a very original idea, I love it. However, there is one flaw that's just killing me. QuickTime is closed source. If we could find an open source paranormic viewer, preferably in Javascript (is that possible?), I see no reason why we shouldn't do this.--Dan 11:37, 26 May 2006 (PDT)

The goal of this wiki (for me) is to be the best. OSS is good (and I personally love it), but the only alternative to QTVR I could find was SPi-V, which is Shockwave, and costs money. QTVR is decent, and if you don't want to use the official QuickTime player, OSS movie players such as Totem can decode the file and play it as a conventional movie. Writing a viewer in Javascript is a completely implausible idea: Javascript was never designed for rendering images in 3D, and neither were browsers, so the clipping and image distortion functionality needed to implement one isn't available for Javascript. My vote goes for QTVR. --DrBob 12:09, 26 May 2006 (PDT)

Zelda OOT

Talk:Zelda: Ocarina of Time I'd like some comments about potential merger of the cover and TOC pages. -- Mason11987 ^{(Talk - Contributions)} 14:41, 23 May 2006 (PDT)

I do have an idea for that, but we'd first have to solve the the issue of navigation. See the new post I made. ech elon 22:16, 25 May 2006 (PDT)

Icons

I think there should be some kind of "icon" system in place for in-guide links. Each link could have a small template before it which displays a small "icon" image which shows what that link is for. For instance, in the LOZ:OOT link Zelda: Ocarina of Time/The Beginning there is this section:

== Welcome to the Kokiri Forest! == {{big|L}}ink, our young hero, is the only boy in the Kokiri village without a fairy. Suddenly he is awakened from a particularly disturbing nightmare to find a fairy in his room. The fairy, exasperated, beckons Link to come with it to the '''[[Zelda: Ocarina of Time/The Great Deku Tree|Great Deku Tree]]''', in order that he would hear important, if not urgent, news. The young boy bursts through the doors of his home, only to be greeted by '''[[Zelda: Ocarina of Time/Saria|Saria]]''', his childhood friend. She is overjoyed that Link has finally gotten a fairy of his own, but Link knows deep inside that this was not to be the happy day his friends would expect it to be. The jealous '''[[Zelda: Ocarina of Time/Mido|Mido]]''' will do his best to make sure of that too. Shocked inexplicably by the apparent favor that both Saria and the Great Deku Tree have shown to Link, he will do everything in his power to prevent you from seeing the great tree. He insists that you must have both a sword and a shield before you can pass. What a jealous fellow, indeed! == Getting past Mido == Clearly, this portion of the game was designed in order for you to become accustomed to the controls. Fortunately, this is unlike almost any other in-game tutorial out there: it's fun. Already, you have been presented with a problem—that Mido is blocking your way—and now you must set out to find a solution. You will need to find the '''[[Zelda: Ocarina of Time/Kokiri Sword|Kokiri Sword]]''' and the '''[[Zelda: Ocarina of Time/Deku Shield|Deku Shield]]'''. While you can get the items in any order, [[#Getting the Sword|getting the sword]] first may help you acquire the 40 Rupees necessary to [[#Getting the Shield|purchase the shield]].

I think it would be useful before the Saria and Mido if there was {{npcicon}} which would let you know that that is an NPC, and would link to an NPC page. (Or enemy, or friend page). Also, for the Kokiri Sword and the Deku Shield links, maybe little {{swordicon}} or {{weaponicon}} and {{shieldicon}} to symbolize what they are. In certain games (FF in particular) this would be very useful. That's because the guide could say you picked up a Gyshal Green in a chest or on the ground, and the since we aren't going to have a Gyshal Green page, we could just have that icon to let you know that that is an Item and the link would lead to an item list page or something. I think this would be especially cool because it would liven up the pages and allow for more information in less space when listing tresures that could be found somewhere or things like that. I don't know exactly what images we'd use or anything like that, but I thought it would be fun and useful. I saw it used very well in an awesome FFVII guide (far better then the wikibooks one) I'll just have to find that to show what I mean. It doesn't need to general templates for all guides, they can definitly be specific if there is a need (like deep rpgs might need their own set), but I think it'd be worth it to try to make things like that. Red links in the "feature guide" isn't really a good thing and while just changing it to the weapons page would be useful, this might be an extra touch that differentiates this site from other game guide sites. -- Mason11987 ^{(Talk - Contributions)} 19:17, 23 May 2006 (PDT)

Do you mean something about the size of the icon next to my username to designate what the link is? ech elon 22:10, 25 May 2006 (PDT)

I am fairly certain that's what he means, but I am sort of on the fence about this. On one hand, it would look really great. On the other, it may be difficult to do for some guides, and not all writers may be spriters on the side. I'll wait for more input from other users before making a real decision. Cosmo _talk

Upgrade Completed! Now our next problem...

We're now running on MediaWiki 1.6.6! You can now use default values in templates. On this note, I need to bring up a potential problem: Our database has grown quite large, and it's difficult to easily manage. While this server has a ton of space available to use, I am getting archive errors every time I try to tar the database. In fact, the database dumps themselves might be to blame; I am not sure mysqldump is handling it correctly. I have tried both with and without the --hex-blob parameter. Any suggestions? ech elon 22:14, 26 May 2006 (PDT)

New community portal

Aside from the big task of finding a solution to the intro pages we unanimously voted to remove, I would also like to bring attention to the community portal. I was growing tired with how outdated it was, since with most wikis the portal serves as a valuable information resource and collaboration tool. I think that we should take advangage of it. By emulating Wikibook's model, the page can serve to host a "collaboration of the month", list "wanted guides", and introduce new users to StrategyWiki. Any thoughts and opinions on this? ech elon 22:20, 26 May 2006 (PDT)

Requests for help in articles

As I've been going through sorting out categorisation issues, I've found quite a few articles have their own non-standard requests for help, pointers to the editing guidelines, and lists of contributors. I think this is quite poor; it takes the attention away from the article itself, and isn't standardised. Articles like this should be using the wip template, but perhaps it isn't helpful enough to persuade potential contributors to improve the page? Regardless, I think articles like this and this (at the bottom) should be changed and standardised. --DrBob 12:37, 27 May 2006 (PDT)

New collaboration of the week

May I suggest that we get everything categorised as a collaboration of the week? Half the games don't have any categories, and the other half aren't fully categorised. One major thing which needs to be done is to add multiplayer or single player categories to every game (either, or both; depending on what the game is like). If this goes ahead, it should be added to the main page. --DrBob 07:11, 30 May 2006 (PDT)

DrBob, categorization would be made much simpler if template:infobox.new enabled inputing multiple genres in the {{genre}} value. I'm trying to learn wiki markup language as much as possible, but there are a few things I don't quite understand. Right now, I'm stuck on how the arrays are structured.

(^--That was Filthy Swine. Please sign your comments in future.) Whatever's put into the page's Template:infobox (or Template:infobox.new) template doesn't categorise it; it just links to the specified page. Categorisation is performed by putting [[Category:Category name]] links at the bottom of pages (note the lack of preceding colon). This includes a page in the specified category, and is what I was talking about. Of course, if you add a category to the bottom of the page, chances are that it should also be linked to in the appropriate place in the Template:infobox, but for that we just use comma-separation, and that's why Template:infobox.new won't work, because in its present state it only allows a link to one category for each heading. --DrBob 01:35, 31 May 2006 (PDT)

I'd have to agree with DrBob. It's a clever idea but it doesn't allow multiple values. Another way to streamline would be a template ({{cat|Whatever Category}}) that expands to [[:Category:Whatever Category|]][[Category:Whatever Category]]. However a major problem with both of these methods is that the infobox is often on a subpage, meaning the automatic categories would be categorising the wrong page. Garrett^Talk 04:31, 31 May 2006 (PDT)

Image Categories

I finally got my wish and now we have a dynamic home page, but unfortunately I didn't forsee the next problem with it: we've run out of images. Not uploaded images, mind you, just images ready to be used. This is bad, as it makes us look empty, irresponsible, lazy, etc. The obvious reason is that users aren't updating the front page; which is not unexpected. But I suspect another as well: lack of organization on our parts.

The Image list is incredibly hard to read, and pretty much never tells you anything you need or want to know. After going through a thousand .gif's of maps for one game that I don't even know the name of looking for game artwork, without knowing what I was clicking on next due to non-descript filenames, I devised a solution.

Images need categories too. They could be any of these: screenshots, game artwork, map, box art, or item. This could help out those who choose front page images out a great deal. There should also be a field when a file is uploaded to add the name of the game it came from, so that when someone goes through the Image list they can see that "such and such image is from this game and is this type." Perhaps even a search function could be implemented, so that users could search for specific categories/games/systems.

I just wanted to know your guys' thoughts on this. I hope that was coherent. Cosmo _{let's chat}

I would agree with categorising the images, but I can't see the necessity for hacking MediaWiki to add stuff to the image upload system. We could change the language strings to encourage people to name images responsibly, and encourage them to link back to the game for which the image has been taken, but hacking MediaWiki's too much. Personally, I've been prefixing all my images for Counter-Strike: Source with "css_", to separate them from everything else, and it works nicely. :-) --DrBob 14:15, 2 June 2006 (PDT)

I was unaware doing some of that would require hacking MediaWiki, so I suppose some of that is now out of the question. I've also named my images things like "mf-bleh" or "metroidfusion-file" to seperate them. Cosmo _{let's chat}

Another possibility is using an external image rotator so there's a different picture every time you visit, however that of course doesn't allow captions. Garrett^Talk 15:22, 2 June 2006 (PDT)

I can't figure out how to get the captions working on the front page anyways! XD Cosmo _{let's chat}

OK, check out this image. Thanks to an obscure MediaWiki feature thumbnails are able to be automatically generated and sourced by this outside rotator. The images have to be manually added to the rotator, BUT the rotation time can be set for as little as a minute or as long as a week. However the lack of captions or hyperlinks is still a setback to this method. Garrett^Talk 16:08, 2 June 2006 (PDT)

Well, you CAN categorize images. We have a a system of image galleries at sporewiki shown here which rely on categories. The same can be done here, just make the naming the same as the game. If there is a game guide for Zelda: Ocarina of Time then create a Category:. Zelda: Ocarina of Time images that all of the images related to that game are placed in. You can create other categorizations with maps and such by just adding them to Category:Map images or anything like that. It creates a fairly easy to view display so you can fine the good ones easily. And of course the cats can have categories as well. That would be quite a task, but starting off a basic sorting program for images is a good start. -- Mason11987 ^{(Talk - Contributions)} 18:55, 2 June 2006 (PDT)

That would be really helpful, but we would need a lot of people to help us categorize everything... I wonder if we could send out an email asking users to come back and categorize any images they uploaded? Cosmo _{let's chat}

Aniki21 has started already without waiting for anybody. :-P He's using Category:Character art (character renders, etc.) and Category:Game art (covers, posters, etc.). I think these are reasonable enough to be made official. --DrBob (Talk) 11:31, 6 June 2006 (PDT)

Perhaps a more neutral "Game images" cat would be better? Just tossing it out there. -- Mason11987 ^{(Talk - Contributions)} 20:04, 6 June 2006 (PDT)

That's a bit ambiguous to me. 90% of the images we're uploading will be game images. --DrBob (Talk) 23:01, 6 June 2006 (PDT)

True, but I meant more along the lines of "images" instead of "art" for stuff like that? Like map images, or character images.

Maybe Category:Game art should be Category:Cover art or Category:Game covers... Game art just seems a bit ambiguous to me.--Dukeruckley

I still think we should just use something like screenshots, game artwork, map, box art, or item for categories. It would be precise and easy. Cosmo _{let's chat}

Date Format

Should we start enacting the wikipedia standard operating posistion of linking Dates(game development, releases et al)? --Filthy swine 06:36, 7 June 2006 (PDT)

"Linking dates may not seem useful; however, please link dates since it enables the use of a user preference in how dates are displayed. An unlinked date, like July 13, 2004, will always be displayed in that manner. If you link the date:

[[July 13]], [[2004]]

Wikipedia will display it in one of the following ways:

July 13, 2004

13 July 2004

2004 July 13

2004-07-13

-according to the preference set by the individual user. (This feature is only available to logged-in users. It only works if the date is linked.)"

That might not be a bad idea. The only problem then is that we have a bunch of linked dates that go nowhere, unless we decide to make pages for them (which I'd say we don't need). Too bad there's no way to allow user preferences to come into effect without linking the dates (unless my understanding is wrong).--Dukeruckley 08:14, 7 June 2006 (PDT)

Board Games

Currently, StrategyWiki is pretty much solely for video and computer games. Are we open to create pages on board games and puzzles as well? For example, I might be interested in starting a Rubik's Cube page. Someone might be interested in a Chess page. Any thoughts? --Dukeruckley 09:58, 7 June 2006 (PDT)

I'm not an official person, but I don't think StrategyWiki is intended for things like that; it's based around video and computer games, and there are other places on the Internet which deal for board games. Let's see what echelon says when he gets back. :-) --DrBob (Talk) 11:22, 7 June 2006 (PDT)

The opening sentence on the main page says the purpose of this site;

"Welcome to StrategyWiki a collaborative wiki that seeks to become the largest source for videogame strategy guides!"

but I wouldn't be opposed to having non-video games. A strategy guide for poker would have relevence in real life as well as a video game of poker. As for the Rubik's Cube, a good Rubik's cube strategy guide is needed to solve it as fast as this guy

Note: my apologies for those of you that can't view a couple of those sites because of Flash issues, but until SVG is shown more support and improved on, it is sometimes the easiest way to do things on the interweb.

--Filthy swine 12:47, 7 June 2006 (PDT)

To clarify myself. There are many sites out there for Rubik's Cube strategies, but not many with multiple strategies. I was hoping to throw them all together in one site (and my idea was to do so here). I would hate to have to find another site that I find respectable or create my own. Plus, this wiki would provide an easy way to upload images of the cube to give a visual representation of an algorithm.

While the site does mention that it is for video games, I see more benefits to adding board games than not. There are many places to find guides for video games and less so for board games and puzzles. Adding these could potentially lead to more people joining StrategyWiki in the long run. Meanwhile, as long as someone updates them and turns them into respectable articles, is there a reason not to add them to the site?--Dukeruckley 13:00, 7 June 2006 (PDT)

I am pretty much against the whole thing - I find it unnecassary for a videogame wiki. Cosmo _{let's chat} 13:16, 7 June 2006 (PDT)