Technology Announcements Page
Past news from the Unreal™ engine
development team
|
 |
August 1, 1999 |
I've been spending the past 5 days or so banging out a Linux client for UT. At this point, it is completely playable with renderers for Glide and MesaGL. It runs very well under my Voodoo 3 3000 at 1024x768 (Redhat 6, Linux 2.2.5-15). (There is some kind of physics bug in the flyby code that only shows up under egcs, so I can't do a timedemo right now. I'll fix it later.)
The client requires X windows, libXpm, and libMesaGL. (My RedHat 6 distribution didn't come with libXpm installed, but Jack says that it is very common. MesaGL is only required if you are using the MesaGL renderer. If you are using the Glide renderer, then you'll need libglide2x.)
The only major issue left on my todo list for the client is to port the Galaxy sound library. That will probably take a day or two (barring any unforseen problems). I also want to tweak my mouse input code a bit, add some kind of support for unwrapping exceptions caused by OS signals, and add a command line option to allow command input from the Linux console (or xterm or whatever).
If everything goes well, then the client will be on the 2nd CD of UT. I'll work out some kind of install program or rpm script to make putting it together easy. This means that the Linux hackers can buy a copy of the game off of the store shelf and be good to go. This isn't guaranteed, as I have to get the sound code working and make sure it plays and works as well as or better than the win32 version first, but its a good possibility. This also means that we will make a Linux UT demo available.
The Linux server is in good shape. We are looking at possibly making a special free distribution of UT that will contain what you need to run a server but no game content. We are also considering giving away around a hundred copies of the gold version of UT as soon as it comes out of duplicaton. Don't email me or anyone else here asking if you can get a copy, because we won't answer. We haven't worked out all the details yet (but will in a few days).
Screenshots
The first is a shot of UT running under linux at 1024x768. Look exactly the same as the
windows version? Well, that's a good thing. :-) The second shot is of my desktop. I'm
launching Unreal Tournament in one window and then trying to take a xwd in the other
window hehe. Notice the UT splash screen, appropriately altered to show the OS of choice.
Pimpage:
Code Crusader is a really cool open source IDE for linux that Jason Keimeg turned me on to. I use MS DevStudio most of the time under windows and when I started using Code Crusader I didn't feel that any features were missing. It has a fast editor and good project management. It also has a very cool C++ inheritance graph capability.
K Desktop Environment is the desktop environment I'm using for X. It rocks! It has all sorts of nifty applications that make things easier, plus it has some cool device browsing capabilities if you are pretty Linux illiterate like me.
LinuxGames.com is a cool site with information about which developers are doing what in Linux. They also keep track of what games they have found to be successful in WINE (a windows emulator for Linux...icky).
So we are making good progress on the Linux front. Now that I've got the Unreal Engine nice and portable, all of our future games will be co-developed under Win32 and Linux. Licensees who base their games off of portable Unreal Engine versions will also be in a good position to make games for both Win32 and Linux.
If you have any questions you can email me at brandon@epicgames.com and if you have any nifty X or Linux programming hints feel free to fire them off. :-)
- Brandon "GreenMarine" Reinhart
|
July 16, 1999 |
I've had a few questions from users asking how to obtain the latest NVidia Riva TNT/TNT2 drivers, which are required to run Unreal in Direct3D (previous drivers had problems with Unreal).
It's easy, just follow these 35 simple steps! :-|
To prepare for installation of the drivers
1 Start Microsoft Windows 98.
2 Click the Start button, point to Settings, and click Control Panel.
3 Double-click Display, and click the Settings tab.
4 Click Adapter, click the Change tab, click Next.
5 Select the option to display a list of drivers, then click Next.
6 Select Show all Hardware button, then select the Standard display types from the Manufactures list.
7 Select Standard PCI Graphics Adapter (VGA) from the list, then select Next.
8 Click Next to install the driver, click Finish, then select Apply to complete the installation.To install the drivers
1 Click the Start button, point to Settings, and click Control Panel.
2 Double-click Display, and click the Settings tab.
3 Click Advanced Properties, click the Adapter tab, then click Change.
4 Click Next, click Next, then Click Next.
5 Select or type the path to the driver, then click OK. Windows should find files for the NVidia RIVA TNT. If Windows cannot find the files, check that the path name is correct.
6 If Windows found the files, click Next. Windows copies the files to the hard disk.
7 Click Finish to complete the installation.
8 Click Yes when Windows asks if you wish to restart the computer.
Downloading drivers and patches is an unfortunate necessity in this industry. There are several reasons for this. One, Direct3D and OpenGL are at a pretty early stage of evolution on the PC compared to other drivers (for example, printer drivers are now very reliable and stable). So, there are a lot of features in the API's that aren't very well defined or well tested, and the API's and extensions are evolving very quickly. Two, hardware makers are under extreme market pressure to get their cards to market quickly, so they often end up rushing the drivers, and fixing them later. Three, there is tremendous variation among Direct3D and OpenGL games, so that a driver that performs bug-free under some games may have bugs revealed as soon as a new game ships.
These factors are unfortunate, especially for novice gamers who buy a new 3D game and have trouble getting it working. But they're not a sign of evil or incompetence among companies. When you combine the free, open nature of the PC hardware and software market with the incredibly rapid pace of 3D hardware innovation, you get a certain amount of chaos. This is why PC games are much less reliable than Playstation games, but also why PC's and games get better every few months. So, I see that as an acceptable tradeoff.
Since software and hardware makers know their games and drivers are imperfect and will need to be patched, we have a responsibility to our customers. We are obligated to keep up with the latest innovations and incompatibilities.
This process isn't perfect. We've released a lot of Unreal patches, and made many improvements to the product -- and the patching process -- along the way. In the beginning, we released many separate sporadic hardware-specific patches as .zip files, and that made it hard for users to keep up with the proper complete version. Since then, we created the Unreal tech page to keep the community informed of patches and progress; we created our own installer/patcher to automate the process, and we have a private beta test team consisting of enthusiasts in the community to validate patches before they're released publicly. So we're always making a real effort to improve the ease-of-use.
Nowadays, the Unreal patching process is pretty close to optimal. To get an update, you need to:
For Unreal Tournament the process is even more automated. UT contains a "download latest version" option in the game, which sends you to our web page, and eliminates steps 1-2 above. It can also automatically detect that your version is outdated.
I'd love to see 3D hardware makers borrow this "make patches easy" concept. It would make all our mutual customers happier! Not to mention any names <cough>NVidia</cough>.
-Tim
|
July 13, 1999 |
Unreal Tournament will ship with out of the box support for statistics logging and ranking using Net Games USA's ngWorldStats software. The software allows players to track their performance online at ut.ngWorldStats.com. You can track tons of different types of stats: your kills, your best game, your total score overall, and so forth.
This Wednesday July 14, 1999 at 10:00PM Eastern, three Epic developers are going to deathmatch three Net Games USA developers and put the stats online at:
So this is what we are going to do. Everybody at Epic uses ngWorldStats and ngStats quite a bit. We think its going to kick some ass for organized clan play and for big tournaments. You can use ngWorldStats for watching your individual performance online and you can use ngStats for LAN parties, big tournaments, or even tracking your single player performance.
In order to show off some of the clan play goodness, we are going to have the following setup.
During the game we'll be taking screenshots to put up afterwards. The stats page will update immediately after the game completes and you'll be able to see how everybody fared.
We think that ngStats is going to be a great way for teams to visualize their strengths and weaknesses as well as archive their games. Craig and Brandon use it at LAN parties (put it on your LAN party server along with a web browser and you have an instant game reporting nexus.)
Finally, UT supports Net Games USA's ngTCS - Tourney Control System out of the box. You can use it for LAN parties or big tourneys to automatically perform online event registration, match scheduling, interactive match brackets, and live game stat reporting.
Coolness! So drop by http://UT.ngWorldStats.com/Epic_vs_ngUSA/ Wednesday night to check out the game. Also check out http://UT.ngWorldStats.com/ for a look at the world stat logging system and check out http://www.netgamesusa.com/ for info on NetGames USA.
- GreenMarine
|
July 12, 1999 |
By popular request, the links on the tech page have been updated and cleaned up. I added:
I also wanted to mention the supercool new download site, Unrealfiles.com, check it out.
-Tim
|
July 10, 1999 |
My new 550 MHz AMD Athlon (K7) just clocked a jaw-dropping 68.5 Unreal timedemo at 1024x768, running on a Voodoo3 3000 card. Even more telling, at no point did the frame rate ever drop below 38.0 fps. That's astounding, considering the intense lightmap and geometry usage in the timedemo level. Even while playing Unreal Tournament's most texture and polygon intensive level (Shane Caudle's DmGothic), the frame rate hardly ever went below 60 fps.
The Athlon's 128K L1 cache is awesome for memory-intensive games like Unreal. Operations like visibility determination, which thrash on the Pentium III's 32K cache, now run at full speed on the Athlon. This CPU truly shows a generational performance improvement, like going from my old 486 to my first Pentium.
When I saw AMD's K7 spec, I was pretty skeptical. The K6 had been hyped up, but in reality it was slower for Unreal than a Pentium II of comparable clock rate, due to its poor non-SIMD floating point performance. The K7 claimed to fix all of that, and debut a new architecture with 3 execution pipelines. I decided to wait and see, without getting my hopes up.
Bottom line: I waited, and now I have seen! The Athlon is clearly the fastest x86 CPU at any clock speed.
Congratulations go to AMD.
My wish list:
-Tim
|
July 8, 1999 |
I just played the first working test game of Unreal Tournament on the linux server. Woo hoo! Huge thanks go out to the Linux Guru Mike Danylchuk for doing the majority of the porting. He brought the linux server up to 224 and then I finished it off. I spent the majority of my time learning egcs and figuring out the right way of doing things. Once I got a hang of it, the process was simple. Most of my problems stemmed from variable size issues (which resulted in offset errors between the C++ and UnrealScript representations of objects). Mike, an experienced egcs hacker, was able to point out the culprits and I adjusted the C++ header generator to compensate.
Also big thanks to Tim for weathering my endless barrage of questions and offering helpful suggestions.
This means that a solid UT linux server will most likely be available when UT ships (if not sooner). I'll probably see what needs to be done to get everything moved over to the Unreal source safe and cook up an Unreal linux server for our beta testers tonight.
Brandon 'Linux Has Issues' Reinhart (GreenMarine)
|
July 3, 1999 |
Ok, the headline is exaggerating a bit. Still, there are some cool things happening with the Unreal engine that we find very exciting--uses of the technology that we never dreamed would exist a couple years ago.
For example, as the latest PlanetUnreal news story describes, the Digitalo Design team is building a "virtual reconstruction" of the Notre Dame Cathedral. And it looks jaw-droppingly amazing! The team here, busy working on Unreal Tournament, is very jealous about the polygon counts these guys are using (the lucky bastards don't have to worry about the CPU impact of 12 players deathmatching in their creation!)
Also, the rapidly-growing independent news site, UnrealEngine.com, is covering lots of other Unreal engine projects that fall way outside the "first person action" stereotype, such as Hasbro's Nerf Arena Blast (see AVault preview) -- as well as the other well-known projects from our partners.
There are other interesting things happening with the tech, behind the scenes. A number of schools (ranging from high schools to universities) are using UnrealScript to each real-time object-oriented programming. Several university masters-degree thesis projects are centered around projects involving the engine. Some architects are using the editor to generate real-time architectural walkthroughs. At least two Silicon Valley startups are pitching completely non-game projects incorporating the Unreal engine to investors.
What we're seeing is part of a larger trend that will continue to grow. Remember ten years ago, when PC's were very weak compared to the state-of-the art: SGI workstations, and the Unix workstations from HP, Sun, and Apollo?
Now, a $2000 Pentium III PC with a Voodoo3 or TNT2 card eclipses the performance of a $30,000 SGI for real-time rendering. The CPU is faster, the fill rate is faster. When I first saw an SGI Reality Engine, my impression was, "Holy cow, I can't believe how much better this is than my '286!" But nowadays, the best 3D games look far cooler than anything you see running on a Reality Engine.
That entire segment of the high tech industry, the one containing non-PC workstations, SGI's high end hardware, simulation tools vendors, and so on, is falling off a cliff and disappearing. One-time leaders like SGI and Intergraph are turning into niche players, who are losing out badly to the new guys like Dell, Gateway, NVidia, and 3dfx who were born and bred in the consumer, high volume, low-price PC era.
The result is that projects, like the Notre Dame reconstruction, architectual walkthroughs, and training simulations--which were once the realm of high-end SGI's--are now coming to the PC in droves. Soon, they'll all be here.
What we're seeing in processors, 3D accelerators, and games is a fundamentally different level of technological progress than happens in other markets. Industrial era businesses, like car manufacturing, and limited by raw materials and labor. Most of what you pay for a car goes to materials, labor, and the other economic components of the industrial pipeline (like transportation, insurance, and so on). Years of tweaking the process have made manufacturing near optimally efficient, so future progress goes very slowly, gaining perhaps 2%-3% productivity per year. That's why there is no Moore's law for car performance.
But in our business, the cost of raw materials is insignificant, so innovation is driven by volume and R&D investment. A 500 MHz Pentium III now costs the same to manufacture as a 60 MHz Pentium cost in its day, or a 386-16 long ago. A retail game contains around $2.50 of raw materials (box and CD) and sells for around $49.95. So, manufacturing isn't a limiting factor here.
Still, games, processors, and 3D cards require a tremendous up-front investment in R&D and facilities. It takes lots of people and a lot of capital to develop a game, design a chip, or design and build a manufacturing plant. The difference is, this investment is a fixed cost--you pay it once, then you have the ability manufacture as many games or chips as you desire at an (approximately) insignificant cost.
The remaining piece of the puzzle is the "winner take all" nature of technology markets. Since manufacturing costs are small, price differences are minor, leadership goes to the companies that have the best high-volume products. Therefore, everyone invests heavily in R&D, and attempts to produce the best product in hopes of selling tons of chips or games or engines. When they do this successfully, they make a profit and plow it back into the business to get further ahead. Most R&D and capital-investment hungry markets work this way; it's why you only see a handful of prominent CPU makers, 3D card makers, and engine developers. The ones who delivered were successful early on and reinvested in their continued growth; and those who didn't deliver either out-of-business or are falling apart now.
The result is that high-volume general-purpose hardware and software is quickly gaining the lead in absolute performance. This trend will only accelerate as the PC market becomes larger and the R&D investments grow. The ramifications are:
When you look at the big picture, what's happening now with 3D graphics on the PC is just the tip of the iceberg. In the past, we've been limited to the realm of hardcore gamers, but now 3D acceleration is becoming much more mainstream, and 3D engines are becoming recognized as a viable development tool for a wide range of projects. The coming years will be interesting.
-Tim
|
July 1, 1999 |
Testing of 226a brought in mixed results: Direct3D performance improved for most testers, but some had crashes and other weirdness. I'm looking into all of this now; I think most of the problems are driver/hardware related, but I should be able to work around most of them in the code. We'll definitely go through a couple more internal test versions before releasing 226 though.
I'm also adding a new "wizard" based user-interface for switching 3D drivers and changing "safe mode" settings, to improve the user-friendlyness of the Direct3D/OpenGL/Glide/Software switching.
A Theory of Objects is an excellent book for people trying to design object-oriented programming languages (or just learn the theoretical background of OOP). It does get pretty technical, defining a lambda-calculus variant in terms of objects, and analyzing OOP concepts within that framework. But it sheds a lot of light on the general language-design problems that UnrealScript faced.
After writing a big piece of code like the UnrealScript compiler, it's cool to examine some of the design decisions that I made without really knowing what I was doing, only to discover there's a well-developed theoretical foundation for what I basically hacked together until I felt it worked right. For example, it turns out that UnrealScript's type-compatibility checking (the rules for determining whether a variable is compatible as an assignment parameter or function call parameter), exactly follow the rules of type covariance, contravariance, and invariance.
|
June 30, 1999 |
We're testing 226a internally now. The results of are good so far. If no significant "non-driver" problems are found, we'll have Unreal 226a out later this week. Here is the kind of feedback we're seeing on D3D Unreal performance.
First client impressions, after zonking it with a couple of really nasty, detailed, clippy, high polycount maps: incredible improvement! I got through DMDowntown, my personal UnrealRavager(tm) with nary a clip, pop or tick. Switching resolutions works well now, but you have to have the latest Hercules driver (now using 1.70, dated 6-28-99) for it to work, or you get a critical error. ALT-ENTER works fine too, thanks Tim (now I can get multiple screenshots without exiting and restarting Unreal). DMBreakfast, a new map which uses a great deal of UnrealEd rendered graphics, played very well too.
This is a quantum leap for the 'in game' video speed on the Hercules TNT2. Most impressive. I'll try to get this patch on the Nali City game server (unreal://207.53.187.28) tomorrow so we can all beat it up.
-Pete, PlanetUnreal
This isn't a miracle improvement, but TNT, G400, and Rage 128 owners should see clear speed and smoothness gains. Just make sure you get the latest drivers available for your card.
-Tim
|
June 19, 1999 |
Our Direct3D performance and stability have increased significantly since version 225. For the past few days, I've been swapping 3D cards in and out, tuning Unreal's Direct3D performance on all of them. I'm not in the benchmarking biz, so I'm just going to give my personal reaction from playing, and say that the Riva TNT, TNT2, Matrox G400, and ATI Rage 128 are all very nice for playing Unreal now!
(Don't ask about the Riva 128, Rage Pro, and Permedia 2, they are worse for gameplay than Unreal's software renderer).
Everyone's complaint with Direct3D support in past versions of Unreal, on good cards like the TNT, has been "the average frame rate and benchmark numbers are fine, but there is major hitching and pausing during gameplay". This was due to several factors, which I tracked down and fixed with help and advice from some driver writers. The key improvements are:
The next patch ("when it's done") will incorporate the new Direct3D code. This will be out before Unreal Tournament ships, and we'll be looking for feedback from players on its performance and stability.
I'd like to thank Ben de Waal, Sim Dietrich, and Doug Rogers at NVidia; Sameer Nene at Microsoft; and Eric Le at Matrox for providing cool advice and performance tips.
Never ever Lock() a video memory surface. That is amazingly slow, especially on TNT cards. When I went to a pure Blt() based texture handling scheme, my worst-case frame rate went from 8 fps to 20 fps.
Games that use large amounts of textures, palettized textures especially, should not use DDSCAPS2_TEXTUREMANAGE. Write your own texture manager, and optimize it around your game's usage patterns. You can get much better performance than using the general-purpose one that's built in.
Realize that DDSCAPS2_TEXTUREMANAGE makes system-memory copies of all your textures as backing-store for the ones cached in video memory temporarily. If your native textures are palettized and the 3D card doesn't support paletted textures (a very common case with Unreal), realize that you're going to end up with major memory waste. Unreal 225 and earlier kept around (a) its own 8-bit copy of each texture, (b) the D3D texture manager's 16-bit copy of each texture, and (c) the 16-bit video memory copy. In Unreal in some cases, this wasted 40+ megs of system RAM! When I dumped DDSCAPS2_TEXTUREMANAGE, I went down to about 12 megs of system RAM. Better yet, a lot of cool new cards like the TNT2 and G400 have 32 megs of video memory, so you can effectively store all your textures there, and free the system memory copies (which I do), to bring the waste down to 0. This improves smoothness very significantly by reducing virtual memory usage.
Realize that DDSCAPS2_TEXTUREMANAGE can potentially do evil stuff to your frame rate, for example if it tries to free many small textures to make room for a big texture. (It's totally general-purpose, so it has to handle all the bizarre inputs you might throw at it).
Never allocate or free video-memory textures during gameplay in Direct3D. This operation is slow. Do it at init time. I do this in Unreal now, caching all textures into fixed-size bins in video memory. I swap textures into the bins in realtime, but never reallocate the bins.
Don't be afraid to constrain your engine, texture formats, texture sizes, etc to get optimal Direct3D performance. GENERAL==SLOW, especially when dealing with texture management, where you are already pushing RAM and memory bandwidth limits.
Overall, Direct3D has come a long way. The API and drivers are quite stable now. In my 100 hours of rewriting the Direct3D code and testing it on 10+ different 3D cards under Windows 98, I had 5 lockups. This is about the same as my experience with OpenGL on Windows NT.
-Tim
|
June 16, 1999 |
There are a bunch of cool new things that mod and map authors can do in UT. Map authors can stick a "mapshot" in their .unr file, which will be displayed when the user starts a practice session or a server (along with the author's name and the map name). Here are the steps:
This will import the texture "Screenshot" into your map. Of course, you don't have to use a screenshot of your map. You can always put a picture of yourself, or a scan of your cat.
- GreenMarine
Mutators are another cool thing. Mutators are like Actor arbitrators for a GameInfo. You can have any number of mutators in a game. When an Actor is added to the game, it asks each Mutator to deal with it. This allows you to write a simple little Mutator object and completely change the behavior of the game. Here are some things we've done with mutators:
InstaGib is particularly cool. We played it for three hours last night. It removes all armor and all powerups and gives everyone a special shock rifle. The rifle has a reduced firing rate, no alt fire, unlimited ammo, and does 1000 points of damage. The game plays like OSP Tourney DM rail arena (my inspiration hehe). One shot kills, but you got to hit them dead on. We were playing with the LowGrav mutator on also, so it was pretty wild.
Using Mutators, a mod author can write a complete mod with only a little bit of code. Just write up your new powerups or weapons and then write a mutator to facilitate their placement, instead of a new GameInfo. Mutators don't have all the capabilities of GameInfos. They are a supplement, not a replacement. The benefit is that the Mutator you write can be used with any gametype. You can play InstaGib CTF if you want, or InstaGib Domination, or LowGrav Team Deathmatch.
Mod authors focusing on larger projects (like a class based mod) could write special mutators to give server operators more options. You could have a NoSnipers mutator, or a NoRocketLauncher mutator. Then a server operator could combine the mutators to get special behavior.
Some mutators are mututally exclusive. There is a special Mutator called "Arena." No more than one Arena mutator subclass can be in the game at one time. The "SniperArena" and "RocketArena" mutators replace each weapon in the map with their respective weapon type. The game will only allow one of these to be added to the mutator list. Programmers can look at the Arena mutator code to learn how to set up a relationship like this.
There is a lot you can do with them, so start coming up with ideas. :-)
- GreenMarine
|
June 6, 1999 |
Since Riva TNT users are reporting that Direct3D is more than 30% faster than OpenGL on their cards, I've been spending some more time improving the D3D code, adding better support for video mode switching, and optimizing the texture management code a bit more.
Another motivation for the Direct3D improvements is the Matrox G400. I just received one, and it's an awesome video card--fast fill rate, great graphics quality, and decent texture management performance. The G400 has a great Direct3D driver, but their OpenGL is hideously bad.
One interesting new feature I managed to implement in Direct3D is recursive, fractal detail textures. With this feature enabled in Direct3D, you never see any individual texels, no matter how close you get to a surface. It's a really interesting contrast to the blurry bilinear filtering you see near surfaces in most games. Considering how fast current 3D hardware has become, there's no reason for games to reveal any individual texels anywhere.
-Tim
|
June 4, 1999 |
You can download the Unreal 225f patch from one of these locations:
I've had to pull the 225f patch from the Tech Page WWW server. Our T1 here in the office has become almost completely unusable since this morning's post on Blue's and elsewhere about the Direct3D improvements in 225f. I am currently organizing a couple of mirror sites so we can make the file available to all in the next hour or so.
- Jack
|
June 1, 1999 |
If UnrealEd is crashing at startup and you are getting an error message regarding "UEditorEngine::FinishAllSnaps <- WM_USER_EXEC <- VbWindowProc <- glxDetectOutput", that is a separate problem that seems to be caused by some sound card drivers.
You can avoid this crash by running "UnrealEd -nosound". You don't get any sound, but UnrealEd otherwise works fine for editing.
A few server admins have been reporting a cheat that enables clients without administrative rights to change the speed of the server's game (as if typing "slomo 0.5" from the console in a local game). What's the trick? First person to give the exact steps to duplicate the cheat gets a free signed copy of Unreal Tournament as soon as it ships. Send reports to unreal225@epicgames.com with a subject "SLOMO CHEAT". Include your shipping address.
Are people seeing any other cheats occuring on the public Unreal servers? If so, let us know, unreal225@epicgames.com (no prizes for this, we'll just fix the security holes!)
The version of Unreal that shipped with 3dfx's Voodoo3 bundle didn't include UnrealEd. So, we now have the Standalone UnrealEd Installer which installs UnrealEd.exe and all of its DLL's into the appropriate directories. For this to work, you must have Unreal installed, and you must point the UnrealEd installer to the same directory Unreal is in (for example c:\Unreal). Then just run c:\Unreal\System\UnrealEd.exe to start editing.
-Tim
|
May 31, 1999 |
Here at Epic HQ, we suspect today is some type of holiday. The tell-tale sign is that the parking lot was empty when we all came to work this morning. That usually gives it away. However, we haven't figured out the identity of the occasion -- it seems too warm outside for Easter, and our publisher isn't calling us three times a day about shipping our game so it's probably not Christmas.
This should fix the UActorChannel::ReplicateActor crash and some smaller problems. It's backwards-compatible with Unreal 224-225 clients. If you have any server crashes, please email your Unreal.log file to unreal225@epicgames.com.
Only download this if you are running an Unreal server: UnrealPatch225f.exe.
-Tim
Server admins are reporting much better performance, but 90% of the bug reports point to a crash in UActorChannel::ReplicateActor. I've been fixing this (and a few other things) and will have a new server-only patch later tonight. Thanks for everyone's feedback!
Based on feedback, Saturday's experimental UnrealEd fix solved the problems for only about 20% of users (wild guesstimate) who were previously unable to run UnrealEd. On further investigation, we've found a set of Visual Basic runtime DLL's that are more likely to work for most users. If UnrealEd still isn't working for you, please try Experimental Fix 2. Please let us know what happens by emailing unreal225@epicgames.com with a subject of "Experimental Fix 2".
IMPORTANT: After installing the fix, reboot your machine before running UnrealEd. The proper files won't be refreshed until you reboot.
Webmasters: Please only post this info on Unreal news sites. I don't want it to go on general gaming sites until we have feedback on patch success/failure from users.
-Tim
|
May 29, 1999 |
This is a test version incorporating all of the latest server-side stability and performance improvements. It's backwards compatible with Unreal 224 clients. If you're running a 224 server and are experiencing performance or stability problems, please upgrade. If you experience any server problems or server crashes with 225, please email your Unreal.log file to unreal225@epicgames.com so we can investigate the problems. The results on our test server here at Epic indicate that this version is significantly faster (i.e. supports more players) than 224, and is more stable but I don't expect it to be perfect, because I rewrote about a thousand lines of server code to improve performance, and there will probably be some bugs to shake out.
Only download this if you are running an Unreal server: UnrealPatch225e.exe.
The general Unreal 225 patch for everybody including users will be available in a few days.
-Tim
In this MSNBC interview, I think John Carmack hit the nail on the head on the "build vs. buy" decision that goes into licensing an engine:
"If you want to aim for something that’s 100 percent proprietary and you’re willing to take 18 months longer on the project to develop the technology while running a significant risk of abject failure, you make your own game engine. If you’ve been to a few E3’s, you’ve probably seen a dozen instances of somebody making a really, really cool demo that’s showing off some new technical direction — then the game never comes out."
Though game engine licensing was occuring over two years ago, we're still very much in the early days of this rapidly growing and evolving market: Game developers are learning what an engine can and can't do for them, and engine developers are still learning the ropes of the business models, engine modularity, support, and version management.
I'm happy to see the press treating engines level-headedly: everyone seem to recognize that an engine is a useful tool that can speed development and enable a developer to focus on game development rather than technology; but also that an engine is just a tool and isn't a miracle solution for game development. When an exciting new technology is evolving, there's always a danger of it being massively overhyped and pushed as a cure-all solution (see Java), but engines seem to have received a fair showing, not unrealistically positive or negative.
-Tim
People who are getting the infamous "Runtime Error 20005" or other problems when UnrealEd is initializing, please install this Experimental Fix, then try running UnrealEd again. Does this solve the problem for you? Please email unreal225@epicgames.com and let us know either way. Note: This is a feedback email address, not tech support.
Webmasters: Can we please not post this on big general gaming sites? I want to get feedback from users on the effectiveness of the fix before widely publicizing it. I'll post the results here in a couple of days. Thanks.
-Tim
|
May 19, 1999 |
The recent work on 225 has been focused on improving server performance and stability, and it has been paying off really well. It turns out that 224's server code was noticeably slower than 220, as a result of some code improvements I made but didn't test and time rigorously. The two bottleneck routines in the server are the visibility tracer and the actor replicator. I've been making the visibility tracer faster by processing all actors simultaneously and optimizing the code for a pure "yes/no" visibility test, rather than using the more general (and slower) line trace routine built into the engine. The actor replicator has gained significant speedups from a combination of low-level optimization (to the bit-stream writer, and replication condition caching code), and a new time-stamping system that speeds up replication by up to 50% on servers with high player counts.
Now, the 225 server is faster than all previous versions, and I'm working on some further improvements over the next few days.
As many server admins have pointed out to us, if we can double Unreal's server performance, admins will be able to run twice as many servers on their machines!
Check out the Contest site for the latest info and news on the contest for Unreal map makers, mod authors, artists, and TC developers!
-Tim
P.S. Check out Unreal Nation, the cool in-depth Unreal news site.
|
May 8, 1999 |
All the known server-crashing problems in 224 have been fixed and are in internal testing now. Stability has improved quite a bit. There is still significantly higher server CPU usage in 224 compared to 220 on heavily populated servers, and I'm still tracking this down.
The Direct3D code has been cleaned up and optimized a bit, giving a few FPS improvement on the Riva TNT, with support for detail textures now enabled. 225 will include the new D3D driver, and the 225 public source release will include the source.
-Tim
|
May 5, 1999 |
Some user maps such has DmHellShrap broke with version 224. This was caused by a little bug in the file backwards-compatibility code, that I've fixed for 225. Map authors don't need to do anything, this will automatically be fixed with 225. The specific problem I fixed was an exit with an assertion:
Assertion failed: Field [File:..\Inc\UnClass.h] [Line: 139]
If there are any user maps which don't require .u file mods, and the maps refuse to load with a different error message than this, please email the map (or a URL where we can download the map) to unreal224@epicgames.com.
-Tim
We've been going through the Unreal 224 bug reports and addressing lots of issues people have pointed out. Here's the latest status.
Many other fixes, tweaks, and incremental improvements are in the works. See the Known Bugs page for more info.
-Tim
|
May 4, 1999 |
A few of people have asked how they can customize the tabs in Unreal Browser, to display specific tabs for their netgame mods. This can be done easily by editing your Unreal.ini file. Each tab in UBrowser has an associated Server List. This server list has one or more Server List Factories - classes which add servers to a server list. We shipped 224 with four list factory classes, but mod makers can make their own if they have some custom method of getting a list of servers for their gametype:
To customize a tab, you just need to decide which list factories you need and the parameters you need to give them. In unreal.ini in the [UBrowser.UBrowserMainClientWindow] section, there are a number of arrays. Each array index represents a server list tab.
For example, a tab which queries two master servers (and removes duplicates), has entries in the ini file like this:
ServerListNames[0]=All Servers
ServerListTags[0]=All
ListFactories0[0]=UBrowser.UBrowserGSpyFact,MasterServerAddress=master0.gamespy.com,MasterServerTCPPort=28900,Region=0
ListFactories1[0]=UBrowser.UBrowserHTTPFact,MasterServerAddress=master.telefragged.com,MasterServerTCPPort=80,MasterServerURI=/servers.txt
URLAppend[0]=
AutoRefreshTime[0]=0
For a tab showing only games of the specific game type for your mod, you would use a UBrowserSubsetFact to filter out only servers for your mod. The SuperSetTag specifies which server list to get the servers to filter from:
ServerListNames[1]=My Mod
ServerListTags[1]=MyMod
ListFactories0[1]=UBrowser.UBrowserSubsetFact,SupersetTag=All,GameType=My Mod Type,bCompatibleServersOnly=True
URLAppend[1]=
AutoRefreshTime[1]=0
Valid parameters to the the UBrowserSubsetFact factory are:
I have just added a "MaxPing" filter for the 225 patch. If anyone has any other requests for filtering servers, or any questions about UBrowser, please let me know. Tim mentioned he's going to modify the mod installer so it's able to add an entry into the next available array slot, so mod makers can automatically add tabs to users' UBrowser windows when they install the mod.
- Jack "Mek" Porter
|
May 3, 1999 |
Having a problem with Unreal? Please visit the Known Bugs page to see if we know about it and are addressing it, and if there any any workarounds.
There will be another Unreal 1 patch. It will be 225. It will contain fixes for the significant bugs reported that are under our control (3D card drivers are dependent on the hardware makers). By popular demand, our focus on future Unreal 1 patches will be making bug fixes and small, incremental improvements. So, we've split off the Unreal 1 code base from the Unreal Tournament code base, and won't be major new features added to the Unreal 1 code base, just fixes.
This code split gives the server community some room to get back together and grow healthily. The server community was fragmented in the past because of our Unreal 224 delays, at one point having 4 major versions available (220 for the PC, 219 for the Mac, 222 for U.S. 3dfx Voodoo3 users, 223 for European 3dfx Voodoo3 users. From here on, we'll keep network compatibility between versions, and keep code changes to a minimum. And we'll keep Unreal 1 script compatibility (but not UT script compatibility).
The split also gives us more flexibility in releasing future patches. In the past, we've been adding so many new features to the engine for Unreal Tournament, some necessitating architectural changes, that we've had a long internal testing cycle for each patch. From now on, the Unreal 1 changes will be simple and localized.
The split is also something our Unreal tech licensees have wanted. From here on, our partners who want to ship games soon (before or soon after Unreal Tournament) will prefer to stay on the 224 track to gain stability and minimize changes, and those with further-off products may want to move forward with the Unreal Tournament code track, to keep up to date with the latest features.
-Tim
I'll be making a summary of reported bugs, workaround, and related feedback from the community later tonight.
Thanks PlanetUnreal for pointing out this feature I added months ago but basically forgot about. :)
Though it theoretically works, the consumer OpenGL drivers I've tried aren't yet stable enough for it to work reliably on real-world hardware. But for people who like experimenting, if in-game OpenGL support works flawlessly, you can try editor OpenGL support by changing the WindowedRenderDevice= line in Unreal.ini to WindowedRenderDevice=OpenGLDrv.OpenGLRenderDevice. Problems I've experienced on my Riva TNT and ATI Rage Pro (2 months ago) include crashing in the display driver when resing windows, failure to create HRC's when opening windows, and texture corruption.
If there is enough demand, perhaps we can pressure 3D hardware makers to test with UnrealEd. Hopefully this will be easier now that we've released Unreal's OpenGL source code to the public.
-Tim
|
May 2, 1999 |
When playing a multiplayer game of Unreal, press TAB and type STAT NET to bring up the network stats display. You'll see something like this:
(IN/OUT):
137 PING
38 CHANNELS
0 0 UNORDERED/SEC
12% 14% PACKET LOSS
11 32 PACKETS/SEC
126 32 BUNCHES/SEC
1395 2031 BYTES/SEC
2600 2600 NETSPEED
The numbers on the left represent incoming statistics (for example, how many packets from the server to you were lost), and the right outgoing statistics (for example, how many packets from you to the server were lost). There interesting stats are:
Unreal 224 servers are popping up very rapidly, and becoming filled to capacity rather quickly. From the last couple hours of cruising the net and playing on various servers, we're seeing wildly varying performance. As with all games, the quality of Unreal netplay is a function of how well the server is performing and how good your connection is (bandwidth, packet loss, and latency).
If you're having a bad experience, please try out a few other servers. This can affect performance hugely. In my game sessions here, I had some great performance with a 300 msec ping and 28.8Kbps bandwidth, and some astronomically bad performance with a 100 ping and 50Kbps bandwidth. The bad performance fell into two categories.
Some servers have more users than bandwidth available, so they are dropping packets, experiencing 50%+ packet loss and escalating ping. Some are just running very slowly, around 5 fps (I'm not sure why, perhaps other processes were running?). This tends to happen whenever we release a patch, as people rush to get into gameplay, flooding the servers that have upgraded, users setting up servers on cable modems out of desperation to get into a game... It can get chaotic. In the future, the new backwards-compatible network code should mean there are always lots of servers available when a patch is released.
So, bottom line: Please don't bitch if netplay performance is erratic over the next couple days as servers get set up and stabilized. If netplay performance sucks after a couple of days, THEN commence bitching. :-)
-Tim
For hardcore mod authors who want to experiment with Unreal's C++ interface, here it is! This code requires Microsoft Visual C++ 6.0 with no service packs or SP1. Read the Public Source ReadMe for more information and distribution terms.
Now it's time for a disclaimer about the C++ code. For mod authors, UnrealScript is the best way to write game code. The fact that 100% of the Unreal 1 and Unreal Tournament game-specific code is in UnrealScript illustrates our strategy here, that UnrealScript is a fully-featured language designed to simplify game programming compared to C++. The C++ code is significantly more complex than UnrealScript, and is only necessary for programming things that just aren't possible under UnrealScript, such as algorithmic textures, performance-critical AI decision making, and that kind of low-level work. Furthermore, our distributing just the headers (and not the C++ engine source), means that many key aspects of the engine are hidden in implementation details, so it's going to be hard to understand what's happening "under the hood". Another major downside to C++ is that C++ mods will break with almost every upcoming patch, whereas UnrealScript is more stable (having broken only 3 times in 11 months and approximately 12 public betas released). Summary: This C++ code is for very, very hardcore mod makers only.
That said, there is some cool stuff here. I've included all of the core and engine header files and .lib link libraries in this release, so you can compile your own DLL's and link them to Unreal. I've also included the C++ code for some modules which we don't feel are confidential: Unreal's OpenGL support layer (OpenGLDrv), the engine startup code (Launch), and the installer/uninstaller (Setup).
The OpenGL code will be of interest to OpenGL driver writers who want to see what we do in Unreal, in order to optimize their drivers, and possible to enthusiasts who want to experiment with rendering.
We will probably be able to publically release the Direct3D driver code soon too, also to aid driver writers and experimenters, but our Direct3D development partner is going to first spend some time cleaning up that code.
This code is provided as-is: we don't have much time for answering everyone's questions about it, so you're mostly on your own.
The C++ code can be downloaded here. Unzip it into your \Unreal directory, and the proper subdirectories will be created (described in the ReadMe). The C++ code compiles there and links to DLL's in the \Unreal\System directory, read to run. Enjoy!
-Tim Sweeney
The Unreal 224v patch is now available for download from our downloads page, along with the release notes.
-Tim Sweeney
|
May 1, 1999 |
The team found about 10 bugs in Unreal 224t that are significant and merit fixing before release, so I'm just wrapping up fixes for them now, and we'll have another release candidate (224u) in internal testing this afternoon. Thanks for the patience...we're almost there.
Blues News posted a huge 3DS Max rendering of a bunch of Unreal Tournament characters. These are the actual meshes (same poly count as the game), but textures of this resolution will only be available on cards that support S3TC texture compression such as the Savage4 (though other cards will have support soon). Current 3D cards will have to make due with four 256x256 textures per player. Our new skinning method enables player meshes to be mapped with four textures, so we can have separate faces and armor. This Ultima Online inspired approach lets players customize their look more than past 3D action games.
-Tim Sweeney
|
April 30, 1999 |
We're testing out another release candidate of 224 internally today. We're up to 224t. We haven't found any showstopper problems yet. Fingers crossed...
I just wanted to post some info about the upcoming Unreal 224 installer for mod authors. One of the major Unreal community-oriented features in this version is the mod installer, which enables mod authors to distribute their work in a single, self-contained ".umod" (Unreal MOD) file. Users can then download and launch a .umod file directly, in the same way that launching a .zip file brings up WinZip. The umod's files are then installed into the appropriate directories.
To create your own .umod file, you need to create two text files describing your mod, for example:
Create these two files carefully, because the syntax is fairly strict. Then, you can build your mod using the new "ucc.exe" command-line tool:
The result is a file MyMod.umod, which installs your mod. You can launch this file by double-clicking on its icon in the Windows Explorer, or start it from the command prompt with: "start MyMod.umod".
| SetupFusion.ini (Technical description of the umod) | SetupFusion.int (English language text describing the umod) |
| [Setup] Product=UnrealFusionMapPack Version=100 Archive=UnrealFusionMapPack.umod SrcPath=. MasterPath=.. Requires=UnrealRequirement Group=SetupGroup Group=MapsGroup [UnrealRequirement] Product=Unreal Version=224 [SetupGroup] Copy=(Src=System\Manifest.*,Flags=3) [MapsGroup] MasterPath=\\Server\Safe\Master\FusionMaps File=(Src=Maps\DM-Cybrosis.unr) File=(Src=Maps\DM-Letting.unr) File=(Src=Maps\DM-Loxi.unr) File=(Src=Maps\DM-Mojo.unr) File=(Src=Maps\DM-Shrapnel.unr) |
[Setup] LocalProduct=Unreal Fusion Map Pack ReadMe=Help\ReadMe224.htm SetupWindowTitle=Unreal Fusion Map Pack Setup AutoplayWindowTitle=Unreal Options ProductURL=http://www.unreal.com/ VersionURL=http://unreal.epicgames.com/versions.htm Developer=Epic Games, Inc. DeveloperURL=http://www.epicgames.com/ Logo=Help\Logo.bmp [UnrealRequirement] LocalProduct=Unreal ProductURL=http://www.unreal.com/ VersionURL=http://unreal.epicgames.com/versions.htm Developer=Epic Games, Inc. DeveloperURL=http://www.epicgames.com/ |
The [Setup] section describes the mod being installed.
The [UnrealRequirement] section describes the minimum version of "Unreal" the mod requires. All Unreal mods require Unreal, so you should always copy this section verbatim. If your mod relies on other mods, you need to add a "Requires=xxxRequirement" to the [Setup] section, and then add an [xxxRequirement] section to the .ini file, with the following information.
The [SetupGroup] section must be included as-is in all mods. It describes the files required by the mod installer. (You don't need to know this, but internally, the mod installer creates files called "Manifest.ini" and "Manifest.int" containing information about the mod).
The [MapsGroup] section is a user-defined list of files to be installed. It includes the following:
The [sections] in the .int file mirror those described in the .ini file above. The idea is that the .ini file contains all the technical info, and the .int file contains all human-readable text. This approach enables us to completely translate the installer into other languages, and the translators only need to deal with the installer text, rather than a jumble of text and technical parameters mixed together.
The [Setup] section contains text describing the mod:
The [UnrealRequirement] (and any other requirement sections you specify) contain the following. In the case of the [UnrealRequirement] section itself, just copy and paste the section above into your own installer files.
This is a very important step. Install another copy of Unreal and the latest patch into a new directory, then try installing your .umod into that directory and running it. This is the only way to make sure your mod is complete and self-contained. It's all too easy to forget certain .u, .utx, .int or .uax files that your mod requires. Installing your .umod into your existing "development" Unreal directory and testing it from there isn't enough, you need to test a clean installation.
By packaging your Unreal mod into a .umod file, you gain the following benefits:
"It's not just for total conversions": Some other uses for .umod's are:
-Tim
|
April 19, 1999 |
But we're not quite there with 224 yet. The guys have been beating on internal test versions for the past few days, and we've been polishing the code. It's both a blessing and a curse that the Unreal code is evolving by leaps and bounds, gaining major new features all the time. This approach makes testing each new patch a major effort. Though, 224 will be especially worth the effort because of the in-game server browser and level-of-detail optimizations.
224 will probably happen late this week.
Here is a Next-Generation article where Mark Rein shamelessly plugs the patch.
(warning: nitty-gritty technical info)
An interesting technology feature in 224 is a new method of evolving .u files in a way that is backwards-compatible for network play.
One of the things that has always bothered me about past versions of Unreal is that clients and servers had to have exactly-matching .u files in order to play together. This has meant that every recent Unreal patch has broken network compatibility, leaving some players orphaned. The reason behind this is that Unreal's network code (described in detail here) uses the positions of objects within .u files as a "common point of reference" which clients and servers use to map objects between each others' address spaces. Some scheme of this nature is necessary when network code is generalized like Unreal's is, with the same scripts executing on the client and server, passing arbitrary data back and forth, with the network code transparently coordinating the game world.
I've been aware of some solutions to this problem all along (such as "send all object names as strings"), but they all sacrificed bandwidth.
Recently, I found a no-compromises way to enable .u files to evolve incrementally without losing compatibility. Now, when we release a new version, we copy the .u files into a new developers-only subdirectory \Unreal\SystemConform. Then we can make minor changes to our scripts and recompile new versions that are network-compatible with the old ones. When recompiling and saving a .u file such as \Unreal\System\Engine.u, the script compiler now examines the existing file \Unreal\SystemConform\Engine.u, and makes the new version "conform to the layout of the original". In addition, when a client connects to a server, they both negotiate to figure out who has the earliest version of each .u file, and both talk about objects "in relation to that old .u file". This enables compatibility without any loss in performance or bandwidth usage.
Really major updates will always break code assumptions and require downloading an update. This approach just makes minor incremental updates possible, enables us to test spot-fixes on the net, and generally makes our programming lives easier.
|
April 15, 1999 |
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:
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
...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.
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.
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.
-Tim
|
April 14, 1999 |
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 |
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.
|
March 19, 1999 |
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.
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...
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:
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.
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 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.
I just wanted to point out the following cool technical things.
-Tim
|
February 12, 1999 |
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.
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 |
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.
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.
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 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.
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 |
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 |
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 |
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:
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.
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.
Here's a link to OpenGL information and DirectX information.
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
|
December 27, 1998 |
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 |
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.
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 |
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.
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
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 |
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 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:
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:
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 |
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 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 DMElsinore.MaleThree0 (Function
Engine.PlayerPawn.SpawnCarcass:0016) Accessed None
- ScriptWarning: MaleThree DMElsinore.MaleThree0 (Function
Engine.PlayerPawn.SpawnCarcass:0032) Accessed None
- ScriptWarning: MaleThree DMHealPod.MaleThree0 (Function Engine.PlayerPawn.DoJump:00E4)
Accessed None
- ScriptWarning: DeathMatchGame DMHealPod.DeathMatchGame0 (Function
Engine.GameInfo.Killed:0142) Accessed None
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
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
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
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.
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.
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:
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 |
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.
The cool independent Unreal editing site I mentioned is actually UnrealEd.net, not UnrealEd.com.
|
November 19, 1998 |
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.
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.
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...
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
|
Added by Hyper: Continue to older news
