GAMEFLOW Download these detailed resources:



Playtesting 1 - Bots

The Bots - by QL Correspondent Jeff Blaine

What is a Quake Bot?
====================

If it hasn't struck you yet for some reason, "Bot" is short for "Robot". In the most common sense, a Quake Bot is a semi-intelligent program that can play Quake on its own. There's generally quite a bit of artificial intelligence (AI) built into Quake Bots. The program guides the Quake Bot "player" around Quake levels while attacking enemies and helping friends (this varies on the Quake Bot software). A Quake Bot visually (clothes, face, etc) looks the same as any player in the game (with the common exception of clothes color).

What's the Point?
=================

Some people see the ultimate goal as creating an unbeatable opponent for deathmatch games, but most people are interested in creating Quake Bots which are more human-like (with faults, weaknesses, varying skill levels, etc. Whatever simulates how humans normally play). As a result of Quake Bot development by numerous individuals and groups, there are several good Quake Bot programs available which provide adequate resistance to anything you can throw at them during a game. They strafe out of the way, circle-attack, avoid lava, etc.

In short, they're excellent opponents for training and improving your skills. They also provide plenty of entertainment when the Internet isn't quite as stable as you'd like it to be.

What Kind of Bots are Available?
================================

First, let me break Quake Bots into two categories:

1. Client/Server bots
2. Local bots

Client/Server bots (really just Client Bots) are programs written in a language other than QuakeC that open a connection to a Quake server across a network (just as a human player would) and are self-contained actual Quake Players(tm) while playing the game. Like actual Quake Players(tm), client bots can lose their connection to the server, they show up in the score table, and so on.

What I refer to as "Local bots" are more popular currently and are written in QuakeC. These bots must be run from the server hosting the game itself (generally with a -game argument to Quake). Most local bots (I don't know of one that can) do not show up in the score table with the other players, and have great response time (they're programs running as part of the network server itself...).

Now that the branding is done...different bot programs are mostly alike in their fundamental concepts. They generally try to accomplish the following tasks (all of which, when taken in sum, make the bot in question more human-like obviously):

1. Avoid lava.
2. Don't drown.
3. Move swiftly and efficiently through the current level.
4. When in normal deathmatch mode, kill anything that moves.
5. When in teamplay deathmatch mode, kill anything that moves that is not on your team (few bots can do teamplay well yet).
6. When in cooperative deathmatch mode, help out your master.

The Reaper Bot
==============

Steven Polge is the author of one of the most popular bots currently (either client or local) called The Reaper Bot. The Reaper Bot is
a local/QuakeC bot program with much more sophistication and intelligence than most other bot programs have at this time.

The following features make The Reaper Bot stand out from the crowd (paraphrased from the .TXT file that comes with the Reaper
Bot, and experienced first-hand):

- The Reaper Bot (TRB) "learns" levels as it plays them by keeping track of where it has been and what obstacles (and weapons for that matter) exist where.
- TRB has a range of skill settings (0.0 to 3.0) for fine-tuning how badly you want your ego crushed.
- Follows opponents around corners, through teleporters, etc.
- Weapon choice based on range of enemy
- Attack mode (strafe, charge, circle, distanced, etc) based on weapon, enemy's weapon, range, etc.
- Avoids combat in certain situations (low health, enemy has Pentagram of Protection, etc)
- Sensible water navigation (won't use lightning gun, avoids drowning, jumps out of water, can chase/follow enemies into water)
- Many others

Where to get it: ftp://ftp.cdrom.com/pub/quake/quakec/bots (look for a file named reaprbXX.zip, where XX are numbers)

How to Install The Reaper Bot
-----------------------------

1. Create a directory named RPBOT underneath your Quake main directory (for example: C:\GAMES\QUAKE\RPBOT).

2. Unzip the reaprbXX.zip file into the directory you created in step 1.

3. Read the .TXT file which was extracted from the reaprbXX.zip file for the latest information on how to use the QuakeC program and how to spawn/remove/adjust Reaper Bots in your game.

For now, here are the links that will get you the necessary files to experiment with this tool:

A very wide variety of bots:ftp://ftp.cdrom.com/pub/idgames2/quakec/bots/
The HAL (Heuristic Algorithm - dynamic learning) Reaper bot:ftp://ftp.cdrom.com/pub/idgames2/quakec/bots/
A more distilled list of bots:Scary's Quakeholio QuakeC Section

Playtesting 2 - Framerate Testing

R_SPEEDS 604, R_TIMEGRAPH. "OUCH."

R_SPEEDS 450, R_TIMEGRAPH, E1M3

R_SPEEDS 463, E1M7

One of the more critical aspects of level editing is the framerate or speed of the level. Generally, the R_SPEEDS value should be kept under 450, although slight excesses are acceptable. To activate the running tally, type R_SPEEDS 1 at the console. Then go through your level, looking all around, and inspecting each room and region to ensure that there are no significant slowdowns ('spikes' in the number outlined in the third screenshot.) An easier way to detect framerate slowdowns is the R_TIMEGRAPH. Type R_TIMEGRAPH 1 at the console to activate the graph. The lower the graph, the better. You shouldn't have to use R_GRAPHHEIGHT to increase the graphable area since this probably indicates that you are far past the reasonable constraints. All the id levels appear to maintain graph measures well within the default graph size. Typing TIMEREFRESH at the console will return an average framerate as measured from your current position.

Before you use these commands, remember to use a complete VIS (vis -level 4) so that you get accurate readings. "I had a level which went up to 900 on the r_speeds before I VISed it. After I VISed it, it barely went up to 400." - Aaron Bentley

"Many people have the 'grey planes' problem when their map becomes too complex. If the grey planes don't go away after a level 4 vis, you should start all over again, because the design of your level is the problem.

If you type "R_NUMEDGES 1" at the console you can examine how complex your level is. The maximum of edges Quake can handle is 2000, so now you can check early if you're approaching this value (and do something about it).

If your level is a bunch of rooms interconnected with hallways, you can easily improve performance by not making any straight hallways. After I transformed a straight hallway into a Z-shaped hallway, the NUMEDGES-value was only 50% of what it was before." - Jasper van der Neut

More details on this later.


Custom-Built Monster Packages

The Giant Spider - by Ken D. Turner at The Birthing Chamber

(SPIDER.ZIP - 67.5 KB) This is a completely new monster for Quake. It is not intended to replace existing monsters - think of it as a newcomer to the charming family of Quake monsters. It fires 'venom' in much the same way as a Death Knight's magical attack. It is very convincing. You will need some knowledge of QuakeC compiling to use this. Check out Quake Command for all your QuakeC needs.

 

The Reptilian Grunt - by Tan Sian Yue

(SNAKEMAN.ZIP) This is a completely new monster for Quake, just like the giant spider. Tan Sian 'Bubbah' Yue admits that 'yes, it's a bit on the cartoonish side,' but that his next monster will have more frames to it and a more 'organic/realistic' look. This genetically warped grunt carries a pair of submachine nailguns and strafes rather quickly towards you and around you in circles, blasting away furiously.

The DOOM Cyberdemon - by Marc Fontaine

(CYBRDMON.ZIP - 512 KB) Here is the Cyberdemon from id Software's DOOM and DOOM II. Fires rockets like the original, walks and sounds like the original. Gibs when killed. Sample level included with instructions on its use.

La Femme Nikita - by Ludovic Texier

(MANGAB.ZIP - 277 KB) Kicks, shrieks, and if you run too far away, watch out for the handheld grenade launcher...Includes the QuakeC source code. She must have some sort of cutting implements built into her boots - gibs fly when her kicks connect! Renamed after a female assasin from a French action flick.


QUAKEWORLD - Internet Multiplayer

It has arrived. Quakeworld, still in its infancy, promises to usher in a new era of Internet multiplayer gaming, with features such as 'on-the-fly' downloading of level or texture files you may not have at the time you connect to a given server, and the ability to let a player pushlatency (literally, push latency) negatively to create a very reasonably playable Internet multiplayer game with an unlimited number of players (theoretically. :) There have been servers observed to be running 32 client slots, and one with 666 clients slots (although I'm not sure that was for real.) Clearly, this is a different game from the one we've been used to thus far. QL Editing Associate and Dark Requiem member QW tester Mark Rohrer brings us this brief guide to making maps for the new Quakeworld:


First I will give you some general impressions of some bugs that may or may not be fixed.. if they can be at all (predictive alogorithms are undoubtedly a nasty thing) So here it is, the definitve QuakeWorld map makers guide:

Level Design
Lag comes from the world itself.. a door, train, or platform can lag an entire map, and even cause rather severe packet loss. Try to make maps as open as possible, tight spaces can cause lockups on the client end, which can be very nasty for hot deathmatches.

Keep the total number of brushes down. This is a handy tip for map making in general. However lag in QW tends to be more jerky, and the fewer the brushes, the less jerky it will be.

Level Distribution
Maps can be downloaded from the console automatically upon joining server.. this has been common knowledge for a while, i just wanted to reinforce it.

Gameflow
Here is something that has bothered me through most of the beta stage of QW... Grenade Launchers. Something about the physics of the grenades' trajectories and/or particle trails truly lag the game. Unless you are partial to Grenade Launchers, you might want to keep them out to improve gameplay. Rockets do the same thing, to a lesser extent, although I dont know of anyone who would keep rocket launchers out of a dm map :)


Multiple Level Episodes

STRTDEMO.ZIP (70.0 KB)"Start" Map Difficulty Selection by Jeff Cochran - NEW!

Includes MAP, BSP, and TXT files. A demonstration of trigger_setskill and trigger_changelevel entities for multiple level episodes. Recommended downloading. :)


The Gurus Speak...

Here are some interesting gameflow related tips from past .plan file updates from Hipnotic's designers.

LEVEL EDITING TIP O'THE DAY: Putting Sky brushes where you would normally have roof stuff is less costly than doing a textured roof. Why? Because the Quake Engine doesn't split the sky texture like a normal textured surface. Therefore, having large areas of sky is actually faster than a closed off roof. Makes you wonder why there aren't more outside places in Quake..eh?

Here's some helpful information that I use for viewing all the models in QUAKE. You might want to try it if you have a need to see the QUAKE monsters up close and personal! I hope most of you have a good understanding of QUAKE, so I won't beat around the bush and explain every last stinking detail!

1. Create a map with simple architecture. (My map is just one room.)
2. Create an entity with class name: viewthing (I'd place it near the center of the map. This is where you'll view the models)
3. BSP your map.
4. Load that map into QUAKE.
5. The player model is the default model for so, it should be sitting on the map.
6. At the console, type: viewmodel "progs/shambler.mdl" (include the quotes).
7. Exit the console and the Shambler should be standing where the player model was.
8. Bind a key to: VIEWPREV - At the console type: BIND [ "viewprev"
9. Bind a key to: VIEWNEXT - At the console type: BIND ] "viewnext"
10. Exit the console.

Now you can use the bracket keys [] to scroll through all the Shambler's animations. If you want to see any other character's animation frames, just type the VIEWMODEL command, and replace the _________.MDL with the new character or weapon filename.

"I don't know all the .MDL filenames!" you say :(
Well, here they are for your viewing pleasure.

BOSS.MDL HKNIGHT.MDL TELEPORT.MDL
DEMON.MDL INVULNER.MDL V_AXE.MDL
DOG.MDL KNIGHT.MDL V_LIGHT.MDL
ENFORCER.MDL OGRE.MDL V_NAIL.MDL
EYES.MDL OLDONE.MDL V_NAIL2.MDL
FISH.MDL PLAYER.MDL V_ROCK.MDL
G_LIGHT.MDL QUADDAMA.MDL V_ROCK2.MDL
G_NAIL.MDL SHALRATH.MDL V_SHOT.MDL
G_NAIL2.MDL SHAMBLER.MDL V_SHOT2.MDL
G_ROCK.MDL SOLDIER.MDL V_SPIKE.MDL
G_ROCK2.MDL SUIT.MDL WIZARD.MDL
G_SHOT.MDL TARBABY.MDL ZOMBIE.MDL

Blinking lights are the #1 slowdown for the Quake engine. If you do a R_SPEEDS 1 on your level, and the last number ( xx surf ) is over50 for any constant time, your level is going to be WAY too slow. What that means is that the engine is redrawing xx surfaces every cycle. Even though Quake's surface cache is the fastest out there, its not that fast.

In english: *Don't make every light and torch in your level flicker/blink/or fade!! *If you have a big complex room with lots of surfaces, don't even put *1* blinking light in there. That single light will affect every surface in that room (if its bright enough) making the surface redraw jump extremly high, and slowing down performance greatly. *If you do use a blinking light, do it in places where there will be low traffic, or where players wouldn't be firing rockets at any given time. A rocket dynamic light acts upon the surface cache just like a blinking light, and if you have two or three players in there firing rockets at each other, ON TOP OF blinking lights in the level, the players will get tremendous slowdown. *This dosen't mean that you can't use blinking lights in places, just use them right. Many levels I look at would play very well if they were not ridden with blinking lights.

There are REASONS why all the torches in Quake don't flicker. On another note: I mention that over 50 updating surfaces can be extremly slow. This perticular figure is for those of us with P133's and under. People with P150's+ don't see as much slowdown from this, but if there are lots of blinking lights, even the 166+ people will suffer.

IN OTHER WORDS: Quake is almost the first game along these lines that level designers can directly effect the playability of a level just by adding a subtracting a spawnflag or two. Doom was almost untouchable with this stuff, and duke only got bad if you layered lots of sprites and lots of sectors. Keep Quake levels fun for everybody, This is one of the easiest ways to ensure smooth framerate for ALMOST everybody :)

I've seen a lot of very cool levels out there that have suffered greatly from this problem. I would love to see them without the slowdown!

John Carmack wrote the light.exe program for a specific reason, SO **LIGHTS** COULD BE PLACED ON LEVELS, SO PLAYERS COULD SEE WHERE THEY ARE GOING!!!!!! Dark hallways are very cool, I do agree, but not when you have to manuver your player in unique ways, and you can't see where you are going. Leave this one up to yourself, and always ask yourself "is this REALLY fun?"

Framerate is considered to be God by professional level designers. What console commands are used to test the framerate; more importantly, how should this information be interpreted? (e.g. the numbers in R_SPEEDS.) What is the guiding standard you employ?

- Steve Fukuda

Levelord's response:

...framerate is NOT a god, it is the devil itself ;) I'd have to say that this is THE concern of mine. Conceiving a cool theme and cool geometry are probably more "important", but they come to me easily and aren't, therefore, a concern of mine.

I use 3 console commands to control framerate: R_SPEEDS, R_DRAWORDER, and R_DRAWFLAT. R_DRAWFLAT will display all brush surfaces as untextured and solid-colored. This can be very helpful in witnessing exactly how BSP cut-up your original brushes, especially when you make irregular, non-rectilinear shapes. Often I will find that BSP has cut-up a cool looking door into hundreds of small, subordinant polygons. This door will be a huge tug on the framerate and I'll usually get rid of it.

R_DRAWORDER is another great tool for controlling framerate. It will display the current view in reverse order; that is, instead of blocking rooms and such that are occluded by obsticles in the foreground, it will display them. These occluded rooms and views, although not "seen", are being included in the overall view's calculations and are an otherwise unseen destroyer of good framerate.

The most useful tool for controlling framerate is R_SPEEDS. This command will display a list of numbers that bear directly on the current view's framerate. These numbers are, from left to right: (1) game cycle time (how long each game cycle is taking in milliseconds), (2) total polygon surfaces in current view, (3) total polygon surfaces actually drawn in current view, (4) total visible (but not drawn) polygon surfaces, and (5) total number of polygon surfaces affected by dynamic lighting.

Game cycle time is obviously the most direct measure of framerate performance. However, since computer platforms are so varied, it is best to pay more attention to the polygon-related numbers. Keeping the polygon-related numbers down will insure, no matter what type of machine your level is being played on, it's performance will be optimal. The next 3 numbers are self explainatory. Make sure you keep a good watch on the fifth number - surfaces affected by dynamic lighting - each time a surface is relit, it has to be recalculated.


The Designer's Guide to Multiplayer Gameplay by Charles Kendrick


Ammunition


 Enemies


Powerups


Weapons


Keys


Secret Places


Deathmatch


Always expanding, playtesting/level 'balance' ideas/methods you think might fit here...all contributors given due credit!