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).

« Last Edit: March 02, 2009, 12:09:48 pm by |TXC| Neon_Knight »

Logged

"Detailed" is nice, but if it gets in the way of clarity, it ceases being a nice addition and becomes a problem. - TVTWant to contribute? Read this.

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.

Logged

"Detailed" is nice, but if it gets in the way of clarity, it ceases being a nice addition and becomes a problem. - TVTWant to contribute? Read this.

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.

Logged

asking when OA3 will be done won't get OA3 done.Progress of OA3 currently occurs behind closed doors alone

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 prettysure I did not agree, because I don't think Q3 mappers and CPMA mappershave 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*" mightsharpen 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 mappingwiki, but even less so for an OA mapping wiki. Am I reading you asyou intended?

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

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

There might be a good reason to post the document, with properattribution, as a *wiki* document, with all that that means in termsof it being a living, collaborative, changing document, the intentionbeing 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 lotof notes about the CMPA guide, Lunaran's Encyclopedia, etc.. Given thesorry state of those notes, it seems I didn't have enough time theneither. Anyway, the commentary, once added to the document, might beuseful 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 opponentshealth easier. With 2x25h, if the player has >75h, he can only take one ofthe 25h's, therefore leaving the other one for his opponent. Therefore,if in testing, the up player is denying the down player health too oftenby 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 hisfeet 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. :-)

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...

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 never want to be aggressive, offensive or ironic with my posts. If you find something offending in my posts, read them again searching for a different mood there. If you still see something bad with them, please ask me infos. I can be wrong at times, but I never want to upset anyone.

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?