Rules for the judges

[Wixen1 [Q2C]]

Judges will score each map from 0-10 in each category below.


1 - Texture work - Should be neat and clean and fit well together.

2 - Originality - Map should have some originality and not a copy of another map.

3 - Game Play - Map should be fun to play on and not boring.

4 - Weapon/Health Layout - Items should be placed throughout the map for easy access.

5 - Extras in the map - Map can include secrets, jump-pads/elevators, traps, etc.

6 - Lighting - Should be pleasant to the eye.

7 - Sounds - Maps should include sounds that fit with the environment

8 - Connectivity - Map should flow smoothly from one room to another.

9 - Technical - This includes r_speeds, brush manipulation, map scaling.

r_speeds: High r_speeds = less tech points. Under 2500 in small areas and up to 3500 in general will be acceptable r_speeds, while anything over 3500 should severely reduce the technical score as this makes the map unplayable for some users.

Brush manipulation: Complex brush manipulation deserves to be credited. (What mappers have to do when creating great-looking and complex geometry, like ex. lighting and texturing).

Map scaling: Proportion of things amongst each other as part of effective architecture.

10 - Subjective opinion/observation - Judges own opinion on map. Breaking from the categories, what map did judge like over.

[redangel121]

As a new judge and having no background in mapping/modeling... could I get a quick breakdown on r_speeds and brush manipulation?

I understand the rest of it...

[spirit]

The r_speeds are an indicator for how much geometry the engine has to draw at a certain camera position (player view point + view direction) in the map. More means that the brushwork is more complex (and most likely the map looks better and more detailed), but it also means that it runs slower.

You can turn on the display of r_speeds in the game by typing r_speeds 1 in the console. Then run through the map and look at different places, and see how the r_speeds change and where they peak.


Brushwork complexity and r_speeds

A map consisting of 6 brushes only (4 walls, a floor and ceiling) will have great r_speeds but suck in every other way. The same map, with a realistically looking tree with thousands of branches in it which has been created out of normal brushes, will have very high r_speeds if you look at the tree (due to the hundreds of faces it consists of, and that have to be drawn at the same time when looking at it).


The importance of the field of view

BUT the engine does NOT render places you cannot currently see, e.g., another room which is behind a wall (provided mappers follow some rules to ensure this).

Note that, technically speaking, the mentioned tree map still has very low r_speed if you look away from the tree (directly at the wall), but that would hardly count for a practical judgement, because players do not look at the walls all the time. The important thing to note though is that the complexity you look at at a certain view point counts, not the overall complexity of the map. This means, if the map consisted of 10 rooms, with one such tree in each room, and the rooms were not visible from each other, the r_speeds of the map with 10 trees would NOT be higher than those of the map with a single tree (because in both map, you can never see more than 1 tree at once).

The challenge for mappers

What mappers have to do when creating great-looking and complex geometry in a map is, they have to assure that the complexity does not get too high at any single view point while keeping the map look good. This is the reason why Quake 2 r_speeds suck for very large, open maps with lots of complexity (think of a forest): in such a map, all of the complexity is visible at once.

Conclusion

So r_speeds are a trade-off. Having very low r_speeds means great performance, but most likely your map will look ass. (Note that we are talking about brushwork -- lighting and texturing do not affect r_speeds*.) So if you build great and complex geometry, as you should for a great map, you have to ensure that not too much is visible at once, so that the performance does not get too bad.


*This is not entirely true, since you may need to split some brushes only to be able to apply several textures to the resulting parts (instead of only one texture to the whole thing), but this is a minor issue.

[Wixen1 [Q2C]]

Feb 2, 2015 9:02:28 GMT -5 spirit said:

The r_speeds are an indicator for how much geometry the engine has to draw at a certain camera position (player view point + view direction) in the map. More means that the brushwork is more complex (and most likely the map looks better and more detailed), but it also means that it runs slower.

You can turn on the display of r_speeds in the game by typing r_speeds 1 in the console. Then run through the map and look at different places, and see how the r_speeds change and where they peak.


Brushwork complexity and r_speeds

A map consisting of 6 brushes only (4 walls, a floor and ceiling) will have great r_speeds but suck in every other way. The same map, with a realistically looking tree with thousands of branches in it which has been created out of normal brushes, will have very high r_speeds if you look at the tree (due to the hundreds of faces it consists of, and that have to be drawn at the same time when looking at it).


The importance of the field of view

BUT the engine does NOT render places you cannot currently see, e.g., another room which is behind a wall (provided mappers follow some rules to ensure this).

Note that, technically speaking, the mentioned tree map still has very low r_speed if you look away from the tree (directly at the wall), but that would hardly count for a practical judgement, because players do not look at the walls all the time. The important thing to note though is that the complexity you look at at a certain view point counts, not the overall complexity of the map. This means, if the map consisted of 10 rooms, with one such tree in each room, and the rooms were not visible from each other, the r_speeds of the map with 10 trees would NOT be higher than those of the map with a single tree (because in both map, you can never see more than 1 tree at once).

The challenge for mappers

What mappers have to do when creating great-looking and complex geometry in a map is, they have to assure that the complexity does not get too high at any single view point while keeping the map look good. This is the reason why Quake 2 r_speeds suck for very large, open maps with lots of complexity (think of a forest): in such a map, all of the complexity is visible at once.

Conclusion

So r_speeds are a trade-off. Having very low r_speeds means great performance, but most likely your map will look ass. (Note that we are talking about brushwork -- lighting and texturing do not affect r_speeds*.) So if you build great and complex geometry, as you should for a great map, you have to ensure that not too much is visible at once, so that the performance does not get too bad.


*This is not entirely true, since you may need to split some brushes only to be able to apply several textures to the resulting parts (instead of only one texture to the whole thing), but this is a minor issue.

Thx. spirit, I was in doubt, with my poor english, if I was able to explain this correctly!

-W1

[redangel121]

So I just used r_speeds on Q2ctf1 - "McKinley Revival" and it fluctuates between 300 and 3000 in some spots. My crap computer still ran at full 60+ fps the whole time... I have never really had an issue with lagging in any map ever so I guess I’m unsure why the r_speeds needs to be kept under 1500. Do people still have machines that can’t run this 17 year old game that well?

[ace]

Feb 3, 2015 23:06:02 GMT -5 redangel121 said:

So I just used r_speeds on Q2ctf1 - "McKinley Revival" and it fluctuates between 300 and 3000 in some spots. My crap computer still ran at full 60+ fps the whole time... I have never really had an issue with lagging in any map ever so I guess I’m unsure why the r_speeds needs to be kept under 1500. Do people still have machines that can’t run this 17 year old game that well?

Yeah, we have a few maps in rotation that can hit r_speeds of 4000+ and most people still get 60fps, and even people with "older" laptops are still getting 30fps+ in those areas. Might be time to upgrade the computer if 1500 makes a map unplayable

[NIN-Kitsune]

I think it's important to keep them down if one can, but don't overly sweat it if you can't always do so in some situations. I've recently learned more about r_speeds although I had already been mapping for a time now, I think though 1500 is a bit on the obsolete side, but I think staying under 2000 and 2500 at tops when possible is still a reasonable standard to maintain if you like going complex looking in your maps, I think pretty impressive results can generally be managed in most cases under that if you try to make the most of efficient geometry. It's harder when one is starting out, but when you get better, you'd be surprised what you can do with less and look pretty nice.

[Wixen1 [Q2C]]

The judges rules is almost 10 years old, and I think, as with new and faster computers, we need to put som new numbers on the r_speed.
Iam thinking 1500 (+/- 100) in small areas and up to 1200 in general will be acceptable r_speeds while anything over 2500 should severely reduce the technical score as this makes the map unplayable for some users.
What do you think?

-W1

[spirit]

Agree. 1500 is a joke, and I already expressed my doubts on this number on one of the other contests some years ago.


BTW: I read claims that the r_speeds also had an impact on playing over the network in some places. It is beyond me why this should be the case, but I would be interested to hear whether anyone can confirm or explain this.

[Deleted]

This contest is for standard Q2 DM...
And create something complex, special will cost you r_speed..
you simply have no choice the r_speeds goes up...and yeah 1500 is pretty average for a complex map.
Margaal17clip 9th contest winner, the R_speed in small rooms 600 and 2200 in open space, and in the corners 2800.

back then I knew nothing of the r_speed, heard it for the first time from Panjoo...
The old beta margaal17clip version was much much more details, many brushes had to be removed and tweaking..
...R_speed was 8000 or above..
A high R_speeds means also more compile time needed....normal is 2a5 minuts compile time..
In the Old beta version I wait hours and hour...
the compile tool (Vis) actually suffocated in the complexity in combination with open space..
haha.....t's a good thing that the train stood still....., Rrrrrggg_speed


map margaal14 is design wrong, a failure open space map......
(( 12½ hour compile time )).

Map margaal14 remake ---> margaal16 with a closed building in the Middle.
only (( 30 minuts )).

A another good example map is margaal21, a very complex map....
(( 34½ minutzz )).
I design this map r_speeds technical.....stop accurate 32 grid before problems and disturbances emerge..
The trick in a complex map is blocking the player look field of view on that side where it is needed..
...Spirit has already explained!..


I have to say this...
but...for Kmq2 engine is the r_speed a thing of the past.
Knightmare knows a lot more about this technical stuff..

[spirit]

I talked to jdolan about this, and brush complexity has nothing to do with the net code / lag.

BUT in earlier times, where little detail was found in a room, high r_speeds meant that you could see a lot of rooms at once (think of the large, open maps I mentioned). And THIS means that you see a large number of entities at once (moving players, rockets, other shots, ...), and these entities need to be updated server to client and vice versa over the net, of course. And this CAN be a prolem.

The map geometry does NOT need to be updated obviously (since both the client and server already have the map, and its geometry does not change during the game).

So many details in a room are no problem for the net code, but large open rooms with many players fighting it them at once are.

[Wixen1 [Q2C]]

There might still be some players out there with computers with an age of 5+ years, so...should we take it out of the rules, what do you guys think?

-W1

[jaydolan]

Wow, my post was deleted. Nice.

[Wixen1 [Q2C]]

Feb 4, 2015 16:27:19 GMT -5 jaydolan said:

Wow, my post was deleted. Nice.

No, It was moved, as it has nothing to do with our 10. contest. I have told you in a PM.

-W1

[Null]

For anyone not formally participating in the contest, for obvious reasons we can't guarantee that your opinion will be taken into consideration, especially if you post comments that are off topic in these contest specific threads. On the other hand, if you're actually interested in supporting this contest and wholeheartedly voicing your concerns, please feel free to officially join the Judges or Mapper panel. We'll gladly hear you out :-)
We're looking for all sorts of informed and helpful suggestions, but we need to stay on topic because we still have a Contest to run.