Mapping resources and tutorials

[Neon_Knight]

This is just a small list which, at least, should give you a start. Head over DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/Mapping_resources_%26_tutorials]this page on the Wiki for the full tutorial list:

Remember to read this first

DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/DeveloperFAQ]DeveloperFAQ
DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/NOTTODO]NOTTODO
DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/GoodPractices]Suggested good practices

Installing and configuring *Radiant for OpenArena

Downloads:
GTKRadiant - NetRadiant - ZeroRadiant - MacRadiant - QuArK

Compiling GTKRadiant in Linux from source code
DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/Configure_GTKRadiant_for_OA]Configurating GTKRadiant for OA
DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/Configure_GTK_Radiant_under_Windows]Configurating GTKRadiant in Windows (DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/Configure_GTK_under_Windows]Also GTK)
DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/]Configurationg GTKRadiant in Linux
DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/]Mapping with MacRadiant

All the tutorials below work for the three editors. If you have any doubt, don't hesitate to ask in this forum.

How to map

LevelDK
Onykage's basics
Onykage's Radiant 101
WeMakeMaps.com
Wikibooks - GTKRadiant
Designing maps for One Flag CTF, Harvester and Overload

Advanced guides and tips

Cardigan's "Before mapping" tips
Lunaran's hows and whys of level design
CPMA guide for competitive level making
SimonOC's terrain and clipping tutorials

Map compiling with Q3Map2

Q3Map2 Official Site
Q3Map2 manual
Q3Map2 - Wikibooks
SPoG's Q3Map2 explanation

Mapping ideas

See DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/Map_Ideas]this page.

[onykage]

also here is a small tut for really basic instructions.  Im still working on the second one.

http://openarena.ws/board/index.php?topic=2507.0

[Neon_Knight]

Bump up... someone could need these.

[Neon_Knight]

Added Map Ideas @ Wiki

[Neon_Knight]

To avoid unnecessary bumps, but to keep this topic on the first page, I'll be posting here some of the docs attached in the first page, which will serve to us. I'll begin with Lunaran ones.
Map Balance

This explains the concept of balance in a map layout by analyzing player behavior and movement in greatly simplified examples, and touches for a moment on the role of items therein. This article has stood the test of time much better than the other sections I wrote, and its only real flaw is that it doesn't carry the concepts far enough.
Jan 30, 1999

A single room, 256x256x128, has perfect balance. No part of the map will see more action than another. Fighting is the same across the Z axis, and the fragging can be done anywhere in the room with equal ease. Now, say we add another room right on top of it, with the same array of DM starts, and we cut a hole in the floor (picture). Balance is affected. Since there is no way to go from the bottom room to the top, but doing the opposite is as easy as falling in a hole, much more fragging will occur in the bottom room than does in the top room. This illustrates the fundamental balance-upsetter: gravity.

Take, for example, Q2DM8, the WareHouse, one of the point-release DM levels from ID. Balance, if it weren't for gravity, is about equal. There are about the same number of stairs between levels, so balance is fine there. But ... gravity. Players will commonly drop a good 256 units in pursuit of a frag (or escape of a pursuer), so you should consider a strong downward shift of balance wherever there is a chance to fall from one area to another, be it off of a catwalk onto the floor, down a pipe from one room to another, or from one level to another. A map with no areas of drop won't have to take this into account, like our small one-room map above.

Another universal balance-tipper to consider is the center of your map. Consider another map, nine identical rooms laid three by three, all connected to horizontal or vertical neighbors but not diagonal ones. If you set a bot to run around the map randomly from one room to a random one, choosing random paths, eventually, the average would show that he entered the corner rooms the least, the center room the most, and the four other rooms evenly. This has to do with the total number of paths from one place to another, with the most paths going through the center room. It works like this: each corner room has two neighboring rooms. Each side room has three neighbors, and the center room has the most, four neighbors (picture).

Consider Q2DM8 again. That room in the center with the rocket launcher, grenade launcher and stacks of crates is always seeing action. That room is in the center of the map, on the lowest floor. That and the two weapons and the two +25 medkits sway balance heavily towards that room. Back to our example. If we ripped out the center room, leaving only eight rooms in a ring, balance would be equaled again. The only paths you could take would be a clockwise ring or a counterclockwise ring. Each room has two neighbors (picture), so balance is equal.

The more complex and varied the floor plan of a DM map becomes, the harder it is to regulate its balance. Consider another example: four rooms of the same size, two by two, each connected to its two neighbors by a hall (but not to its diagonal neighbor). Balance between the four rooms is equal here, too. Each room has two neighbors. Say we choose one room, and lower the ceilings in the hallways leading to that room to 32 units from the floor. To reach that room, a player would have to crouch, slowing him considerably. That room would not see any action. Alternately, the room diagonal to that room would see the most action. It has two neighbors that are easy to get to. The two odd rooms have one neighbor easy to get to and one hard to get to, and the first room has two neighbors that are hard to reach. Say we lowered the ceilings on two opposite halls, isolating the rooms into pairs. Balance would be equal again, because each room would have one easy-to-reach neighbor and one hard-to-reach neighbor (but flow from one pair to the other would be obstructed (see below)).

Stairs and ramps can be seen as an equal-opportunity level connector (by levels, I don't mean maps. I mean stories, floors, that kind of level). It is just as easy to go up them as it is down them. So they don't affect Z balance. But, if the only way to go from one level to another is by way of one stairwell in the corner of the map, that area will be choked with people trying to use that one stairwell, and balance will be tipped heavily in the direction of that stairwell. It is a very effective bottleneck. One or two more stairwells generally alleviate the problem by adding more capacity and spreading it out in different points across the map, but a stairwell always draws attention no matter how many other stairwells there are.

Lifts are useful for upward balance shifting. As most of us know, the platform entity is incredibly annoying if you need to get down, but incredibly useful if you need to get up. The platform waits at the bottom, and when it detects someone on it, it goes up to the top of its path, waits for you to get off, and then goes back down again. This is all well and good if you need to go up, but it makes getting down difficult. Say I'm at the top of the lift shaft and need to get to the bottom. There's no way to trigger the lift to come up to get me, and even if I could do that, it wouldn't go back down until I got off. So, the only thing I can do is to drop down the lift shaft. *WHAM*, I lose a good 20 points of health, and what do you know? The lift detects me standing on it, and, being the nice lift it is, brings me back up to the top of the shaft again. A platform, therefore, isn't useful for going down, so it shifts balance upward. (The same XY bottleneck imbalance of stairwells applies to lifts). This is useful for countering the downward balance shift caused by falling. You should not put a lift everywhere that the player could fall to counter the gravity imbalance, because it could affect the flow of the map negatively (and platforms shooting up and down all over looks stupid and causes lag).

[cosmo]

Neon Knight it would be better if you post the link where you found that and not the content. It's kind of theft.

[Neon_Knight]

The link was always there, look at "Map Balance", the only thing is that due to text & link colors on this forum are almost the same, links will be confused with plain text. :/

[Peter Silie]

Two links, both in german:
http://www.haradirki.de/tutor/index.htm
http://home.arcor.de/q3michel/tutor/tutindex.html (thx, panic!)

[0kelvin]

openarena

[Neon_Knight]

Added more tutos.

[Neon_Knight]

I've added this full list to the wiki. It's linked to the main page, so I'm sure everyone will see it.

(DO NOT LINK) h t t p s : / / openarena . wikia . com/wiki/Mapping_resources_%26_tutorials

[jukeboxhero]

Thank you very much Neon_Knight. I will go over these links!

JukeBoxHero

[Neon_Knight]

There was many complaints about the disordering on the wiki, so I took the initiative and rearranged/created many articles, specially those related to development.

Check the DO NOT LINK) h t t p s : / / openarena . wikia . com]Main Page[/url][/b]/Development section.

[Neon_Knight]

I'm in a doubt... so I'm asking to you...

The ProMode guide to create competitive maps was vanished from the net since the fall of promode.org, but the guide (fortunately) it's saved on the Internet Archive. Now we all know that IA's site, despite that it's a neat place to find most of that info and pages which aren't there anymore, has HUGE loading times, so my idea is to rescue that 2-page guide, and put it onto the OA wiki.

The problem is that the promode wiki doesn't have any license, as far as I know. Neither the about or disclaimer page states that, so I'm in a doubt now.

[kit89]

It is probably under public domain then.

If it is very useful information, I would recommend posting it on the wiki, but state all the information possible(original website, author, etc).

[Neon_Knight]

Well, my idea was to wait fromhell's word before posting it on the wiki, so there shoudn't be any doubt.

[fromhell]

It would be better suited to a Q3 mapping wiki. A promode mapper would hardly likely turn to OA resources for Promode mapping tips, it wouldn't make sense.  Ask in their IRC channel about the article. If you want to really archive it i'd just put the page on some stable webhost then link to it externally.

[bill-----]

It would be better suited to a Q3 mapping wiki. A promode mapper would hardly likely turn to OA resources for Promode mapping tips, it wouldn't make sense. [...]

This is a *very* interesting comment, to me anyway. At first I was pretty
sure I did not agree, because I don't think Q3 mappers and CPMA mappers
have the same goals.

But, since the subject in this forum is OA, I wondered if a rephrasing
"better suited to a Q3 mapping wiki *than an OA mapping wiki*" might
sharpen a distinction you're trying to make between Q3, CPMA and OA.
Not to say that the document is particularly well suited to a Q3 mapping
wiki, but even less so for an OA mapping wiki.  Am I reading you as
you intended?

Here I don't mean Q3 the iDTech engine, since all three more or less
share that, but the intended audience and game experience that audience
enjoys using the base Q3 content and 3rd party maps, vs the CPMA mod
and content, vs the OA/IOQuake engine and content.

Given the above, a first effort at preservation might be as you may
be suggesting, to encourage the Q3/CPMA crowd to preserve their own
documents.  That failing, we could reconsider. There are some other
interesting and useful documents by Geit and Hoony as well as some
interviews that relate to CPMA mapping that also ought to be preserved.
IMO the CPMA boys and girls, those few who are left, should get busy
finding a new home for that stuff too.

There might be a good reason to post the document, with proper
attribution, as a *wiki* document, with all that that means in terms
of it being a living, collaborative, changing document, the intention
being that it serve as a starting point for commentary, guidelines,
etc. for mapping *for OA*.

Back when I thought I had time to think about such things, I made a lot
of notes about the CMPA guide, Lunaran's Encyclopedia, etc.. Given the
sorry state of those notes, it seems I didn't have enough time then
either. Anyway, the commentary, once added to the document, might be
useful to the active mappers here, not that I'm an expert (I have *no*
credentials!), but as a stimulus to thought.

Here's a fun note, not necessarily the juiciest or most controversial,
but illustrative.

From the Guide:

"2x25h vs. 50h - With a 50h in there, players can deny their opponents
health easier. With 2x25h, if the player has >75h, he can only take one of
the 25h's, therefore leaving the other one for his opponent. Therefore,
if in testing, the up player is denying the down player health too often
by picking up the 50h's, change them to 25h's."

Makes sense, huh?  My comment:

"... or if he wishes, he can 'waste' health with the PG, shooting his
feet then taking the remaining 25H.  [...]".

So, it turns out that 2 25Hs might be better not because they prevent anything,
but because they give the player more options.

Perhaps the Guide isn't the final word on mapping, but *only* a guide. :-)

[vindimy]

Since nobody mentioned it yet, here's what looks like some awesome Radiant and other level-making tutorials:

http://q3a.ath.cx/?editing=radiant_tutorials

[vindimy]

Here's another one:

http://modulatum.wordpress.com/2008/07/26/creating-a-map-in-gtkradiant-for-openarena/

[Neon_Knight]

Just a FYI, all the links are going now to the entry at the Wiki.

[son_goku2]

I'm leaving  behind what I know and learned to make legodeck and legocurse.

High resolution lightmaps: Rewrote it to make it more clear and corrected a long time confusion between what lightmap's resolution is and what lightmap sample size does. Also deleted filter radius because according to the official shader manual that's something for sunlight only. New addition: "hack" to force q3map2 to compile ultra high quality lightmaps that would otherwise cause a crash with safe_malloc error message. Added warning about a unsolved issue regarding lightmap seams.

Visibility and hint brushes: Rewrote half of it and added more and better examples.

Speed up visibility calculations: New article.

Fake indirect lighting: Rewrote everything, replaced all images.

Modelling a map: Erased everything about externally rendered lightmaps and wrote a quick explanation about that in "fake indirect lighting" article.

Hint brushes and lightmaps: Dropped, deprecated. Untested theory that might even prove to be worthless.

Fixing overburned pixels: New addition that I saw in warsow community.

Portal camera: I couldn't make it work in legodeck, tried it a dozen of times. Opened OA DM 5 (the cistern port from quake 1) and checked the entities setup to no avail. In the end I used env maps and gave up the portals...

[Gig]

Portal camera: I couldn't make it work in legodeck, tried it a dozen of times. Opened OA DM 5 (the cistern port from quake 1) and checked the entities setup to no avail. In the end I used env maps and gave up the portals...

I haven't tried this... did you? (DO NOT LINK) h t t p s : / / openarena . wikia . com/wiki/Creating_a_portal

[BRS]

I've always liked GTKRadiant the best but the last map I was working on kept compiling texture loss.. sometimes they would compile then they wouldn't.. I test my map through the build to see if I need to make structure/item changes. Could it be just a problem with the brush/block?