Unreal Engine 1 Announcements Page

The A-team, makers of Action Quake2 and Action Half Life, would like to
announce that we are in active development of Action Unreal Tournament.
Action is the game that lets you experience your favorite action movie
from your very own PC, bringing realism with a fast paced touch. Have
you ever seen a good action movie, and wished your regular old death
match could be as furious, fast, and exciting? Action does that and
more. With the Unreal Tournament engine powering Action, be prepared for
an experience not soon forgotten. Watch for it at:
http://aut.action-web.net

April 15, 1999

Important Unreal 224 Note To Mod Authors

Unreal 224 .u files aren't backwards compatible with past versions of the engine.   So you'll need to take special steps to upgrade your .u files.

To upgrade mods to 224, you'll first need to export your scripts to *.uc files.   You can do this in all versions of UnrealEd^? like this:

1. Bring up the UnrealEd^? class browser on the right side of the screen.
2. Click on the "Load" button and load your mod's .u file.
3. Click on the "Export All" button and have UnrealEd^? export all of the loaded scripts to .uc files (including yours and the engine's), creating a directory structure for all the .uc files: for example, the files from the Core package are in \unreal\core\classes\*.uc.  If your mod is named XYZ, your .uc files will be exported to \unreal\XYZ\classes\*.uc.

In Unreal version 221 and earlier, you can rebuild your mod named "XYZ" from the command line by typing:

cd \unreal\system
del XYZ.u
unreal -make

You can do that now, prior to the release of 224, to verify that your mod has been safely exported and can be rebuilt from the command line.  I highly recommend doing this now, because if you install 224, you will no longer be able to load your old .u files, so you'll have to downgrade back to 220 in order to export them.  Some developers prefer to edit scripts in UnrealEd^?, but many of us actually edit scripts in an external editor (like Visual C++) and use the command-line interface for all production work.

In Unreal 224, we have a new command-line compiler with a slighly different syntax:

cd \unreal\system
del XYZ.u
ucc make

-Tim

Maps, Textures, Sounds, Music are backwards compatible

...so there shouldn't be any problem with existing user maps built with past versions of UnrealEd^?.  I checked this by downloading a bunch of maps from Unreal Resources and Nali City and testing them.  The one "gotcha" is that some user maps being distributed contain .u files, and those aren't backwards compatible, so they will refuse to load until the .u files they depend on are upgraded.

Latest News

I've been awake for way too long, so please forgive my spelling and grammar!

Internal testing of 224 continues.  Things are looking pretty good, though we need to go through a couple more iterations before everything's in perfect shape.

The Adrenaline Vault has a good article on the latest Unreal 224 features.  They spill the beans on the major new feature I alluded to below:

Another major enhancement to be included in 224 is continuous level of detail,which varies polygon counts on objects such as player characters and power-ups relative to their distance from the camera, or player's perspective. In Unreal Tournament, this will enable the engine to place more characters and objects on the screen and still maintain a consistent and fluid framerate. Rein said this is an important feature not just for Unreal and Unreal Tournament but also for engine licensees since it also opens the engine to new game types, such as real-time strategy titles, that were not previously obvious choices for the engine.

Cool Stuff

While I wait for 200,000 lines of Unreal code to recompile, I wanted to point out some more cool things that seem to be under-appreciated.

• WinAmp is a great MP3 music player for Windows; and its companion, ShoutCast is a streaming "Internet radio" companion.  While I know MP3's and Internet radio has been around for a while, WinAmp^? really deserves credit for its grassroots following and overall coolness factor.
• Windows 2000 internationalization support.  This pure Unicode OS will mark the first time Microsoft ships a single binary worldwide, which will be a great leap forward in making it easy to develop games (and applications, and websites...) for the international market.
• MELP 2400 bits-per-second phone-quality voice compresion.  Speech compression research has been making major leaps and bounds lately, as quality voice compression ratios skyrocket.   The latest set of algorithms analyze an audio stream and (to simplify things a bit) transform it backwards to vocal cord excitation.  The resulting compression ratio is in the neighborhood of 100-to-1.  This is a research subject Carlo Vogelsang (Unreal sound engine programmer) and I have been looking into lately, and it turns out to be very complex and math intensive.

-Tim

April 14, 1999

3dfx Voodoo3 Totally Rocks!

I just picked up a carload of the new Voodoo3 3000's; we've put them to good use, as the team is now testing the upcoming 224 patch.

The performance and graphical quality of the Voodoo3 are simply amazing.  Though we've had a board for over a month, beta drivers and pre-release board problems prevented us from realizing just how far ahead of the pack this hardware is.

On the PC, most technological improvements come in little incremental improvements, such that we seldom have a chance to experience a single major leap.  Back when 3dfx introduced the Voodoo 1, that was one of those rare leaps.  Since I've been off working on "OpenGL land" on the Riva TNT, ATI Rage 128, and other accelerators, I haven't had a 3dfx card in my machine since soon after Unreal shipped.  So, for me at least, getting a Voodoo3 and being able to play at those ultra high resolutions at a great frame rate, is another one of those leaps.

While the Voodoo3's fill rate is outstandling, where the card really clobbers all others is its texture management performance.  This is a very important characteristic, because it determines how smooth the performance is from frame-to-frame.   Unreal, though it shipped nearly a year ago, still pushes texture limits harder than other 3D action games, and Unreal Tournament pushes them even harder. 

Unreal 224 performance is also being helped by some new lighting optimizations, and a major new engine feature, which Erik de Neve (Unreal optimization and algorithmic texture guru) has been working on.  But I'm not allowed to talk about that since Mark Rein is writing a press release about it now.

Note: Unreal 220 is incompatible with Voodoo3's due to some changes that were made to Glide; people who have Voodoo3 2000's will need the upcoming 224 patch. 

-Tim Sweeney

March 24, 1999

Stat logging & Global ranking in UT

A press release went out today discussing how Unreal Tournament is going to be using NetGames, USA's stat collection software. I thought I would update the tech page to make it a little more clear on exactly what this means.

NetGames, USA has published a very cool set of stat logging guidelines for games. The guidelines, called ngLog, establish a series of criteria for in-game logging as well as an output format. UT is currently 100% compliant with the ngLog guidelines.

Why is this cool? Well, stat collection during a game allows us to do some pretty neat things. Using NetGames^?, USA's ngStats software, we can take the log files and generate HTML reports on how you played the game. You'll be able to see things like how many kills you got with a certain weapon, who killed you the most, and so forth. Unreal Tournament implements this report generation in two ways.

First, you have local logging. This applies to the single player game, listen servers, and some dedicated servers. When you turn on local logging an unencrypted log of the game is recorded on your machine. The exact contents of the log depend on the game type...for example in CTF you'll get special CTF events in addition to the normal game messages. At the end of the single player game, the log is compiled and an HTML report of the game is generated. You can take a look at the report if you want or you can keep playing. If you want to run a listen server or a dedicated server for a LAN party or a bunch of buddies, than you can turn on local logging and generate HTML for those games.

The really cool thing about local logging is the persistant stat tracking. As you play, all of your scores are tracked to give you a lifetime total. If you play through the entire single player Unreal Tournament with local logging turned on, you can see how many kills you personally racked up during the entire game, your proficiency with a certain weapon, or what bot gave you the most trouble. There is also a link on the main report page that tracks your best game ever...other games are sorted by date. Its really cool to watch in action, especially when you are playing with friends. Building up a database of many games can show some surpising insight into the way you play.

The second type of stat logging is global logging. This is very very cool. Dedicated servers that have an external internet connection can turn on global logging. When a game is played on that server an encrypted log is generated. At the end of the game a batcher is called that sends the log file to NetGames^? USA's global stat compilation server. All of the stats for that game are entered into the global database and the relevant HTML is updated. This allows for some very cool things like: global laddering, player of the week, and clan of the week. You can even pull up your own stats and compare them to anyone else who plays UT online. Don't want to be logged? UT's internal server browser indicates whether or not a server is running global logging.

We are fully aware of methods of cheating and hacking that might be employed against the system. Log forgery is not possible because of safeguards and watermarks built into the ngLog system. There are a couple ways where hackers could ruin global laddering. If this happens, we'll remove the ladder. I'm hoping people will play nice and we won't have to do this, but there are lot of punks out there. Even if the ladder is compromised, there will still be a lot of other cool things, like global game tracking and personal stat tracking. These can't really be compromised, because if you get online and play legitimately than your own scores will reflect that. If you cheat up your own scores...no one else cares. You've only cheated yourself.

I hope this explanation is clear. I'm going to bug Craig at NetGames^? USA for some snappy shots of the system and if he doesn't get back to me I'll just make some of my own. :-P

A couple other things. All of the batcher URLs for the NetGames^? USA executables are exposed in the UT .ini files. This means that util programmers can read up on ngLog now and start on their own HTML generation programs. They can change the .ini reference or write an UnrealScript^? frontend to their util and have UT call it instead. In addition there are two new engine level objects for use with stat logging. StatLog^? and StatLogFile^? can be subclassed for the purpose of writing stat logs that aren't in the ngLog protocol. Finally, mod authors will be able to add their own log entries by making custom StatLogFile^? objects.

<img SRC="ngStats_For_UT_Totals_Small.gif" width="138" height="200">
Here are two shots of local logging [ngStats] and global logging [ngWorldStats]. Click to enlarge. - GreenMarine^?

March 19, 1999

Latest News

We've been going through many iterations of internal testing and improvements on the upcoming patch, which is now known as 223.  Here is the latest list of changes.  The story behind the version number is that each time we make a new version for internal testing, we give it a new version letter (for example, 221a, 221b).  Between the previously released 220 patch and the current one we're working on,  we've gone through more than 52 internal versions.  We've beta-tested two release candidate patches, but each one has required more work.  I don't have a release date for this patch yet, but we're working hard to get it finished.

One unfortunate side-effect of the recent UnrealScript^? improvements (dynamic strings, multi-skin support, other engine enhancements) is that 223 will have to break mod compatibility with previous versions, and require at least a recompile (and code changes in many cases).  We hate breaking mods, because we understand how much pain it causes for mod makers and the community to get back in synch with the latest version, but sometimes it's a necessary evil, as a side-effect of progress. 

One bonus we're putting into 223 to help compensate for the pain and suffering is Jack "Mek" Porter's windowed GUI code, the high-level UnrealScript^? windowing framework we're using for Unreal Tournament.  This includes the graphical "server browser" for finding good servers to play on -- sort of an in-game GameSpy^?. The windowing code will give the community a chance to experiment with windowing well before Unreal Tournament ships.

Level-Of-Detail Texture Mapping

I finally got the chance to write a rendering optimization I've been thinking about for a long time now, level-of-detail texture mapping.

Unreal's biggest performance problem in OpenGL^? has been texture management overhead, which causes frame rates to vary a lot (for example, jumping from 30+ fps down to 15 fps for a frame or two when new textures come into view).  This is especially noticeable on on the Riva TNT, which has a very good fill rate and can handle large polygon counts, but is around 4X slower transferring textures to the card than Voodoo2.

Solution: I create redundant versions of textures, scaled down 4X (in memory usage), 16X, 64X, and 256X. When an object being rendered is far away, I use a lower resolution version of the texture -- which doesn't cause visual problems (since the texture would be mipmapped anyway) but requires less texture data to be transferred.

This has enabled us to boost the Unreal Tournament player models' texture usage to 256K of texels per model.  More info about additional level-of-detail features later...

Future of Programming Languages

Lately, I've been doing research on programming languages, in the interest of gaining new ideas to implement in the successor to UnrealScript^? for our next-generation (after Unreal Tournament) engine.  Some of the topics I've been formulating are:

• Garbage collection (see the <a href="http://www.iecc.com/gclist/GC-faq.html" target="_parent">GC FAQ for background).  UnrealScript^? uses a simple recursive mark-and-sweep garbage collector which is only executed when changing levels, along with some special-case code to garbage-collect destroyed actors during gameplay.  Most implementations of Java use a background thread to run a generational garbage collector.   Java's approach is more general, but can cause pauses during execution as large amounts of garbage are purged, which is bad for frame-rate consistency.
  
  Java garbage collection presents a problem for object finalizers (the equivalent of C++ destructors), because the finalizer is executed at some random time after the object in question effectively becomes garbage, and finalizers of multiple objects are executed in random order.  This limitation makes finalizers dangerous and not terribly useful.   One work-around is to not support finalizers.  Another work-around is to support them, but publish a list of "things that aren't safe to do from within a finalizer" (such as cause finalized objects to become rooted again, make assumptions about finalization order, etc).  UnrealScript^?'s current solution is a mix of the two; finalizers must be native (implemented in C++) and are subject to those safety guidelines.
  
  Another general conceptual problem I have with garbage collection is that, often, the physical lifetime of an object (as defined by the garbage collector) often exceeds the "practical" lifetime of an object (as defined by the semantics of the program you're writing).  For example, a window object in a windowing system is only meaningful when the window is open on screen; after the window has been closed, the object becomes meaningless even though it still exists and other objects might still be referring to the window.  The general problem is that programmers often would like a "way of explicitly destroying an object and removing any other objects' references to it".   C and C++ avoid this problem by making all memory management the program's responsibility.  Java avoids it by making the program responsible for determening whether an object you're referring to is meaningful (for example by calling IsOpen^?()).  It would certainly be nice if object lifetime management and notifications became the full responsibility of the programming language, enabling programmers to instead focus on higher-level problems.
  
  The garbage-collection strategy that would be ideal, from the standpoint of predictable code and memory usage, is to finalize and destroy objects the exact moment they become garbage, i.e. when the last variable still referencing it changes.  I've tried, very unsuccessfully, to find efficient approaches to manage such as system by tracking multiple reference counts, doubly-linked lists of two-way references between objects, etc etc etc, and haven't been able to find an approach more efficient that performing a brute-force mark-and-sweep pass every time a reference to an object changes (plus optimizations such as reference counting to collect objects without cyclic references).  Stated in graph theory, the question boils down to "Given a graph and a particular directed edge of the graph, does removing that edge break the graph into two disjoint pieces?"   Does anybody know if there is a graph-theory algorithm for determining this, which enables you to add a directed edge to the graph in constant time, and also remove an edge and determine disjointedness from that removal in constant time?
  
• LISP defines a new kind of object called a "function closure" which basically represents a pointer-to-a-member-function with several of its parameters bound to specific values (for example, binding the implicit "Self"/"this" parameter to a particular object.  This is a great object-oriented generalization of function-pointers, but the syntax becomes fairly complex in a statically-typed language (some issues you run into are recursively-defined closure types, and cyclic closure types).  Microsoft's Java extensions in Visual J++ include a simpler and more limited type of object called a "delegate" which is a pointer-to-a-member-function bound to a specific instance of an object.  I plan to experiment with these possibilities and implement "something along these lines" in the next engine.
  
• Inner classes, as defined by Java, are a great feature for attaching objects together hierarchically.  This is definitely a feature I want for the future.  One example area where inner would simplify and generalize the code is Unreal's actor lighting support.  Currently, the Actor class has a bunch of variables related to lighting (LightBrightness^?, LightHue^?, LightSaturation^?, LightEffect^?, etc), and an enumeration LightType^? that describes the light's overall mode of operation.  While this is an improvement over past engines, and general enough for 1998-1999 games, it could be much better.  Actors could instead reference a separate Light object which describes the lighting in a more general way.  Instead of having a hardcoded enumeration for light effects (such as LE_TorchWaver, LE_Cylinder, LE_Spotlight), all the different light types could be represented by separate classes (TorchWaverLight^?, CylinderLight^?, SpotLight^?) with the class supplying the appropriate spatial and volumetric lighting math.   Additionally, the lighting objects could be made hierarchical, so you could modulate a cylinder light by a spotlight, and add a torch wavering effect on top.   New light classes could be defined modularly to supply new lighting functions without modifying the engine source.

While my plan for the next scripting language is gaining more clarity, there are still a lot of wide-open issues.  For example, whether Java-style interfaces are necessary (since most of the same functionality can be obtained from inner classes), what the final garbage-collection strategy is, how similar do we want to make the language to Java, etc.

Visible Surface Determination

One of the biggest next-generation challenges for 3D programmers will be in solving the "visible surface determination" problem for complex scenes.  Doom basically used a densely portalized BSP scheme; Quake used a BSP in conjunction with precomputing the visibility from each BSP leaf in the world to every other leaf, trading off precomputation time in exchange for rendering performance. Unreal uses a sparsely portalized BSP tree and performs a software span-buffering pass to determine which polygons are visible prior to actually rendering them.  None of these approaches are clearly superior to the others; they each have strengths and weaknesses.  Unreal's tradeoff enables us to render more complex multi-pass surfaces (very high-res textures, detail textures, light maps, and fog maps) but limits our polygon counts, since rendering performance grows approximately as "n log n" with polygon counts, compared to Quake's basically linear "n" scaling.

The visuals of Unreal Tournament vs. Quake 3 Arena will provide a very useful equal-footing comparison between the two techniques, with id Software is pushing the limits of polygon counts, and us pushing the limits of texture detail.

After this generation of games, I think we'll all have to fundamentally change the way we approach the visibility problem.  As 3D worlds grow larger, more seamlessly interconnected, and more vibrant in terms of dynamic and procedural geometry, we'll need more of a no-tradeoffs approach than precomputed visibility or BSP's.  Portal and anti-portal clipping schemes look promising.  Hardware-assisted visibility tests (such as HP's <a href="http://www.opengl.org/Documentation/Version1.2/HPspecs/occlusion_test.txt" target="_parent">OpenGL occlusion test extension) look promising.  Even the good old DFE scheme becomes more practical with increased 3D hardware performance.  After Unreal Tournament, I'll be experimenting again with all of these techniques.

Commentary on Cool Stuff

I just wanted to point out the following cool technical things.

• OpenGL <a href="http://www.opengl.org/Documentation/Version1.2/EXTspecs/fragment_lighting.txt" target="_parent">Fragment Lighting and <a href="http://www.opengl.org/Documentation/Version1.2/EXTspecs/light_texture.txt" target="_parent">Light Texture extensions.  These exceedingly clear, general, and well thought-out rendering capabilities are going to be the next quantum leap in 3D hardware acceleration acceleration, enabling true Phong/Blinn bump mapping and a tremendous variety of other features.  My reaction to seeing this spec for the first time is reminiscent of first experiencing 3dfx's Voodoo accelerator and the Glide API--it's "I can't believe how powerful yet simple this is to work with".
• Hyperbolic Tree Controls: This is the first generally useful new GUI control I've seen in years. Imagine the possibilities for using hyperbolic trees to browse the actor lists and server interconnectivity of huge interconnected online worlds.
• Burrows-Wheeler Data Compression: A new, unpatented approach to data compression; trivial implementations can easily beat PKZIP.

-Tim

February 12, 1999

Cool Unreal resources on the Net

This UnRoyal site contains reviews of single-player maps and a top-ten list.  If you want some new Unreal single-player action but don't like digging masses of levels, go check it out! It's a very useful site and it's currently under-appreciated.

In contrast, Unreal Resources is for people who want to see it all...it's a massive site containing nearly all deathmatch maps and Unreal mods in existence.

Playing modem Half Li..., um, I mean, Unreal

For people who want to play direct modem-to-modem multiplayer, the Atomic Half-Life site has a good article on configuring Windows for this, which will work with most Internet playable games.

-Tim

February 10, 1999

Latest News

Progress on Unreal 221 and Unreal Tournament continues.  We are making changes and improvements at such a fast pace that it has been hard/impossible to stabilize the code for the 3-5 days required to fully test a new patch.  I apologize for the earlier false start we had with 221.

What we've been programming

I've been juggling work on the installer, OpenGL^?, and some core UnrealScript^? improvements.  The installer is coming together, and is complete in terms of installing the retail game and patches, but more work remains to be done on uninstallation issues, and improved support for installing/distributing mods.  Some of the latest UnrealScript^? improvements include a command-line script compiler, which can be used from any programmer's editor (or Visual C++) with standard output of error messages; UnrealScript^? execution optimizations; and support for dynamic strings.

UnrealScript's string support has been pretty solid all along, as a result of using BASIC style functions (Left, Right, Mid, InStr^?, Chr, Asc...) instead of C's error-prone string handling functions (strcpy, strcat, strcmp, sprintf).  The one annoying limitation, which has been the source of some bugs in the past, is that strings were fixed length.  221 supports dynamically sized strings with no practical size limitation (just available memory).  This makes it easier to write text-processing routines, which the new in-game server browser is really stressing.

Steve Polge has been improving the AI and the flexibility of the game code.   Because Unreal Tournament's gameplay can be far more complex than Unreal 1's (from a bot's perspective) as a result of team play and Capture The Flag, Steve has been teaching the bots a lot of new techniques for coordinating together and better understanding the environments.  It's sooo cool watching Cliff and Myscha playing CTF with a few bots on their teams.

Jack Porter is hammering away on the new user interface code and the in-game server browser.  In the past, first-person action games haven't been known for having good user interfaces.  We're hoping to change that, and go for the quality level of an EA Sports interface.  Sticking to our general-purpose roots, Jack isn't just creating user-interface code for Unreal Tournament, he's creating a flexible, object-oriented UI framework which will be very suitable for licensees and mod makers.

Brandon Reinhart is working hard, implementing a lot of the Unreal Tournament game code, the single-player progression, stats tracking, and much more.  The stats tracking is going to be a very cool feature for Internet play; perhaps I can convince Brandon to write a note about it here.

Erik de Neve, who created Unreal's algorithmic fire and water effects and optimized much of the rendering code, is working on a next-generation project that will make its debut in Unreal 2.

Linux Notes

We now have a command-line (windowless, console based) script compiler and server for Unreal, which has minimal dependencies on Windows.  This is a first step towards a Linux port, and it also runs very well under Wine, with minimal overhead.  This might be a good interim solution for Linux server administrators, before the full port is done.   I just noticed in GameSpy^? that the top server on the list is titled "CHiX Unreal NT Server (220) PORT UNREAL TO LINUX".  Hint taken. :)

We actually have the Unreal 221 Core source compiling under EGCS 2.90.29, C++ templates and all.  Getting the thing linking and running successfully will require a lot more work, which we won't be able to focus on until UT ships, but the experience thus far has been very positive.

-Tim Sweeney

January 28, 1999

Unreal 221 Development Update

Unreal 221 development continues, with quite a lot of new features slipping into this version.

Right now, Mark Poesch (the lead programmer of Wheel of Time) is visiting us here in Raleigh, merging in some of the improvements the Legend team has added into the Unreal engine for WoT^? and Legend's upcoming Unreal level pack.

I'm working on Unreal's OpenGL^? support, and will soon get a version of the code to the 3D hardware makers who have some driver issues to work out.  The Riva TNT is currently the fastest and most stable card, with the ATI Rage 128 looking very promising, especially in 24-bit color.

I'm also extending the Unreal installer which shipped with the 220 patch, turning it into a full-blown installation program for future patches, shareware versions, and retail versions.  I'm also contemplating extending it to support Unreal mods, which could then be distributed in a self-contained format (.uzip?) which Unreal automatically knows how to install.  This would put cool mods just 3-4 mouse clicks away from users who are browsing mod sites like Unreal Resources, a great improvement over the current process of "download a file, run PkZip^?, extract the .utx files to the Unreal\Textures directory, extract the .unr files to the Unreal\Maps directory, run Unreal, then try to figure out how to launch the mod".   This has the potential to bring mods to a much wider audience.

While I don't enjoy the painful and redundant task of writing an install program, I see it as worthwhile because it's such a critical piece of a game--especially one which is supported by an online community and third-party licensees.

Unreal Tournament

The rest of the team is hard at work on Unreal Tournament, and we're really happy with the way the game is shaping up.  Unreal was such a huge, multi-faceted project that we weren't able to focus on deathmatch as much as we would have liked.  Unreal Tournament, with its identical gameplay style between single-player and multiplayer (the only difference being bots vs. human opponents) has given us a far more opportunity to polish the gameplay and the look-and-feel.

-Tim Sweeney

January 7, 1999

Demo Recording

Unreal finally supports demo recording! I have spent the last few days implementing server-side demo recording, based on Unreal's generic networking code. It currently supports recording demos of multiplayer games on dedicated and non-dedicated Unreal servers, as well as recording Botmatches. When played back, you can watch the game from the perspective of any of the players, or fly about the level at will - just like you can as a spectator in multiplayer games. This will be available in an alpha form in Unreal 221.

Multiplayer client-side and single-player recording are not fully operational yet, although it should currently be possible to record demos on a co-op play server. Testing and bug-fixing of 221 continued on Wednesday, but there's still a litte more to be done before we can release it.

- Jack "Mek" Porter

January 4, 1999

Unreal 221 Not Yet Available

Currently there is a bad UnrealBeta221^?.exe patch being distributed around the net. This is NOT Unreal 221. Please do not download and use this patch. Sorry about the confusion.

- Brandon "GreenMarine" Reinhart

January 1, 1999

Happy New Year

The team is now getting back together from the holiday and we'll get back to Unreal 221 development first thing tomorrow (Saturday).  We were on the verge of releasing the patch right before Christmas, but we're now back to being a few days away, since I added some new features that need re-testing, and some additional bugs have been found.

For me, the holidays were fun and productive.  I hauled my computer up to Maryland for a one-week visit with my parents, and that provided a good excuse to work on engine improvements and new R&D in a zero-distractions environment.  Without getting to deep into the details, here are some of the things I worked on:

• Unicode Unreal.  I finished up 16-bit Unicode support; now the Unreal code base can be recompiled for the ANSI (8-bit) or UNICODE (16-bit) character sets.  This has several advantages.  First of all, localizing a game for non-Roman languages (such as Japanese, Chinese, Korean, Hebrew, Arabic) is easy with Unicode.  Second, we're really interested in Windows CE, and that is a pure Unicode OS.  Windows CE is the native operating system of the Dreamcast, so Unicode is a natural stepping-stone along the Dreamcast porting path which we're exploring.   Windows CE is also used in tons of palm-top computers.  Now, none of these palm-top computers are currently interesting from a gamer's perspective, but if you extrapolate their grown--in terms of video resolutions, RAM, and processing power--along a Moore's Law curve, they're not that many years away from being comparable to low-end Pentium II PC's today.  I like to think that the GameBoy^?'s of the future won't be a closed platform, but rather run a standardized OS like Windows CE.
  
  All Unreal data files are "character set neutral", meaning they can contain any mix of ANSI and Unicode characters, and they're automatically converted/truncated at load time.  Network play similarly "just works" between the Unicode and non-Unicode versions.
  
  Regarding Unicode font issues ("who's going to paint all those Japanese characters?"), Jack Porter has built a TrueType^? font importer into UnrealEd^?, which converts any Windows TrueType^? font to an Unreal-compatible font bitmap.  This is an essential part of our Unicode efforts, but also ties into the new user interface he and Brandon are building for Unreal Tournament.  There are lots of Unicode fonts with support for nearly all Windows-supported languages, so localizing games into all languages should be fairly painless.
  
  
• Data compression.  I spent a couple days experimenting with various compression schemes and found some interesting results.  First of all, it's fairly easy to achieve PKZIP-quality compression--the algorithms are well documented and easy to implement.  Second, it's nearly impossible to beat PKZIP by much of a margin.   Beyond the standard algorithms (Huffman and LZH compression), I experimented with many variations, including:
  • "Double" Huffman-compressing each character in a file then recursively merging compressed regions together into spans, with the goal of compressing "different types of data" with different encoding tables.  This approach came out neutral: there were huge gains in compression, but they were offset by having to store lots of Huffman tables.
  • Trying Huffman compression in bases other than 2 (such as 3, 5, and 7): no overall gains.
  • "Infinite sliding window": An LZH-style scheme that spends a huge amount of CPU time on compression by analyzing an entire file for differences.  Here, the gain was typically 10%, but it was unbearably slow to work with.
  • Arithmetic encoding.  This is a Huffman-style scheme that employs some basic number theory to generate a compression table using arbitrary bases (other than base 2).   This gets real gains of around 10% compared to Huffman, but is much slower to decode because it relies on arbitrary-precision integer math.

  I didn't get the compression code into the Unreal master source (it was standalone R&D).  I'm considering supporting compression for client-downloadable files in Unreal Tournament, to make it easier to go onto servers running custom maps.  My most usable compression scheme got 4:1 compression on .unr and .u files (nice!) but no significant compression on textures and sounds.
  
  Unreal's textures compress poorly for an interesting reason: they are already stored using palettes, which are a form of compression.  Furthermore, the process of generating an optimal palette for an image yields an array of bytes which are distributed near-uniformly, which is the worst possible case for variable-code-word compression.   I think the state-of-the-art in texture compression will be S3's real-time S3T/DXT scheme, which is fairly lossy, but optimal for real-time decompression while rendering.   And it's 6:1 for all possible kinds of data.

  One interesting technique I played around with for texture compression is wavelet compression.  The 2D wavelet scheme for textures is quite similar to mipmaps: to oversimplify a lot, you represent an nxn image as a sequence of 1x1, 2x2, 4x4, 8x8 ... nxn.  Each bitmap is stored as "signed differences" relative to the lower-res versions of the bitmap.  Wavelets are a good starting point for lossy compression schemes, because the "most visually noticeable" details are in the low-res bitmaps, and in the high-frequency portions of the high-res ones.  So, it's fairly easy to filter out unimportant details and compress what remains.  Wavelets are also nice because you can generate all your texture's mipmaps from a single wavelet without any overhead.  While I don't think wavelets will play a role in our future texture-mapping plans, they look more useful as a way of storing and manipulating height maps and displacement maps.  Wavelets provide a very efficient, "level of detail"-aware form of storing 2D surface geometry.

• 3D API's.  I spent a few days learning the basics of curved surface rendering, which turned out to be very interesting.  I was going to do my research with Direct3D (under Windows NT 5.0 Beta 3 RC0) but the 3D hardware support isn't quite there yet, so I took the opportunity to learn OpenGL^? using the software rasterizer and 3dfx's OpenGL^? minidriver.  Both renderers were extremely stable and easy to use.   To my amazement, I never experienced a "blue screen of death" or had to reboot--quite a difference from my past work with Glide and Direct3D!  (Note: I haven't been very closely involved in the Unreal Direct3D and OpenGL^? support, which has been developed by our partners, so this is my first really in-depth experience).

  OpenGL's approach to window management turns out to be extremely simple and reliable.  I went from zero to having a spinning cube up and running in under 30 minutes.  The tools GL provides for polygon drawing are extremely simple and powerful.  For just drawing a few lone polygons, glVertex() and its associated functions are super-easy.  For drawing complex meshes, GL's approach to providing separate client-side arrays for vertices, colors, and texture coordinates is very easy and efficient for multi-pass rendering, since you can swap out one table (say, texture coordinates) without affecting the others.

  OpenGL's texture approach (glTexImage2D and glBindTexture) are also very simple and powerful.  I remember back under DirectX5^?, trying to upload a texture to hardware.   I spent 4 hours trying to figure out the code and rebooting my computer as it repeatedly locked up.  I spent less than 15 minutes figuring out OpenGL^? texturing and implementing it.  Comparing both API's texturing approaches, OpenGL^?'s texture management is absolutely the right way to go.

  • It's extremely foolproof--you call 3 textures to create, upload, and delete textures.   Nothing can possibly go wrong!
  • There is no bizarre/mysterious emulation going on.  For example, in Direct3D you can modify a texture by Lock()ing it and writing to "video memory" directly.   But, on some hardware (like the Riva TNT), the hardware stores textures internally in a "swizzled" format you can't access directly.  So some emulation thing has to go on behind the scenes where multiple copies of the textures are maintained and copied around.
  • OpenGL hides the inner details of texture management from the app, enabling the driver to be optimized for whatever style of texture management is best for a particular 3D card.   In OpenGL^?, a driver writer has total control over texturing and can optimize the hell out of it.  In Direct3D, the API hides the application from the hardware and vice-versa, which makes it impossible for a game or a hardware driver to implement good texture caching.

  Here's a link to OpenGL information and DirectX information.

• Curved Surfaces. I became familiar with a bunch of different techniques.  Curved surfaces pose the same kind of dilemma I felt when writing Unreal's software renderer: there are lots of mutually incompatible approaches to choose from, but no really clear favorite.  Each technique has some desirable strengths, but no technique combines them all.

  My first experimentation was with bicubic bezier patches, which are a great primitive for building curvy shapes without holes between patches (as with polygons, continuity can be guaranteed by having adjacent patches share vertices and control points).  However, they require a fair amount of math for tessellation and, though continuity can be guaranteed, it's hard to join patches together smoothly (with a continuous normal vector across adjacent patches), especially during animation.  I'm pretty sure these will be a key primitive in the next-generation engine.  Beziers are very intuitive to model with.

  The tensor-product math for bicubic bezier quad patches can easily be modified to enable "bicubic bezier triangles", which can share edges continuously with quads.  I haven't been able to find any references on this, but I derived the math, and it seems to work.

  Then, a totally different approach can be used to generate smoothly curved surfaces of arbitrary topology, using a technique known as "subdivision surfaces".   This looks promising: approximately the same overhead as Beziers, but a bit more general.

  All of the above approaches can also be modified to support displacement maps, for creating more organic geometry.  While it will be a long time before 3D hardware supports sufficient triangle densities for displacement maps to be practical for fine surface detail (such as rocks and bricks in walls), they're very applicable to terrain and coarse surface detail.

  There are two even wilder curved techniques I experimented with and found to be quite promising, but I don't want to get too far off on that tangent.

  No, Unreal Tournament will not contain any curved surfaces.  While curves are cool and we'd love to have them, we've been totally focused on core game play, networking, and user-interface enhancements for UT.

  One thing that has become extremely clear in my curved-surface rendering research is that editing tools will be a make-or-break factor in the success of next-generation level design.  UnrealEd^? is a pretty feature-filled polygon based editing tool, but we're going to need a lot more than that for the next generation.  So many features that were trivial with polygon engines--such as texture alignment, light map placement, primitive building tools, object alignment, and freeform object editing--become more complex when curves are involved.  The editing tools will need to be more powerful and intuitive in order to compensate.  Editing tools will be a huge focus for us going into the next project.

-Tim Sweeney

Other Updates

• We updated and coolified the Unreal Technology Partners page, which lists all the announced Unreal engine licensees. 
• Alexander Brandon updated the Music composition page.
• Dave Carter's Nerve Damage contains lots of cool resources for Unreal modelers and animators.

December 27, 1998

Unreal Resources

Morn has reopened unreal.org to serve as a comprehensive Unreal resources page. In addition to basic pointers to news, mod authoring, and mapping information, he's running a few local newsgroups you can obtain from news://unreal.org.

Hope everyone had a great Christmas. I know I did. Sleater-Kinney is amazing.

221 will be out any day, right now I'm the only dude here in the offices and while I could release the patch, I need word from Tim on whats up first. Laterz,

Brandon "GreenMarine" Reinhart

December 23, 1998

We're going to hold off on the upcoming 221 update until after Christmas.  A few minor issues remain and, with most of the team away or inaccessible for Christmas, testing has been going slowly.

Have a safe and happy holidays, everyone!

-Tim Sweeney

December 21, 1998

Unreal 221 ReadMe^? file

For the curious, here is ReadMe221.htm, the list of bug fixes for the upcoming patch.  Also, we translated the original release Unreal ReadMe^? File to HTML.

221 internal testing; installer underway

We're still testing and tweaking 221 internally.  It's really stabilizing well, though it's still a couple days away.

Work continues on the new Unreal installer and patching program.  While this might not seem like a very good use of Unreal development time, PlanetUnreal's survey indicated that 17.1% of the respondents encountered problems installing the 220 patch.  So, this was a pretty important thing to fix.  Here's a screenshot.

-Tim Sweeney

December 19, 1998

Unreal Licensing Information

Since I get a lot of emails about this, I went ahead and added the Unreal engine licensing information to the page here.  See the links under "licensing" in the frame on the left.

I also went ahead and posted the remaining Unreal licensee documentation.  Most of this info will only be useful to mod authors after the C++ code is released with 221.

Unreal 221 Status

We're wrapping up the bug fixes and testing it internally now.  It's near release, but it could take us 24-72 hours to go throught the final iterations of testing.   The 221 patch just incorporates minor bug-fixes to 220 based on feedback from gamers; it doesn't contain any significant new features or optimizations.

For 221, I've also been writing a real installation program, since we've received a lot of support questions along the lines of "I downloaded UnrealBeta220^?.zip, now what do I do with it?"  It turns out there are a lot of issues with people not having WinZip^?, old versions of Zip/WinZip not supporting long filenames and refusing to overwrite read-only files, and uncertainty over where to unzip the patch files.

-Tim Sweeney

Improved skin and mod support in Unreal 220

The menus in Unreal 220 determine what player classes, game types, weapons, and skins are available by scanning the .int files.  Each package (.u file or .utx texture file) should have an associated .int file which can specify what new objects can be found in that package.  This allows mod authors to have their new content seamlessly integrated and available from the existing Unreal menus.

To add new skins, you should create a utx file containing only skins for a specific mesh.  The utx name should begin with this mesh's name, for example "male1skins2" or "female2skinsCTF".  This utx file goes in the Unreal\Textures directory, while the associated .int file (with  the same name) goes into the Unreal\System directory.  The .int file should specify what skins are available in the .utx file using the format

[Public]
Object=(Name=Male1Skins2.JMale2,Class=Texture)
Object=(Name=Male1Skins2.JMale3,Class=Texture)
Object=(Name=Male1Skins2.JMale4,Class=Texture)
Object=(Name=Male1Skins2.JMale5,Class=Texture)
Object=(Name=Male1Skins2.JMale6,Class=Texture)
Object=(Name=Male1Skins2.JMale7,Class=Texture)
Object=(Name=Male1Skins2.JMale8,Class=Texture)

Male1Skins2 should be replaced with the package name (the name of the .utx file).   When importing the skins into the utx file, do not give them a group, since this will confuse the skin name parser.  As an example, you can create a .utx file containing the "hidden" Male1 skins.  Open UnrealEd^?, and from the Textures browser select and export the skins JMale2 to JMale8 (using the export button in the bottom right hand corner).  Then import all these skins into a new .utx file, Male1Skins2 (you should specify this as the package name).  Save this package, and the use notepad to create a Male1Skins2.int file in Unreal\System.  It should include the lines above, listing all the skins contained in the .utx file. Or, if you're lazy, you can get male1skins2.zip.

You will also want to reference this new skins package in the ServerPackages^?[] list in unreal.ini so that your server will download this package to clients if necessary.

If you have created a new game type (a subclass of GameInfo^?), with a class name of   "Mayhem", and the name of your package is "Bloodshed" , you can make it visible to Unreal menus by adding the following line in the [public] section of Bloodshed.int:

Object=(Name=BloodShed.Mayhem,Class=Class,MetaClass=Engine.GameInfo)

If you also created a new weapon "BlastCannon", you can make it visible to the Unreal menus by adding the following line in the [public] section of Bloodshed.int:

Object=(Name=Bloodshed.BlastCannon,Class=Class,MetaClass=Engine.Weapon)

Finally, if you also created a new player class ( a subclass of PlayerPawn^?) called "Executioner", you can make it visible to the Unreal menus by adding the following line in the [public] section of Bloodshed.int:

Object=(Name=Bloodshed.Executioner,Class=Class,MetaClass=UnrealShare.UnrealiPlayer)

- Steve Polge

December 18, 1998

Unreal Tournament notes for mod authors

I've had several inquiries from mod makers about how hard it will be to "port maps and mods from Unreal 1 to Unreal Tournament".  The answer is, port?  What's this talk of porting?  This stuff just works.

Steve Polge put a lot of effort into updating the Unreal 220+ game code so that it integrates seamlessly with Unreal Tournament.  Both products install into the \Unreal directory, and are mutually compatible.  So, you can install one, the other, or both -- and existing maps and mods which are compatible with the latest version of Unreal, will be fully compatible.

For convenience, Unreal Tournament ships with all of the script packages from Unreal 1 (including UnrealShare^?.u and UnrealI^?.u), all of the .utx files, and all of the .uax files.   Unreal Tournament is a superset of the Unreal 1 with the exception of the Unreal 1 maps and music.  All new UT content (lots of scripts, textures, sounds, game types, and new actors) are designed to interoperate with the existing ones in Unreal 1.

The new player code is implemented in a subclass of UnrealIPlayer^?, which means that Unreal Tournament players will work in user-created deathmatch maps for Unreal 1.   However, the new UnrealTournamentPlayer^? classes and meshes include new features and animations, so you can choose to take advantage of this (and require UT), or not.   The new game types are GameInfo^? subclasses.  The new weapons and pickups interoperate with the old ones.

UnrealEd supports Unreal Tournament maps without any modifications.  This "just works" in the same way that most of the licensees use UnrealEd^? without modifications.

One huge Unreal Tournament feature that script programmers will be interested in is the all-new user interface code.  While Unreal 1's menus are functional, the "look and feel" is basically derived from Doom's menus, which were derived from Wolfenstein 3D's menus, which probably date back to some even earlier id Software game.

The new game UI is a cutting-edge redesign, and continues our tradition of creating code and tools which licensees and mod makers can endlessly customize and tweak.  I can't say more about it yet, but the ongoing joke is that we're going to rename it UnrealOS^? (it's just a joke, but the analogy will become clear later).  Maybe we'll release UI screenshots at some point.

-Tim Sweeney

December 15, 1998

Unreal Networking Code: Status

Unreal 220 incorporates the majority of the low-level bandwidth optimizations I've been planning for Unreal 1 and Unreal Tournament.  I was just looking back at the initial shipping version of Unreal and comparing packets, and realized that we've achieved a bandwidth usage improvement of over 250% in both directions.

This doesn't mean we're going to stop now...there are some minor protocol improvements planned, and also high-level game play optimizations that Steve and Brandon are working on, moving more logic to the client-side to reduce lag and save bandwidth.  But, the foundation is now very solid, and the rest of our work mostly consists of building on that foundation.

The cool thing about Unreal's networking support is that we brought the real-world Internet play performance up to the state-of-the-art without sacrificing generality.   When I first posted the Unreal Networking Architecture, it was simultaneously praised for being a powerful and very general framework, and flamed because Unreal's initial Internet play performance was below gamers' expectations.   The critics were delighted to claim, "this networking engine is a Grand Scheme that will never perform well in the real world".  They sure were wrong!   Iit turned out that all the performance bottlenecks were in the low-level protocol, and were all completely fixable given sufficient R&D time.

It took a lot of hard work to identify all of the inefficiencies in the protocol and come up with solid, general solutions.  The key problems in game networking are data compression, error correction, and latency reduction.  They turn out to be mutually opposing:

• Standard data compression schemes (i.e. Huffman and arithmetic coding) work best when you have a large, well-known compression window, and large symbol tables.  Sending symbol tables isn't practical when you have a low-bandwidth, high-latency connection, and when your window history is questionable due to transmission errors.
• Error correction schemes are tough to implement when you have low-bandwidth, high packet loss conditions (for example., most gamers' modem-based Internet connections!)  I went through 6 separate error correction schemes in Unreal, 5 of which all fell apart in various conditions.  One big trap is getting into a feedback loop that saps away bandwidth and increases ping times.  Another trap is retransmitting time-sensitive data when it gets lost, causing lag.  These issues are tricky in bandwidth-intensive action games, because you need to support multiple tiers of reliability in packets, and some level of sequencing between them.
• Latency reduction is another tricky issue, because of the way modems queue data:   The larger a packet is sent, the more latency is induced in the buffering scheme.   So, you want to send small packets to keep latency down.  But, UDP packets have significant built-in overhead, so you want to send large packets to keep bandwidth up.

In the end, I opted to go with several a custom bit-encoding compression scheme, which adapts itself to the type of data being sent, and intelligently crams it into the least amount of bits possible.  This has worked very well, because the previously large overhead present in packet headers (which identify the game objects being updated) was reduced very significantly.

My initial attempts at error correction were based on sliding-window schemes.   These are still supported in the protocol, because they are great for sending latency-insensitive data, for example when you download a map upon entering an Unreal server.  However, for the far majority of game data, I use an asynchronous scatter-gather data replication scheme which guarantees that game objects will all be updated correctly under all packet-loss conditions, sacrificing guaranteed ordering of updates in order to improve bandwidth usage.

To trade off latency and bandwidth, I adjust packet sizes based on the bandwidth available, and hand-tuned the factors to get an acceptable tradeoff.

Behind the scenes, we've also optimized a lot of the prioritization logic.   Visible objects are now updated based on a priority queue that is weighted according to a viewing probability, and a predictor/corrector algorithm which updates the objects which "need it most" (based on extrapolated position error and gameplay priority).

To test everything, I wrote an "ISP From Hell" simulator into Unreal that lets you toy around with various packet loss, variable packet lag, and packet disordering combinations, and the "STAT NET" display.  There's also an option built in (C++ source required) which writes an extremely detailed network traffic analysis to the log file.  Having and using these visualization tools turned out to be invaluable.   Without the tools, the wasted bits, complex feedback loops, and race conditions in the protocol would have never have been found.

So, where do we go from here?  The majority of the network-related improvements coming in the Unreal Tournament timeframe (still unannounced) are high-level, in areas like gameplay rules, client-side prediction, ease of use, and user interface.

Further off in the future, there are a lot of new possibilities that can be directly extrapolated from the Unreal Networking Architecture document.   Unreal 1 networking can be described simply as "a small number of game clients connected to a single server".  However, the protocol's low-level design is peer-to-peer rather than client-server.  You might say that Unreal just looks like a client-server engine, because our Unreal 1 game code favors the server's logic over the client's.  For the next-generation engine, I'm going to experiment with a lot of new networking configurations.  For example, the protocol could be used for a server-to-server backbone, enabling servers to be clustered together with objects moving seamlessly between them--can you say Ultima Online 3D?  There are also other interesting possibilities for servers, such as a spanning-tree chat backbone similar to IRC, or UnrealScript^? application servers (for example, managing user accounts on one machine, chatting on a second, skin repository on a third, supporting a cluster of dedicated game servers).  These aren't promised features at this point, just possibilities...but to me, very exciting possibilities.

-Tim

December 14, 1998

SaveGames

Somehow the patch info file says that 220 supports previous savegames.  It doesn't.  You can use the list at http://www.planetunreal.com/index.asp?/game/Console.shtm to get the names of all the maps in the game and how to rebuild your game (by warping to the map you were on and summoning all the weapons).  Sorry about that, I know it sucks, but 220 made big changes to the PlayerPawn^? format and other things that end up breaking old save games.

- Brandon "GreenMarine" Reinhart

WinZip Reminder

Remember, if you get an error that says "Cannot find file for package: UnrealShare^?" you need to reinstall the patch using an unzip program that supports long file names.

- Brandon "GreenMarine" Reinhart

Dedicated Server Plan

The feedback regarding what is needed to improve the state of Unreal dedicated servers on the net has been great.  I've taken that feedback and compiled a list of what needs to be done to make Unreal better from the server point of view:

• Linux Server Port: This was suggested by everyone who emailed me!   Mek and I plan on having a Linux server port ready in February.  It might be ready sooner, but Unreal Tournament is our current highest priority.  (Certain cool things in UT will be added to Unreal in future patches.)
• Win NT Service: This was also highly recommended.  We will set it up so that Unreal can be run as an NT service as soon as possible.
• Fixed Remote Administration: I'll be looking into the current issues with remote server administration.  If you have issues with remote administration, send lists to unreal220@epicgames.com.
• Longer Uptimes: There are a few issues that have been pointed out to me that are causing dedicated servers to crash after a few hours of play.  If you experience this, email your server's log files to unreal220@epicgames.com.

Those are the primary points we hope to address as soon as possible.  A lot of people have told me that the lack of a Linux server is the number one issue preventing Unreal servers from proliferating.  The demand is very high so we will answer it as soon as we can.  Thank you for your feedback regarding dedicated servers.

- Brandon "GreenMarine" Reinhart

December 13, 1998

Installer Problems

Let me just reiterate again: do not ctrl-alt-del out of the installer.  It will take up to 15 minutes to patch your copy of Unreal.  If you abort the process you will just have to start over.  If you have virtual memory errors, you need to close programs on your machine, clear off some harddrive space and try again.  The #1 problem people are having with the patch is that they are killing the patch process prematurely.

- Brandon "GreenMarine" Reinhart

220 Known Issues

220 Reported Issues
Drafted by: Brandon Reinhart
Draft Date: 12/13/98

Previous saved games do not work with 220. Such is the bane of object serialization.

NOT BUGS
- You MUST use a long filenames unzip program to correctly unarchive the patch.
- Installer requires a large amount of virtual memory. If you get a virtual memory error,
close some programs, clear some HD space and try again.
- If the installer pauses, IT IS NOT HUNG. Let it continue. It may take 15 minutes to patch.
- If the patcher reports that it is NOT RESPONDING please DO NOT kill the process.

Sound Issues
- Dying pilot sound doesn't play.
- Kevlar armor doesn't play.

Botmatch
- Default AI set to 255.

Misc
- Cycling through players as a spectator does 2 at once?
- ScriptWarning^?: MaleThree^? MaleThree0^? (Function SpawnCarcass^?:0016) Accessed None
- ScriptWarning^?: MaleThree^? MaleThree0^? (Function SpawnCarcass^?:0032) Accessed None
- ScriptWarning^?: MaleThree^? MaleThree0^? (Function DoJump^?:00E4) Accessed None
- ScriptWarning^?: DeathMatchGame^? DeathMatchGame0^? (Function GameInfo^?.Killed:0142) Accessed None

Long Filenames

A few users have reported getting an error that Unreal couldn't locate UnrealShare^?.u. This happens when you use a ZIP program like PKZIP for DOS to extract the 220 patch. Be sure to use a ZIP program which supports long filenames, such as WinZip.

- Jack "Mek" Porter

Dedicated Servers

I'm going to update the information on starting a dedicated server pretty soon.  I want to get feedback from people regarding servers.  Do you think it is easy or hard to start a server?  Would a linux server help increase the number of servers available on the net?

I'm really interested in trying to get more dedicated servers up and running and I would like to get email from people regarding their thoughts on the issue.  We've greatly reduced the RAM and CPU requirements of Unreal dedicated servers and want to figure out ways to better improve the state of the scene by getting more servers on GameSpy^?.  Send your feedback to brandon@epicgames.com or unreal220@epicgames.com.  As it stands, its really hard to find a good game because of the lack of dedicated servers.

So far the feedback regarding the 220 patch has been great.  The team would like to thank all the fans who have supported Unreal throughout its growth.  We think that online play has come a long way since the game was released and we know we still have a lot to do.

- Brandon "GreenMarine" Reinhart

Building List of Issues

I'm currently going through the bug reports building a list of issues people are reporting.  Thanks for the great feedback!  I'll probably post a list of known issues to this page tonight so everyone can get an idea of what has already been reported and what is going to be fixed in 221 (which should be out next weekend, I would imagine).

The most serious issues at this point are problems people are having with the patch installer.  The installer requires a fairly large about of virtual memory to run successfully, so make sure you aren't running any other applications when you install it.   If you get an error indicating you are low on virtual memory, clean off some harddrive space and try the patch again.  There will probably not be any other patches this big, but we aren't sure at this point.  I have also received reports of CRC errors when installing the patch.  I would imagine that the cause of this is archive corruption (in which case you need to redownload the patch), but I"m not sure.  I'll ask Tim :-).

The other major install issues is that some people are running unreal.exe and then getting no harddrive activity (patch lockup).  If you have this problem, please send information on your system configuration to unreal220@epicgames.com.   Include what steps you took to installing the patch.

Finally, we know about the botmatch skill bug that causes bots to play at skill level 255.  To fix it, just adjust the bots skill manually.  We'll have a code fix for that in 221.

- Brandon "GreenMarine" Reinhart

Request of Webmasters

When announcing the patch, please point users to http://unreal.epicgames.com/versions.htm to obtain the patch, rather than putting a hyperlink directly to the patch file.   This way, users will always see the release notes and installation instructions, and the list of download mirrors will be readily available.  Thank you!

Also, a big thanks to the PlanetUnreal team, and a bunch of hardcore Unreal players on IRC for helping with last-minute testing.

Unreal Mod Breakage

A quick reminder, Unreal 220 breaks compatibility with most user mods which include UnrealScript^? (.u) files.  Mod authors will need to update their mods to fix compatibility.  I apologize for the inconvenience to mod authors;  this was a tough decision, but the extent of the improvements we were able to make to the game code by breaking compatibility makes it all seem worthwhile.

All user maps and texture sets should continue to work.

Unreal 220 Beta Patch Released

Go to the Unreal Patch Page for information and downloads!   This is a huge patch containing a lot of new Deathmatch features, game improvements, and script improvements.

Unreal 220 is a public beta patch.  We've done a significant amount of internal testing, but we'll be doing more wide-scale testing before the upcoming official, non-beta patch.  To summarize the Unreal 1 roadmap:

• Unreal 220 (Beta): Internet improvements, core game improvements, bug fixes.
• Unreal 221 (Beta): Incremental fixes.
• Unreal 222 (Official): Non-beta patch; shareware version will be released.
• Additional patches as necessary.

Report bugs to: unreal220@epicgames.com. If you're experiencing a crash, please attach a copy of your log file: \Unreal\System\Unreal.log to help us troubleshoot.  This is not a tech support email address; the Unreal team reads all bug reports and looks into them, but we can't guarantee an individual response.

I'll be away on Sunday, and back in Monday to start dealing with any issues people have with 220.

Also, next week I'll be releasing Unreal's C++ headers so that mod authors can start experimenting with C++ plug-ins for game play, algorithmic textures, and lots of other stuff--everything but UnrealEd^? plug-ins (which are coming later with the UnrealEd^? C++ rewrite).  The C++ headers require Microsoft Visual C++ 6.0 to compile.

Enjoy!

-Tim

December 12, 1998

The team played a huge coop game through all the levels of Unreal, and 220 is looking good -- "almost there".  Here's the list of bugs we found during the test session, which we're fixing now:

    tim's issues:
        "brightness" txt isn't shown
        brightness setting not saved
        alt-enter loses menu in w95 glide but "advanced options" doesn't
        verify ipdrv not loaded for normal play
        avoid losing savegames! (firstrun detect *.usa)
        no music when enter dig coop
        spinning death anim plays superfast
        "connecting" msg shows current level name not next
        "netspeed" setting doesn't persist across level switches in lan game
        cliff says screenshot crashing
        make sure all mover subclasses are bAlwaysRelevent
        text wrap: additional lines have leading spaces

    steve issues:
        no pickup sound for kevlar vest
        dude in chair isn't screaming
        sparking wire anim in vortex rikers isn't showing

    brandon:
        coop scoreboard needed, to show who's in the game

December 11, 1998

Here is the ReadMe file from the upcoming 220 patch.   We're doing some final testing on it now.  If that goes well, 220 will be released Saturday.  Otherwise, we'll spend a few more days fixing and testing.

December 10, 1998

We're still testing and tweaking Unreal 220.  It's getting closer...

LoonyGames has a cool article that compares, contrasts, and critiques some next-generation game development tools, and focuses on the strengths and weaknesses of UnrealEd^? and 3D Studio Max.  The author makes a lot of good points about features that would improve UnrealEd^?, many of which are already planned for the upcoming C++ UnrealEd^? rewrite.

December 14, 1998

Hard at work

We're hard at work putting the finishing touches on Unreal 220.  It's looking good, but the extent of the changes and improvements has required quite a lot of testing and refinement.  It won't be ready for public consumption this week or over the weekend, but hopefully early next week.

A lot of mod authors have emailed asking for early access to Unreal 220 so they can get their stuff is up and running in the new version.  The answer right now is "maybe"...if the code comes together over the weekend, I'll post a public "for mod authors only" version.  220 will break compatibility with most UnrealScript^? mods, but I've modified UnrealEd^? so that mods can still be loaded (this is a change: 219's UnrealEd^? gives a fatal error when loading an incompatible .u file).   Upgrading most mods will be easy; the most significant changes are function parameter changes all over the place, and splitting off the network-related variables in Pawn into a new PlayerReplicationInfo^? class, to make scoreboard-programming simpler and more expandable.  In terms of mod support, the week following 220's release will be chaotic, with mods being repaired and re-released.  Sorry, we would have liked to avoid this, but the improvements we wanted to make were just too cool to stick with full backwards-compatibility.

Levels, sounds, texture files, music files, and audio files remain backwards-compatible.

Shortly after 220, I'll be releasing the C++ headers required for users to write C++ add-ons.  I'm planning on throwing together a very simple SampleTexture^? package showing how to make algorithmic textures, and a SampleActor^? package showing how to write intrinsic C++ functions for actors.  This stuff should give mod authors a very significant amount of new stuff to play with, though the more exciting C++ stuff will come in a later release with the UnrealEd^? plug-in interface.  It will be interesting to see the response to the C++ headers, because the Unreal engine's C++ architecture is very, very different than what people are used to in Quake and other engines.  It's very much a framework rather than an API.

Jack "Mek" Porter has come here from Australia for a few months to help with the Unreal Tournament programming, and is currently working on some cool new mouse-based user interface code.  He is a big Linux fan, and is talking with Brandon Reinhart about cooperating on a native Linux port of the Unreal server.

That's UnrealEd^?.net

The cool independent Unreal editing site I mentioned is actually UnrealEd.net, not UnrealEd^?.com.

November 19, 1998

Unreal 220 Internet Improvements

I'm now down in Raleigh, North Carolina with the rest of the Unreal team.  Things are really coming together for the top-secret project we're working on, and Unreal 220 is starting to solidify.  We don't have a release date yet, but it could be as early as next week.

The Internet play improvements in 220 are quite noticeable.   Steve and I are using a new physics prediction scheme based on motion compensation.  This improves the smoothness of other players' movement in deathmatch games, especially in large, open levels like DmDeck16^?, where lots of players are visible.

Steve has redesigned the moving brush code so that moving brushes now are now handled client-side.  Platforms and doors are very smooth now.  Finally, I've created a new scheme for managing temporary actors like projectiles, which reduces their bandwidth by about 30%.

Steve and Brandon have also added a lot of other improvements, such as showing ping times, server name, and level name in the player list, showing the name of opponents when you point the crosshair at them in a network game, a beep when chat messages come in, and color coding of messages.

Unreal Editor Progress

I've also been working on the new Unreal Editor, featuring a user-interface rewrite (moving over to C++ from Visual Basic). It's now more than half-way done.   Architecturally, the new editor code is far more general than the old UnrealEd^?.   The editor itself is very abstract, and almost all functionality is implemented through plug-ins.  There are plug-in interfaces for brush builders, views of objects (like 3D scenes and the 2D editor), view controllers, import tools, export tools, browsers, and operations on arbitrary kinds of objects.  Plug-ins can even define their own sub plug-in interfaces, etc.

This new approach will provide a more solid foundation for Unreal 1 editing, but the big gains will come in the next-generation engine.  A major bottleneck in creating the Unreal 1 engine was the complex coupling between the rendering engine and the editor, which made it difficult to modify the renderer.  The new approach generalizes the concept of editing, and will make it easier to add cool new features which require editor support.

I plan to start releasing public betas of the new UnrealEd^? as soon as it's really stabilized, with the first beta in the first week or two of 1999 if all goes well.

We have long planned to release the editor as a full retail product through GT Interactive after it has been cleaned up and finalized, but there doesn't seem to be enough mainstream retail interest to justify it.  So, unless something changes real soon, we'll plan to release the final version freely, with the manual provided in HtmlHelp^? format rather than printed.

Web Site Notes

A request of web sites providing collections of Unreal related files, such as the cool Unreal Resources page: Please link to the official Download page for the Unreal patches, rather than mirroring specific patch versions locally.  A bunch of web sites have old Unreal patches in their download sections (as old as the 1.01 patch), which are no longer relevent.  If everyone links to the central Download page, users are more likely to get the latest patch. Thanks!

Cool Unreal related things I've seen recently...

• Unloaded, a great "overhead view" mod including some custom levels. It feels a lot like the classic arcade game Gauntlet.
• AEus' Unreal Stats Page, a totally cool stats tool for server administrators.
• UnrealEd.com has grown to contain more and more useful UnrealEd^? resources.

Unreal mod notes

Mod developers who get the cryptic "sandbox" error when trying their mods in network play: This error means you have a .upkg file that says server-side-only because you copied the one from IpDrv^?.u (which is SUPPOSED to be server-side-only).  This usually prevents the mod from working, but sometimes just causes actors defined in the mod to not be visible to players.  If you don't have a .upkg problem, you won't have a problem.  If you do have a .upkg file, it should read:

[Flags]
AllowDownload^?=False
ClientOptional^?=False
ServerSideOnly^?=False

-Tim Sweeney

Older News (1998)

News 11-10-98

Latest News

The latest PlanetUnreal survey shows a significant gain in gamers' satisfaction with the latest 219 patch, compared to the previous ones.  We're now hammering on version 220, which includes significant new Internet play improvements, plus some core game improvements that the rest of the team has been working on. 220 won't be out this week, but should be ready soon after.

There seems to be one Internet problem in 219 that is affecting 10-15% of players.     I haven't figured out the cause yet, but the symptom is a ping time (visible with STAT NET) that swings around wildly, going from 200 to 1000 or more over the course of several seconds.  Many of these players report that other games like Quake 2 don't exhibit the problem--which indicates it's not just a bad connection or ISP.   I suspect packet-ordering problems, though I haven't been able to duplicate it here.

The Roadmap

In the remainder of 1998, we will be releasing:

• Unreal 219: Latest version. Download here.
• Unreal 220: Further Internet improvements, core game improvements, bug fixes.
• Unreal 221: Incremental fixes
• Unreal 222: Offical (non-beta) patch; shareware version will be released.
• Additional patches as necessary.

We also have some cool things in the works for 1999.  Since Unreal first shipped, I've been working on Internet improvements and bug fixes, while the rest of the team has been working on a top-secret project we are referring to as "Unreal Tournament".    There have been a lot of rumors and speculation about what this project will be.   Some of the rumors are completely incorrect. For example, we are not using any alien technology recovered from crashed spaceships on Tournament. (We're saving that for our next project).

I'm also working on the new, enhanced UnrealEd^?, with lots of new features, improved stability, a plug-in interface, and other goodies. We don't have a date for this, but I'm expecting a public beta around new years, with final release early in 1999.

At some point, we'll be publically releasing Unreal's C++ interface so the community can start on .dll plug-ins for Unreal and UnrealEd^?.  This will happen no later than the new UnrealEd^? public beta.  It might be possible to release it sooner, however there are changes in the works which won't be binary compatible, so user-created .dll's would break and need to be recompiled.

What can you do with Unreal .dll's? Lots. Here are some examples:

• Define new kinds of algorithmic textures that can be created in UnrealEd^? and used in levels.
• Expose anything you can do in C++ to UnrealScript^?, for example the file system, ActiveX^?, more Internet functionality, etc.
• Write performance-critical game support routines, such as AI.

While it's also possible to write game code directly in C++, the preferable way to do that is UnrealScript^?, since there is already a lot of game support infrastructure built into the language.

Server Administration

Remote server administration isn't working in 219, but will be addressed shortly. 219 does have a few new features for local server administration.  While running a server, click on the Unreal server icon and choose "Show log window". In the log, you can type:

• SERVERTRAVEL <levelname>: Jump to a new server.
• SAY <message>: Broadcast a message to all users.

-Tim Sweeney

News 11-2-98

Unreal 219!

It's now available for download HERE.   The Epic Deathmatch servers will be shut down for the night, to provide more bandwidth for downloads.

The testing is going well

Ok, ok, you can stop now, that's enough testers. :)  Server performance has definitely improved since I last benchmarked it. My dual-processor Pentium II-300 is serving a 20-player game, copying 600 megs across the network, and running a 3dfx Unreal client at 800x600. The server is keeping up a steady 15 fps.  I have more optimizations planned, though.

On my 28.8K connection, gameplay has remained pretty smooth until I get into a firefight with 5-6 people, at which point the movement of other players starts to become unsmooth.  We should be able to improve this significantly further in 220, with two protocol improvements.  First, I'll be improving the scheme for managing temporary objects like projectiles, which should reduce their bandwidth usage by around 30%.    Second, Steve Polge and I working out a new variable priority predictor/corrector scheme for transmitting the movement of other players.

Testing 219

I have an Unreal 219 server up and running at unreal://208.212.53.3/ in case a few people want to help test.  You can join in and play with 218; it's fully compatible. 219 should be available soon, unless new bugs are discovered.

News 11-1-98

Unreal Grows...

More public servers keep popping up every day.  Awesome!

I noticed that the percentage of servers shown as "not responding" has gone up, though I'm not sure whether that's due to server crashes, or people accidentally having their LAN server listed in GameSpy^? when it's not meant to be public.  Server admins, if your server crashes unexpectedly, please email your Unreal.log file to unreal218@epicgames.com so we can investigate it.

A reminder, server administrators can get help in the new "Server Administration" forum on the <a href="http://megaboard.epicgames.com/" target="_parent">Epic Message Board.

According to the feedback we receive, and in <a href="http://www.planetunreal.com/" target="_parent">PlanetUnreal's survey, 218 has fixed the past network problems and made Unreal playable on the Internet for the large majority of people.  Still, we have lots of improvements in the works, which will further increase the game's smoothness and responsiveness during network play, as well as a few new features that I'm not allowed to announce yet. :)  The next patch, 219, will be purely bug fixes to 218 (no speed difference).  After that, 220 will contain some more high-level improvements to many areas of the network code.

Currently, there seem to be two sets of people who are still having some problems with Unreal on the Internet.  One set has 28.8K-33.6K modem connections that experience an unusally  high amount of packet loss.  220 should improve this a bit, but when you have upwards of 20% packet loss, gameplay is bound to suffer.  The other set of problems is being reported by people with some unusual connections we haven't been able to test on internally: people with dual simultaneous modem connections, people with connections that receive via satellite and send via modem, and some similar configurations.  I haven't determined what's going wrong in these cases yet, but I suspect packet-order problems.

News 10-30-98

Unreal 218 patch information (RTFM!)

If you downloaded the 218 patch, please read the release notes.   If you're still experiencing problems with Unreal on your modem connection, you need to use the NETSPEED command described there, so that Unreal doesn't try to use more bandwidth than you have available.

Resources for Server Administrators

Here are some resources to aid new Unreal server administrators in getting up and running:

• Master Servers:  How to get listed in GameSpy^? and other querying tools (new).
• Server Administration Tips:  Basic information about running an Unreal server.
• Epic Message Board:   New "Server Administration" forum.  Steve Polge, Brandon Reinhart, and I will be answering questions from server administrators and people writing server-querying tools.

Unreal Multiplayer Ramp-Up

A lot of news sites have been picking up on Unreal's multiplayer improvements:

• Next Generation Online
• Blue's News
• Voodoo Extreme

The number of public Unreal servers listed in GameSpy^? is now up to 51 as I write this, and has been growing at a rate of over 20% daily.  While working on the upcoming 219 patch, I've been spending a couple hours each day playing Unreal online, especially on the servers running user-created levels.  The community has made some really impressive levels, and I'm glad to see that a lot of servers are now making use of downloadable levels, textures, sounds, and music.

Other Servers

In addition to the public servers listed in GameSpy^?, there are 14 extremely high quality, public servers on World Opponent Network listed in their own web-based "server finder" site.

I should also mention our other online partner, MPlayer, and the Unreal Kingdom news site on MPlayer.

-Tim

Status of Direct3D 10-28-98

All Drivers

Some issues across-the-board with switching between fullscreen and windowed mode, and switching resolutions during gameplay. We're looking into theses issues.

Riva TNT

Has lots of potential, but there are major problems with their Direct3D driver: rainbow colors, time-lag, w-buffering issues, missing textures.  We are hoping nVidia will issue an updated driver soon.  The ball is in their court now.

Riva 128

Their latest driver should run Unreal OK.  The framerate isn't very good, and there will be a lot of "stuttering" since texture downloads are very slow on this hardware.  Some users are reporting that creature polygons appear corrupted.    Hopefully nVidia will fix thie error in their driver.

Intel i740

There are some problems with their currently-available Direct3D driver, but they have an internal beta driver which fixes many problems.  Hopefully this will be ready for the public soon.

ATI Rage Pro

They have a beta Direct3D driver which runs Unreal pretty well (though it doesn't appear to be available for public release yet).  Multitexturing currently isn't working with Unreal, because of a hardware limitation (it can't multitexture a paletted base texture map along with a non-paletted light map).

3dfx Voodoo2

There isn't any reason to use Direct3D for Voodoo2, since we support Glide natively and that tends to be more stable and faster, but their latest Direct3D driver does run Unreal pretty well.  Their detail texture blending (D3DBLEND_DIFFUSEALPHA) doesn't work, which breaks detail textures.  There are reports of missing lightmaps in some areas (not sure what's wrong).  3dfx could get a performance increase here by implementing subrect Blts and hardware triangle-fan setup.

S3 Savage 3D

Works well with their internal beta Direct3D driver.  Not sure when this will be available via the web.

Matrox G200

Works pretty well.

Rendition

Works pretty well.

Permedia

Only supports monochrome lighting due to blending limitations.  Explosions are displayed with a black background (due to a bug in the current Unreal code).  Fairly slow texture downloading -- performance isn't great.

Drivers we consider playable, in best-to-worst order

• Voodoo2: Fastest of all.
• Savage/G200: Reasonable performance. Not as fast a fill rate as Voodoo2, but texture downloads are fast, and they support palettes, making for a steady frame rate.
• Rage Pro/Rendition: Reasonable performance. High display quality in truecolor mode.

The others should be playable pending public release of improved Direct3D drivers for their hardware.

On Permedia, Riva 128, and Rendition, you may get better performance using Unreal's software renderer, especially if you have a Pentium II class processor.  This isn't such a bad thing, because the software renderer supports all of Unreal's key features, including truecolor lighting and volumetric fog.

News 10-28-98

Latest Happenings

Since the Unreal 218 patch was released, the number of Unreal servers showing up in GameSpy^? has increased by 225%.  A huge thanks to everyone who is running Unreal servers now.  It's awesome to see the community grow and begin to reach critical mass.

At any time, about 20% of the servers listed in GameSpy^? are shown as "Not Responding".  I've been looking into this, and there are three reasons for this.    One, the server has been shut down or crashed but hasn't timed out and been removed from the list.  Two, the server is switching levels, which prevents it from responding to GameSpy^? queries for 5-20 seconds.  Third, the server is shown in GameSpy^? because a user running a LAN server (dedicated or non-dedicated) enabled the "DoUplink" option to publicise their server to the world without realizing the consequences, but either exited or is on a LAN blocked off by a firewall.  We'll work with the GameSpy^? guys to adjust the timeouts so that fewer "Not Responding" servers are listed.

News 10-26-98

Direct3D Drivers

To use Unreal's Direct3D support, you must have Microsoft DirectX^? 6.0 installed. You also need the latest Direct3D driver from your 3D hardware maker.  Because Unreal uses many new Direct3D features, many hardware makers had to update their drivers for Unreal to work. Therefore, some of the drivers distributed with DirectX^? 6.0 have problems with Unreal (crashes or visual anomalies).  Here are driver download sites for various brands:

• 3DLabs Permedia
• 3Dfx Voodoo, Voodoo Rush, Voodoo2, Voodoo Banshee
• ATI Rage
• Intel i740
• Matrox G200
• nVidia Riva 128 (known problems), Riva TNT
• Rendition Verite
• S3 Savage 3D
• Trident Microsystems (untested, probably doesn't work)
• #9 Visual Technology (untested, probably doesn't work)

Please keep in mind that Unreal's Direct3D support is an early beta and isn't yet working reliably on all 3D hardware.

Known Issues

I've update the list of Known Issues, summarizing the problems people have found with 219.  There are a bunch of items, but most are non-showstoppers.  I'm working on them now.  Overall, though, 218 is by far the best-received version of Unreal to date! New servers are popping up rapidly (50% increase in the past 18 hours), with player counts rising even faster.

Unreal 218 Gaining Support

After releasing the patch at midnight Sunday night, it was amazing to see how many Unreal servers had it up and running in less than an hour minutes.

It will be interesting to watch new Unreal servers spring up on the net now that our Internet play quality is under control. In the not-too-distant future, we'll have many more improvements in Unreal network play: performance enhancements, new features requested by the community, and several cool upcoming surprises. GameSpy^? currently shows 27 Unreal servers, and a couple thousand for Quake. Clearly, we got off to a very slow start while we learned the the ins-and-outs of Internet game programming; now Unreal is on a solid footing and we're really beginning to pick up the pace!

Level designers in the Unreal community have already started producing some great Deathmatch maps (see Unreal Resources for downloads), so we expect to see things accelerate in this area, too.

PlanetUnreal^? performance survey

If you're using the new 218 patch, please fill out PlanetUnreal's Unreal performance survey.    We'll be watching Unreal players' feedback in the survey, and looking at all the 218 bug reports sent to the unreal218@epicgames.com account.  Everyone's feedback will be taken into account for future improvements to the Internet play and other features.

More about 3D API's

In an interview on Voodoo Extreme, I gave my opinion in the ongoing OpenGL^? vs Direct3D debate, and I wanted to add some more information here.

First of all, both our DreamForge^? partners working on the OpenGL^? support, and our Direct3D partner have both done a very high-quality job, given the constraints of Unreal and the 3D card drivers available.  My feelings on the two 3D standards are based completely on their API's and the quality of drivers available.

Next, I wanted to give some more detail on the code.

API support layer	Lines of C++ code
3dfx Glide	1711
Direct3D	3123
NEC PowerVR?	4049
OpenGL	5697

Now, the Glide is the simplest, because it's aimed at the Voodoo family of 3D cards, which are very standard and straightforward to support.  For programming to 3dfx cards, Glide is the ideal API.  For people thinking "If Glide is so great, why don't other 3D cards support it?"  The short answer is, if Glide supported other manufacturer's 3D cards, it would pick up all the complications  involved in real-world Direct3D and OpenGL^? programming: Testing for core capabilities, working around driver bugs, etc.

The Direct3D code is next in simplicity.  It began as a working 1600 line driver, then expanded as it was optimized and support was added for 3D cards that lack key features.  The Direct3D API follows the traditional Microsoft model of being not very beautiful code, but dealing with real-world hardware robustly, by providing a capability-querying mechanism and well-tested drivers.

The PowerVR^? code is large because the PCX2 chip's rendering approach is very different than what Unreal was designed for.  This makes the implementation fairly complex, though the next-generation PowerVR^?, currently on-hold in the PC market while NEC focuses on the Sega DreamCast^?, is a great chip that's more traditional in its architecture, and more optimal for Unreal.

The OpenGL^? code is large because of optimizations and support for lots of real-world hardware.  If reduced to plain-vanilla OpenGL^?, this would probably be the simplest and most stable driver of them all, because the OpenGL^? API is very straightforward.

Unreal 218 Patch is ready!

You can read the release notes and download the patch from the Patch Page!  Our test session went well, and the participants (including a lot of modem players, and even some overseas modem players) reported major success with the performance improvements.

Epic's two deathmatch servers have been upgraded to 218: Deathmatch 1 and Deathmatch 2.  However, since our T1 line is going to be very saturated with people downloading the patch, performance probably won't be very good on our server for the next several days.

10-25-98

Geting closer...

We're gearing up for a big internal test session with 218 right now.  The release date of the 218 patch will depend on the outcome.  Note that 218 is not network-compatible with 217, so if you see our 2 test servers in GameSpy^?, please don't try to join (you won't be able to).

10-24-98

Almost there...

The latest Direct3D support is now integrated into the Unreal codebase.  It will be in the upcoming 218 patch in "public beta" form.  It hasn't gone through wide testing yet, but we and our partners have been testing it a lot internally on Windows 95 and 98.  It's looking good on the next-generation 3D cards (Riva TNT, Matrox G200, Savage 3D), though high-level optimizations are planned that will boost performance further.

The Voodoo2 multitexture code is in, thanks to the efforts of Jack Mathews at 3dfx.

I'm doing some final Internet play testing and tweaking on the patch.  My "torture test" environment is an ISP connection at 24.4K with 400 msec ping.    If it's playable on that, it should be playable on anything. :)   Yesterday's testing revealed a few last-minute problems that I'm working on now.

More discussion on CORBA

William van der Sterren provided this insight into CORBA with respect to realtime apps:

In general, CORBA causes too much overhead and latency to be a server/clients gaming protocol. This is due to IIOP's (the default inter-ORB protocol) use of TCP/IP, and the use of large packet sizes (compared to the dedicated bit-tuned gaming protocols being used in,  for example, Quake2 and Unreal). Though support for IIOP is mandatory, an ORB vendor can deploy more efficient (or more secure) protocols between 'his' ORBs, optionally using other network protocols. By default, CORBA calls are synchronous (that is, the calling object is blocked until a response is received from the called object). Such a connection-oriented call is best implemented using TCP.

CORBA also supports so-called 'one-way' operations, that  enable the caller to continue processing immediately  after making the call - the call is non-blocking. Here, it might make sense to use UDP as an underlying protocol, provided you deal with the unreliability at the application level (the 'call' might not arrive at the client). Some specialized high-performance ORBs, such as Nortel's RCP-ORB, <http://www.nortel.com/RCP-ORB/>, use other transport protocols than TCP for one-way calls. Most ORBs implement optimized mechanisms for 'intra-server' and 'intra-process' communication (not that relevant for multi-player gaming).

 

I'll post more thoughts on the topic in the future.  With Unreal, distributed object models are already playing a role in multiplayer gaming, but only in a "tip of the iceberg" sort of way.  This kind of technology will expand very interestingly in the future.

10-22-98

Linux Unreal

Linux Games has reported a way to run the existing version of Unreal under Linux, using the Wine Windows emulator for Linux.  They've included a screenshot and more information at this Unreal in Wine page.

Hired Guns

Want to see something cool and unique that's being done with the Unreal engine?    Check out the Hired Guns preview.  The Devil's Thumb team is really pushing the engine, and has implemented a beautiful user-interface design featuring multiple game windows. I look forward to playing this game. (Thanks PlanetUnreal for pointing out the preview).

10-19-98

Network Improvements Underway

I went ahead and modified Unreal's streaming protocol to read and write bit-oriented streams rather than byte-oriented streams.  This has led to an additional increase in bandwidth efficiency.  Compared to 217, upstream bandwidth is now utilized 25% more efficiency, with downstream bandwidth boosted by approximately 35%.  I've also been tweaking the priotitization of actors, and gaining some incremental improvements in smoothness from that.  I really look forward to releasing the new patch in a few days and hearing what people think!

Unreal's separation of network support into three layers, UnrealScript^? replication/RPC, the low-level transport protocol, and the TCP/IP driver, has really made the optimizations manageable.  While monolithic C-style code has a reputation for being more optimizable than a layered, object-oriented design, the experience I've gained on Unreal mostly indicates the opposite.  It's great to be able to rip out one module (like Unreal's low-level transport) and replace it with a better and more efficient implementation, without breaking all the code it interfaces too.

10-14-98

Network Objects Follow-Up

I've chatted with several people lately who have added insight to the discussion of multi-language programming and networking.  One interesting topic mentioned was using the CORBA protocol to coordinate network games.  CORBA is a high-reliability protocol with a fairly high amount of overhead and latency, due to its exacting nature and use of TCP.  I see CORBA as a very suitable protocol for network game backbones. For example, if you were doing an Ultima Online style world with multiple servers that stay in synch, CORBA would be good for linking servers together in a high-reliability, non performance-critical way. But, CORBA isn't suited for an actual realtime modem-based gameplay protocol, since it's TCP based (which adds terrible lag under lossy conditions), and the protocol has enough overhead that it's not going to be able to handle large amounts of data over the modem.

AWT

AWT is a graphical user-interface layer for UnrealScript^?, which has been making some cool progress lately.

Cheat Challenge Update

I've received a bunch of tips from two Unreal enthusiasts.  Congratulations go to Mek @ PlanetUnreal^? and RisingSun^? for discovering and verifying two holes in Unreal, and to Mike Lambert for suggesting a potential third one.  Also, thanks all the players who provided observations they saw of potential cheating online.  I'll write more about these techniques after the next patch has been released, and the holes plugged.

In the meantime, if you too have figured out how to cheat in Unreal, pat yourself on the back, you outsmarted me!  But also, please resist the temptation to cheat on the public deathmatch servers...it spoils the fun.

Another Public Master Server

This just in:

How about a mention of the OGN Public Unreal Master Server? It's been available for almost two weeks and has no access restrictions, bandwidth or otherwise. The server is running @ master.ogn.org:27500. Server lists can be retrieved @ http://master.ogn.org:6669/list/game/unreal. A page describing how to link to it can be found @ http://www.ogn.org/UnrealMaster

-- sky G.
http://www.qhunter.com/
http://www.golightly.org/
http://www.aurorablue.org/

10-13-98

Unreal Cheat-Finding Challenge

I've seen two reports that people have found a way to cheat in Internet play.    One person reported seeing a little tiny 1-inch tall player walking around named "LilTinyChessPiece", and another reported a player who never took damage.    I've been scouring the code, and haven't found any holes which would enable this kind of cheating, but I'd love to hear if anybody has found a way.

If you find a way for players to cheat or crash servers over the Internet in Unreal, please email me.  The first person to report a particular security hole in Unreal will receive credit and thanks here for helping to protect the Unreal community from cheaters.

People who cheat in Deathmatch are lamers, but people who are motivated by simply discovering ways to cheat are doing valuable research.

Note: I don't consider the following things Unreal cheats:

• Server administrators cheating on their own server. Since the admin is in control of the server, there are many ways he could disadvantage players (in any game, not just Unreal), but fortunately people who go to the effort of setting up their own server tend to be honest and respectful of the community.
• Any of the standard TCP/IP tricks people can use to confuse Web & FTP servers, such as SYN flooding, packet flooding, DNS spoofing, and so on.  These aren't Unreal-specific cheats, and I can't stop them.

UnrealScript^? Notes

There was recently a "to script or not to script" debate about the merits of UnrealScript^? vs pure C/C++.  In this debate, several misconceptions were put forth, which I want to correct:

1. UnrealScript replicated functions (described in the Network Architecture Documentation) indeed return instantly, rather than blocking execution while waiting for network acknowledgement.  Function calls are sent across the network using an asynchronous RPC-like approach, and are executed upon reception.   They can either be sent wih guaranteed delivery and sequencing (by using the "reliable" keyword), or without sequencing (using "unrelible").   Unreliable replicated functions are most efficient, and should be used for non-vital events like hearing sounds.
   
   If one were to assume UnrealScript^? functions were synchronous and blocking, one would indeed draw incorrect conclusions such as this statement: "That must make AIs in multiplayer games really fun, they fire at you and do an RPC, then freeze until they get a ping back from the client."
   
2. As our licensees know, UnrealScript^? classes and C++ classes fully interoperate.   You can derive C++ classes from UnrealScript^? classes, and vice-versa.  For all actor classes, running "Unreal.exe -make" automatically parses the UnrealScript^? classes, and generates C++ stubs for them, including:
   
   • C++ variable declarations mirroring the UnrealScript^? ones, allowing variables to be accessed identically in either language.
   • C++ -> UnrealScript^? calling stubs, enabling C++ functions to call into UnrealScript^? functions.
   • UnrealScript -> C++ calling stubs, enabling UnrealScript^? functions to call into C++.

   Indeed, we invested a lot of effort into providing dual programming interfaces, enabling seamless sharing of objects and code between the two languages.  Among other things, I studied COM, MFC/VB/ActiveX, CORBA/IDL, and JNI in order to determine the most efficient and least error-prone methods of cross-language programming. There is a lot of great research material on the net, for those who are interested.

   I suspect that people who have a low opinion of mixed-language programming have likely drawn their conclusions from JNI and CORBA/IDL which do indeed involve a lot of messy handle/id references and error-prone redundent declaration of objects.  It doesn't have to be this way.  For an example of "cross-language programming done right", check out the ActiveX^? support in Microsoft Visual J++ and Visual Basic -- they're ultra-clean, automatic, and they involve no redundency.  MFC also does a pretty good nearly-automatic job of cross-language ActiveX^? object handling.  Mixed-language programming can be very fruitful, if it's implemented properly.

3. Unreal performs all file loading and saving using serialization.  Serialization is automatic for objects defined in UnrealScript^?.  For objects and structures defined only in C++, such as the following function that serializes a vector.

   friend FArchive& FVector::operator<<( FArchive& Ar, FVector& V )
   {
           return Ar << V.X << V.Y << V.Z;
   }

   For programmers just learning about object-orientation, a must-read is: <a href="http://www.amazon.com/exec/obidos/ASIN/0201633612/o/qid=908310340/sr=2-1/002-5033601-8164246" target="_parent">Design Patterns: Elements of Reusable Object-Oriented Software (Addison-Wesley Professional Computing) by Erich Gamma, Richard Helm,