Professional Documents
Culture Documents
http://www.team5150.com/~andrew/sweeney
March 18, 2007
Contents
1 Prologue 10
2 1998 News 11
2.1 Oct 13, 1998 . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1.1 Unreal Cheat-Finding Challenge . . . . . . . . . . . 11
2.1.2 UnrealScript Notes . . . . . . . . . . . . . . . . . . . 12
2.2 Oct 14, 1998 . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.1 Network Objects Follow-Up . . . . . . . . . . . . . . 14
2.2.2 AWT . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.3 Cheat Challenge Update . . . . . . . . . . . . . . . . 15
2.2.4 Another Public Master Server . . . . . . . . . . . . . 15
2.3 Oct 22, 1998 . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3.1 Linux Unreal . . . . . . . . . . . . . . . . . . . . . . . 16
2.3.2 Hired Guns . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4 Oct 24, 1998 . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4.1 Almost there... . . . . . . . . . . . . . . . . . . . . . . 16
2.4.2 More discussion on CORBA . . . . . . . . . . . . . . 17
1
Tim Sweeney Archive 2 News
CONTENTS
Tim Sweeney Archive 3 News
CONTENTS
Tim Sweeney Archive 4 News
3 1999 News 43
3.1 Jan 01, 1999 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.1.1 Happy New Year . . . . . . . . . . . . . . . . . . . . . 43
3.1.2 Other Updates . . . . . . . . . . . . . . . . . . . . . . 49
3.2 Jan 28, 1999 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.2.1 Unreal 221 Development Update . . . . . . . . . . . 49
3.2.2 Unreal Tournament . . . . . . . . . . . . . . . . . . . 50
3.3 Feb 10, 1999 . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.3.1 Latest News . . . . . . . . . . . . . . . . . . . . . . . 51
3.3.2 What we’ve been programming . . . . . . . . . . . . 51
3.3.3 Linux Notes . . . . . . . . . . . . . . . . . . . . . . . 52
3.4 Mar 19, 1999 . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.4.1 Latest News . . . . . . . . . . . . . . . . . . . . . . . 53
3.4.2 Level-Of-Detail Texture Mapping . . . . . . . . . . . 54
3.4.3 Future of Programming Languages . . . . . . . . . . 54
3.4.4 Visible Surface Determination . . . . . . . . . . . . . 57
3.4.5 Commentary on Cool Stuff . . . . . . . . . . . . . . . 58
3.5 Apr 14, 1999 . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
CONTENTS
Tim Sweeney Archive 5 News
CONTENTS
Tim Sweeney Archive 6 News
CONTENTS
Tim Sweeney Archive 7 News
CONTENTS
Tim Sweeney Archive 8 News
CONTENTS
Tim Sweeney Archive 9 News
CONTENTS
Chapter 1
Prologue
This is a collection of (almost) all the news posts by Tim Sweeney from
the original Unreal Technology archive. Posts not by Tim Sweeney or
not really having anything engine-related may have been left out. The
archive continues to 2003, but Tim Sweeney unfortunately stopped post-
ing in early 2000.
10
Chapter 2
1998 News
I’ve seen two reports that people have found a way to cheat in Internet
play. One person reported seeing a little tiny 1-inch tall player walking
around named ”LilTinyChessPiece”, and another reported a player who
never took damage. I’ve been scouring the code, and haven’t found any
holes which would enable this kind of cheating, but I’d love to hear if
anybody has found a way.
If you find a way for players to cheat or crash servers over the Internet
in Unreal, please email mailto:tim@epicgames.com. The first person to
report a particular security hole in Unreal will receive credit and thanks
here for helping to protect the Unreal community from cheaters.
People who cheat in Deathmatch are lamers, but people who are moti-
vated by simply discovering ways to cheat are doing valuable research.
Note: I don’t consider the following things Unreal cheats:
11
Tim Sweeney Archive 12 News
advantage players (in any game, not just Unreal), but fortunately
people who go to the effort of setting up their own server tend to be
honest and respectful of the community.
• Any of the standard TCP/IP tricks people can use to confuse Web
& FTP servers, such as SYN flooding, packet flooding, DNS spoof-
ing, and so on. These aren’t Unreal-specific cheats, and I can’t stop
them.
There was recently a ”to script or not to script” debate about the merits of
UnrealScript vs pure C/C++. In this debate, several misconceptions were
put forth, which I want to correct:
3. Unreal performs all file loading and saving using serialization. Se-
rialization is automatic for objects defined in UnrealScript. For ob-
jects and structures defined only in C++, such as the following func-
tion that serializes a vector.
friend FArchive& FVector::operator<<( FArchive& Ar, FVector& V )
{
return Ar << V.X << V.Y << V.Z;
}
I’ve chatted with several people lately who have added insight to the dis-
cussion of multi-language programming and networking. One interest-
ing topic mentioned was using the CORBA protocol to coordinate net-
work games. CORBA is a high-reliability protocol with a fairly high amount
of overhead and latency, due to its exacting nature and use of TCP. I see
CORBA as a very suitable protocol for network game backbones. For
example, if you were doing an Ultima Online style world with multiple
servers that stay in synch, CORBA would be good for linking servers to-
gether in a high-reliability, non performance-critical way. But, CORBA
isn’t suited for an actual realtime modem-based gameplay protocol, since
it’s TCP based (which adds terrible lag under lossy conditions), and the
protocol has enough overhead that it’s not going to be able to handle
large amounts of data over the modem.
2.2.2 AWT
third one. Also, thanks all the players who provided observations they
saw of potential cheating online. I’ll write more about these techniques
after the next patch has been released, and the holes plugged.
In the meantime, if you too have figured out how to cheat in Unreal,
pat yourself on the back, you outsmarted me! But also, please resist the
temptation to cheat on the public deathmatch servers...it spoils the fun.
Want to see something cool and unique that’s being done with the Un-
real engine? Check out the http://www.gagames.com/news/bits/9+22+
98/13:01:36.html preview. The http://www.devilsthumb.com/ team is
really pushing the engine, and has implemented a beautiful user-interface
design featuring multiple game windows. I look forward to playing this
game. (Thanks http://www.planetunreal.com/ for pointing out the pre-
view).
The latest Direct3D support is now integrated into the Unreal codebase.
It will be in the upcoming 218 patch in ”public beta” form. It hasn’t gone
through wide testing yet, but we and our partners have been testing it
a lot internally on Windows 95 and 98. It’s looking good on the next-
generation 3D cards (Riva TNT, Matrox G200, Savage 3D), though high-
level optimizations are planned that will boost performance further.
The Voodoo2 multitexture code is in, thanks to the efforts of Jack Math-
ews at 3dfx.
I’m doing some final Internet play testing and tweaking on the patch. My
”torture test” environment is an ISP connection at 24.4K with 400 msec
ping. If it’s playable on that, it should be playable on anything. :) Yes-
terday’s testing revealed a few last-minute problems that I’m working on
now.
I’ll post more thoughts on the topic in the future. With Unreal, distributed
object models are already playing a role in multiplayer gaming, but only
in a ”tip of the iceberg” sort of way. This kind of technology will expand
very interestingly in the future.
We’re gearing up for a big internal test session with 218 right now. The
release date of the 218 patch will depend on the outcome. Note that 218
• http://www.3dlabs.com/drivers/ Permedia
• http://support.atitech.ca/drivers/drivers.html Rage
• http://developer.intel.com/design/graphics/drivers i740
• http://www.matrox.com/mga/drivers/home.htm G200
• http://www.rendition.com/download.html Verite
• http://www.s3.com/bbs/0main/topindex.htm Savage 3D
Please keep in mind that Unreal’s Direct3D support is an early beta and
isn’t yet working reliably on all 3D hardware.
If you’re using the new 218 patch, please fill out http://www.planetunreal.
com/ Unreal performance survey. We’ll be watching Unreal players’ feed-
back in the survey, and looking at all the 218 bug reports sent to the
mailto:unreal218@epicgames.com account. Everyone’s feedback will be
taken into account for future improvements to the Internet play and other
features.
Now, the Glide is the simplest, because it’s aimed at the Voodoo family
of 3D cards, which are very standard and straightforward to support. For
programming to 3dfx cards, Glide is the ideal API. For people thinking
”If Glide is so great, why don’t other 3D cards support it?” The short an-
swer is, if Glide supported other manufacturer’s 3D cards, it would pick
up all the complications involved in real-world Direct3D and OpenGL
programming: Testing for core capabilities, working around driver bugs,
etc.
You can read the release notes and download the patch from the http:
//unreal.epicgames.com/Versions.htm! Our test session went well, and
the participants (including a lot of modem players, and even some over-
seas modem players) reported major success with the performance im-
provements.
Epic’s two deathmatch servers have been upgraded to 218: unreal://
208.212.53.39:7777 and unreal://208.212.53.39:7787. However, since
our T1 line is going to be very saturated with people downloading the
patch, performance probably won’t be very good on our server for the
next several days.
Since the Unreal 218 patch was released, the number of Unreal servers
showing up in GameSpy has increased by 225%. A huge thanks to every-
one who is running Unreal servers now. It’s awesome to see the commu-
nity grow and begin to reach critical mass.
At any time, about 20% of the servers listed in GameSpy are shown as
”Not Responding”. I’ve been looking into this, and there are three reasons
for this.
One, the server has been shut down or crashed but hasn’t timed out and
been removed from the list. Two, the server is switching levels, which
prevents it from responding to GameSpy queries for 5-20 seconds. Third,
the server is shown in GameSpy because a user running a LAN server
(dedicated or non-dedicated) enabled the ”DoUplink” option to publi-
cise their server to the world without realizing the consequences, but ei-
ther exited or is on a LAN blocked off by a firewall. We’ll work with the
GameSpy guys to adjust the timeouts so that fewer ”Not Responding”
servers are listed.
Has lots of potential, but there are major problems with their Direct3D
driver: rainbow colors, time-lag, w-buffering issues, missing textures. We
are hoping nVidia will issue an updated driver soon. The ball is in their
court now.
Their latest driver should run Unreal OK. The framerate isn’t very good,
and there will be a lot of ”stuttering” since texture downloads are very
slow on this hardware. Some users are reporting that creature polygons
appear corrupted. Hopefully nVidia will fix thie error in their driver.
They have a beta Direct3D driver which runs Unreal pretty well (though
it doesn’t appear to be available for public release yet). Multitexturing
currently isn’t working with Unreal, because of a hardware limitation (it
can’t multitexture a paletted base texture map along with a non-paletted
light map).
There isn’t any reason to use Direct3D for Voodoo2, since we support
Glide natively and that tends to be more stable and faster, but their latest
Direct3D driver does run Unreal pretty well. Their detail texture blend-
ing (D3DBLEND DIFFUSEALPHA) doesn’t work, which breaks detail tex-
tures. There are reports of missing lightmaps in some areas (not sure
what’s wrong). 3dfx could get a performance increase here by imple-
menting subrect Blts and hardware triangle-fan setup.
2.7.8 S3 Savage 3D
Works well with their internal beta Direct3D driver. Not sure when this
will be available via the web.
2.7.10 Rendition
2.7.11 Permedia
On Permedia, Riva 128, and Rendition, you may get better performance
using Unreal’s software renderer, especially if you have a Pentium II class
processor. This isn’t such a bad thing, because the software renderer sup-
ports all of Unreal’s key features, including truecolor lighting and volu-
metric fog.
Here are some resources to aid new Unreal server administrators in get-
ting up and running:
• http://www.next-generation.com/
• http://www.bluesnews.com/
• http://www.voodooextreme.com/
Ok, ok, you can stop now, that’s enough testers. :) Server performance
has definitely improved since I last benchmarked it. My dual-processor
Pentium II-300 is serving a 20-player game, copying 600 megs across the
network, and running a 3dfx Unreal client at 800x600. The server is keep-
ing up a steady 15 fps. I have more optimizations planned, though.
On my 28.8K connection, gameplay has remained pretty smooth until I
get into a firefight with 5-6 people, at which point the movement of other
players starts to become unsmooth. We should be able to improve this
significantly further in 220, with two protocol improvements. First, I’ll be
improving the scheme for managing temporary objects like projectiles,
which should reduce their bandwidth usage by around 30%. Second,
Steve Polge and I working out a new variable priority predictor/corrector
scheme for transmitting the movement of other players.
We also have some cool things in the works for 1999. Since Unreal first
shipped, I’ve been working on Internet improvements and bug fixes, while
the rest of the team has been working on a top-secret project we are re-
ferring to as ”Unreal Tournament”. There have been a lot of rumors and
speculation about what this project will be. Some of the rumors are com-
pletely incorrect. For example, we are not
using any alien technology recovered from crashed spaceships on Tour-
nament. (We’re saving that for our next project).
I’m also working on the new, enhanced UnrealEd, with lots of new fea-
tures, improved stability, a plug-in interface, and other goodies. We don’t
have a date for this, but I’m expecting a public beta around new years,
with final release early in 1999.
At some point, we’ll be publically releasing Unreal’s C++ interface so the
community can start on .dll plug-ins for Unreal and UnrealEd. This will
happen no later than the new UnrealEd public beta. It might be possible
to release it sooner, however there are changes in the works which won’t
be binary compatible, so user-created .dll’s would break and need to be
recompiled.
What can you do with Unreal .dll’s? Lots. Here are some examples:
While it’s also possible to write game code directly in C++, the preferable
way to do that is UnrealScript, since there is already a lot of game support
infrastructure built into the language.
-Tim Sweeney
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 compen-
sation. 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 func-
tionality 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 edit-
ing, but the big gains will come in the next-generation engine. A ma-
jor 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 edit-
ing, 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.
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 SUP-
POSED to be server-side-only). This usually prevents the mod from work-
ing, 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
2.13.1 No News
We’re still testing and tweaking Unreal 220. It’s getting closer...
http://www.loonygames.com/ has a cool http://www.loonygames.com/content/
1.16/bent/ 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.
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 dur-
ing the test session, which we’re fixing now:
tim’s issues:
steve issues:
brandon:
We’re hard at work putting the finishing touches on Unreal 220. It’s look-
ing 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 con-
sumption 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 func-
tion 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 be-
ing 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.
very well, because the previously large overhead present in packet head-
ers (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 send-
ing 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 guar-
antees 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 proto-
col would have never have been found.
So, where do we go from here? The majority of the network-related im-
provements coming in the Unreal Tournament timeframe (still unan-
nounced) are high-level, in areas like gameplay rules, client-side predic-
tion, 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 http://unreal.epicgames.com/Network.
htm document. Unreal 1 networking can be described simply as ”a small
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 pack-
ages 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
1999 News
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:
42
Tim Sweeney Archive 43 News
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 compres-
sion 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 compres-
sion. 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 pos-
sible kinds of data.
One interesting technique I played around with for texture com-
pression is wavelet compression. The 2D wavelet scheme for tex-
tures is quite similar to mipmaps: to oversimplify a lot, you repre-
sent an nxn image as a sequence of 1x1, 2x2, 4x4, 8x8 ... nxn. Each
bitmap is stored as ”signed differences” relative to the lower-res ver-
sions of the bitmap. Wavelets are a good starting point for lossy
compression schemes, because the ”most visually noticeable” de-
tails 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 de-
tails 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.
-Tim Sweeney
Unreal 221 development continues, with quite a lot of new features slip-
ping into this version.
Right now, Mark Poesch (the lead programmer of Wheel of Time) is visit-
ing 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, share-
ware 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 http://www.freshmeat.org/unreal/, a great im-
provement over the current process of ”download a file, run PkZip, ex-
tract 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
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 differ-
ence being bots vs. human opponents) has given us a far more opportu-
nity to polish the gameplay and the look-and-feel.
-Tim Sweeney
I’ve been juggling work on the installer, OpenGL, and some core Unre-
alScript improvements. The installer is coming together, and is com-
plete 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 improve-
ments 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 Cap-
ture 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 Tour-
nament, 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 Tour-
nament 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’ve been going through many iterations of internal testing and im-
provements on the upcoming patch, which is now known as 223. Here is
the latest http://unreal.epicgames.com/ReadMe223.htm. The story be-
hind 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 work-
ing 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 (dy-
namic strings, multi-skin support, other engine enhancements) is that
223 will have to break mod compatibility with previous versions, and re-
quire 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 Unre-
alScript 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 com-
munity a chance to experiment with windowing well before Unreal Tour-
nament ships.
I finally got the chance to write a rendering optimization I’ve been think-
ing about for a long time now, level-of-detail texture mapping.
Unreal’s biggest performance problem in OpenGL has been texture man-
agement 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 tex-
tures 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’ tex-
ture usage to 256K of texels per model. More info about additional level-
of-detail features later...
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 ob-
tained from inner classes), what the final garbage-collection strategy is,
how similar do we want to make the language to Java, etc.
• OpenGL http://www.opengl.org/Documentation/Version1.2/EXTspecs/
fragment_lighting.txt and http://www.opengl.org/Documentation/
Version1.2/EXTspecs/light_texture.txt extensions. These exceed-
ingly clear, general, and well thought-out rendering capabilities are
going to be the next quantum leap in 3D hardware acceleration ac-
celeration, enabling true Phong/Blinn bump mapping and a tremen-
dous variety of other features. My reaction to seeing this spec for
the first time is reminiscent of first experiencing 3dfx’s Voodoo ac-
celerator and the Glide API–it’s ”I can’t believe how powerful yet
-Tim
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 amaz-
ing. 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 sin-
gle 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, get-
ting 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 clob-
bers all others is its texture management performance. This is a very
Unreal 224 .u files aren’t backwards compatible with past versions of the
engine. So you’ll need to take special steps to upgrade your .u files.
To upgrade mods to 224, you’ll first need to export your scripts to *.uc
files. You can do this in all versions of UnrealEd like this:
1. Bring up the UnrealEd class browser on the right side of the screen.
3. Click on the ”Export All” button and have UnrealEd export all of the
loaded scripts to .uc files (including yours and the engine’s), creat-
ing a directory structure for all the .uc files: for example, the files
from the Core package are in \unreal\core\classes\*.uc. If your
mod is named XYZ, your .uc files will be exported to \unreal\XYZ\classes\*.uc.
In Unreal version 221 and earlier, you can rebuild your mod named ”XYZ”
from the command line by typing:
cd \unreal\system
del XYZ.u
unreal -make
You can do that now, prior to the release of 224, to verify that your mod
has been safely exported and can be rebuilt from the command line. I
highly recommend doing this now, because if you install 224, you will no
longer be able to load your old .u files, so you’ll have to downgrade back
to 220 in order to export them. Some developers prefer to edit scripts in
UnrealEd, but many of us actually edit scripts in an external editor (like
Visual C++) and use the command-line interface for all production work.
In Unreal 224, we have a new command-line compiler with a slighly dif-
ferent 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 http://www.freshmeat.org/unreal/ and http://www.planetunreal.
com/nalicity/ and testing them. The one ”gotcha” is that some user
maps being distributed contain .u files, and those aren’t backwards com-
patible, 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 gram-
mar!
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 http://avault.com/ has a good article on the latest http://avault.
com/news/displaynews.asp?story=4141999-221754. They spill the beans
on the major new feature I alluded to below:
-Tim
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 ap-
proach 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 http://www.next-generation.com/jsmid/news/6387.html where
Mark Rein shamelessly plugs the patch.
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.
http://www.bluesnews.com/ posted a huge http://www.bluesnews.com/
screenshots/ut/utshot1.shtml of a bunch of Unreal Tournament char-
acters. 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
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:
• NETSPEED: The network speed setting you set using the console
NETSPEED command. Recommended settings 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 band-
width. The bad performance fell into two categories.
Some servers have more users than bandwidth available, so they are drop-
ping 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 re-
lease 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 per-
formance sucks after a couple of days, THEN commence bitching. :-)
-Tim
For hardcore mod authors who want to experiment with Unreal’s C++ in-
terface, here it is! This code requires Microsoft Visual C++ 6.0 with no ser-
vice packs or SP1. Read the http://unreal.epicgames.com/ReadMeSrc.
htm for more information and distribution terms.
Now it’s time for a disclaimer about the C++ code. For mod authors, Un-
realScript 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 neces-
sary 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
The Unreal 224v patch is now available for download from our http://
unreal.epicgames.com/versions.htm, along with the release notes.
-Tim Sweeney
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, incremen-
tal improvements. So, we’ve split off the Unreal 1 code base from the Un-
real 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 to-
gether and grow healthily. The server community was fragmented in
the past because of our Unreal 224 delays, at one point having 4 ma-
jor 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
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 mailto: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 http://unreal.epicgames.com/Bugs.htm page for more info.
-Tim
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
The recent work on 225 has been focused on improving server perfor-
mance 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” vis-
ibility test, rather than using the more general (and slower) line trace
routine built into the engine. The actor replicator has gained signifi-
cant 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 http://www.unrealcontest.com/ 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 http://www.unrealnation.net/, the cool in-depth Unreal
news site.
”If you want to aim for something that’s 100 percent propri-
etary 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 some-
body 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 mar-
ket: 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 tech-
nology; 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 http://unreal.
epicgames.com/Files/UnrealEdFix.exe, then try running UnrealEd again.
Does this solve the problem for you?
Please email mailto: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
3.15.2 Holiday?
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.
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!
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 mailto: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, mailto: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 in-
clude UnrealEd.
So, we now have the http://unreal.epicgames.com/Files/UnrealEdFix4.
exe 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
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 improv-
ing 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 re-
cursive, 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 any-
where.
-Tim
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 ad-
vice and performance tips.
Never ever Lock() a video memory surface. That is amazingly slow, espe-
cially 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 Di-
rect3D. 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,
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.
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
http://www.amazon.com/exec/obidos/ASIN/0387947752/002-3430157-9555648
is an excellent book for people trying to design object-oriented program-
ming languages (or just learn the theoretical background of OOP). It does
get pretty technical, defining a lambda-calculus variant in terms of ob-
jects, 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 know-
ing 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.
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 http://www.planetunreal.com/ news story de-
scribes, the http://www.digitalo.com/ team is building a ”virtual recon-
struction” of the http://www.planetunreal.com/index.asp?images.asp?
interviews/images/vrnd1big.jpg. And it looks jaw-droppingly amaz-
ing!
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 cre-
ation!)
Also, the rapidly-growing independent news site, http://www.unrealengine.
com/, is covering lots of other Unreal engine projects that fall way out-
side the ”first person action” stereotype, such as Hasbro’s http://www.
unrealengine.com/pic/pic_990701Big.jpg (see http://www.avault.com/
news/displaynews.asp?story=6301999-102335) – as well as the other well-
known projects from our http://unreal.epicgames.com/Partners.htm.
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
What we’re seeing is part of a larger trend that will continue to grow. Re-
member 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 impres-
sion 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, architec-
tual 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.
projects that tie into the engine, such as mods and TC’s, and the re-
search projects like Notre Dame. The community has a multiplica-
tive effect on growing the platform.
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
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
By popular request, the links on the tech page have been updated and
cleaned up. I added:
3.24.1 DirectX7
Some people have been asking about our plans for supporting the up-
coming DirectX7. Unreal Tournament will ship with DirectX6 support,
and will be compatible with (but not optimized for) DirectX7. As soon as
Microsoft has released DirectX7 and we’ve had a chance to optimize the
code for DX7 and test it across a wide range of cards, we’ll release an Un-
real Tournament patch with complete DirectX7 optimizations. This has
been the plan all along.
DirectX7 has lots of cool new features. The ones which Unreal Tourna-
ment will exploit are:
-Tim
In response to the pirate punk who has been claiming to have a ”final”
version of UT...
Unreal Tournament isn’t finished yet, so there isn’t a final version. We’re
still polishing, fine-tuning, and optimizing the game and will ’till it’s done.
Believe me, when UT goes gold, we’ll be announcing it here prominently.
Until the demo and release version are available, any copy of UT you see
is an unfinished beta version; unless you’re a reviewer who received such
a copy direct from Epic or GT, having such a copy is illegal. These versions
are clearly labeled ”confidential beta version” or ”release candidate - not
for distribution” in at least 5 places in the program. In addition, they
have time-bomb logic which will cause them to stop functioning after a
certain amount of time. So if anybody gets hold of a version of UT before
release, it should be pretty clear that it’s not legitimate.
3.26.2 DirectX7
Microsoft’s new DirectX7 API will be released soon. I’ve already ported
Unreal Tournament’s Direct3D code to DirectX7 and have noticed a nice
speedup on the TNT2 and GeForce256, primarily due to improved tex-
ture management.
The API’s simplicity has also improved, which is something you don’t of-
ten see: usually code just gets more complex as it evolves. Porting Unreal
Tournament’s code from DirectX6 to DirectX7 only took 3.5 hours, and
mostly consisted of deleting now-redundant code and changing func-
tion calls and interfaces. I’m very glad to see the IDirect3DTexture, IDi-
rect3DViewport, and IDirect3DLight interfaces gone, and replaced by much
simpler state-setting code. Direct3D’s abuses of object-oriented program-
ming are now gone.
With DirectX7, Microsoft did something I welcome, and would like to see
more of: they designed the new Direct3D interfaces to not be backwards-
compatible with the old ones. This enabled them to remove from view a
bunch of the old baggage that obfuscated Direct3D: execute buffers are
gone, unnecessary intermediate objects are gone, and much less weird
COM QueryInterface stuff is necessary.
Ripping out old code and replacing it with new, better designed code is a
great practice which too many software developers are afraid of.
-Tim Sweeney
3.27.1 DirectX7
Microsoft has released DirectX7. You can read about it and download it
from http://www.microsoft.com/DirectX and download it on their http:
//www.microsoft.com/directx/homeuser/downloads/default.asp.
Now that DirectX7 is available, we’re doing final testing and tweaking
We’re still maintaining OpenGL sypport, though it’s not as much of a pri-
ority at the moment because texture management performance in GL
on Windows is significantly behind Direct3D. It’s still useful in NT4 and
Linux of course. I’ve been advocating a GL extension which would en-
able the fine-grained control over texture management that has led to
such an improvement in Unreal performance under Direct3D. Here is a
suggestion I sent to the OpenGL ARB.
-Tim
• Jack and I have been tracking down the performance problems with
the TNT on 64-meg (and lower) machines. To our great surprise, it
appears that the TNT is keeping duplicate system memory copies
of all our textures–we saw system memory grow and shrink in al-
most exact proportion to our ”supposed” video memory texture al-
locations. Thus the game uses an extra 12-26 megabytes of system
memory–a very inefficient allocation of resources. This is a big sur-
prise, because the NVidia guys has always told us this isn’t the case.
Problem in http://unreal.epicgames.com/files/Direct3D7.cpp?
I don’t think so, but I’d love to be proven wrong. I’ll follow up with
our henchmen at NVidia and Microsoft and see if we can track this
down...
Mark Rein walked into Best Buy and picked up a 650 MHz Athlon off the
shelf – an IBM Aptiva with a TNT2 Ultra bundled in. Fastest off-the-shelf
machine we’ve ever seen! Click http://unreal.epicgames.com/Kickass.
wav for our in-depth Athlon review.
-Tim
Tweaks:
These two downloads are beta and haven’t been rigorously tested yet, but
in our gameplay sessions here, they’re a huge improvement on low-RAM
machines with the TNT, TNT2, and GeForce256.
Please let us know how these work for you, by emailing mailto:utbugs@
epicgames.com
We’re working with the NVidia guys to track down the source of the extra
25 megabytes of memory consumption. I’m going to hold off on posting
our benchmarks till we’ve had a good chance to deal with the memory
consumption issue, so everyone is on a level playing field. The NVidia
cards already perform well on PC’s with lots of RAM, so they should be in
good shape once the memory issues are solved.
3.29.3 Links
• http://www.msnbc.com/news/318085.asp?cp1=1#BODY - MSNBC
• http://www.newsday.com/plugin/ccov0929.htm - Newsday
Cool Sites:
-Tim
-Tim
• Much more stable than Windows 98, especially for software devel-
opment.
• Good administration tools, more powerful than NT4 and far easier
to use.
This is a topic we’re very interested in, because we’re always trying to
make our games and engine as widely accessible as possible. As a mat-
ter of fact, today I’m working out the font management issues for the
Japanese version of Unreal Tournament.
The Windows 95/98 OS had very weak international support, and a con-
fusing array of incomplete features such as supporting Unicode in a few
API’s but not all, weird and undocumented multibyte character set han-
dling, and mixed ANSI/OEM file system conventions. Localizing Win-
dows 9X apps is a very difficult undertaking.
On the other hand, Windows 2000 is by far the most thoroughly inter-
nationalized piece of software I’ve ever seen. All international versions
sharing the same binaries, fonts, and input support. Everything is 100%
Unicode. So, you can open up a Japanese language document on your
English computer, visit Arabic web sites, use an Input Method Editor to
type in Chinese text, and so on. While most people might not care about
that, it’s infinitely beneficial for developers to have that power at their
fingertips, because it enables you to do all of your international devel-
opment and most of your testing without jumping through hoops and
installing multiple OS’s.
When Windows 2000 makes its transition into the consumer OS market,
it will be a great day for worldwide software development.
-Tim
2000 News
9 out of 10 doctors say now would be a good time to prune the Unreal
tech page, and that sounds like a good idea to me. I’d like to start over
by talking about a bunch of things I’ve been meaning to cover, but never
found the time.
Q. I’m an aspiring game developer and I want to get into the business.
What’s the best way to be hired?
A. The single most important thing game companies will look for is past
experience: what cool stuff you have worked on previously. This might
sound like a Catch-22: ”You need experience to get a job, and you need
a job to get experience”. But nowadays, the mod communities around
leading games like Half-Life, Unreal Tournament, and Quake 3 Arena
are great proving grounds where aspiring game developers can work on
projects freely (mostly in their spare time), and build levels, mods, and
other game-play enhancements. In the past few years, the majority of
new talent Epic has hired have been people from the Unreal and Quake
103
Tim Sweeney Archive 104 News
communities:
While past work on cool projects is the number one criteria for most
game developers, having a University degree is a major advantage. While
this isn’t a must at Epic, most larger game developers place more em-
phasis on having a degree. Besides that, college is a great opportunity
to learn useful stuff. My degree is in Mechanical Engineering (University
of Maryland) – by the time I was in college, I had been programming for
about 10 years and didn’t feel getting a computer science degree would
be challenging. So, I chose engineering, and that turned out to be a major
challenge, and incredibly valuable.
The math I learned there, including vector calculus and finite element
analysis, which are directly applicable to 3D games, is something I never
would have studied independently. Self-taught programmers pick up al-
gorithms just by looking at other code and reading the occasional book
(that’s how I learned to program). But differential equations are just not
the kind of thing you’re likely to rediscover on your own, though un-
derstanding them brings clarity to lots of real-world problems you’ll en-
counter.
Q. What do I need to get started making mods for popular games?
A. Just a copy of the game, the editing and compiling tools, and access
to the web sites that contain information for mod authors. For http:
//www.unrealtournament.com/, you just need a copy of UT, which in-
cludes the editor (on CD#2) and all the http://unreal.epicgames.com/
unrealscript.htm code for the entire game; visit the Unreal community
web sites (listed at the top of this page) for tons of pointers to Unreal in-
formation. For http://www.idsoftware.com/, you need the retail game
and the utilities; visit http://www.planetquake.com/
to get started. For http://www.valvesoftware.com/, get the game and
see http://www.planethalflife.com/ for tips.
Q. I’m working on a project; do I need to license the Unreal Tournament
engine or sign any paperwork?
A. That depends on what you’re doing:
• If you are making a freely available mod, all you need is the retail
version of the game.
• If you are using the engine for non-commercial academic purposes,
all you need is the retail game. Lots of people have been using the
Unreal Tournament engine as part of university projects and theses.
• If you are a startup game developer and are prototyping a game in
the Unreal Tournament engine (using the tools available in the re-
tail version), you don’t need a license agreement while you’re proto-
typing the game. You do need a license agreement in place before
you advertise a game, sign a publishing agreement, or otherwise
profit from the game.
4.1.3 Also...
• The cool soon-to-be-public site http://www.linuxnewbie.com/ al-
ready has posted a http://www.linuxnewbie.org/nhf/intel/games/
unreal_tourney.html on how to get started with Unreal Tourna-
ment under Linux.
This site is a great idea; the biggest barrier to widespread Linux
adoption right now is the difficulty of getting started, and now in
standard decentralized Linux fashion, sites and resources are start-
ing to pop up to address this.
• http://www.chessmess.com/musqa-0100.htm on http://www.chessmess.
com/ (saw this on http://www.bluesnews.com).
-Tim
Now is an exciting time for mod development, as the best teams of enthu-
siasts are earning tremendous praise, opening up serious biz opportuni-
ties. This dynamic reminds me of the shareware game business around
1991 when Epic, Apogee/3D Realms and id Software were born. Back
then, we were just a handful of kids making games for our own enjoy-
ment, and releasing them online for others to enjoy – hoping that we
might be able to make some money to pay the bills.
Today all three companies are industry leaders.
Now, think about where today’s best mod authors will be in 9 years!
The advantage that enabled id, 3D Realms, and Epic to rise to the top
is something that today’s mod authors have too: we’re in the middle of
a thriving community, and that gives us an awesome feedback loop. If
we release something that sucks – whether it’s something big like Un-
real 1’s network code, or something subtle like weapon balancing – then
thousands of people will email us complaining until we fix it. Thousands
of smart people besides ourselves are expanding the game universe by
running web sites, making mods, building levels, and running servers,
and they let us know what they like and dislike. In this kind of pressure-
cooker environment, only good games and good ideas survive.
-Tim