Multitexturing (multipass with Voodoo1, single pass with Voodoo2) would allow for using texture decals, that is, small patches that do not tile/repeat, and are added on top of the base texture.
Examples that John Carmack already considered are shadows and specular highlights. If set during editing, such patches would add detail without multiplying the textures (thus avoiding texture cache problems). If set at runtime, these could be used to add graffiti/bullett marks to the walls at runtime.
The interface in the DLL would be a function that allows adding a (temporary) patch to a surface decriptor.
It should be possible to add decals below and on top of the illumination textures, the latter being fullbright.
Lens flare, light bulbs, explosions, clouds, basically anything that can not be represented by polygons, or that some artists would rather like to paint than model, can be done by one or several overlapping quads or triangles with an RGBA texture mapped on it.
Mipmapping avoids having the sprites stick out of the polygon scene, otherwise aliasing would be noticable.
Sprites are different from RGBA mipmapped translucent polygons (walls, floors) in that a polygon has a fixed orientation in the world, while a sprite has a fixed orientation with respect to the viewer. Quake supported several varieties, it would be great to get this support in Q3, and to have it exposed in the DLL so that a sprite could be created as a temporary entity or edict during the game.
Sprites will look awful when intersecting passable surfaces (water). OpenGL (and most hardware) does not support depth mapped sprites. Sprites also look bad when rotating an asymmetric object (a tree). The latter effect could be overcome by using several sprites, so the basic primitive (the sprite model) should be a set of quads/tris plus a set of RGBA mipmaps. For the former problem (intersection), use of stencil in OpenGL is possible.
For some effects, the current Q2 dynamic lighting is really efficient. If possible, there should be an option to enable shine-through for point lightsources, that is, lightsources that shine through thin walls, or move within solids.
Has been done for Q1, Q2, Half-Life. If it's possible, it will surely be done, and id does not need us to tell them.
Projective textures as probably used for shadows should be available for game DLL controlled dynamic spotlights. Alpha (brightness), shape texture), and scaling (projection parameters) should be set for spotlight entities.
Might be too expensive. If it's possible, it will surely be done, and id does not need us to tell them.
Sky is a box of six square textures, resolution roughly equal to screen resolution - which is to say, it is way expensive, and runs into the 256x256 limitation of boards like the 3Dfx. Frame animated skys would be even more expensive.
Lightning effects (sky light sourcing), patches/decals (a sun, lightnings). Comeback of Quake1 sky as a low level cloud layer, fading in the distance, added to the box.
Objects/surfaces that could be set on fire. Some materials are less easy to put on fire and will note burn that long. Fire animation is only temporary.
Different techniques have been tried, and could be combined: DOOM-style sprites, Quake-style polygon models, spark-like Quake particles. Smoke would re-use techniques needed for volumetric lighting/fog, and/or Q2 polygon-modelled explosion clouds.
Incremental radiosity. Well, a body can ask.
The Game DLL to be used should be referenced by a "dll" "ctfgame.dll" line in the worldspawn entity. Specifying the DLL to load in a specific map could be overridden by the paths, but would set the default game mode for a map. See plugin wish.
The game DLL should load plugins in the same way the server loads the game DLL. The actual loading should be controlled per entity. See some plugin structure proposals based on multimods done for Q2 for details.
Incorporating 32bit textures in standard TGA format would make it ALOT easier for developers to make textures that not only require no conversion but also look the same way in Photoshop as they do in the game. The only downfall to this that i can see would be the size of the TGA files. In particular the need for palette handling should be removed.
Support for PNG, which supports lossless compression for true color images with non-patented, free compression algorithms, would address the issue of file size.
WAL could be replaced with either paired PCX/TGA or a single PCX with the RGB on top and the transparency on the bottom. SP2 could become MPEG, AVI, or an array of PCX.
Replacing or complementing all the proprietary formats (e.g. WAL, SP2, MD2) with something that is in widespread use, and does not require Q3 specific programs to work with. MD2 could be 3DS, TRI or an array of DXF.
Creating mods/TCs/partial conversions would be WAY easier, presuming that the standard formats as such do not have bugs or deficiencies (e.g. normals invalid).
To use MPEG Layer 3 encoding (MP3) for all music and sound effects. Documentation at ftp://ftp.fhg.de/pub/iis/layer3/MPEG_Audio_L3_FAQ.html#intro Advantage: standard, compression savings. It could mean the difference between a 1 cd game, or a 2 cd game, and homebrew music add-ons.
A3D, preferably the new format, 2.0, from aureal, should be supported. Direct 3d is slower and does not sound as good. I think they missed the boat in quake 2 when they didn't have it. To be able to hear exactly where the enemy (or dm opponent) is coming from would really be nice. If anyone hasn't heard what it is like, ask for the free demo cd from aureal, it is great, trust me.
See Half-Life. Echo, pitch, doppler.
IPphone so you can yell at your team mates to cover the flag. Compression?
Extend the GUI by hooks for Natural Language Processing as with Dragon Systems. See
Video Computer sets PC Gamers Free with World-first Hands-free Headset Controller UR Gear combines hands-free game control with speech recognition and stereo headphones. Streamline design by Ferrari's Paolo Pininfarina www.videocomputer.it/info@worldview.co.uk CONSUMER ELECTRONICS SHOW, LAS VEGAS, Nev. January 8, 1998--Video Computer S.p.A. has announced a multi-function headset that will add a whole new dimension to the way PC games are played. Called UR Gear, this all-in-one product is a true world-first - comprising head-activated 3D joystick and PC controller, and a stereo headphone with integrated microphone. Advanced software from speech recognition leaders, Dragon Systems Inc., is incorporated in the product,
Generate a synthetic voice from ASCII messages, configurable. Based on modules like Terence Senjowskis "NetTalk" (neural net learning phonemes). Not useful for player-player (even if combined with artifical radio static to cover mistakes), but good enough for monsters and gibberish alien talk.
Each Q2 coordinate is described by a 13bit number resulting in a volume of 8192x8192x8192. This is already too limiting in Q2. Large/"wide" connected structures are stopped by the 13-bit limit as it is now. There might be a performance penalty, if the 3bit grid and 16bit processing used in Q2 (and maybe Q3) still has advantages for motion clipping or culling. However, seamless multi-server will require a larger coordinate space anyway.
Does not fit a rendering approach based on PVS, as no convex subspaces can be defined easily. Requires extended mapsize, maybe distance-based haze.
No precalculation, no radiosity, no static shadows. More or only Dynamic Lights, which could be placed anywhere and attached to entities such as Trains.
Previewing levels would be much quicker if lights were all dynamic.
Beyond simple bullet mark decals, in a truly dynamic environment, any brush should be moveable (if not too heavy), or shatter (if damaged enough). There could be shallow damage on any surface (displacement map variation), or cracks in walls, or walls that shatter into bricks.
Select left/right buffer rendering mode from the game, have the two viewpoints defined within the game (maybe model specific, with adjustable FOV etc.). H3D requires a special Glide, the 3Dfx minidriver does not (yet) expose GL_STEREO/GL_BACK_LEFT/GL_BACK_RIGHT.
Along with different resolutions, and maybe framebuffer color depths, support 16:9, and other aspect ratios. Adopt a Normalized Device Coordinates (NDC) approach to on-screen placements of messages, HUD elements etc.
Improve collision detection, and maybe bounding box size. It's too easy to get caught on corners. Navigating around corners tightly doesn't feel realistic to me. Getting caught on the top of objects when trying to jump them also doesn't feel right.
If I can see over a box I should be able to jump over or on it - since there is no climbing the jumping height should be compensated for this. I'm a marine darn it! I can fall 10's of feet but I can't jump that darn box!
Alternatively, it should be possible to climb a reasonably small obstacle the player can't jump over, by pressing the same button used for ladders. Penalty could be that weapon can't be used while climbing with both hands. Height could be checked (body+arm length). See Both Hands animation, too.
See Hand.
Creatures that do not attack, do not attack right away, can not be killed, should not be killed... forces to reckon with, distractions, decoys.
Particle-like movement generation code available for sets of NPC's. AI extensions that make monsters try to avoid or follow each other, keep a certain distance from some, stick to others. For both visual neatness and, on a slower scale, improvements of enemy AI.
Required by builtin bots anyway.
More precisely, simple sensor-effector mappings in compact lookup tables could add a lot to the game. See e.g. Valentine Braitenbergs Cybernetiv Vehicles. ANN based enemy AI requires mechanisms for Reinforcment Learning - it is nice to have ambient creatures doing odd things, goal-orientated (hunting/fighting) behavior is a different problem.
id should include a training bot in the release of Quake 3, client side and/or server side. A server side bot would add some incentive to improving the builtin AI, a client side bot would encourage an engine design which allows using the builtin AI as a client bot toolkit.
With or without master server, with or without encryption, PGP, whatever, a persistent player ID for reference, per client would be nice for homebrew and commercial online multiplayer with accumulated records (see rating).
Without a standard builtin in Q3, and delivered with the product, the current proliferation of proprietary, server specific, or just plain silly rating/ranking schemes will continue. The mathematical background has been done 60+ years ago by Arpad Elo, who designed the ELO ranking scheme used in Chess (and other international gaming based on one-on-one encounters). See some article for details, references and pointers.
Standard rating has to be tied to a builtin DM mode. There is no way to use one scheme for all the different game mods/modes. It is also useless w/o a persistent player ID.
Existing mechanisms for preventing cheating in multiplayer games (e.g. map checksums, network packet checks) from Q1, QW, Q2 should be used and improved in Q3.
Builtin display settings (gl_flashblend), should always be subject to server-side approval, and not executed client side if not approved. Display settings have become utilizied as means to gain advantages in deathmatch. The ability to turn off certain modifications of the rendered image, like full screen blends, also improve visibility of opponents. A server admin should have means to enforce "fair" constraints on participants, or monitor necessary configurations like gamma correction.
Like Symantec's. Besides game patches, it should include options for popular add-ons: CTF, GameSpy, ModSpy ( if and when ... ). The big concern is that it NOT get in the way of the advanced user.
See Quakeworld. Redirect to a Resource Server, so the game is not hampered by late joiners downloading a map. A mechanism to hook in client side is described here.
During shutdown of a (dedicated) server, the current state of the game including all connections should optionally be transferred to another machine that will take over as a server. See here for details.
Keep track of time! I don't know how many countless times I have accidentally wasted three to four hours playing Quake!
A a small "LCD-style" clock as a status bar/HUD component, displaying system time. Could also be used for in game purposes ("Countdown to reactor explosion") time.
Alternatively, a client-side timelimit that kicks out "in 30 minutes" or "at 3am". Could be used for LBE-style setups, at LAN parties, etc. A visible countdown would increase "the experience" in pay-per-minute setups.
Put all public source releases under a license that enforces release of modified sources along with release of any binaries, by including a GNU GPL like regulation. See description. Remove EULA-like time limitations at the same time, effectively using an Artistic License for Open Source that can't be exploited commercially (see X11 R6.4, Open Group, and Mozilla.org/Netscape, Perl, etc.).
Deliver editor, processing tools, resource database etc. along wirth game (same CD), or as separate CD (even product), as Developer Kit. See description.
Put together sounds, textures and anything else from Wolfenstein, DOOM, Quake1, Quake2 that could be useful for editing and conversion, in a 24bpp/16bit sound high quality format, on a single CD, bundled in WAL/PAK by games. Separate CD (Developer Kit), or on Q3 CD. See desription.