Talk:Grand Theft Auto: San Andreas

Welcome to the discussion page for the wiki book Grand Theft Auto: San Andreas. To mininize editing conflicts, use the + button at the top of the page, rather than the edit this page button.

Historical

 * This walkthrough needs more work including screenshots and maps. --24.59.197.201 17:11, 8 Nov 2004 (UTC)


 * Please, add as you see fit. This books needs a lot of filling out.  As it is a highly popular game, a good walkthrough here might encourage similar work with other games.  --Alpharigel 22:40, 9 Nov 2004 (UTC)


 * I'm delighted to see someone else is actual concern about the game guides, i'll try to give you a hand with the gta guide, and develkop a standard format. --CGorman 16:05, 12 Nov 2004 (UTC)


 * I suggest we wait untill the PC version to take screenshots. --142.46.130.26 00:45, 23 May 2005


 * Added FAQ sub-page. Tidied this page, and added some proposed style guidelines. --Aya 15:48, 14 Jun 2005 (UTC)


 * Added font-formatting explanation. --Master Thief Garrett 03:07, 15 Jun 2005 (UTC)


 * Added more FAQ content. Major changes to this page. --Aya 17:20, 15 Jun 2005 (UTC)


 * Moved contents from the main page to its own page, and added all active pages to it, in an effort to keep track of what content we have already. More major changes to this page. --Aya 21:35, 15 Jun 2005 (UTC)

Mission page renaming
The mission pages are getting ridiculously long names. Like Grand Theft Auto: San Andreas: Sean "Sweet" Johnson I.

Then if Aya makes his individual mission pages we'll have even *longer* names.

What I suggest is that we have pages named like Grand Theft Auto: San Andreas: Missions: Sweet: Mission Here. Short and simple. We don't need the person's surnames etc., just the main name used for them. Similarly, the character page for him would be Grand Theft Auto: San Andreas: Characters: Sweet.

That is if we change Grand Theft Auto >> GTA for the longer page names of course. But they definitely need to be threaded together somehow, and not just by the character. Master Thief Garrett 01:51, 16 Jun 2005 (UTC)

UPDATE: upon further investigation of the Wikibooks mechanics, shortening the name is not advisable as those pages would be "orphaned" from the actual namespace. Master Thief Garrett 03:09, 16 Jun 2005 (UTC)

Re: Mission page renaming
I'm worried (although no-one else seems to be) about namespace collisions across the whole Wikibooks site. Some Wikibooks have taken extremely common page names like Appendix in the global namespace.

I figured it would be polite to minimise this 'pollution' by ensuring a consistent prefix which is guaranteed never to collide with anything else. I don't see a big problem if we at least keep the global prefix as per the above standards, especially considering every page so far already uses that convention. Bear in mind that I initially wrote the standards based on what was convention at the time. Much easier than changing all existing content to meet a new set of standards.

Regarding new mission pages (if I ever get around to it), I was considering dropping the name of the mission 'boss' from the page name completely. I want to minimise the number of pages containing indices, since these need to be updated if any page names change, so I'm just thinking of a separate content-page for each significant concept, and one HUGE contents page to index it.

As far as I can see there are two choices:


 * Use separate namespaces
 * Use disambiguation where necessary

The former will produce pages named:


 * Grand Theft Auto: San Andreas: Mission: Ryder
 * Grand Theft Auto: San Andreas: Character: Ryder
 * Grand Theft Auto: San Andreas: Vehicle: Infernus

And the latter:


 * Grand Theft Auto: San Andreas: Ryder (mission)
 * Grand Theft Auto: San Andreas: Ryder (character)
 * Grand Theft Auto: San Andreas: Infernus

Personally I find the former slightly neater, but I'm fairly easy either way. Aya 03:16, 16 Jun 2005 (UTC)


 * The advantage of the first method is that you can see where a page is "housed" without brackets. Also it creates "clean" URLs, for example "Grand_Theft_Auto:_San_Andreas:_Contents" as opposed to "Grand_Theft_Auto:_San_Andreas:%28Contents%29".
 * Also a visitor who comes across a URL leading to "Grand Theft Auto: San Andreas/Vehicles/Infernus" can cut off the car name to get Grand Theft Auto: San Andreas/Vehicles, whereas if they decided that "Grand Theft Auto: San Andreas: Ryder" would lead to a core page they would instead get an error. Nothing major, but might as well make it as foolproof as possible IMO.
 * Note the slashes instead of colons, this makes it a lot easier. Look at Grand Theft Auto: San Andreas/Vehicles/Vehicle Missions, it automatically generates a mini-navigation list. Also for the technical side of things this threads the pages together, whereas with colons it treats the other bits as if they are sub-books and does not attach them to the preceding "directory" they contain like it does with the slashes. Master Thief Garrett 05:23, 16 Jun 2005 (UTC)
 * The problem with not having boss subpages is that things can be revealed too soon. Right now the table of contents lists all the boss names; this could potentially spoil it for someone who hadn't got that far. So perhaps we should at the least have the region subpages, so you'd go to "Grand Theft Auto: San Andreas: Missions: Los Santos: Ryder". That way only by clicking through to the region page would the bosses' identities be revealed. Not ideal, but the original goal of this Wikibook was that the layout be as accidental-spoiler-free as possible. Master Thief Garrett 05:30, 16 Jun 2005 (UTC)

Once more, from the top
Okay. I think we both have different interpretations of what Wikibooks actually is, and the most effective means of using it. I guess it was rather a dumb idea of mine to choose some standards without adequately justifying those choices. This almost always fails to produce standards which get adhered to, in any system where people are not rewarded for following said standards. e.g. In a company, you get paid money to follow their rules. On a wiki there is no obvious financial reward at all. But I hope you at least agree that standards are important on collaborative projects, if only to the extent that we interpret language in the same way. i.e. We share a common 'dictionary'.

For what it's worth, I'm a 28-year-old software developer, and during some of the projects I've had to 'endure', I came across various pitfalls of the processes commonly used within those projects. Most of these don't really pertain to wiki, but some do. I also fairly new to the wiki community, but I really like the idea, because it does to information what web-forums and newsgroups can only dream of.

The dangers of page naming
I've finally read through all the material I can find about page name delimiters, and I'll just summarise what I've found here:

N.B. I use the character '*' to represent any amount of whitespace, including no whitespace. Valid whitespace characters seem to be: '_' and '%20', but not ' ', since this is an illegal character in a URL. All browsers convert it to '%20'.

page name -> wiki interpretation

"*GTASA*" -> a page in the global namespace named "GTASA"

"*Talk*:*GTASA*" -> a page in the "Talk" namespace named "GTASA"

"*GTASA:Ryder*" -> a page in the global namespace named "GTASA:Ryder"

"*GTASA:_Ryder*" -> a page in the global namespace named "GTASA:_Ryder"

"*GTASA/Ryder*" -> a page in the global namespace named "GTASA/Ryder". Provides a link to "GTASA"

"*GTASA/_Ryder*" -> a page in the global namespace named "GTASA/_Ryder". Provides a link to "GTASA"

"*GTASA_/_Ryder*" -> a page in the global namespace named "GTASA_/_Ryder". Provides a link to "GTASA"

Notice the last three are conceptually identical, but will return three different pages. Not really what we want.

The dangers of hierarchies
Hierarchies are probably most familiar in things like URLs. The idea is to use them when something is conceptually a 'child' element of another element. This is great for some applications, but the problem is that with a bunch of disparate concepts, as you might find in a guide for GTA:SA, it's nigh impossible to get everyone to agree which means of arranging things in a hierarchy is best.

e.g. I noticed above that the page 'Vehicle Missions' is a child of the 'Vehicles' page, whereas since it's ultimately talking about missions, and not vehicles, I might have decided to make it a child of the 'Missions' page.

The same is true for most classification schemes. Let's take an example for movies. If I decide on some categories like 'Action', 'Drama', 'Comedy', 'Horror', 'Sci-Fi', etc.

The problem now is that when I want to add a movie to one of these categories, which one should I choose? The movie 'Pulp Fiction' surely belongs to more than one of these categories.

The error here is defining categories which are not mutually-exclusive. A good example of categories might be 'A', 'B', 'C', etc., in which case, there could be little argument that the movie 'Pulp Fiction' should belong in the 'P' category.

Categories also fail where the category names are poorly defined, as they are right now.

Furthermore the hierarchy might change as new content is added, and if this hierarchy is included in the page name, then the page name will have to change also. From my experience, it's a lot easier to change the content of a page, than it is to change the page's name.

Another problem with using the '/' notation is the implication that the parent node MUST exist. I might want to have a page "foo/bar", but not a page "foo".

Conclusions
To avoid confusion, I shall define the following terms:


 * bookshelf:Conceptially, an index of one of more categories of books on Wikibooks.
 * book:This is perhaps analagous to a paper book. This book may belong to any number of bookshelves.
 * page:This is perhaps analagous to a chapter in a paper book. Note that one of the design goals of Wikibooks was to allow many books to share the same pages. e.g. Most of the Wikibooks relating to computer programming, tend to include the global page containing the ASCII chart.
 * page name:The suffix of the URL used to retrieve a page. i.e. http://en.wikibooks.org/wiki/ page name. Note that many similar suffices may be used to reference the same page, so I shall define it to mean the shortest suffix required to retrieve the page.
 * content page:Conceptually, perhaps, a leaf-node page which contains mostly useful content pertaining to its page name.
 * index page:A page whose primary reason for existence is to provide an index to other pages. The index could be hierarchical, alphabetical, or whatever. A bookshelf page is an example of such a page.


 * Use page names solely to uniquely identify discrete concepts within the scope of the book. They should not be used to denote hierarchy.
 * Keep the page names as short as possible, while making every effort to avoid namespace collision, by using scoping or disambiguation where necessary.
 * To provide a hierarchical model of all the content pages relevant to the book, use an index page to index the existing content. This is the current purpose of the 'Contents' page. If the conceptual hierarchy should need to change, you only need to modify that one page. This also allows you to apply multiple conceptual models to the same information, simply by having multiple index pages. e.g. the 'Index' page will ultimately provide an alphabetical index of the same content pages, and the FAQ page is starting to link back into the main content.
 * To provide a hierarchical model of all the content pages relevant to a smaller scope (e.g. all missions in Los Santos), use another index page.
 * Try to avoid changing the page names of existing pages, or creating too many new content pages until there is a clear page naming standard.

Perhaps it would be clearer if I specified how I ultimately expect the pages to be named. The string "GTASA" should be interpreted as "Grand Theft Auto: San Andreas":-


 * Index pages
 * "GTASA" - Main page, linking only to other index pages.
 * "GTASA: Contents" - Full hierarchical contents, linking to every content page.
 * "GTASA: Index" - Full alphabetical index, linking to every content page.
 * "GTASA: Frequently Asked Questions " - This page is a little hairy, since it contains both indices and content, but I shall put it in here in the hope that ultimately it will only contain links to other pages.
 * Content pages
 * "GTASA: Mission: Ryder" - Anything pertaining to the 'Ryder' mission.
 * "GTASA: Mission: End of the Line" - Anything pertaining to the 'End of the Line' mission.
 * "GTASA: Character: Ryder" - Anything pertaining the the character 'Ryder'
 * "GTASA: Vehicle: Infernus" - Anything pertaining the the vehicle 'Infernus'
 * "GTASA: Item: Night-vision Goggles" - Anything pertaining the the item 'Night-vision Goggles'
 * "GTASA: Item: Night-vision Goggles" - Anything pertaining the the item 'Night-vision Goggles'

If you think having only a single index to all missions is too much of a 'spoiler', then you could create another index page, say, just for Los Santos missions, which would link to the 'Ryder' mission, but not to the 'End of the Line' mission.

The means used to disambiguate the page names is arbitrary. I merely chose the colon (as used typographically rather than in a scoping context. i.e. "foo: bar" rather than "foo:bar"), because this seemed to be the way that the content was already organised. Some other examples:


 * "GTASA: Ryder (mission)"
 * "GTASA: Mission - Ryder"

I really don't care which method is used, providing it's agreed upon. Maybe the colon is a bad idea because it implies a namespace where none exists.

See also: Naming_conventions

Okay. It's 8:00pm here, and I'm off to the pub for a while.

Aya 18:56, 16 Jun 2005 (UTC)


 * I wasn't aware that there was a misunderstanding at all, but now I finally see what you're getting at! Yes I did think of the hierarchy of the Vehicle Missions--after I'd moved it! Certainly it should go under missions.
 * But what other examples are there of multiple-location pages like the Pulp Fiction example you gave? From a quick look at the list, pretty much everything might as well stay right where it is until such time as good names are found for "collectible hidden things" and such. For neatness' sake the Burglary guide should go under the Vehicle Missions page, but, again, that's minor.
 * As for implying the parent exists, in the currently applicable situations I can't think of a parent directory that would be unwanted, except for /Cheats/ but I've got plans for content there too.
 * The colons as they look nice and make nicer-looking page auto-titles than the slashes do, but they still imply an upper directory exists. Brackets make users less inclined to think there is a higher level, but as a downside they generate ugly URLs ("Grand_Theft_Auto:_San_Andreas_%28Contents%29").
 * I'm interested in using slashes because that is the standard for nested pages both in many of the other books here and the pages on other Wikis. Also, and more importantly, the MediaWiki engine will eventually support a TOC link on each page that will generate a list of its child pages, but this will not however support colon-based directories. Therefore for future-proofing and overall cohesiveness with the style adopted by the rest of the Wikibooks projects it seems the slash should be the way to go. Hmmm...
 * But hang on, I've got an idea, I'll just post this and do that :) Master Thief Garrett 14:22, 17 Jun 2005 (UTC)

Colons Considered Harmful
Okay. You've given a good reason for using '/', so I've changed the standards to reflect that. Any idea when MediaWiki will support auto-TOC for '/'-based subpages?

You'll also notice a lot of things have moved around. This page was getting too complex, so I thought I'd move parts of it to a metadata section.

Aya 18:49, 17 Jun 2005 (UTC)