News | Forum | People | FAQ | Links | Search | Register | Log in
Quake Documentation Project
Quaketree brought up the idea that the community needs to rescue / dig out the information from this forum and other sources and store it in one accessible place.

Others chimed in and most agree that this place should be a wiki. Spirit has suggested Quaddicted, and I personally agree that it's the right place for such a project, but the Wiki over there seems to be limited. Others (Willem, me) have also volunteered to set up such a Wiki.

Let's discuss this idea further in this thread. I think it would be a fantastic thing to have a community Wiki for Quake level design.

UPDATE: there is now a URL: http://quakewiki.org/
First | Previous | Next | Last
Quick Start 
I'd like to see a detailed section on the basics. Totally a noob start point. Get as many new people to give Quake a look as we can. Right now the time cost to learn Quake mapping is too high, info is scattered, links are long dead.
Lets get people able to build that first box room quickly. 
On The Basics 
I agree. And I do mean "The basics". Right down to what exactly is a brush. I know that it sounds stupid but way back when, like in 1997 when I first started looking at making a level, I kept seeing the word brush and I kept thinking to myself that "Painting on" a texture was nice and all but what does that have to do with making stuff. I finally figured it out of course but it took me about half an hour to figure out what people meant when they said brush, the name itself isn't intuitive to what it is relative to real world items. I mean seriously, one of the most important tools and I couldn't find a solid and concise definition of what it was anywhere on the internet.

So yeah. Something with no assumptions of knowledge on the part of the reader other than how to read and click a mouse button. One thing that I learned in the Navy was that there was no such thing as a dumb question as long as it was an honest one. 
 
Is there anybody who would be interested in making Quake 1 maps these days that wouldn't have baseline knowledge like, "What is a brush?" 
Like I Said 
That assumes that they already know what a brush is. How exactly is someone supposed to know that unless they either figure it out through context or are told? I used the brush as an example but there are probably plenty more examples out there where the jargon is assumed to be understood but isn't laid out somewhere in plain english in case it comes up as a question.

The whole point of a Wiki is to impart knowledge no matter how trivial. Assume nothing on the part of the reader.

As far as to who might still be interested in mapping for Quake I'd just say that Quake is probably one of the best engines for people new to the idea to start off with. It's relatively simple (no meshes, shaders and so on to deal with). The tools are similar (or the same if you use Radiant) to what's used in much more complex games and much of the same terminology is used throughout most games. Overall an excellent platform to start off with to learn the basics because this game was where the basics of 3D level design were first though up and implemented. 
Willem I Hope So 
Half life 1-2 and it's mods what else is there? The more modern a game is the steeper the learning curve. The harder to learn the faster a game falls into obsolesce. I may be wrong but what other game would be a good start, from zero knowledge of game design.
What game would be good for a kid to start with? 
What Could Possibly Go Wrong 
Did the final import, user rights should be working. Now browse and edit around and knock yourself out with content. Do not advertise it yet please, this is the beta stage. We should first see what happens.

There is a lot of house-keeping to do. Categories, templates, license reminders. Keep in mind that you must not copy and paste things in there. If you use references, please link them. If you plan want to do big restructuring, please discuss it somewhere in the wiki (using Talk pages). The wiki should be self-contained. Discussion and decision that happens inside the wiki has precedence over anything said elsewhere.

Content-wise, you decide.

Busy and productive users become admins. So far scar3crow and Sajt are fellow admins. Both were imported that way. I am not sure if Sajt is still interested at all, we'll see. 
 
I set the Wiki to be case-sensitive, so you can now actually create pages starting with lowercase characters. This is great for variables and stuff. We could rename the existing pages with a bot (or sore fingers). 
 
Can you please make the font size bigger? It's so small I can barely read it without touching the monitor. 
 
you can get around that temporarily by using the other themes although they don't look as good, but yeah, it is tiny. 
Negke Just Wait Til The Layout Is Final 
To the busy editors, please add some appropriate categories to your pages, that would help structure later. Just at the bottom of the page (or anywhere really), something like: [[Category:Entity]] or [[Category:QuakeC Function]].

No idea if those really are QuakeC functions or engine functions, necros. I am just trying to help! :) 
 
I don't know anything about wiki editing, so thanks for the info. 
 
k, put a few qc things in. need someone who is more familiar with all the trace() globals to check on that one though. 
 
I'm working on a write up 'The Basics of Quake Mapping', which I plan to define brush, entity, making a sealed room, compiling, and playing the compiled map. The aim is for total newbies using Trenchbroom.

Plan to have it ready tomorrowish to put on the wiki 
Basics 
I agree that it is important that we have all the basics. This is because when the apocalypse happens, the survivors need to be able to rebuild humanity, and that includes Quake ;)

Also, I like the level of information in the Doom wiki - we should document the original game, create stubs for all the monsters, maps, weapons, powerups, creators and whoever wants to can add information at a later date. 
Entity Definition Pages 
ok, so I was just looking at the wiki and thought I would fill out a couple of entity information pages before doing some mapping.

So I went into info_player_start and wrote a very short description and then realised that it might be useful to have a table of keys that are supported by each entity as standard as a mapping reference.

info_player_start is not a good example, as it only supports origin, angle and spawnflags, but for other, more complex entities, having a table of keys and what they do would be helpful. However, whether this should be in some kind of standard table format or just as a list I don't know, though I do quite like the format used by Kell/Necros for the Quoth mapping guide:
http://www.quaddicted.com/webarchive/kell.quaddicted.com/quoth/quoth_tutorial.html

Whatever we do though, it should be the same for all entities. Also, I think support specific to mods should be contained in a separate page, so if, for example, we transferred the info from the Quoth mapping guide to the wiki, it would be best to keep it in a specific Quoth section. 
 
For the qc section, I was doing something simple with just h4 and preformatted text but maybe that will give you some ideas? 
I Agree 
I did a couple of entities as well (the sigil, episodegate and bossgate ones). I inserted the .fgd entry and was using that to describe what was going on but I think that it ended up looking a bit cludgy. I think that a good basic description of all of the keys and so on would be a good idea, plus it will help those who are writing in the Wiki to maintain consistency throughout the section.

Perhaps also a temporary template page (named entity template) that can be copied (cut and paste style) that has all of the common elements in it. It can be deleted once all of the entity pages are started. 
Formatting And Naming Conventions 
Ok, I wrote up a little extra info on the entity guide page. It might be worth splitting it off into subsections though. I also added info_player_start and info_player_deathmatch stubs. I'll try doing an example of an entity that has got settings.

If you are going to write up anything in the mapping section on an entity, please read the bit I wrote and if you have any suggestions for formatting or naming improvements then please respond here (or should we use the wiki talk page?)

I think we should add images of all the mapping features too, but for now lets just figure out the formatting of each page and write some basic text.

We should probably think about where and how we are going to write up information about specific hacks and tricks later too, though at this stage it's not really important. 
Oops.. 
forgot the link:
http://quakewiki.org/wiki/Entity_guide

Scampie said he was writing some basic mapping descriptions, so maybe that should be merged with what I wrote, or perhaps if it's better organised/written then just remove the bit I wrote. I'm not sure if the entity guide should include the general entity info, or if it is intended to simply be a list of entities. 
I'll Link To Yours 
I'm aiming closer toward 'tutorial' than indepth articles on each and every thing. Yours is a much nicer in-depth knowledgebase than the 2 paragraphs I am writing. 
By The Way 
sorry to keep spamming, but for spawnflags, I think it's important we also include the value of each flag. Still not sure how we should format this stuff though. I think what quaketree wrote for the door was ok, but perhaps we need a little cleaner formatting as it looks a little clumped together perhaps?

I'll have a go at making the page for func_button if that's ok. 
Also 
I really think you should put your information on http://quakewiki.org/wiki/Entity as it's a very good writeup of the information. 
Argh 
ok, I'm going to split off Entity into a separate page, because putting it where I have was a dumb idea. We should have pages for all the mapping fundamental terms:
Brush (Scampie?)
Entity (kind of done)
Unit (done)
Angle?
Position / Vector?
Spawnflags (in entity)
Key/Value (in entity)
etc...

I guess the entity guide should contain a list of entities as it does now, though we might want to later split that off into Standard Quake entities and add pages specific to mods, or even just add a footnote with links to entity guides for mods and keep the standard entities on the entity guide page. 
Obviously 
This is and will be an ongoing thing regarding internal links that was an inevitable result of internal linking using outside resources.

As this develops I would hope that the links will stabilize as common terms are defined within the Wiki (and that punctuation is ignored. Brush links should be hyperinked to brush and not brushes for example. The "es" should be not included in the link unless you are talking about grouping brushes.) 
Quaketree 
yep, I think I did that everywhere. However, I realised that I made a shitty mistake of using lower case for page names, so the page name appears lower case. I haven't checked how to format page names, but we should all agree on some kind of page naming standard, and even if our pages are all named perfectly, we have to format the entity names properly as they contain underscores, which are used by the wiki to denote a space in links :/

I'm looking at this now, but I can't figure out how to do it (I just borked the Entity Guide page and it now has two titles... grr) 
First | Previous | Next | Last
You must be logged in to post in this thread.
Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors.