I happen to think that the things that would improve the enjoyment immensely are things that have nothing to do with new visual effects, but improving the usability, individuality, reducing the maintenance, and adding communal features. I've made this wishlist of all the generic stuff I would like to see implemented within the rendering engine and gamecode that I think would improve the gaming experience. I'd also be handy to be able to fit a game on a usb flash drive and be able to play it directly.
Procedural Generation of Textures :
If you browse through the textures of games you'll notice that many of them are very similar. Many textures are composites of 2-3 simple textures. For example, the 'tech' textures (from a retexturing project for Quake One) are basically composed of two textures (white and dark marble) which in turn can be generated from a fractal noise algorythim.
My idea is that along with other raster image formats, something similar to a subset of scalar vector graphic (SVG) format be used for procedural generation of textures. Many of the processes that a user would go through in a graphic editing application to create a texture could be done through this scripting. As part of this, an alpha channel could be applied to a greyscale image (see teamskins below). Many team games the textures are differentiated by team color only (usually red and blue).
Eliminating redundancy in textures would dramatically lower the amount of hard drive space needed for textures.
Another advantage that the SVG format has is that it scales without a loss in resolution. A symbol used for the team as a small sign could also be used in a giant flag, a floor texture encompassing the entire team base main area, at any size without pixelization.
Some ideas using this : generate team decal symbols (such as
Threewave Hammer and Lightning Bolt
team symbols), tattoos on player skins, stamping rivets, damage, or vent holes onto a texture. Effects such as adding rust, peeling paint, or 'leatherizing' could probably also be done. Damage skins could be generated realtime by stamping a damage texture to the player's skin at the location of damage. I've always wondered how a colorblind person sees a game. With generated textures, you can do the same thing as stylesheets in web pages - and render high contrast images.
This process may be too CPU intensive for reasonable level load times. If so this would still be a great way to generate static game data during the installation process. For instance, for graphics cards that store the texture data in various compressed formats, it begs the question why not directly generate and store it in a compressed format native to the hardware to begin with? It would save hard drive space, load up quicker, and there would be no artifacts from the conversion process.
An abstract dealing with this issue is at :
Using SVG for graphically rich 2D content in mobile 3D games.
theprodukkt uses procedural texture generation (as well as map) and fits an entire game in 96k. Iikka Keranen's Utilities page has a utility to combine elements from two separate textures into one.
A recent article on the subject : Procedural Textures: Gaming's Future
in which the game Roboblitz saved 90% of the entire game size (480 MB). XREAL's
Texture specs include hardware-native formats.
Teamskins :
Remember the original Super Mario Brothers? The second player played as Luigi who was nothing more than a green recolor of everything red on Mario. Typically, the 'moveable object block' video hardware back then was only capable of a limited pallette, so modifying a register that held the red color to a green value gives a recolor. One thing I think the Quake one engine really got right was teamskins, the ability to have a range of colors in texture replaced at runtime. For those that was before their time, Quake One's ingame multiplayer menu let you select your shirt and pants color for the player's model, using the same source graphic. This saves editing and drive space. For an example. Quake one let you select from 16 colors for shirt and pants for a total of 256 possible combinations. Q3 has the ability to use alpha channels but there was no using this feature from the ground up in the engine. In Quake one, this feature was only available for the player skin (not textures). Teamskins were a great way of letting the user exercise individuality and many used to communicate position (defense, offense, roaming, etc.) Ideally, each player model's skin would be divided into parts based on content - skin surface, body armor, etc.
Featured in : Most Q1 engine derivatives (Q1, Halflife, source ports), Warsow, Doom, also an author who implemented by segmenting models in the Q2 shirt and pants mod has now done this using the alpha channel in his Q3A++ mod. Challenge Promode Arena lets a user recolor different sections on their CPMA skin. Tomaz's Miniracer and Warsow features blending RBG values to generate any of 16 million colors. In its source code Nexuiz, LORDHAVOC's Q1 engine derivative, it lists :
_pants.tga (pants overlay for colormapping on models, this should be shades of grey (it is tinted by pants color) and black wherever the base texture is not black, as this is an additive blend)
_shirt.tga (same idea as pants, but for shirt color)
Jerseys :
I'd like to be able to customize my skins' appearance ingame in a manner similar to a football jersey - a 2 digit alphanumeric and possibly a short name (that would probably be pushing it). Most models obviously won't be good candidates for this, as they weren't designed with this in mind, but I always thought that the cyborg Q2 model would be great for this. Clan letters on the shoulder pad armor would be a nice touch, a couple of numbers/letters on the front/back and name in small letters above that. The 4u2 clan has done this on their skins the hard way (look under members) by putting the number in the skin. Of course the letter color would be selectable, using the teamskins code. Half-life has logos that you can spray paint. I don't find these as useful as it takes active use by the player and you have to go to the part of the map that was painted on. vehicle models have a lot of flat surface area and would be ideal for this such as.
Similar uses : Not jerseys, but Quake 3 Team Arena allowed the player to select from multiple heads for each model.
Featured in : Q3A Alliance CTF / Loki's Revenge (as numbers floating above players but not on skin). Unreal Tournament 2004 puts the player's name on the license plate of the Hellbender vehicle. In FEAR your name is displayed on the kevlar armor on the back of your player. FEAR also shows a selectable icon above team members or just the icon when looking in their direction (if they are not visible).
'Mutator' Programming Structure in the GameCode : So far Unreal Tournament engine based games are the only ones I've seen do this. Basically this allows a great amount of flexibility for modifications and they can run concurrently. For instance you can run runes in any mode - not just a CTF mod. Instagib, Realistic weapons, Advanced server features, cheat protection, or expert scoring used simultaneously. This results in less people having to recode the same stuff needlessly (a lot of mod creators do not share their code) and being more variety in servers. If you look through the details of modifications for games, you'll notice a lot of the same features duplicated in the code.
Simple Map Texture Options :
A large part of playing a fast paced shooter is identifying enemy players against the background. Many Q3 players use a setting that essentially changes the textures to blurred solid colors (r_picmip 5) and lets the players stand out from the background. This is better than most games where there is no option. Unfortunately, it also looks rater ugly - nearly as ugly as Duke Nukem 3D in double pixel mode. My idea is that every texture have an simplified alternate that the user has the option to use instead, procedurally generated.
Similar uses : Evillair's Texture Templates uses a bunch of textures that are used in mapmaking. It seems Warsow being a competition-based derivative of Q3 has simplified maps as a philosopy.
Useless Eye Candy :
Quake 3 and many other newer shooters have started adding a lot of useless eye candy. Specific to Q3 are animated flames, statues, spotlights, torches, gargoyles, light fixtures, imported models, floating dirigibles, etc. Lowering the detail still leaves these items in. It may look nice, but ten minutes after you've seen them, shot them, and tried to rocket jump on them you don't even notice them any more, so what's the point in their being in the level at all? A variable that removes brushes / models that have a 'useless' flag set on them would go a long way - something like cg_no_useless_decorations.
The map that got me thinking about this was a ctf one that has in the flagrooms a statue looming over the flag (finnegan's revenge?). This area is one of the most active battlegrounds and as such should be as low detail as possible.
Optimized dedicated server :
It seems to me that a dedicated server does actually not need any graphical or sound information, so why should it require the data at all? How about just using necessary (non map) data from a text file a checksum for CRC cheating checks on game data so that it wouldn't need massive 500MB of files and graphics? Maps could be complied under a special option to only output data needed for servers.
A specific faucet of the optimized dedicated code that would be of particular interest to me is that it would require much less memory to the point that it wouldn't really require a harddrive and could be put in flash memory. There are rural gamers beyond the distance limit of broadband. A dedicated server onboard a satellite in a
satellite based internet connection
would solve this problem and get acceptable ping if optimized and the gamer's data were prioritized. (Phase 2 is getting a dedicated gaming server satellite launched)
Advanced Server features : There are many things that should be included under this, such as : remotely update gamecode and server files, giving some administration abilities to trusted gamers, high scores, reserved player slots, IP and name filtering, etc without needing to modify source code. One way this has been implemented is in Adminmod for halflife. Perhaps a platform independent scripting language such as python to do this.
Game Community Features :
I believe that community features add a lot to the game. It'd be neat if for instance if the game would flag people who were using the same ISP or geographical region as you. Ever talk to someone and find out that they were at least at one time into lanparties and had a few or were into something you once were at the time? A lot of people pick up games and other things for a period of time and after a while give it up kind of like when you were in college and got together with your friends to watch a certain show. As much of the enjoyment was being with your friends as the actual game itself. Though I wouldn't want to make it where the loser I'd just beaten could look me up in the phone book and call me up at two that morning.
Featured in : Excessive Plus (a Q3 Mod) has a feature where the country of the player is displayed in the scoreboard. (see /set xp_country)
Unix-Type File redirecting : I understand Unix lets you basically say 'if this directory is referenced, then files under another path defined by the user will be accessed as if they were in that directory' . The specific instance I'm thinking of is the quake engine based games where the directory defines the game content for modifications. For instance many CTF mods for Q2 required that you copy the pakfiles into the mod's directory, wasting space. Under the Windows 2000 / XP NTFS file systems, a feature called hard linking allows this for individual files but within the same harddrive volume only.
More info on Windows related filesystem NTFS junction point and Hard link
Multi-User LAN Accommodations :
When I went to college, one semester we played a lot of Duke Nukem 3D. DN3D's size is minuscule by today's standards, but 30 MB times 15 machines alone is 450MB alone. The Unix file redirection would have been nice to require only one copy easily maintainable from one location. (Duke Nukem did not have a directory structure that was mod friendly and would not connect if there was any difference.) Similar to the ability to set the base CD path in Q2, the main config file and command line shortcut (or that OS's variation of it) should be able to specify several paths in which game files could be accessed from. IE, the base directory (ID1, baseq2, baseq3), the mod directory (CTF, Q3F, Runes), and one or more auxiliary directories such as a folder that each user would have exclusive access to that stores your config files. This could be considered a subset of the file redirecting. This would be great in cyber cafes. In the STEAM distribution model, each and every client has to download individually which is a huge hassle for lanparties. If users could get files from other computers on the same lan it would drastically reduce the nuisance this content delivery system creates.
Featured in : Some of the source ports of Doom allow specifying the path to the Wadfiles, Q1 and Q2 let you set the base directory. Q2 also lets you set the CD directory. I think Q3 allows this as well, so they could probably be set up to use game data from a common source.
Skeletal Animation : Saves memory (a spec on Q3TA MD5 models said the memory footprint was 16 times less for the new model format), more animations and realistic player movements. Loading up multiple animated models and all their animations uses up a lot of memory, which is why most people use cg_forcemodel (or the equivalent for games other than Q3) to restrict to one model. All 3DFPSs are going to this so I won't complain about it too much, although I wish ID would release updated Q3 MD4 models (though I am uncertain as to weather Q3 supports them or not, even though some documentation say it does). One thing you might notice about the 4u2 clan's Bomberman model is that it has animated anime-style expression sequences, which uses a lot of memory (relatively) due to the Q2 model format. This is also something skeletal models excel at, and probably the reason Half-life switched to it.
Make useless content optional :
I'm thinking of Q2 and Q3's cinematics specifically, but useless content seems to be a creeping issue. Another useless content issue is music. Most people don't use music enabled in the background, but some games still store it on the harddrive. My solution would be segregate the useless content from the good stuff where it can be deleted if desired.
Q3's Pak0.pk3 is 457MB. The Music in it is 165 MB, the roq files (video) is 116 MB totaling 281MB or 61% of useless content. (Most people disable music and choose to never see the video more than once.) I don't want to come off as beating up Quake 3 too much, but because of my familiarity with it many specifics are from it. UT2K4 has 188MB of music. It's file structure is less familiar to me, so no telling how much more is waste of the 6.36GB (yes it's GB). Halflife 2 has made a step in the right direction by separating it's singleplayer and multiplayer files.
Dynamicly Resizing Maps :
I've only seen this in the RealCTF mod for Unreal Tournament, but this sounds like it could be a revolutionary feature. The idea is that sections of the map close off for smaller player loads. This would result in getting much more use in a properly designed map. Instead of loading up a smaller level, smaller groups would reuse large maps on round changes. Imagine in Torlan for UT2K4 if the number of players dropped below 6, the farthest nodes from the bases were covered up with rock removing them from the game. Ideally, this should be implemented at an engine level so that the extra level content is not draw if unused.
Featured in : Battlefield2. In Unreal 2004 Onslaught mode, I believe this feature could be implemented by disconnecting nodes, and I have seen one map - ONS-Frostbite where there is an alternate node linkage setup that works for this.
Nosferatu is planning on adding this feature, calling it
Map Area Adaption System Quake Team Arena re-released several maps that were modified versions of the ones included in Quake 3. Look at the differences between Q3CTF1 and MPQ3CTF1 and see that this would have been a useful feature.
External Entity File Access :
Here I am talking about modifying 'entities' which are used to define spawn points for non-static items. Some of these items would include : player starts, vehicles, weapons, ammo, and goal items (CTF flags, onslaught nodes, domination points) which obviously have a huge effect on game play. Less obvious items are : lighting, location points (used to say $Playername at $Location, etc), and decorative models / prefabs. Having the ability to redefine where and what items spawn is a powerful method for customizing a level.
What got me thinking about this was the release of the ECE Community Bonus Packs for Unreal Tournament 2004. Many server operators have chosen to edit the original maps to add the newer vehicles, suffixing (ECE) to the map filename. I've also seen cases where the server operator just didn't like something minor like the spider mines on ONS-Articstronghold and removed them. The problem with this is that the new map must be downloaded and two copies of the map stored. With external entity file access, a very small *.ent file would be all that was needed, saving bandwidth. I remember also patching a lot of Quake one levels with either CTF entities or bot waypoint files. There are several Quake source ports that handle external *.loc (location waypoints), *.lit (light sources), and *.vis (visibility for transparent water) files. *.ent file handling is much less common.
With this you could transform an Onslaught level into a Capture the Flag / Domination level. If you developed a custom game type such as Headhunters, it would be much easier add the new entities, like HH's altar. For the original Quake the singleplayer maps could also be used for CTF levels, but only after modification. I'd like a command something along the lines of : changelevel (levelname.map) (entityfile.ent) (secondaryentityfile.ent) where the secondary ent file would be applied after the first. There are also issues as to distribution rights, that this would eliminate.
Featured in :
Fuhquake and
Zquake. See also Q1 Wiki - Entfiles.
Open Standards : As much as possible, all game content and communications protocols should be open. One thing that bugs me about games is that the server query software has to deal with a new protocol for almost every game. As far as I'm concerned games should use a XML based standard for the query response and remote server management. Both query and management of game servers should also be available through a web browser. Many game engines insist on supporting a proprietary texture format, instead of a standard that is easily editable.
Arbitrary Resolution Capable :
With such things as HD television format wars, widescreen computer monitors, rotatable displays, oddball display sizes, varying international standards, and similar it would be really handy for a game to be capable of doing any arbitrary resolution to support the display hardware (without interpolation). Some games support this, but many do not support anything other than the 4:3 aspect ratio resolution. Interrelated to the above Procedural Generation of Textures, which would generate resolution appropriate textures. Nonspecific to 3DFPS, I personally think it would be cool to play 'living room suitable' games such as TEAM17's Worms Series on a 42" widescreen TV with friends when they visit.
Featured in :
Many Quake one ports. Here is A
Tutorial
dealing with how to add custom resolutions (not quite the same thing) to Quake Source Ports.
TigerDave's Widescreen Gaming List
has info specifically on widescreen modes.
Concatenated File Format : Many games use a aggregated file type to store many small files as one large one. This is mainly done because for file systems there is a certain minimal file size so many small files will take up more space than a single large one. Many smaller games do not bother doing this, and waste a lot of space.
Efficient File Formats : This is more pronounced in games that aren't pushing the technological edge or ones that use proprietary file formats, but I think just because gamers typically have hardware in excess of what a game requires that is not reason for a game to inefficiently use resources. Games that use music really should use Ogg Vorbis format like UT2K4 does. One of the reasons the music and sound content of Q3 uses so much space is that it is in wav format. Worms 2 does this as well, but does not have the benefit of using a concatenated file format, further wasting a lot of space. Even a lossless compression format like FLAC would be preferable to wav format.
Scriptable menu system : The menu system should be scriptable to facilitate adding new features. Mainly for adding items that mod authors need, so they don't have to resort to having people manually binding commands to drop runes and such. It shouldn't require creating new graphics, and should be capable of using a resolution independant font. Also, for server side mods it should be able to send a menu to the clients.
Featured in : VENGANCE Quake
Voice communications : Obviously useful for team games. A lot more efficient than typing. Should also use waypoints so that it tells where the speaker is talking from. Just have a way to silence 8 year olds playing the Super Mario Brothers theme endlessly.
Last Modified: April 28th, 2008
