Tim Sweeney Archive - News Archive
This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA
Overview
Download & View Tim Sweeney Archive - News Archive as PDF for free.
More details
- Words: 29,827
- Pages: 108
Tim Sweeney Archive - News
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
2.5 Oct 25, 1998 . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5.1
18
Geting closer... . . . . . . . . . . . . . . . . . . . . . .
18
2.6 Oct 26, 1998 . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
2.6.1
Direct3D Drivers . . . . . . . . . . . . . . . . . . . .
18
2.6.2
Known Issues . . . . . . . . . . . . . . . . . . . . . .
19
2.6.3
Unreal 218 Gaining Support . . . . . . . . . . . . . .
19
2.6.4
PlanetUnreal performance survey . . . . . . . . . .
20
2.6.5
More about 3D API’s . . . . . . . . . . . . . . . . . .
20
2.6.6
Unreal 218 Patch is ready! . . . . . . . . . . . . . . .
22
2.7 Oct 28, 1998 . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
2.7.1
Latest Happenings . . . . . . . . . . . . . . . . . . .
22
2.7.2
Status of Direct3d - All Drivers . . . . . . . . . . . . .
23
2.7.3
Riva TNT . . . . . . . . . . . . . . . . . . . . . . . . .
23
2.7.4
Riva 128 . . . . . . . . . . . . . . . . . . . . . . . . .
23
2.7.5
Intel i740 . . . . . . . . . . . . . . . . . . . . . . . . .
23
2.7.6
ATI Rage Pro . . . . . . . . . . . . . . . . . . . . . . .
23
2.7.7
3dfx Voodoo2 . . . . . . . . . . . . . . . . . . . . . .
24
2.7.8
S3 Savage 3D . . . . . . . . . . . . . . . . . . . . . . .
24
2.7.9
Matrox G200 . . . . . . . . . . . . . . . . . . . . . . .
24
2.7.10 Rendition
. . . . . . . . . . . . . . . . . . . . . . . .
24
2.7.11 Permedia . . . . . . . . . . . . . . . . . . . . . . . . .
24
2.7.12 Drivers we consider playable, in best-to-worst order
25
2.8 Oct 30, 1998 . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
2.8.1
Unreal 218 patch information (RTFM!) . . . . . . . . CONTENTS
25
Tim Sweeney Archive
3
News
2.8.2
Resources for Server Administrators . . . . . . . . .
26
2.8.3
Unreal Multiplayer Ramp-Up . . . . . . . . . . . . .
26
2.8.4
Other Servers . . . . . . . . . . . . . . . . . . . . . .
27
2.9 Nov 01, 1998 . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
2.9.1
Unreal Grows... . . . . . . . . . . . . . . . . . . . . .
27
2.10 Nov 02, 1998 . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
2.10.1 Unreal 219! . . . . . . . . . . . . . . . . . . . . . . . .
28
2.10.2 The testing is going well . . . . . . . . . . . . . . . .
28
2.10.3 Testing 219 . . . . . . . . . . . . . . . . . . . . . . . .
29
2.11 Nov 10, 1998 . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
2.11.1 Latest News . . . . . . . . . . . . . . . . . . . . . . .
29
2.11.2 The Roadmap . . . . . . . . . . . . . . . . . . . . . .
30
2.11.3 Server Administration . . . . . . . . . . . . . . . . .
31
2.12 Nov 19, 1998 . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
2.12.1 Unreal 220 Internet Improvements . . . . . . . . . .
31
2.12.2 Unreal Editor Progress . . . . . . . . . . . . . . . . .
32
2.12.3 Web Site Notes . . . . . . . . . . . . . . . . . . . . . .
33
2.12.4 Unreal mod notes . . . . . . . . . . . . . . . . . . . .
34
2.13 Dec 10, 1998 . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
2.13.1 No News . . . . . . . . . . . . . . . . . . . . . . . . .
34
2.14 Dec 11, 1998 . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
2.15 Dec 12, 1998 . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
2.16 Dec 14, 1998 . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
2.16.1 Hard at work . . . . . . . . . . . . . . . . . . . . . . .
36
CONTENTS
Tim Sweeney Archive
4
News
2.16.2 That’s UnrealEd.net . . . . . . . . . . . . . . . . . . .
37
2.17 Dec 15, 1998 . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
2.17.1 Unreal Networking Code: Status . . . . . . . . . . .
38
2.18 Dec 18, 1998 . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
2.18.1 Unreal Tournament notes for mod authors . . . . .
41
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 3.5.1
5
News
3dfx Voodoo3 Totally Rocks! . . . . . . . . . . . . . .
59
3.6 Apr 15, 1999 . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
3.6.1
Important Unreal 224 Note To Mod Authors . . . . .
60
3.6.2
Maps, Textures, Sounds, Music are backwards compatible . . . . . . . . . . . . . . . . . . . . . . . . . .
62
3.6.3
Latest News . . . . . . . . . . . . . . . . . . . . . . .
62
3.6.4
Cool Stuff . . . . . . . . . . . . . . . . . . . . . . . . .
63
3.7 Apr 19, 1999 . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
3.7.1
Getting closer... . . . . . . . . . . . . . . . . . . . . .
64
3.7.2
Network Cross-Compatibility . . . . . . . . . . . . .
64
3.8 May 01, 1999 . . . . . . . . . . . . . . . . . . . . . . . . . . .
65
3.8.1
224 Progress Continued . . . . . . . . . . . . . . . .
65
3.9 May 02, 1999 . . . . . . . . . . . . . . . . . . . . . . . . . . .
66
3.9.1
STAT NET: Diagnosing your connection to the server 66
3.9.2
Server Alert
. . . . . . . . . . . . . . . . . . . . . . .
68
3.9.3
Unreal 224v C++ headers released! . . . . . . . . . .
69
3.9.4
Unreal 224v Released to the public! . . . . . . . . . .
70
3.10 May 03, 1999 . . . . . . . . . . . . . . . . . . . . . . . . . . .
71
3.10.1 Known Bugs . . . . . . . . . . . . . . . . . . . . . . .
71
3.10.2 Future Patch . . . . . . . . . . . . . . . . . . . . . . .
71
3.10.3 Check out the Unreal news sites . . . . . . . . . . . .
72
3.10.4 OpenGL UnrealEd . . . . . . . . . . . . . . . . . . . .
72
3.11 May 05, 1999 . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
3.11.1 Maps that broke since 220 . . . . . . . . . . . . . . .
73
CONTENTS
Tim Sweeney Archive
6
News
3.11.2 Quick Notes . . . . . . . . . . . . . . . . . . . . . . .
73
3.12 May 08, 1999 . . . . . . . . . . . . . . . . . . . . . . . . . . .
74
3.12.1 Latest progress . . . . . . . . . . . . . . . . . . . . .
74
3.13 May 19, 1999 . . . . . . . . . . . . . . . . . . . . . . . . . . .
75
3.13.1 Unreal 225 musings . . . . . . . . . . . . . . . . . . .
75
3.13.2 ”Make Something Unreal” Contest . . . . . . . . . .
76
3.13.3 Things That Are Cool . . . . . . . . . . . . . . . . . .
76
3.14 May 29, 1999 . . . . . . . . . . . . . . . . . . . . . . . . . . .
77
3.14.1 For server administrators only: Unreal 225e Patch .
77
3.14.2 On engine licensing . . . . . . . . . . . . . . . . . . .
77
3.14.3 UnrealEd ”Runtime Error 20005” Experimental Fix .
78
3.15 May 31, 1999 . . . . . . . . . . . . . . . . . . . . . . . . . . .
79
3.15.1 Latest News . . . . . . . . . . . . . . . . . . . . . . .
79
3.15.2 Holiday? . . . . . . . . . . . . . . . . . . . . . . . . .
79
3.15.3 New 225f Patch for server administrators only . . . .
80
3.15.4 Server 225e Patch Feedback . . . . . . . . . . . . . .
80
3.15.5 UnrealEd Experimental Fix 2
. . . . . . . . . . . . .
80
3.16 Jun 01, 1999 . . . . . . . . . . . . . . . . . . . . . . . . . . .
81
3.16.1 UnrealEd Follow-Up . . . . . . . . . . . . . . . . . .
81
3.16.2 Server Cheats? . . . . . . . . . . . . . . . . . . . . . .
81
3.16.3 UnrealEd for 3dfx Voodoo3 bundle owners . . . . .
82
3.17 Jun 06, 1999 . . . . . . . . . . . . . . . . . . . . . . . . . . .
82
3.17.1 Direct3D Improvements . . . . . . . . . . . . . . . .
82
3.18 Jun 19, 1999 . . . . . . . . . . . . . . . . . . . . . . . . . . .
83
CONTENTS
Tim Sweeney Archive
7
News
3.18.1 Unreal Direct3D . . . . . . . . . . . . . . . . . . . . .
83
3.18.2 Summary of things I learned about Direct3D . . . .
84
3.19 Jun 30, 1999 . . . . . . . . . . . . . . . . . . . . . . . . . . .
85
3.19.1 Direct3D Is Happening . . . . . . . . . . . . . . . . .
85
3.20 Jul 01, 1999 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
86
3.20.1 226 Progress . . . . . . . . . . . . . . . . . . . . . . .
86
3.20.2 Recommended Reading . . . . . . . . . . . . . . . .
87
3.21 Jul 03, 1999 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
87
3.21.1 On Our World Domination Plans . . . . . . . . . . .
87
3.21.2 What’s really happening here? . . . . . . . . . . . . .
88
3.21.3 The Economics . . . . . . . . . . . . . . . . . . . . .
89
3.21.4 The Result: General-Purpose Solutions Win . . . . .
90
3.21.5 Where we go from here . . . . . . . . . . . . . . . . .
91
3.22 Jul 10, 1999 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
92
3.22.1 The AMD Athlon Rocks! . . . . . . . . . . . . . . . .
92
3.23 Jul 12, 1999 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
93
3.23.1 New Downloads & Links Pages . . . . . . . . . . . .
93
3.24 Aug 14, 1999 . . . . . . . . . . . . . . . . . . . . . . . . . . .
94
3.24.1 DirectX7 . . . . . . . . . . . . . . . . . . . . . . . . .
94
3.25 Aug 16, 1999 . . . . . . . . . . . . . . . . . . . . . . . . . . .
94
3.25.1 Unreal Tournament development note . . . . . . . .
94
3.26 Sep 14, 1999 . . . . . . . . . . . . . . . . . . . . . . . . . . .
95
3.26.1 Unreal Tournament demo schedule . . . . . . . . .
95
3.26.2 DirectX7 . . . . . . . . . . . . . . . . . . . . . . . . .
95
CONTENTS
Tim Sweeney Archive
8
News
3.27 Sep 22, 1999 . . . . . . . . . . . . . . . . . . . . . . . . . . .
96
3.27.1 DirectX7 . . . . . . . . . . . . . . . . . . . . . . . . .
96
3.27.2 What about OpenGL? . . . . . . . . . . . . . . . . . .
97
3.27.3 Experiencing poor Internet play on your Voodoo3 3500TV? . . . . . . . . . . . . . . . . . . . . . . . . .
99
3.28 Sep 29, 1999 . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 3.28.1 More Hardware Troubleshooting . . . . . . . . . . . 100 3.28.2 Direct3D Anomalies . . . . . . . . . . . . . . . . . . 101 3.28.3 Athlon In The House . . . . . . . . . . . . . . . . . . 102 3.29 Oct 01, 1999 . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 3.29.1 TNT Users, Try This! . . . . . . . . . . . . . . . . . . 102 3.29.2 Latest Findings . . . . . . . . . . . . . . . . . . . . . 103 3.29.3 Links . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 3.30 Oct 02, 1999 . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 3.30.1 Unreal Tournament players overtake QuakeWorld at #5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 3.31 Oct 06, 1999 . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 3.31.1 Windows 2000 RC2 Rocks! . . . . . . . . . . . . . . . 105 3.31.2 Windows 2000 Internationalization . . . . . . . . . . 106 4 2000 News
108
4.1 Feb 22, 2000 . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 4.1.1
Common Questions I’m Asked . . . . . . . . . . . . 108
4.1.2
Programming Languages . . . . . . . . . . . . . . . . 110
4.1.3
Also... . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
CONTENTS
Tim Sweeney Archive
9
News
4.2 Feb 28, 2000 . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
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 posting in early 2000.
10
Chapter 2 1998 News 2.1 2.1.1
Oct 13, 1998 Unreal Cheat-Finding Challenge
I’ve seen two reports that people have found a way to cheat in Internet play. One person reported seeing a little tiny 1-inch tall player walking around named ”LilTinyChessPiece”, and another reported a player who never took damage. I’ve been scouring the code, and haven’t found any holes which would enable this kind of cheating, but I’d love to hear if anybody has found a way. If you find a way for players to cheat or crash servers over the Internet in Unreal, please email mailto:[email protected]. The first person to report a particular security hole in Unreal will receive credit and thanks here for helping to protect the Unreal community from cheaters. People who cheat in Deathmatch are lamers, but people who are motivated by simply discovering ways to cheat are doing valuable research. Note: I don’t consider the following things Unreal cheats: • Server administrators cheating on their own server. Since the admin is in control of the server, there are many ways he could dis11
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 spoofing, and so on. These aren’t Unreal-specific cheats, and I can’t stop them.
2.1.2
UnrealScript Notes
There was recently a ”to script or not to script” debate about the merits of UnrealScript vs pure C/C++. In this debate, several misconceptions were put forth, which I want to correct: 1. UnrealScript replicated functions (described in the http://unreal. epicgames.com/Network.htm) indeed return instantly, rather than blocking execution while waiting for network acknowledgement. Function calls are sent across the network using an asynchronous RPC-like approach, and are executed upon reception. They can either be sent wih guaranteed delivery and sequencing (by using the ”reliable” keyword), or without sequencing (using ”unrelible”). Unreliable replicated functions are most efficient, and should be used for non-vital events like hearing sounds. If one were to assume UnrealScript functions were synchronous and blocking, one would indeed draw incorrect conclusions such as this statement: ”That must make AIs in multiplayer games really fun, they fire at you and do an RPC, then freeze until they get a ping back from the client.” 2. As our licensees know, UnrealScript classes and C++ classes fully interoperate. You can derive C++ classes from UnrealScript classes, and vice-versa. For all actor classes, running ”Unreal.exe -make” automatically parses the UnrealScript classes, and generates C++ stubs for them, including:
2.1. OCT 13, 1998
Tim Sweeney Archive
13
News
• C++ variable declarations mirroring the UnrealScript ones, allowing variables to be accessed identically in either language. • C++ -> UnrealScript calling stubs, enabling C++ functions to call into UnrealScript functions. • UnrealScript -> C++ calling stubs, enabling UnrealScript functions to call into C++. Indeed, we invested a lot of effort into providing dual programming interfaces, enabling seamless sharing of objects and code between the two languages. Among other things, I studied COM, MFC/VB/ActiveX, CORBA/IDL, and JNI in order to determine the most efficient and least error-prone methods of cross-language programming. There is a lot of great research material on the net, for those who are interested. I suspect that people who have a low opinion of mixed-language programming have likely drawn their conclusions from JNI and CORBA/IDL which do indeed involve a lot of messy handle/id references and error-prone redundent declaration of objects. It doesn’t have to be this way. For an example of ”cross-language programming done right”, check out the ActiveX support in Microsoft Visual J++ and Visual Basic – they’re ultra-clean, automatic, and they involve no redundency. MFC also does a pretty good nearly-automatic job of cross-language ActiveX object handling. Mixed-language programming can be very fruitful, if it’s implemented properly. 3. Unreal performs all file loading and saving using serialization. Serialization is automatic for objects defined in UnrealScript. For objects and structures defined only in C++, such as the following function that serializes a vector. friend FArchive& FVector::operator<<( FArchive& Ar, FVector& V ) { return Ar << V.X << V.Y << V.Z; }
For programmers just learning about object-orientation, a mustread is: http://www.amazon.com/exec/obidos/ASIN/0201633612/o/
2.1. OCT 13, 1998
Tim Sweeney Archive
14
News
qid=908310340/sr=2-1/002-5033601-8164246 (Addison-Wesley Professional Computing) by http://www.amazon.com/exec/obidos/Author= Gamma,%20Erich/002-5033601-8164246, http://www.amazon.com/exec/ obidos/Author=Helm,%20Richard/002-5033601-8164246,
2.2 2.2.1
Oct 14, 1998 Network Objects Follow-Up
I’ve chatted with several people lately who have added insight to the discussion of multi-language programming and networking. One interesting topic mentioned was using the CORBA protocol to coordinate network games. CORBA is a high-reliability protocol with a fairly high amount of overhead and latency, due to its exacting nature and use of TCP. I see CORBA as a very suitable protocol for network game backbones. For example, if you were doing an Ultima Online style world with multiple servers that stay in synch, CORBA would be good for linking servers together in a high-reliability, non performance-critical way. But, CORBA isn’t suited for an actual realtime modem-based gameplay protocol, since it’s TCP based (which adds terrible lag under lossy conditions), and the protocol has enough overhead that it’s not going to be able to handle large amounts of data over the modem.
2.2.2
AWT
http://unrealscript.net/AWT/ is a graphical user-interface layer for UnrealScript, which has been making some cool progress lately.
2.2.3
Cheat Challenge Update
I’ve received a bunch of tips from two Unreal enthusiasts. Congratulations go to Mek @ PlanetUnreal and RisingSun for discovering and verifying two holes in Unreal, and to Mike Lambert for suggesting a potential 2.2. OCT 14, 1998
Tim Sweeney Archive
15
News
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.
2.2.4
Another Public Master Server
This just in: How about a mention of the OGN Public Unreal Master Server? It’s been available for almost two weeks and has no access restrictions, bandwidth or otherwise. The server is running @ master.ogn.org:27500. Server lists can be retrieved @ http: // master. ogn. org: 6669/ list/ game/ unreal . A page describing how to link to it can be found @ http: // www. ogn. org/ UnrealMaster – sky G. http: // www. qhunter. com/ http: // www. golightly. org/ http: // www. aurorablue. org/
2.3
Oct 22, 1998
2.3.1
Linux Unreal
http://www.linuxgames.com/ has reported a way to run the existing version of Unreal under Linux, using the Wine Windows emulator for Linux. They’ve included a screenshot and more information at this http://www. sgic.fi/~tj/unreal.html page.
2.3. OCT 22, 1998
Tim Sweeney Archive
2.3.2
16
News
Hired Guns
Want to see something cool and unique that’s being done with the Unreal 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 preview).
2.4 2.4.1
Oct 24, 1998 Almost there...
The latest Direct3D support is now integrated into the Unreal codebase. It will be in the upcoming 218 patch in ”public beta” form. It hasn’t gone through wide testing yet, but we and our partners have been testing it a lot internally on Windows 95 and 98. It’s looking good on the nextgeneration 3D cards (Riva TNT, Matrox G200, Savage 3D), though highlevel optimizations are planned that will boost performance further. The Voodoo2 multitexture code is in, thanks to the efforts of Jack Mathews at 3dfx. I’m doing some final Internet play testing and tweaking on the patch. My ”torture test” environment is an ISP connection at 24.4K with 400 msec ping. If it’s playable on that, it should be playable on anything. :) Yesterday’s testing revealed a few last-minute problems that I’m working on now.
2.4.2
More discussion on CORBA
mailto:[email protected] provided this insight into CORBA with respect to realtime apps: 2.4. OCT 24, 1998
Tim Sweeney Archive
17
News
In general, CORBA causes too much overhead and latency to be a server/clients gaming protocol. This is due to IIOP’s (the default inter-ORB protocol) use of TCP/IP, and the use of large packet sizes (compared to the dedicated bit-tuned gaming protocols being used in, for example, Quake2 and Unreal). Though support for IIOP is mandatory, an ORB vendor can deploy more efficient (or more secure) protocols between ’his’ ORBs, optionally using other network protocols. By default, CORBA calls are synchronous (that is, the calling object is blocked until a response is received from the called object). Such a connectionoriented call is best implemented using TCP. CORBA also supports so-called ’one-way’ operations, that enable the caller to continue processing immediately after making the call - the call is non-blocking. Here, it might make sense to use UDP as an underlying protocol, provided you deal with the unreliability at the application level (the ’call’ might not arrive at the client). Some specialized high-performance ORBs, such as Nortel’s RCP-ORB, < http://www.nortel.com/RCP-ORB/> , use other transport protocols than TCP for one-way calls. Most ORBs implement optimized mechanisms for ’intra-server’ and ’intra-process’ communication (not that relevant for multi-player gaming). I’ll post more thoughts on the topic in the future. With Unreal, distributed object models are already playing a role in multiplayer gaming, but only in a ”tip of the iceberg” sort of way. This kind of technology will expand very interestingly in the future.
2.5 2.5.1
Oct 25, 1998 Geting closer...
We’re gearing up for a big internal test session with 218 right now. The release date of the 218 patch will depend on the outcome. Note that 218
2.5. OCT 25, 1998
Tim Sweeney Archive
18
News
is not network-compatible with 217, so if you see our 2 test servers in GameSpy, please don’t try to join (you won’t be able to).
2.6 2.6.1
Oct 26, 1998 Direct3D Drivers
To use Unreal’s Direct3D support, you must have http://www.microsoft. com/directx/download.asp installed. You also need the latest Direct3D driver from your 3D hardware maker. Because Unreal uses many new Direct3D features, many hardware makers had to update their drivers for Unreal to work. Therefore, some of the drivers distributed with DirectX 6.0 have problems with Unreal (crashes or visual anomalies). Here are driver download sites for various brands: • http://www.3dlabs.com/drivers/ Permedia • http://www.3dfx.com/developers/drivers.html Voodoo, Voodoo Rush, Voodoo2, Voodoo Banshee • 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.nVidia.com/home.html Riva 128 (known problems), Riva TNT • http://www.rendition.com/download.html Verite • http://www.s3.com/bbs/0main/topindex.htm Savage 3D • http://www.trid.com/trident/html/DRIVERS.HTM (untested, probably doesn’t work) • http://www.nine.com/support/drivers/index.html (untested, probably doesn’t work) 2.6. OCT 26, 1998
Tim Sweeney Archive
19
News
Please keep in mind that Unreal’s Direct3D support is an early beta and isn’t yet working reliably on all 3D hardware.
2.6.2
Known Issues
I’ve update the list of http://unreal.epicgames.com/Bugs.htm, summarizing the problems people have found with 219. There are a bunch of items, but most are non-showstoppers. I’m working on them now. Overall, though, 218 is by far the best-received version of Unreal to date! New servers are popping up rapidly (50% increase in the past 18 hours), with player counts rising even faster.
2.6.3
Unreal 218 Gaining Support
After releasing the patch at midnight Sunday night, it was amazing to see how many Unreal servers had it up and running in less than an hour minutes. It will be interesting to watch new Unreal servers spring up on the net now that our Internet play quality is under control. In the not-too-distant future, we’ll have many more improvements in Unreal network play: performance enhancements, new features requested by the community, and several cool upcoming surprises. GameSpy currently shows 27 Unreal servers, and a couple thousand for Quake. Clearly, we got off to a very slow start while we learned the the ins-and-outs of Internet game programming; now Unreal is on a solid footing and we’re really beginning to pick up the pace! Level designers in the Unreal community have already started producing some great Deathmatch maps (see http://www.freshmeat.org/unreal/ for downloads), so we expect to see things accelerate in this area, too.
2.6. OCT 26, 1998
Tim Sweeney Archive
2.6.4
20
News
PlanetUnreal performance survey
If you’re using the new 218 patch, please fill out http://www.planetunreal. com/ Unreal performance survey. We’ll be watching Unreal players’ feedback in the survey, and looking at all the 218 bug reports sent to the mailto:[email protected] account. Everyone’s feedback will be taken into account for future improvements to the Internet play and other features.
2.6.5
More about 3D API’s
In an interview on http://www.voodooextreme.com, I gave my opinion in the ongoing OpenGL vs Direct3D debate, and I wanted to add some more information here. First of all, both our DreamForge partners working on the OpenGL support, and our Direct3D partner have both done a very high-quality job, given the constraints of Unreal and the 3D card drivers available. My feelings on the two 3D standards are based completely on their API’s and the quality of drivers available. Next, I wanted to give some more detail on the code. API support layer 3dfx Glide Direct3D NEC PowerVR OpenGL
Lines of C++ code 1711 3123 4049 5697
Now, the Glide is the simplest, because it’s aimed at the Voodoo family of 3D cards, which are very standard and straightforward to support. For programming to 3dfx cards, Glide is the ideal API. For people thinking ”If Glide is so great, why don’t other 3D cards support it?” The short answer is, if Glide supported other manufacturer’s 3D cards, it would pick up all the complications involved in real-world Direct3D and OpenGL programming: Testing for core capabilities, working around driver bugs, etc. 2.6. OCT 26, 1998
Tim Sweeney Archive
21
News
The Direct3D code is next in simplicity. It began as a working 1600 line driver, then expanded as it was optimized and support was added for 3D cards that lack key features. The Direct3D API follows the traditional Microsoft model of being not very beautiful code, but dealing with realworld hardware robustly, by providing a capability-querying mechanism and well-tested drivers. The PowerVR code is large because the PCX2 chip’s rendering approach is very different than what Unreal was designed for. This makes the implementation fairly complex, though the next-generation PowerVR, currently on-hold in the PC market while NEC focuses on the Sega DreamCast, is a great chip that’s more traditional in its architecture, and more optimal for Unreal. The OpenGL code is large because of optimizations and support for lots of real-world hardware. If reduced to plain-vanilla OpenGL, this would probably be the simplest and most stable driver of them all, because the OpenGL API is very straightforward.
2.6.6
Unreal 218 Patch is ready!
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 overseas modem players) reported major success with the performance improvements. 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.
2.6. OCT 26, 1998
Tim Sweeney Archive
2.7 2.7.1
22
News
Oct 28, 1998 Latest Happenings
Since the Unreal 218 patch was released, the number of Unreal servers showing up in GameSpy has increased by 225%. A huge thanks to everyone who is running Unreal servers now. It’s awesome to see the community grow and begin to reach critical mass. At any time, about 20% of the servers listed in GameSpy are shown as ”Not Responding”. I’ve been looking into this, and there are three reasons for this. One, the server has been shut down or crashed but hasn’t timed out and been removed from the list. Two, the server is switching levels, which prevents it from responding to GameSpy queries for 5-20 seconds. Third, the server is shown in GameSpy because a user running a LAN server (dedicated or non-dedicated) enabled the ”DoUplink” option to publicise their server to the world without realizing the consequences, but either exited or is on a LAN blocked off by a firewall. We’ll work with the GameSpy guys to adjust the timeouts so that fewer ”Not Responding” servers are listed.
2.7.2
Status of Direct3d - All Drivers
Some issues across-the-board with switching between fullscreen and windowed mode, and switching resolutions during gameplay. We’re looking into theses issues.
2.7.3
Riva TNT
Has lots of potential, but there are major problems with their Direct3D driver: rainbow colors, time-lag, w-buffering issues, missing textures. We are hoping nVidia will issue an updated driver soon. The ball is in their court now. 2.7. OCT 28, 1998
Tim Sweeney Archive
2.7.4
23
News
Riva 128
Their latest driver should run Unreal OK. The framerate isn’t very good, and there will be a lot of ”stuttering” since texture downloads are very slow on this hardware. Some users are reporting that creature polygons appear corrupted. Hopefully nVidia will fix thie error in their driver.
2.7.5
Intel i740
There are some problems with their currently-available Direct3D driver, but they have an internal beta driver which fixes many problems. Hopefully this will be ready for the public soon.
2.7.6
ATI Rage Pro
They have a beta Direct3D driver which runs Unreal pretty well (though it doesn’t appear to be available for public release yet). Multitexturing currently isn’t working with Unreal, because of a hardware limitation (it can’t multitexture a paletted base texture map along with a non-paletted light map).
2.7.7
3dfx Voodoo2
There isn’t any reason to use Direct3D for Voodoo2, since we support Glide natively and that tends to be more stable and faster, but their latest Direct3D driver does run Unreal pretty well. Their detail texture blending (D3DBLEND DIFFUSEALPHA) doesn’t work, which breaks detail textures. There are reports of missing lightmaps in some areas (not sure what’s wrong). 3dfx could get a performance increase here by implementing subrect Blts and hardware triangle-fan setup.
2.7. OCT 28, 1998
Tim Sweeney Archive
2.7.8
24
News
S3 Savage 3D
Works well with their internal beta Direct3D driver. Not sure when this will be available via the web.
2.7.9
Matrox G200
Works pretty well.
2.7.10
Rendition
Works pretty well.
2.7.11
Permedia
Only supports monochrome lighting due to blending limitations. Explosions are displayed with a black background (due to a bug in the current Unreal code). Fairly slow texture downloading – performance isn’t great.
2.7.12
Drivers we consider playable, in best-to-worst order
• Voodoo2: Fastest of all. • Savage/G200: Reasonable performance. Not as fast a fill rate as Voodoo2, but texture downloads are fast, and they support palettes, making for a steady frame rate. • Rage Pro/Rendition: Reasonable performance. High display quality in truecolor mode. The others should be playable pending public release of improved Direct3D drivers for their hardware. 2.7. OCT 28, 1998
Tim Sweeney Archive
25
News
On Permedia, Riva 128, and Rendition, you may get better performance using Unreal’s software renderer, especially if you have a Pentium II class processor. This isn’t such a bad thing, because the software renderer supports all of Unreal’s key features, including truecolor lighting and volumetric fog.
2.8 2.8.1
Oct 30, 1998 Unreal 218 patch information (RTFM!)
If you downloaded the 218 patch, please http://unreal.epicgames.com/ versions.htm. If you’re still experiencing problems with Unreal on your modem connection, you need to use the NETSPEED command described there, so that Unreal doesn’t try to use more bandwidth than you have available.
2.8.2
Resources for Server Administrators
Here are some resources to aid new Unreal server administrators in getting up and running: • http://unreal.epicgames.com/Master.htm: How to get listed in GameSpy and other querying tools (new). • http://unreal.epicgames.com/ServerTips.htm: Basic information about running an Unreal server. • http://megaboard.epicgames.com/: New ”Server Administration” forum. Steve Polge, Brandon Reinhart, and I will be answering questions from server administrators and people writing server-querying tools.
2.8. OCT 30, 1998
Tim Sweeney Archive
2.8.3
26
News
Unreal Multiplayer Ramp-Up
A lot of news sites have been picking up on Unreal’s multiplayer improvements: • http://www.next-generation.com/ • http://www.bluesnews.com/ • http://www.voodooextreme.com/ The number of public Unreal servers listed in GameSpy is now up to 51 as I write this, and has been growing at a rate of over 20% daily. While working on the upcoming 219 patch, I’ve been spending a couple hours each day playing Unreal online, especially on the servers running usercreated levels. The community has made some really impressive levels, and I’m glad to see that a lot of servers are now making use of downloadable levels, textures, sounds, and music.
2.8.4
Other Servers
In addition to the public servers listed in GameSpy, there are 14 extremely high quality, public servers on http://www.won.net/unreal listed in their own web-based ”server finder” site. I should also mention our other online partner, http://www.mplayer. com/action/games/unreal/, and the http://www.mplayer.com/action/unreal/ news site on MPlayer. -Tim
2.8. OCT 30, 1998
Tim Sweeney Archive
2.9 2.9.1
27
News
Nov 01, 1998 Unreal Grows...
More public servers keep popping up every day. Awesome! I noticed that the percentage of servers shown as ”not responding” has gone up, though I’m not sure whether that’s due to server crashes, or people accidentally having their LAN server listed in GameSpy when it’s not meant to be public. Server admins, if your server crashes unexpectedly, please email your Unreal.log file to mailto:[email protected] so we can investigate it. A reminder, server administrators can get help in the new ”Server Administration” forum on the http://megaboard.epicgames.com/. According to the feedback we receive, and in http://www.planetunreal. com/’s survey, 218 has fixed the past network problems and made Unreal playable on the Internet for the large majority of people. Still, we have lots of improvements in the works, which will further increase the game’s smoothness and responsiveness during network play, as well as a few new features that I’m not allowed to announce yet. :) The next patch, 219, will be purely bug fixes to 218 (no speed difference). After that, 220 will contain some more high-level improvements to many areas of the network code. Currently, there seem to be two sets of people who are still having some problems with Unreal on the Internet. One set has 28.8K-33.6K modem connections that experience an unusally high amount of packet loss. 220 should improve this a bit, but when you have upwards of 20% packet loss, gameplay is bound to suffer. The other set of problems is being reported by people with some unusual connections we haven’t been able to test on internally: people with dual simultaneous modem connections, people with connections that receive via satellite and send via modem, and some similar configurations. I haven’t determined what’s going wrong in these cases yet, but I suspect packet-order problems.
2.9. NOV 01, 1998
Tim Sweeney Archive
28
2.10
Nov 02, 1998
2.10.1
Unreal 219!
News
It’s now available for download http://unreal.epicgames.com/Versions. htm. The Epic Deathmatch servers will be shut down for the night, to provide more bandwidth for downloads.
2.10.2
The testing is going well
Ok, ok, you can stop now, that’s enough testers. :) Server performance has definitely improved since I last benchmarked it. My dual-processor Pentium II-300 is serving a 20-player game, copying 600 megs across the network, and running a 3dfx Unreal client at 800x600. The server is keeping up a steady 15 fps. I have more optimizations planned, though. On my 28.8K connection, gameplay has remained pretty smooth until I get into a firefight with 5-6 people, at which point the movement of other players starts to become unsmooth. We should be able to improve this significantly further in 220, with two protocol improvements. First, I’ll be improving the scheme for managing temporary objects like projectiles, which should reduce their bandwidth usage by around 30%. Second, Steve Polge and I working out a new variable priority predictor/corrector scheme for transmitting the movement of other players.
2.10.3
Testing 219
I have an Unreal 219 server up and running at unreal://208.212.53.3/ in case a few people want to help test. You can join in and play with 218; it’s fully compatible. 219 should be available soon, unless new bugs are discovered.
2.10. NOV 02, 1998
Tim Sweeney Archive
29
2.11
Nov 10, 1998
2.11.1
Latest News
News
The latest http://www.planetunreal.com/ survey shows a significant gain in gamers’ satisfaction with the latest 219 patch, compared to the previous ones. We’re now hammering on version 220, which includes significant new Internet play improvements, plus some core game improvements that the rest of the team has been working on. 220 won’t be out this week, but should be ready soon after. There seems to be one Internet problem in 219 that is affecting 10-15% of players. I haven’t figured out the cause yet, but the symptom is a ping time (visible with STAT NET) that swings around wildly, going from 200 to 1000 or more over the course of several seconds. Many of these players report that other games like Quake 2 don’t exhibit the problem–which indicates it’s not just a bad connection or ISP. I suspect packet-ordering problems, though I haven’t been able to duplicate it here.
2.11.2
The Roadmap
In the remainder of 1998, we will be releasing: • Unreal 219: Latest version. Download http://unreal.epicgames. com/Versions.htm. • Unreal 220: Further Internet improvements, core game improvements, bug fixes. • Unreal 221: Incremental fixes • Unreal 222: Offical (non-beta) patch; shareware version will be released. • Additional patches as necessary.
2.11. NOV 10, 1998
Tim Sweeney Archive
30
News
We also have some cool things in the works for 1999. Since Unreal first shipped, I’ve been working on Internet improvements and bug fixes, while the rest of the team has been working on a top-secret project we are referring to as ”Unreal Tournament”. There have been a lot of rumors and speculation about what this project will be. Some of the rumors are completely incorrect. For example, we are not using any alien technology recovered from crashed spaceships on Tournament. (We’re saving that for our next project). I’m also working on the new, enhanced UnrealEd, with lots of new features, improved stability, a plug-in interface, and other goodies. We don’t have a date for this, but I’m expecting a public beta around new years, with final release early in 1999. At some point, we’ll be publically releasing Unreal’s C++ interface so the community can start on .dll plug-ins for Unreal and UnrealEd. This will happen no later than the new UnrealEd public beta. It might be possible to release it sooner, however there are changes in the works which won’t be binary compatible, so user-created .dll’s would break and need to be recompiled. What can you do with Unreal .dll’s? Lots. Here are some examples: • Define new kinds of algorithmic textures that can be created in UnrealEd and used in levels. • Expose anything you can do in C++ to UnrealScript, for example the file system, ActiveX, more Internet functionality, etc. • Write performance-critical game support routines, such as AI. While it’s also possible to write game code directly in C++, the preferable way to do that is UnrealScript, since there is already a lot of game support infrastructure built into the language.
2.11. NOV 10, 1998
Tim Sweeney Archive
2.11.3
31
News
Server Administration
Remote server administration isn’t working in 219, but will be addressed shortly. 219 does have a few new features for local server administration. While running a server, click on the Unreal server icon and choose ”Show log window”. In the log, you can type: • SERVERTRAVEL < levelname> : Jump to a new server. • SAY < message> : Broadcast a message to all users. -Tim Sweeney
2.12
Nov 19, 1998
2.12.1
Unreal 220 Internet Improvements
I’m now down in Raleigh, North Carolina with the rest of the Unreal team. Things are really coming together for the top-secret project we’re working on, and Unreal 220 is starting to solidify. We don’t have a release date yet, but it could be as early as next week. The Internet play improvements in 220 are quite noticeable. Steve and I are using a new physics prediction scheme based on motion compensation. This improves the smoothness of other players’ movement in deathmatch games, especially in large, open levels like DmDeck16, where lots of players are visible. Steve has redesigned the moving brush code so that moving brushes now are now handled client-side. Platforms and doors are very smooth now. Finally, I’ve created a new scheme for managing temporary actors like projectiles, which reduces their bandwidth by about 30%. Steve and Brandon have also added a lot of other improvements, such as showing ping times, server name, and level name in the player list, showing the name of opponents when you point the crosshair at them in 2.12. NOV 19, 1998
Tim Sweeney Archive
32
News
a network game, a beep when chat messages come in, and color coding of messages.
2.12.2
Unreal Editor Progress
I’ve also been working on the new Unreal Editor, featuring a user-interface rewrite (moving over to C++ from Visual Basic). It’s now more than halfway 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.
2.12. NOV 19, 1998
Tim Sweeney Archive
2.12.3
33
News
Web Site Notes
A request of web sites providing collections of Unreal related files, such as the cool http://www.freshmeat.org/unreal/ page: Please link to the official http://unreal.epicgames.com/Versions.htm 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 http://unreal.epicgames.com/Versions.htm page, users are more likely to get the latest patch. Thanks! Cool Unreal related things I’ve seen recently... • http://unrealnation.com/unloaded/, a great ”overhead view” mod including some custom levels. It feels a lot like the classic arcade game Gauntlet. • http://www.astro.uni-bonn.de/~cloewe/unreal/, a totally cool stats tool for server administrators. • http://www.unrealed.com/ has grown to contain more and more useful UnrealEd resources.
2.12.4
Unreal mod notes
Mod developers who get the cryptic ”sandbox” error when trying their mods in network play: This error means you have a .upkg file that says server-side-only because you copied the one from IpDrv.u (which is SUPPOSED to be server-side-only). This usually prevents the mod from working, but sometimes just causes actors defined in the mod to not be visible to players. If you don’t have a .upkg problem, you won’t have a problem. If you do have a .upkg file, it should read: [Flags] AllowDownload=False ClientOptional=False ServerSideOnly=False
2.12. NOV 19, 1998
Tim Sweeney Archive
34
News
-Tim Sweeney
2.13
Dec 10, 1998
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.
2.14
Dec 11, 1998
Here is the http://unreal.epicgames.com/ReadMe220.htm 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.
2.15
Dec 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:
2.13. DEC 10, 1998
Tim Sweeney Archive
35
News
• ”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
2.15. DEC 12, 1998
Tim Sweeney Archive
36
2.16
Dec 14, 1998
2.16.1
Hard at work
News
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 networkrelated 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 backwardscompatible. 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 2.16. DEC 14, 1998
Tim Sweeney Archive
37
News
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.
2.16.2
That’s UnrealEd.net
The cool independent Unreal editing site I mentioned is actually http: //www.unrealed.net/, not UnrealEd.com.
2.17
Dec 15, 1998
2.17.1
Unreal Networking Code: Status
Unreal 220 incorporates the majority of the low-level bandwidth optimizations I’ve been planning for Unreal 1 and Unreal Tournament. I was just looking back at the initial shipping version of Unreal and comparing packets, and realized that we’ve achieved a bandwidth usage improvement of over 250% in both directions. This doesn’t mean we’re going to stop now...there are some minor protocol improvements planned, and also high-level game play optimizations that Steve and Brandon are working on, moving more logic to the clientside 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 http://unreal.epicgames. com/Network.htm, it was simultaneously praised for being a powerful and very general framework, and flamed because Unreal’s initial Internet play 2.17. DEC 15, 1998
Tim Sweeney Archive
38
News
performance was below gamers’ expectations. The critics were delighted to claim, ”this networking engine is a Grand Scheme that will never perform well in the real world”. They sure were wrong! Iit turned out that all the performance bottlenecks were in the low-level protocol, and were all completely fixable given sufficient R&D time. It took a lot of hard work to identify all of the inefficiencies in the protocol and come up with solid, general solutions. The key problems in game networking are data compression, error correction, and latency reduction. They turn out to be mutually opposing: • Standard data compression schemes (i.e. Huffman and arithmetic coding) work best when you have a large, well-known compression window, and large symbol tables. Sending symbol tables isn’t practical when you have a low-bandwidth, high-latency connection, and when your window history is questionable due to transmission errors. • Error correction schemes are tough to implement when you have low-bandwidth, high packet loss conditions (for example., most gamers’ modem-based Internet connections!) I went through 6 separate error correction schemes in Unreal, 5 of which all fell apart in various conditions. One big trap is getting into a feedback loop that saps away bandwidth and increases ping times. Another trap is retransmitting time-sensitive data when it gets lost, causing lag. These issues are tricky in bandwidth-intensive action games, because you need to support multiple tiers of reliability in packets, and some level of sequencing between them. • Latency reduction is another tricky issue, because of the way modems queue data: The larger a packet is sent, the more latency is induced in the buffering scheme. So, you want to send small packets to keep latency down. But, UDP packets have significant built-in overhead, so you want to send large packets to keep bandwidth up. In the end, I opted to go with several a custom bit-encoding compression scheme, which adapts itself to the type of data being sent, and intelligently crams it into the least amount of bits possible. This has worked 2.17. DEC 15, 1998
Tim Sweeney Archive
39
News
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 packetloss 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 http://unreal.epicgames.com/Network. htm document. Unreal 1 networking can be described simply as ”a small 2.17. DEC 15, 1998
Tim Sweeney Archive
40
News
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 nextgeneration engine, I’m going to experiment with a lot of new networking configurations. For example, the protocol could be used for a server-toserver 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
2.18
Dec 18, 1998
2.18.1
Unreal Tournament notes for mod authors
I’ve had several inquiries from mod makers about how hard it will be to ”port maps and mods from Unreal 1 to Unreal Tournament”. The answer is, port? What’s this talk of porting? This stuff just works. Steve Polge put a lot of effort into updating the Unreal 220+ game code so that it integrates seamlessly with Unreal Tournament. Both products install into the \Unreal directory, and are mutually compatible. So, you can install one, the other, or both – and existing maps and mods which are compatible with the latest version of Unreal, will be fully compatible. For convenience, Unreal Tournament ships with all of the script packages from Unreal 1 (including UnrealShare.u and UnrealI.u), all of the .utx files, and all of the .uax files. Unreal Tournament is a superset of the Unreal 1 with the exception of the Unreal 1 maps and music. All new UT content (lots of scripts, textures, sounds, game types, and new actors) are 2.18. DEC 18, 1998
Tim Sweeney Archive
41
News
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
2.18. DEC 18, 1998
Chapter 3 1999 News 3.1 3.1.1
Jan 01, 1999 Happy New Year
The team is now getting back together from the holiday and we’ll get back to Unreal 221 development first thing tomorrow (Saturday). We were on the verge of releasing the patch right before Christmas, but we’re now back to being a few days away, since I added some new features that need re-testing, and some additional bugs have been found. For me, the holidays were fun and productive. I hauled my computer up to Maryland for a one-week visit with my parents, and that provided a good excuse to work on engine improvements and new R&D in a zerodistractions environment. Without getting to deep into the details, here are some of the things I worked on: • Unicode Unreal. I finished up 16-bit Unicode support; now the Unreal code base can be recompiled for the ANSI (8-bit) or UNICODE (16-bit) character sets. This has several advantages. First of all, localizing a game for non-Roman languages (such as Japanese, Chinese, Korean, Hebrew, Arabic) is easy with Unicode. Second, we’re really interested in Windows CE, and that is a pure Unicode 42
Tim Sweeney Archive
43
News
OS. Windows CE is the native operating system of the Dreamcast, so Unicode is a natural stepping-stone along the Dreamcast porting path which we’re exploring. Windows CE is also used in tons of palm-top computers. Now, none of these palm-top computers are currently interesting from a gamer’s perspective, but if you extrapolate their grown–in terms of video resolutions, RAM, and processing power–along a Moore’s Law curve, they’re not that many years away from being comparable to low-end Pentium II PC’s today. I like to think that the GameBoy’s of the future won’t be a closed platform, but rather run a standardized OS like Windows CE. All Unreal data files are ”character set neutral”, meaning they can contain any mix of ANSI and Unicode characters, and they’re automatically converted/truncated at load time. Network play similarly ”just works” between the Unicode and non-Unicode versions. Regarding Unicode font issues (”who’s going to paint all those Japanese characters?”), Jack Porter has built a TrueType font importer into UnrealEd, which converts any Windows TrueType font to an Unrealcompatible font bitmap. This is an essential part of our Unicode efforts, but also ties into the new user interface he and Brandon are building for Unreal Tournament. There are lots of Unicode fonts with support for nearly all Windows-supported languages, so localizing games into all languages should be fairly painless. • Data compression. I spent a couple days experimenting with various compression schemes and found some interesting results. First of all, it’s fairly easy to achieve PKZIP-quality compression–the algorithms are well documented and easy to implement. Second, it’s nearly impossible to beat PKZIP by much of a margin. Beyond the standard algorithms (Huffman and LZH compression), I experimented with many variations, including: – ”Double” Huffman-compressing each character in a file then recursively merging compressed regions together into spans, with the goal of compressing ”different types of data” with different encoding tables. This approach came out neutral: there were huge gains in compression, but they were offset by having to store lots of Huffman tables.
3.1. JAN 01, 1999
Tim Sweeney Archive
44
News
– Trying Huffman compression in bases other than 2 (such as 3, 5, and 7): no overall gains. – ”Infinite sliding window”: An LZH-style scheme that spends a huge amount of CPU time on compression by analyzing an entire file for differences. Here, the gain was typically 10%, but it was unbearably slow to work with. – Arithmetic encoding. This is a Huffman-style scheme that employs some basic number theory to generate a compression table using arbitrary bases (other than base 2). This gets real gains of around 10% compared to Huffman, but is much slower to decode because it relies on arbitrary-precision integer math. I didn’t get the compression code into the Unreal master source (it was standalone R&D). I’m considering supporting compression for client-downloadable files in Unreal Tournament, to make it easier to go onto servers running custom maps. My most usable compression scheme got 4:1 compression on .unr and .u files (nice!) but no significant compression on textures and sounds. Unreal’s textures compress poorly for an interesting reason: they are already stored using palettes, which are a form of compression. Furthermore, the process of generating an optimal palette for an image yields an array of bytes which are distributed near-uniformly, which is the worst possible case for variable-code-word compression. I think the state-of-the-art in texture compression will be S3’s real-time S3T/DXT scheme, which is fairly lossy, but optimal for real-time decompression while rendering. And it’s 6:1 for all possible kinds of data. One interesting technique I played around with for texture compression is wavelet compression. The 2D wavelet scheme for textures is quite similar to mipmaps: to oversimplify a lot, you represent an nxn image as a sequence of 1x1, 2x2, 4x4, 8x8 ... nxn. Each bitmap is stored as ”signed differences” relative to the lower-res versions of the bitmap. Wavelets are a good starting point for lossy compression schemes, because the ”most visually noticeable” details are in the low-res bitmaps, and in the high-frequency portions of the high-res ones. So, it’s fairly easy to filter out unimportant details and compress what remains. Wavelets are also nice because 3.1. JAN 01, 1999
Tim Sweeney Archive
45
News
you can generate all your texture’s mipmaps from a single wavelet without any overhead. While I don’t think wavelets will play a role in our future texture-mapping plans, they look more useful as a way of storing and manipulating height maps and displacement maps. Wavelets provide a very efficient, ”level of detail”-aware form of storing 2D surface geometry. • 3D API’s. I spent a few days learning the basics of curved surface rendering, which turned out to be very interesting. I was going to do my research with Direct3D (under Windows NT 5.0 Beta 3 RC0) but the 3D hardware support isn’t quite there yet, so I took the opportunity to learn OpenGL using the software rasterizer and 3dfx’s OpenGL minidriver. Both renderers were extremely stable and easy to use. To my amazement, I never experienced a ”blue screen of death” or had to reboot–quite a difference from my past work with Glide and Direct3D! (Note: I haven’t been very closely involved in the Unreal Direct3D and OpenGL support, which has been developed by our partners, so this is my first really in-depth experience).OpenGL’s approach to window management turns out to be extremely simple and reliable. I went from zero to having a spinning cube up and running in under 30 minutes. The tools GL provides for polygon drawing are extremely simple and powerful. For just drawing a few lone polygons, glVertex() and its associated functions are super-easy. For drawing complex meshes, GL’s approach to providing separate client-side arrays for vertices, colors, and texture coordinates is very easy and efficient for multi-pass rendering, since you can swap out one table (say, texture coordinates) without affecting the others. OpenGL’s texture approach (glTexImage2D and glBindTexture) are also very simple and powerful. I remember back under DirectX5, trying to upload a texture to hardware. I spent 4 hours trying to figure out the code and rebooting my computer as it repeatedly locked up. I spent less than 15 minutes figuring out OpenGL texturing and implementing it. Comparing both API’s texturing approaches, OpenGL’s texture management is absolutely the right way to go. – It’s extremely foolproof–you call 3 textures to create, upload, and delete textures. Nothing can possibly go wrong! 3.1. JAN 01, 1999
Tim Sweeney Archive
46
News
– There is no bizarre/mysterious emulation going on. For example, in Direct3D you can modify a texture by Lock()ing it and writing to ”video memory” directly. But, on some hardware (like the Riva TNT), the hardware stores textures internally in a ”swizzled” format you can’t access directly. So some emulation thing has to go on behind the scenes where multiple copies of the textures are maintained and copied around. – OpenGL hides the inner details of texture management from the app, enabling the driver to be optimized for whatever style of texture management is best for a particular 3D card. In OpenGL, a driver writer has total control over texturing and can optimize the hell out of it. In Direct3D, the API hides the application from the hardware and vice-versa, which makes it impossible for a game or a hardware driver to implement good texture caching. Here’s a link to http://www.opengl.org/ and http://www.microsoft. com/directx. • Curved Surfaces. I became familiar with a bunch of different techniques. Curved surfaces pose the same kind of dilemma I felt when writing Unreal’s software renderer: there are lots of mutually incompatible approaches to choose from, but no really clear favorite. Each technique has some desirable strengths, but no technique combines them all.My first experimentation was with bicubic bezier patches, which are a great primitive for building curvy shapes without holes between patches (as with polygons, continuity can be guaranteed by having adjacent patches share vertices and control points). However, they require a fair amount of math for tessellation and, though continuity can be guaranteed, it’s hard to join patches together smoothly (with a continuous normal vector across adjacent patches), especially during animation. I’m pretty sure these will be a key primitive in the next-generation engine. Beziers are very intuitive to model with. The tensor-product math for bicubic bezier quad patches can easily be modified to enable ”bicubic bezier triangles”, which can share edges continuously with quads. I haven’t been able to find any references on this, but I derived the math, and it seems to work. 3.1. JAN 01, 1999
Tim Sweeney Archive
47
News
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
3.1.2
Other Updates
• We updated and coolified the http://unreal.epicgames.com/Partners. htm page, which lists all the announced Unreal engine licensees. 3.1. JAN 01, 1999
Tim Sweeney Archive
48
News
• Alexander Brandon updated the http://www.epicgames.com/alex/ music.htm. • Dave Carter’s http://www.nervedamage.com/ contains lots of cool resources for Unreal modelers and animators.
3.2 3.2.1
Jan 28, 1999 Unreal 221 Development Update
Unreal 221 development continues, with quite a lot of new features slipping into this version. Right now, Mark Poesch (the lead programmer of Wheel of Time) is visiting us here in Raleigh, merging in some of the improvements the Legend team has added into the Unreal engine for WoT and Legend’s upcoming Unreal level pack. I’m working on Unreal’s OpenGL support, and will soon get a version of the code to the 3D hardware makers who have some driver issues to work out. The Riva TNT is currently the fastest and most stable card, with the ATI Rage 128 looking very promising, especially in 24-bit color. I’m also extending the Unreal installer which shipped with the 220 patch, turning it into a full-blown installation program for future patches, shareware versions, and retail versions. I’m also contemplating extending it to support Unreal mods, which could then be distributed in a self-contained format (.uzip?) which Unreal automatically knows how to install. This would put cool mods just 3-4 mouse clicks away from users who are browsing mod sites like http://www.freshmeat.org/unreal/, 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 3.2. JAN 28, 1999
Tim Sweeney Archive
49
News
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 thirdparty licensees.
3.2.2
Unreal Tournament
The rest of the team is hard at work on Unreal Tournament, and we’re really happy with the way the game is shaping up. Unreal was such a huge, multi-faceted project that we weren’t able to focus on deathmatch as much as we would have liked. Unreal Tournament, with its identical gameplay style between single-player and multiplayer (the only difference being bots vs. human opponents) has given us a far more opportunity to polish the gameplay and the look-and-feel. -Tim Sweeney
3.3 3.3.1
Feb 10, 1999 Latest News
Progress on Unreal 221 and Unreal Tournament continues. We are making changes and improvements at such a fast pace that it has been hard/impossible to stabilize the code for the 3-5 days required to fully test a new patch. I apologize for the earlier false start we had with 221.
3.3.2
What we’ve been programming
I’ve been juggling work on the installer, OpenGL, and some core UnrealScript improvements. The installer is coming together, and is complete in terms of installing the retail game and patches, but more work remains to be done on uninstallation issues, and improved support for installing/distributing mods. Some of the latest UnrealScript improvements include a command-line script compiler, which can be used from 3.3. FEB 10, 1999
Tim Sweeney Archive
50
News
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 ingame 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 ingame 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 generalpurpose 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.
3.3. FEB 10, 1999
Tim Sweeney Archive
3.3.3
51
News
Linux Notes
We now have a command-line (windowless, console based) script compiler and server for Unreal, which has minimal dependencies on Windows. This is a first step towards a Linux port, and it also runs very well under Wine, with minimal overhead. This might be a good interim solution for Linux server administrators, before the full port is done. I just noticed in GameSpy that the top server on the list is titled ”CHiX Unreal NT Server (220) PORT UNREAL TO LINUX”. Hint taken. :) We actually have the Unreal 221 Core source compiling under EGCS 2.90.29, C++ templates and all. Getting the thing linking and running successfully will require a lot more work, which we won’t be able to focus on until UT ships, but the experience thus far has been very positive. -Tim Sweeney
3.4 3.4.1
Mar 19, 1999 Latest News
We’ve been going through many iterations of internal testing and improvements on the upcoming patch, which is now known as 223. Here is the latest http://unreal.epicgames.com/ReadMe223.htm. 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 betatested 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 3.4. MAR 19, 1999
Tim Sweeney Archive
52
News
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.
3.4.2
Level-Of-Detail Texture Mapping
I finally got the chance to write a rendering optimization I’ve been thinking about for a long time now, level-of-detail texture mapping. Unreal’s biggest performance problem in OpenGL has been texture management overhead, which causes frame rates to vary a lot (for example, jumping from 30+ fps down to 15 fps for a frame or two when new textures come into view). This is especially noticeable on on the Riva TNT, which has a very good fill rate and can handle large polygon counts, but is around 4X slower transferring textures to the card than Voodoo2. Solution: I create redundant versions of textures, scaled down 4X (in memory usage), 16X, 64X, and 256X. When an object being rendered is far away, I use a lower resolution version of the texture – which doesn’t cause visual problems (since the texture would be mipmapped anyway) but requires less texture data to be transferred. This has enabled us to boost the Unreal Tournament player models’ texture usage to 256K of texels per model. More info about additional levelof-detail features later...
3.4. MAR 19, 1999
Tim Sweeney Archive
3.4.3
53
News
Future of Programming Languages
Lately, I’ve been doing research on programming languages, in the interest of gaining new ideas to implement in the successor to UnrealScript for our next-generation (after Unreal Tournament) engine. Some of the topics I’ve been formulating are: • Garbage collection (see the http://www.iecc.com/gclist/GC-faq. html for background). UnrealScript uses a simple recursive markand-sweep garbage collector which is only executed when changing levels, along with some special-case code to garbage-collect destroyed actors during gameplay. Most implementations of Java use a background thread to run a generational garbage collector. Java’s approach is more general, but can cause pauses during execution as large amounts of garbage are purged, which is bad for frame-rate consistency. Java garbage collection presents a problem for object finalizers (the equivalent of C++ destructors), because the finalizer is executed at some random time after the object in question effectively becomes garbage, and finalizers of multiple objects are executed in random order. This limitation makes finalizers dangerous and not terribly useful. One work-around is to not support finalizers. Another work-around is to support them, but publish a list of ”things that aren’t safe to do from within a finalizer” (such as cause finalized objects to become rooted again, make assumptions about finalization order, etc). UnrealScript’s current solution is a mix of the two; finalizers must be native (implemented in C++) and are subject to those safety guidelines. Another general conceptual problem I have with garbage collection is that, often, the physical lifetime of an object (as defined by the garbage collector) often exceeds the ”practical” lifetime of an object (as defined by the semantics of the program you’re writing). For example, a window object in a windowing system is only meaningful when the window is open on screen; after the window has been closed, the object becomes meaningless even though it still exists and other objects might still be referring to the window. The general problem is that programmers often would like a ”way of explicitly 3.4. MAR 19, 1999
Tim Sweeney Archive
54
News
destroying an object and removing any other objects’ references to it”. C and C++ avoid this problem by making all memory management the program’s responsibility. Java avoids it by making the program responsible for determening whether an object you’re referring to is meaningful (for example by calling Window.IsOpen()). It would certainly be nice if object lifetime management and notifications became the full responsibility of the programming language, enabling programmers to instead focus on higher-level problems. The garbage-collection strategy that would be ideal, from the standpoint of predictable code and memory usage, is to finalize and destroy objects the exact moment they become garbage, i.e. when the last variable still referencing it changes. I’ve tried, very unsuccessfully, to find efficient approaches to manage such as system by tracking multiple reference counts, doubly-linked lists of twoway references between objects, etc etc etc, and haven’t been able to find an approach more efficient that performing a brute-force mark-and-sweep pass every time a reference to an object changes (plus optimizations such as reference counting to collect objects without cyclic references). Stated in graph theory, the question boils down to ”Given a graph and a particular directed edge of the graph, does removing that edge break the graph into two disjoint pieces?” Does anybody know if there is a graph-theory algorithm for determining this, which enables you to add a directed edge to the graph in constant time, and also remove an edge and determine disjointedness from that removal in constant time? • LISP defines a new kind of object called a ”function closure” which basically represents a pointer-to-a-member-function with several of its parameters bound to specific values (for example, binding the implicit ”Self”/”this” parameter to a particular object. This is a great object-oriented generalization of function-pointers, but the syntax becomes fairly complex in a statically-typed language (some issues you run into are recursively-defined closure types, and cyclic closure types). Microsoft’s Java extensions in Visual J++ include a simpler and more limited type of object called a ”delegate” which is a pointer-to-a-member-function bound to a specific instance of an object. I plan to experiment with these possibilities and implement ”something along these lines” in the next engine. 3.4. MAR 19, 1999
Tim Sweeney Archive
55
News
• Inner classes, as defined by Java, are a great feature for attaching objects together hierarchically. This is definitely a feature I want for the future. One example area where inner would simplify and generalize the code is Unreal’s actor lighting support. Currently, the Actor class has a bunch of variables related to lighting (LightBrightness, LightHue, LightSaturation, LightEffect, etc), and an enumeration LightType that describes the light’s overall mode of operation. While this is an improvement over past engines, and general enough for 1998-1999 games, it could be much better. Actors could instead reference a separate Light object which describes the lighting in a more general way. Instead of having a hardcoded enumeration for light effects (such as LE TorchWaver, LE Cylinder, LE Spotlight), all the different light types could be represented by separate classes (TorchWaverLight, CylinderLight, SpotLight) with the class supplying the appropriate spatial and volumetric lighting math. Additionally, the lighting objects could be made hierarchical, so you could modulate a cylinder light by a spotlight, and add a torch wavering effect on top. New light classes could be defined modularly to supply new lighting functions without modifying the engine source. While my plan for the next scripting language is gaining more clarity, there are still a lot of wide-open issues. For example, whether Java-style interfaces are necessary (since most of the same functionality can be obtained from inner classes), what the final garbage-collection strategy is, how similar do we want to make the language to Java, etc.
3.4.4
Visible Surface Determination
One of the biggest next-generation challenges for 3D programmers will be in solving the ”visible surface determination” problem for complex scenes. Doom basically used a densely portalized BSP scheme; Quake used a BSP in conjunction with precomputing the visibility from each BSP leaf in the world to every other leaf, trading off precomputation time in exchange for rendering performance. Unreal uses a sparsely portalized BSP tree and performs a software span-buffering pass to determine 3.4. MAR 19, 1999
Tim Sweeney Archive
56
News
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 http://www.opengl.org/Documentation/Version1.2/HPspecs/occlusion_ test.txt) 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.
3.4.5
Commentary on Cool Stuff
I just wanted to point out the following cool technical things. • 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 exceedingly clear, general, and well thought-out rendering capabilities are going to be the next quantum leap in 3D hardware acceleration acceleration, enabling true Phong/Blinn bump mapping and a tremendous variety of other features. My reaction to seeing this spec for the first time is reminiscent of first experiencing 3dfx’s Voodoo accelerator and the Glide API–it’s ”I can’t believe how powerful yet 3.4. MAR 19, 1999
Tim Sweeney Archive
57
News
simple this is to work with”. • http://teach.belmont.edu/ht/applet/htbu.html: This is the first generally useful new GUI control I’ve seen in years. Imagine the possibilities for using hyperbolic trees to browse the actor lists and server interconnectivity of huge interconnected online worlds. • http://dogma.net/markn/articles/bwt/bwt.htm: A new, unpatented approach to data compression; trivial implementations can easily beat PKZIP. -Tim
3.5 3.5.1
Apr 14, 1999 3dfx Voodoo3 Totally Rocks!
I just picked up a carload of the new Voodoo3 3000’s; we’ve put them to good use, as the team is now testing the upcoming 224 patch. The performance and graphical quality of the Voodoo3 are simply amazing. Though we’ve had a board for over a month, beta drivers and prerelease 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
3.5. APR 14, 1999
Tim Sweeney Archive
58
News
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
3.6 3.6.1
Apr 15, 1999 Important Unreal 224 Note To Mod Authors
Unreal 224 .u files aren’t backwards compatible with past versions of the engine. So you’ll need to take special steps to upgrade your .u files. To upgrade mods to 224, you’ll first need to export your scripts to *.uc files. You can do this in all versions of UnrealEd like this: 1. Bring up the UnrealEd class browser on the right side of the screen. 2. Click on the ”Load” button and load your mod’s .u file. 3. Click on the ”Export All” button and have UnrealEd export all of the loaded scripts to .uc files (including yours and the engine’s), creating a directory structure for all the .uc files: for example, the files from the Core package are in \unreal\core\classes\*.uc. If your mod is named XYZ, your .uc files will be exported to \unreal\XYZ\classes\*.uc.
3.6. APR 15, 1999
Tim Sweeney Archive
59
News
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
3.6.2
Maps, Textures, Sounds, Music are backwards compatible
...so there shouldn’t be any problem with existing user maps built with past versions of UnrealEd. I checked this by downloading a bunch of maps from 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 compatible, so they will refuse to load until the .u files they depend on are upgraded. 3.6. APR 15, 1999
Tim Sweeney Archive
3.6.3
60
News
Latest News
I’ve been awake for way too long, so please forgive my spelling and grammar! Internal testing of 224 continues. Things are looking pretty good, though we need to go through a couple more iterations before everything’s in perfect shape. The 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: 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 realtime strategy titles, that were not previously obvious choices for the engine.
3.6.4
Cool Stuff
While I wait for 200,000 lines of Unreal code to recompile, I wanted to point out some more cool things that seem to be under-appreciated. • http://www.winamp.com/ is a great MP3 music player for Windows; and its companion, http://www.shoutcast.com/ is a streaming ”Internet radio” companion. While I know MP3’s and Internet radio has been around for a while, WinAmp really deserves credit for its grassroots following and overall coolness factor.
3.6. APR 15, 1999
Tim Sweeney Archive
61
News
• Windows 2000 internationalization support. This pure Unicode OS will mark the first time Microsoft ships a single binary worldwide, which will be a great leap forward in making it easy to develop games (and applications, and websites...) for the international market. • http://www.plh.af.mil/ddvpc/melp.htm 2400 bits-per-second phonequality voice compresion. Speech compression research has been making major leaps and bounds lately, as quality voice compression ratios skyrocket. The latest set of algorithms analyze an audio stream and (to simplify things a bit) transform it backwards to vocal cord excitation. The resulting compression ratio is in the neighborhood of 100-to-1. This is a research subject Carlo Vogelsang (Unreal sound engine programmer) and I have been looking into lately, and it turns out to be very complex and math intensive. -Tim
3.7 3.7.1
Apr 19, 1999 Getting closer...
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 http://www.next-generation.com/jsmid/news/6387.html where Mark Rein shamelessly plugs the patch.
3.7. APR 19, 1999
Tim Sweeney Archive
3.7.2
62
News
Network Cross-Compatibility
(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 http:// unreal.epicgames.com/network.htm) 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
3.7. APR 19, 1999
Tim Sweeney Archive
63
News
makes our programming lives easier.
3.8 3.8.1
May 01, 1999 224 Progress Continued
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 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
3.9 3.9.1
May 02, 1999 STAT NET: Diagnosing your connection to the server
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
3.8. MAY 01, 1999
Tim Sweeney Archive
38 0 12% 11 126 1395 2600
0 14% 32 32 2031 2600
64
News
CHANNELS UNORDERED/SEC PACKET LOSS PACKETS/SEC BUNCHES/SEC BYTES/SEC 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: • PING: Round-trip time between you and the server, in milliseconds. Modem users will typically see 200-350 for in-country gameplay. ISDN/T1 users will be in the 50-200 range. Playing overseas results in enormous times, 600-1000 or more. This number represents the quality of the connection between you and the server, and really should be 300 or less for good gameplay performance. A bad connection on either end can hurt the ping time. • CHANNELS: Roughly, the number of objects that the server is actively updating to you. Proportional to how much combat is happening around you. • PACKET LOSS: Percentage of packets lost between the client and server. The higher the packet loss, the worse the performance will be, and the more you’ll see objects skipping around rather than moving smoothly. High packet loss can be caused by: – Using too aggressive a network speed on the client side. Try typing ”NETSPEED 2600” on the console to reign in bandwidth usage. – The server’s connection is overtaxed. This will result in heavy packet loss and a bad gameplay experience for everyone. Servers will limited bandwidth available need to set their play limit conservative (expect 5000 bytes per client per second), and also lower the MaxClientRate variable in Unreal.ini. A value of 5000 should be good for everyone. 3.9. MAY 02, 1999
Tim Sweeney Archive
65
News
– A bad connection anywhere between you and the server. – A bad connection between you and your ISP. • PACKETS/SEC: Number of packets being sent per second. The number on the left should be 13 or higher. If it’s significantly less, that means the server is either running too slowly, or experiencing high packet loss. Gameplay will be bad at 10, and unbearable at 5. The number on the right is proportional to your frame rate and you don’t need to worry about it. • BUNCHES/SEC: Number of objects being updated per second. Not important for tweaking. • BYTES/SEC: Bytes being sent per second. • NETSPEED: The network speed setting you set using the console NETSPEED command. Recommended settings are: – 2600 for a typical modem connection. – 2400 for a poor modem connection. – 5000 for an ISDN connection. – 20000 for a T1 connection.
3.9.2
Server Alert
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. 3.9. MAY 02, 1999
Tim Sweeney Archive
66
News
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
3.9.3
Unreal 224v C++ headers released!
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 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, 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
3.9. MAY 02, 1999
Tim Sweeney Archive
67
News
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 http://unreal.epicgames.com/UnrealPubSrc224v.zip. Unzip it into your \Unreal directory, and the proper subdirectories will be created (described in the http://unreal.epicgames.com/ReadMeSrc.htm). The C++ code compiles there and links to DLL’s in the \Unreal\System directory, read to run. Enjoy! -Tim Sweeney
3.9.4
Unreal 224v Released to the public!
The Unreal 224v patch is now available for download from our http:// unreal.epicgames.com/versions.htm, along with the release notes. -Tim Sweeney
3.9. MAY 02, 1999
Tim Sweeney Archive
68
3.10
May 03, 1999
3.10.1
Known Bugs
News
Having a problem with Unreal? Please visit the http://unreal.epicgames. com/Bugs.htm page to see if we know about it and are addressing it, and if there any any workarounds.
3.10.2
Future Patch
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 3.10. MAY 03, 1999
Tim Sweeney Archive
69
News
move forward with the Unreal Tournament code track, to keep up to date with the latest features. -Tim
3.10.3
Check out the Unreal news sites
• http://www.planetunreal.com/ has lots of news and tips about 224. • http://www.unrealengine.com/ is a news site dedicated to the Unreal engine. • http://www.unreal.org/ is a master index of Unreal resources on the Internet, and has tons of cool Unreal related links. I’ll be making a summary of reported bugs, workaround, and related feedback from the community later tonight.
3.10.4
OpenGL UnrealEd
Thanks http://www.planetunreal.com/ 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.OpenGLRenderDe 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 3.10. MAY 03, 1999
Tim Sweeney Archive
70
3.11
May 05, 1999
3.11.1
Maps that broke since 220
News
Some user maps such has http://www.planetunreal.com/dl/dl.asp?nalicity/ dmhellshrap.zip 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 mailto:unreal224@ epicgames.com. -Tim
3.11.2
Quick Notes
We’ve been going through the Unreal 224 bug reports and addressing lots of issues people have pointed out. Here’s the latest status. • Creative Labs EAX 3D sound support is fixed for 225. • We’re working with Aureal to get A3D 2.0 support into 225, which is very likely to happen. • I fixed the cause of the ”out of memory” errors that tended to happen when the console was pulled down on some machines. There was a problem in UnrealScript with switch statements operating on strings, which caused this and some similar problems reported by licensees. Thanks to Mark Poesch of http://www.wheeloftime.com for tracking this one down. 3.11. MAY 05, 1999
Tim Sweeney Archive
71
News
• Under some conditions, alt-tabbing between fullscreen and windowed play would cause the in-a-window game window to be collapsed to zero size. Fixed. • I optimized the network visibility code by about 25%. Server admins are reporting notably more CPU usage per player with 224 than 220. I haven’t tracked this down, but I’m going through a lot of code to measure and improve the server performance. Many other fixes, tweaks, and incremental improvements are in the works. See the http://unreal.epicgames.com/Bugs.htm page for more info. -Tim
3.12
May 08, 1999
3.12.1
Latest progress
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
3.12. MAY 08, 1999
Tim Sweeney Archive
72
3.13
May 19, 1999
3.13.1
Unreal 225 musings
News
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 bitstream writer, and replication condition caching code), and a new timestamping 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!
3.13.2
”Make Something Unreal” Contest
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!
3.13.3
Things That Are Cool
• http://msdn.microsoft.com/ssafe/: Anybody who is programming on a large project without using a source-control system is nuts! 3.13. MAY 19, 1999
Tim Sweeney Archive
73
News
SourceSafe provides a central repository for all code, and enables programmers to check out files and work on them without their changes ”colliding” with those of other programmers. SourceSafe also tracks all changes to all files since the beginning of a project, which has been incredibly useful in developing Unreal, because it enables us to examine our past code changes when tracking down bugs. Finally, SourceSafe is excellent for managing ”branched” projects: when we split Unreal 224 apart from the Unreal Tournament codebase, SourceSafe managed the files’ shared history automatically. • http://www.glsetup.com/: Now that Microsoft has publicly committed to dropping the ball on 3D hardware driver distribution with DirectX7, GLsetup is the only hope for game developers who want their game to work on users’ computers out-of-the-box. The PC is already plagued by driver problems, and the classic symptom is users having to go to the web and download new drivers to get new games working. The world would be a much better place if Microsoft took a leadership role in driver updates, by keeping the DirectX redistribution continually refreshed with new QA-certified drivers, thus assuring that new games always work ”out of the box” – if that happened, PC gaming would be a lot closer to the level of reliability of console games. But Microsoft isn’t doing that, and GLsetup is a grassroots effort to solve the problem. -Tim P.S. Check out http://www.unrealnation.net/, the cool in-depth Unreal news site.
3.13. MAY 19, 1999
Tim Sweeney Archive
74
News
3.14
May 29, 1999
3.14.1
For server administrators only: Unreal 225e Patch
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 mailto:[email protected] 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: http://unreal. epicgames.com/Files/UnrealPatch225e.exe. The general Unreal 225 patch for everybody including users will be available in a few days. -Tim
3.14.2
On engine licensing
In this http://www.msnbc.com/news/274561.asp#BODY, 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.” 3.14. MAY 29, 1999
Tim Sweeney Archive
75
News
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
3.14.3
UnrealEd ”Runtime Error 20005” Experimental Fix
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:[email protected] 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.14. MAY 29, 1999
Tim Sweeney Archive
76
3.15
May 31, 1999
3.15.1
Latest News
News
• 4 out of 5 users have reported success with the experimental UnrealEd fix – it made those nasty ”Runtime Error” messages go away. If you’re having problems with UnrealEd not starting up, grab this file! • The other one reported an error message relating to Threed32.ocx which I fixed in http://unreal.epicgames.com/Files/UnrealEdFix3. exe. • There was a master server outage/problem today. If you weren’t seeing servers in Unreal’s new server browser or GameSpy today, don’t worry, the problem was at the master server and it has been fixed. • Aussies, check out the http://www.unrealed.net/ozunreal/ for Australian level designers!
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.
3.15.3
New 225f Patch for server administrators only
This should fix the UActorChannel::ReplicateActor crash and some smaller problems.
3.15. MAY 31, 1999
Tim Sweeney Archive
77
News
It’s backwards-compatible with Unreal 224-225 clients. If you have any server crashes, please email your Unreal.log file to mailto:unreal225@ epicgames.com. Only download this if you are running an Unreal server: http://unreal. epicgames.com/Files/UnrealPatch225f.exe. -Tim
3.15.4
Server 225e Patch Feedback
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!
3.15.5
UnrealEd Experimental Fix 2
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 http://unreal.epicgames. com/Files/UnrealEdFix2.exe. Please let us know what happens by emailing mailto:[email protected] 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
3.15. MAY 31, 1999
Tim Sweeney Archive
78
3.16
Jun 01, 1999
3.16.1
UnrealEd Follow-Up
News
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.
3.16.2
Server Cheats?
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:[email protected] 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:[email protected] (no prizes for this, we’ll just fix the security holes!)
3.16.3
UnrealEd for 3dfx Voodoo3 bundle owners
The version of Unreal that shipped with 3dfx’s Voodoo3 bundle didn’t include 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 3.16. JUN 01, 1999
Tim Sweeney Archive
79
News
example c:\Unreal). Then just run c:\Unreal\System\UnrealEd.exe to start editing. -Tim
3.17
Jun 06, 1999
3.17.1
Direct3D Improvements
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
3.17. JUN 06, 1999
Tim Sweeney Archive
80
3.18
Jun 19, 1999
3.18.1
Unreal Direct3D
News
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: 1. Dramatically less memory usage. My Direct3D code wasted tons of hidden, ”behind the scenes” memory while swapping textures into video memory, leading to lots of virtual-memory swapping. 2. New texture management code, better optimized for Unreal’s texture usage patterns. I had been relying on Direct3D’s built-in texture manager, which is slowed down by its generality. 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.
3.18. JUN 19, 1999
Tim Sweeney Archive
3.18.2
81
News
Summary of things I learned about Direct3D
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, 3.18. JUN 19, 1999
Tim Sweeney Archive
82
News
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
3.19
Jun 30, 1999
3.19.1
Direct3D Is Happening
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, http: // www. planetunreal. com/
3.19. JUN 30, 1999
Tim Sweeney Archive
83
News
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
3.20
Jul 01, 1999
3.20.1
226 Progress
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.
3.20.2
Recommended Reading
http://www.amazon.com/exec/obidos/ASIN/0387947752/002-3430157-9555648 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. 3.20. JUL 01, 1999
Tim Sweeney Archive
84
News
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.
3.21
Jul 03, 1999
3.21.1
On Our World Domination Plans
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 describes, the http://www.digitalo.com/ team is building a ”virtual reconstruction” of the http://www.planetunreal.com/index.asp?images.asp? interviews/images/vrnd1big.jpg. 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, http://www.unrealengine. com/, is covering lots of other Unreal engine projects that fall way outside 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 wellknown 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 3.21. JUL 03, 1999
Tim Sweeney Archive
85
News
are pitching completely non-game projects incorporating the Unreal engine to investors.
3.21.2
What’s really happening here?
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 stateof-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.
3.21.3
The Economics
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 3.21. JUL 03, 1999
Tim Sweeney Archive
86
News
(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 highvolume 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.
3.21.4
The Result: General-Purpose Solutions Win
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 3.21. JUL 03, 1999
Tim Sweeney Archive
87
News
grow. The ramifications are: • Specialized software and hardware loses out to general-purpose. The company that focuses on generality (for example, a CPU, or a 2D+3D graphics accelerator, or a general-purpose game engine) has the expectation of higher sales, and can make so much more of an R&D investment that special-purpose solutions can’t compete (for example, 3D-only accelerators, or a once-off engine powering a single game). • Volume and increasing R&D investment enable 3dfx and NVidia to sell millions of $150 graphics cards that outperform SGI’s $50,000 solution which sells 1000 units. That has the effect of crushing SGI’s business model, even though companies like 3dfx aren’t even consciously trying to compete with SGI. • When a company like Epic or id Software builds a 3D engine, we do it with the expectation of it powering games that sell a few million copies, between our games and licensee projects. We make money from each one, and that realization drives investment in making more and better tools. This gives our engines a price, performance, and feature advantage over ”in-house” engines made specifically for one game, and over less-capable engines designed for niche markets. We amortize our R&D investment over ~10X more units sold. This licensing model has already proven successful with mainstream game developers, but now it’s starting to overflow into non-game markets too. We have this great 3D engine, why not use it for your architectural walkthrough? • As a result of widespread interest, thriving ecosystems develop around successful general-purpose products. For example, there are hundreds of web sites dedicated to 3dfx hardware, and lots of developers optimizing their games for 3dfx. There are many hundreds of web sites covering Unreal and licensee projects; thousands of kickass aspiring level designers building maps and making them available online; many licensees building games; and lots of other cool 3.21. JUL 03, 1999
Tim Sweeney Archive
88
News
projects that tie into the engine, such as mods and TC’s, and the research projects like Notre Dame. The community has a multiplicative effect on growing the platform.
3.21.5
Where we go from here
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
3.22
Jul 10, 1999
3.22.1
The AMD Athlon Rocks!
My new 550 MHz http://www.amd.com/products/cpg/athlon/index.html (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.
3.22. JUL 10, 1999
Tim Sweeney Archive
89
News
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: • I want to be able to buy dual-processor Athlon workstations from major manufacturers like Dell and Gateway. • I want MMX, 3DNow! and SSE code generation support in Visual C++, with native SIMD C/C++ datatypes like float2, float4, and short4, making the compiler manage all register allocation and code generation. • I want http://www.kryotech.com/sgindex.asp! 8-) -Tim
3.23
Jul 12, 1999
3.23.1
New Downloads & Links Pages
By popular request, the links on the tech page have been updated and cleaned up. I added: • New http://unreal.epicgames.com/Downloads.htm page: An index of all the official files here on the tech page, plus links to dedicated Unreal download sites. If you’re looking for the latest PC or Mac patch, UnrealEd patch, Fusion maps, or whatever, look here. 3.23. JUL 12, 1999
Tim Sweeney Archive
90
News
• New http://unreal.epicgames.com/Links.htm page. Links to some of the major ”hub” web sites related to the Unreal community, Epic, our partners. I also wanted to mention the supercool new download site, http://www. unrealfiles.com/, check it out. -Tim
3.24
Aug 14, 1999
3.24.1
DirectX7
Some people have been asking about our plans for supporting the upcoming 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 Unreal Tournament patch with complete DirectX7 optimizations. This has been the plan all along. DirectX7 has lots of cool new features. The ones which Unreal Tournament will exploit are: • Improved texture management. • Hooks to enable 3D card drivers to perform their own texture management to improve performance. • Optimized polygon path for significantly faster polygon rates. • Windows 2000 support. -Tim
3.24. AUG 14, 1999
Tim Sweeney Archive
91
3.25
Aug 16, 1999
3.25.1
Unreal Tournament development note
News
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
Sep 14, 1999
3.26.1
Unreal Tournament demo schedule
To quote http://www.voodooextreme.com/ quoting me :), here’s the Unreal Tournament demo release plan: • Windows 3dfx demo this week. • Windows Direct3D/OpenGL next week. • Linux Glide/OpenGL soon after. • Mac timing not figured out yet.
3.25. AUG 16, 1999
Tim Sweeney Archive
3.26.2
92
News
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 texture management. The API’s simplicity has also improved, which is something you don’t often 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 function calls and interfaces. I’m very glad to see the IDirect3DTexture, IDirect3DViewport, and IDirect3DLight interfaces gone, and replaced by much simpler state-setting code. Direct3D’s abuses of object-oriented programming 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 backwardscompatible 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
Sep 22, 1999
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 3.27. SEP 22, 1999
Tim Sweeney Archive
93
News
on the upcoming Unreal Tournament demo with Direct3D and OpenGL support, coming in the next few days. One thing we’ve found on DirectX7 is that NVidia TNT2 performance is not fill-rate limited until you get to very high resolutions. During testing, performance at 640x480 seemed a bit slow, but as we increased the resolution, the frame rate was hardly impacted at all. So 1024x768 seems to yield the best overall experience on this card. I’ve enabled support for 32-bit color textures under Direct3D, which significantly improve the graphical quality, with a 10-15% frame rate impact. The Direct3D code now uses vertex buffers, which speeds up mesh and text drawing a bit.
3.27.2
What about OpenGL?
We’re still maintaining OpenGL sypport, though it’s not as much of a priority 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 enable 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. I’ve been maintaining the Unreal / Unreal Tournament rendering code under both Direct3D and OpenGL simultaneously for a while. They used to have approximately equal performance back when I was using Direct3D’s ”driver-managed textures” (similar to the one and only OpenGL option for texture management, which is transparent to the application). Unfortunately, the performance wasn’t very good, and the memory usage was nuts because our game uses a huge amount of textures, and the automatic texture management in Direct3D and OpenGL had to keep duplicate copies around as ”backing store” to the copies in video memory. 3.27. SEP 22, 1999
Tim Sweeney Archive
94
News
However, I recently rewrote my Direct3D code to manage textures explicitly. I create a limited number of textures of all possible sizes, forced to be in video memory, and then at runtime swap my actual game textures into those ”video memory textures”. This way, I have complete control over texture management, and can make optimal decisions about where to put textures, based on the constraints of my app, such as: • Texture usage patterns. • Decompressing textures at glTexImage2D time using my own internal formats. • Having a background thread load them off disk speculatively and stick them in video memory when needed.\ • Other nonlinear, possibly time-variant priority factors. When I replaced D3D’s default texture manager with my own code, Unreal’s performance and memory usage under Direct3D improved very significantly, to the point where it’s not worth bothering playing the game in OpenGL anymore. So, my question is, does anybody have plans to add an ”extended version of glBindTexture” which lets the application tell the OpenGL driver, ”allocate this texture in video memory, keep it there, and never swap it out”? If an option like this existed, I could do the same kind of high-level optimizations as I did in Direct3D, and probably get a comparable increase in performance. Obviously, video memory is a limited resource, so at some point those glBindTextures will fail if video memory fills up, and have to return an error code. This is a bit lower-level than GL’s existing glBindTexture mechanism, but I think it’s justified by the need to support apps which use huge quantities of textures and have to manage them carefully in order to maintain realtime frame rates. For example: If the GL EXT BIND TEXTURE 2D VIDEOMEMORY string is exposed, then you can replace a call to glBindTexture( GL TEXTURE 2D, MyBindId ) with glBindTexture( GL TEXTURE 2D VIDEOMEMORY, MyBindId ) and the texture is guaranteed to be allocated in
3.27. SEP 22, 1999
Tim Sweeney Archive
95
News
video memory and never moved around by the GL driver’s texture manager. For my application, glPrioritizeTextures(?) isn’t a viable solution, because it still requires extra backing-store copies of textures to be kept in system memory so they can be swapped in and out. In addition, implementing my own texture manager on top of the existing, unextended glBindTexture isn’t at all efficient, because I don’t have any way of knowing how many textures I can allocate before they start spilling out of video memory, and in addition most GL drivers do lots of extra internal memcpy’s in the process – and with big textures, having lots of unnecessary 256K memcpys (for 256x256x32-bit textures) just kills performance. Such a solution would benefit Unreal engine games on Windows, Linux, and possibly Mac such as Unreal Tournament, Duke Nukem Forever, Deus Ex, Wheel of Time, etc etc etc. As well as other developers’ texture-intensive games that use OpenGL, such Starsiege: Tribes (the developers have been running into this same issue).
3.27.3
Experiencing poor Internet play on your Voodoo3 3500TV?
As http://www.voodooextreme.com/ reports, the Voodoo3 3500TV’s WebTV installer does some evil things to your Internet setting, causing many games (including Unreal Tournament and Quake 3 Arena) to experience poor Internet play: Hello, We are aware of the problems that the Voodoo3 3500TV is experiencing with online games. Many of these problems can be cured by removing WebTV, however that will disable the Visual Reality software. The problem usually can also be cured by removing the Internet Explorer 5 upgrade from Windows98. While these are just a work around, and not really fixes, both options usually will cure the problem until 3dfx releases a real fix. We are currently working with Microsoft to try and figure 3.27. SEP 22, 1999
Tim Sweeney Archive
96
News
out whether the problem is due to Microsoft software (WebTV and IE5) or 3dfx software (3500TV drivers and Visual Reality). Thank you for your patience, Aaron D. Patton 3dfx Interactive Email Support -Tim
3.28
Sep 29, 1999
3.28.1
More Hardware Troubleshooting
• We received some more confirmations of Unreal working better on TNT’s with the Creative Labs unified drivers using Glide than Direct3D. If you have a Creative Labs TNT card and have having performance problems, try that. Especially if you have under 128 megs of RAM. • Lots of reports of slowdowns from users with Monster Sound’s who have enabled the ”Advanced Options / Audio / Use3DHardware”. If you’re having this slowdown, disable Use3DHardware and try again. Then please email mailto:[email protected] and let us know whether that helped. I’ve seen three confirmations from users that their problems (huge slow down) went away after disabling this. • 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 almost exact proportion to our ”supposed” video memory texture allocations. Thus the game uses an extra 12-26 megabytes of system memory–a very inefficient allocation of resources. This is a big surprise, 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 3.28. SEP 29, 1999
Tim Sweeney Archive
97
News
our henchmen at NVidia and Microsoft and see if we can track this down...
3.28.2
Direct3D Anomalies
We’ve been looking at the feedback on Direct3D performance and investigating some strange reports. Recently, we’ve mainly been testing on 96-meg and 128-meg machines (I have a Celeron 400, Jack Porter has a K6-2 450). On these machines, TNT1 performance is good – average 28 fps at 648x480, 25 fps at 800x600. The TNT2 performance is significantly better. However, upon removing some RAM and testing Direct3D on a 64-meg K6-2, the ”precache” time increased by about 5X, and performance dropped to a few frames per second. These performance drops don’t occur in the software renderer, and don’t occur in Glide. Something is going wrong between Unreal, Direct3D, and the TNT’s Direct3D driver, and we’re investigating. Overall, the feedback indicates a very wide variance in performance among TNT users, much more so than with any other card. Our internal testing has indicated this too; for example, we’ve found (and worked around) a lot of driver bugs that only happen on one machine, and not others with otherwise similar configurations. Don’t Try This At Home Dept.: Some TNT users have reported that tweaking their BIOS’s ”AGP Aperture Size” improves performance on 64-meg machines. We have tried this and couldn’t find any differences on our 64-meg test machine. Others report that the Creative Labs unified drivers (with TNT Glide support) outperform Direct3D on their cards. If anybody finds definite improvements or workarounds, or has insight into what’s happening, please email mailto:[email protected] and let us know. Thanks.
3.28. SEP 29, 1999
Tim Sweeney Archive
3.28.3
98
News
Athlon In The House
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
3.29
Oct 01, 1999
3.29.1
TNT Users, Try This!
Tweaks: • Play in 16-bit color, which is significantly faster than 32-bit color. • Turn the detail options down in the Preferences/Video menu. • Use the ”-” key to reduce the HUD size. • In Preferences/Game, turn off the display of your weapon. • If you have enabled Advanced Options / Audio / Use3DHardware audio support, TURN IT OFF for now! Big driver performance problems. Experimental improvement for the brave: • Try http://www.geforce-fr.com/drivers/win9x_nv3.34.exe (thanks to http://www.anandtech.com/ site for the link). • Try putting this new http://unreal.epicgames.com/D3DDRV.DLL into your \TournamentDemo\System directory. Please back up your existing one first!
3.29. OCT 01, 1999
Tim Sweeney Archive
99
News
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
3.29.2
Latest Findings
We’ve been benchmarking UT performance and memory usage on many 3D cards, and we’ve found the source of the performance problems on 64-96 meg machines with TNT/TNT2 cards. Our measurements indicate that the TNT/TNT2 drivers consume up to 25 megabytes of page-locked system memory with UT, while other Direct3D cards don’t. On machines with 64-96 megs, that kills performance, as one would expect. The game runs, but data is swapped to the hard drive so frequently that playability is compromised. We’ve been comparing with other 3D cards and aren’t seeing the issue on the Rage 128 or Voodoo3 under Direct3D. System-wide memory allocations measured with SYSMON.EXE on a 64meg Celeron running Windows 98 SE: • TNT D3D: 51 MB baseline, 122 MB playing UT in 16-bit color, 134 MB playing UT in 32-bit color. • Rage 128 D3D: 55 MB baseline, 107 MB playing UT in 16-bit color, 109 MB playing UT in 32-bit color. • Voodoo3 D3D: 51 MB baseline, 100 MB playing UT in 16-bit color. 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. OCT 01, 1999
Tim Sweeney Archive
3.29.3
100
News
Links
Unreal Technology in the news: • http://www.msnbc.com/news/318085.asp?cp1=1#BODY - MSNBC • http://www.newsday.com/plugin/ccov0929.htm - Newsday Cool Sites: • http://www.unreality.dk/ - Cool Unreal site & community host in Denmark. • http://www.gamespy.com/ - The GameSpy empire’s new portal site. Check out their http://www.gamespy.com/stats/index.shtm page, where Unreal Tournament is #6 and rising quickly. Hopefully someday we’ll overtake that 3-year-old QuakeWorld thing. :-) -Tim
3.30
Oct 02, 1999
3.30.1
Unreal Tournament players overtake QuakeWorld at #5
Top Game Servers By Players from http://www.gamespy.com/stats/index. shtm @ 7:52 PM EST
Game Servers Players ================== ======= ======= Half Life 1502 4344
3.30. OCT 02, 1999
Tim Sweeney Archive
Quake II Starsiege TRIBES Quake 3: Arena Unreal Tournament Quakeworld Kingpin Unreal Turok 2 Descent 3
101
1628 589 1040 423 623 127 134 20 8
News
1711 1162 1156 520 517 256 144 43 23
-Tim
3.31
Oct 06, 1999
3.31.1
Windows 2000 RC2 Rocks!
I recently upgraded to Windows 2000 Release Candidate 2, and wanted to mention that it’s extremely solid! With NVidia’s latest Windows 2000 TNT/GeForce drivers, DirectX7’s Direct3D and OpenGL both work flawlessly. What’s cool about the new OS: • High-performance DirectX7 Direct3D and OpenGL support. • USB mouse support – mouse movement is very smooth. • Much more stable than Windows 98, especially for software development. • Good administration tools, more powerful than NT4 and far easier to use. • Great international support. • Dual processor support. • Plug and play. 3.31. OCT 06, 1999
Tim Sweeney Archive
3.31.2
102
News
Windows 2000 Internationalization
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 matter 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 confusing array of incomplete features such as supporting Unicode in a few API’s but not all, weird and undocumented multibyte character set handling, and mixed ANSI/OEM file system conventions. Localizing Windows 9X apps is a very difficult undertaking. On the other hand, Windows 2000 is by far the most thoroughly internationalized 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 development 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
3.31. OCT 06, 1999
Chapter 4 2000 News 4.1
Feb 22, 2000
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.
4.1.1
Common Questions I’m Asked
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: • Steve Polge, creator of the ReaperBot mod for Quake. • Brandon ”GreenMarine” Reinhart, early Unreal mod maker and writer of cool UnrealScript programming tutorials. • Jack ”mek” Porter, Unreal mod maker and PlanetUnreal news correspondent. • Alan Willard, maker of cool Unreal and Quake levels. • Shane Caudle, amazing artist and level designer who was building his own Quake TC. 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 emphasis 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 algorithms 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 understanding them brings clarity to lots of real-world problems you’ll encounter. 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 includes the editor (on CD#2) and all the http://unreal.epicgames.com/ 4.1. FEB 22, 2000
Tim Sweeney Archive
105
News
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 information. 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 retail version), you don’t need a license agreement while you’re prototyping 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.2
Programming Languages
Ever since my http://www.gamespy.com Developer Week article, ”http: //www.gamespy.com/articles/devweek_b.shtm”, I’ve been getting questions about whether we plan to ”do something about it” and define a new programming language. The answer is, we’re already doing that to a certain extent with http://unreal.epicgames.com/unrealscript.htm, which is a high-level, object-oriented, platform-independent language with some cool extensions aimed at game code development. As an engine developer, we’ll always be involved in language design to a certain extent. In the future, the scripting language could evolve into a 4.1. FEB 22, 2000
Tim Sweeney Archive
106
News
simpler form, more true to the ”scripting” term: controlling sequences of in-game events. Or, the scripting language could grow to subsume even more of the engine code. We’ll be evaluating these options anew with each major iteration of the engine, doing whatever is most appropriate for the technology, recognizing the benefits and drawbacks of going with well-known proven tech, versus creating newer, better tech.
4.1.3
Also...
• The cool soon-to-be-public site http://www.linuxnewbie.com/ already has posted a http://www.linuxnewbie.org/nhf/intel/games/ unreal_tourney.html on how to get started with Unreal Tournament 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 starting 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
4.2
Feb 28, 2000
Check out the http://www.gamespy.com/articles/moddevweek_b.shtm on the state of mod development, by our own Brandon ”GreenMarine” Reinhart. This is the first feature in http://www.gamespy.com/ new http:// www.gamespy.com/articles/moddevweek_a.shtm feature. Upcoming articles in the series feature Jesse Taylor from the Infiltration mod team for Unreal Tournament, and David ”crt” Wright of Rocket Arena for Quake 3 and Unreal Tournament.
4.2. FEB 28, 2000
Tim Sweeney Archive
107
News
Now is an exciting time for mod development, as the best teams of enthusiasts are earning tremendous praise, opening up serious biz opportunities. 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 enjoyment, 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 Unreal 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 pressurecooker environment, only good games and good ideas survive. -Tim
4.2. FEB 28, 2000
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
2.5 Oct 25, 1998 . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5.1
18
Geting closer... . . . . . . . . . . . . . . . . . . . . . .
18
2.6 Oct 26, 1998 . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
2.6.1
Direct3D Drivers . . . . . . . . . . . . . . . . . . . .
18
2.6.2
Known Issues . . . . . . . . . . . . . . . . . . . . . .
19
2.6.3
Unreal 218 Gaining Support . . . . . . . . . . . . . .
19
2.6.4
PlanetUnreal performance survey . . . . . . . . . .
20
2.6.5
More about 3D API’s . . . . . . . . . . . . . . . . . .
20
2.6.6
Unreal 218 Patch is ready! . . . . . . . . . . . . . . .
22
2.7 Oct 28, 1998 . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
2.7.1
Latest Happenings . . . . . . . . . . . . . . . . . . .
22
2.7.2
Status of Direct3d - All Drivers . . . . . . . . . . . . .
23
2.7.3
Riva TNT . . . . . . . . . . . . . . . . . . . . . . . . .
23
2.7.4
Riva 128 . . . . . . . . . . . . . . . . . . . . . . . . .
23
2.7.5
Intel i740 . . . . . . . . . . . . . . . . . . . . . . . . .
23
2.7.6
ATI Rage Pro . . . . . . . . . . . . . . . . . . . . . . .
23
2.7.7
3dfx Voodoo2 . . . . . . . . . . . . . . . . . . . . . .
24
2.7.8
S3 Savage 3D . . . . . . . . . . . . . . . . . . . . . . .
24
2.7.9
Matrox G200 . . . . . . . . . . . . . . . . . . . . . . .
24
2.7.10 Rendition
. . . . . . . . . . . . . . . . . . . . . . . .
24
2.7.11 Permedia . . . . . . . . . . . . . . . . . . . . . . . . .
24
2.7.12 Drivers we consider playable, in best-to-worst order
25
2.8 Oct 30, 1998 . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
2.8.1
Unreal 218 patch information (RTFM!) . . . . . . . . CONTENTS
25
Tim Sweeney Archive
3
News
2.8.2
Resources for Server Administrators . . . . . . . . .
26
2.8.3
Unreal Multiplayer Ramp-Up . . . . . . . . . . . . .
26
2.8.4
Other Servers . . . . . . . . . . . . . . . . . . . . . .
27
2.9 Nov 01, 1998 . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
2.9.1
Unreal Grows... . . . . . . . . . . . . . . . . . . . . .
27
2.10 Nov 02, 1998 . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
2.10.1 Unreal 219! . . . . . . . . . . . . . . . . . . . . . . . .
28
2.10.2 The testing is going well . . . . . . . . . . . . . . . .
28
2.10.3 Testing 219 . . . . . . . . . . . . . . . . . . . . . . . .
29
2.11 Nov 10, 1998 . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
2.11.1 Latest News . . . . . . . . . . . . . . . . . . . . . . .
29
2.11.2 The Roadmap . . . . . . . . . . . . . . . . . . . . . .
30
2.11.3 Server Administration . . . . . . . . . . . . . . . . .
31
2.12 Nov 19, 1998 . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
2.12.1 Unreal 220 Internet Improvements . . . . . . . . . .
31
2.12.2 Unreal Editor Progress . . . . . . . . . . . . . . . . .
32
2.12.3 Web Site Notes . . . . . . . . . . . . . . . . . . . . . .
33
2.12.4 Unreal mod notes . . . . . . . . . . . . . . . . . . . .
34
2.13 Dec 10, 1998 . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
2.13.1 No News . . . . . . . . . . . . . . . . . . . . . . . . .
34
2.14 Dec 11, 1998 . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
2.15 Dec 12, 1998 . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
2.16 Dec 14, 1998 . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
2.16.1 Hard at work . . . . . . . . . . . . . . . . . . . . . . .
36
CONTENTS
Tim Sweeney Archive
4
News
2.16.2 That’s UnrealEd.net . . . . . . . . . . . . . . . . . . .
37
2.17 Dec 15, 1998 . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
2.17.1 Unreal Networking Code: Status . . . . . . . . . . .
38
2.18 Dec 18, 1998 . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
2.18.1 Unreal Tournament notes for mod authors . . . . .
41
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 3.5.1
5
News
3dfx Voodoo3 Totally Rocks! . . . . . . . . . . . . . .
59
3.6 Apr 15, 1999 . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
3.6.1
Important Unreal 224 Note To Mod Authors . . . . .
60
3.6.2
Maps, Textures, Sounds, Music are backwards compatible . . . . . . . . . . . . . . . . . . . . . . . . . .
62
3.6.3
Latest News . . . . . . . . . . . . . . . . . . . . . . .
62
3.6.4
Cool Stuff . . . . . . . . . . . . . . . . . . . . . . . . .
63
3.7 Apr 19, 1999 . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
3.7.1
Getting closer... . . . . . . . . . . . . . . . . . . . . .
64
3.7.2
Network Cross-Compatibility . . . . . . . . . . . . .
64
3.8 May 01, 1999 . . . . . . . . . . . . . . . . . . . . . . . . . . .
65
3.8.1
224 Progress Continued . . . . . . . . . . . . . . . .
65
3.9 May 02, 1999 . . . . . . . . . . . . . . . . . . . . . . . . . . .
66
3.9.1
STAT NET: Diagnosing your connection to the server 66
3.9.2
Server Alert
. . . . . . . . . . . . . . . . . . . . . . .
68
3.9.3
Unreal 224v C++ headers released! . . . . . . . . . .
69
3.9.4
Unreal 224v Released to the public! . . . . . . . . . .
70
3.10 May 03, 1999 . . . . . . . . . . . . . . . . . . . . . . . . . . .
71
3.10.1 Known Bugs . . . . . . . . . . . . . . . . . . . . . . .
71
3.10.2 Future Patch . . . . . . . . . . . . . . . . . . . . . . .
71
3.10.3 Check out the Unreal news sites . . . . . . . . . . . .
72
3.10.4 OpenGL UnrealEd . . . . . . . . . . . . . . . . . . . .
72
3.11 May 05, 1999 . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
3.11.1 Maps that broke since 220 . . . . . . . . . . . . . . .
73
CONTENTS
Tim Sweeney Archive
6
News
3.11.2 Quick Notes . . . . . . . . . . . . . . . . . . . . . . .
73
3.12 May 08, 1999 . . . . . . . . . . . . . . . . . . . . . . . . . . .
74
3.12.1 Latest progress . . . . . . . . . . . . . . . . . . . . .
74
3.13 May 19, 1999 . . . . . . . . . . . . . . . . . . . . . . . . . . .
75
3.13.1 Unreal 225 musings . . . . . . . . . . . . . . . . . . .
75
3.13.2 ”Make Something Unreal” Contest . . . . . . . . . .
76
3.13.3 Things That Are Cool . . . . . . . . . . . . . . . . . .
76
3.14 May 29, 1999 . . . . . . . . . . . . . . . . . . . . . . . . . . .
77
3.14.1 For server administrators only: Unreal 225e Patch .
77
3.14.2 On engine licensing . . . . . . . . . . . . . . . . . . .
77
3.14.3 UnrealEd ”Runtime Error 20005” Experimental Fix .
78
3.15 May 31, 1999 . . . . . . . . . . . . . . . . . . . . . . . . . . .
79
3.15.1 Latest News . . . . . . . . . . . . . . . . . . . . . . .
79
3.15.2 Holiday? . . . . . . . . . . . . . . . . . . . . . . . . .
79
3.15.3 New 225f Patch for server administrators only . . . .
80
3.15.4 Server 225e Patch Feedback . . . . . . . . . . . . . .
80
3.15.5 UnrealEd Experimental Fix 2
. . . . . . . . . . . . .
80
3.16 Jun 01, 1999 . . . . . . . . . . . . . . . . . . . . . . . . . . .
81
3.16.1 UnrealEd Follow-Up . . . . . . . . . . . . . . . . . .
81
3.16.2 Server Cheats? . . . . . . . . . . . . . . . . . . . . . .
81
3.16.3 UnrealEd for 3dfx Voodoo3 bundle owners . . . . .
82
3.17 Jun 06, 1999 . . . . . . . . . . . . . . . . . . . . . . . . . . .
82
3.17.1 Direct3D Improvements . . . . . . . . . . . . . . . .
82
3.18 Jun 19, 1999 . . . . . . . . . . . . . . . . . . . . . . . . . . .
83
CONTENTS
Tim Sweeney Archive
7
News
3.18.1 Unreal Direct3D . . . . . . . . . . . . . . . . . . . . .
83
3.18.2 Summary of things I learned about Direct3D . . . .
84
3.19 Jun 30, 1999 . . . . . . . . . . . . . . . . . . . . . . . . . . .
85
3.19.1 Direct3D Is Happening . . . . . . . . . . . . . . . . .
85
3.20 Jul 01, 1999 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
86
3.20.1 226 Progress . . . . . . . . . . . . . . . . . . . . . . .
86
3.20.2 Recommended Reading . . . . . . . . . . . . . . . .
87
3.21 Jul 03, 1999 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
87
3.21.1 On Our World Domination Plans . . . . . . . . . . .
87
3.21.2 What’s really happening here? . . . . . . . . . . . . .
88
3.21.3 The Economics . . . . . . . . . . . . . . . . . . . . .
89
3.21.4 The Result: General-Purpose Solutions Win . . . . .
90
3.21.5 Where we go from here . . . . . . . . . . . . . . . . .
91
3.22 Jul 10, 1999 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
92
3.22.1 The AMD Athlon Rocks! . . . . . . . . . . . . . . . .
92
3.23 Jul 12, 1999 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
93
3.23.1 New Downloads & Links Pages . . . . . . . . . . . .
93
3.24 Aug 14, 1999 . . . . . . . . . . . . . . . . . . . . . . . . . . .
94
3.24.1 DirectX7 . . . . . . . . . . . . . . . . . . . . . . . . .
94
3.25 Aug 16, 1999 . . . . . . . . . . . . . . . . . . . . . . . . . . .
94
3.25.1 Unreal Tournament development note . . . . . . . .
94
3.26 Sep 14, 1999 . . . . . . . . . . . . . . . . . . . . . . . . . . .
95
3.26.1 Unreal Tournament demo schedule . . . . . . . . .
95
3.26.2 DirectX7 . . . . . . . . . . . . . . . . . . . . . . . . .
95
CONTENTS
Tim Sweeney Archive
8
News
3.27 Sep 22, 1999 . . . . . . . . . . . . . . . . . . . . . . . . . . .
96
3.27.1 DirectX7 . . . . . . . . . . . . . . . . . . . . . . . . .
96
3.27.2 What about OpenGL? . . . . . . . . . . . . . . . . . .
97
3.27.3 Experiencing poor Internet play on your Voodoo3 3500TV? . . . . . . . . . . . . . . . . . . . . . . . . .
99
3.28 Sep 29, 1999 . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 3.28.1 More Hardware Troubleshooting . . . . . . . . . . . 100 3.28.2 Direct3D Anomalies . . . . . . . . . . . . . . . . . . 101 3.28.3 Athlon In The House . . . . . . . . . . . . . . . . . . 102 3.29 Oct 01, 1999 . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 3.29.1 TNT Users, Try This! . . . . . . . . . . . . . . . . . . 102 3.29.2 Latest Findings . . . . . . . . . . . . . . . . . . . . . 103 3.29.3 Links . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 3.30 Oct 02, 1999 . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 3.30.1 Unreal Tournament players overtake QuakeWorld at #5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 3.31 Oct 06, 1999 . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 3.31.1 Windows 2000 RC2 Rocks! . . . . . . . . . . . . . . . 105 3.31.2 Windows 2000 Internationalization . . . . . . . . . . 106 4 2000 News
108
4.1 Feb 22, 2000 . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 4.1.1
Common Questions I’m Asked . . . . . . . . . . . . 108
4.1.2
Programming Languages . . . . . . . . . . . . . . . . 110
4.1.3
Also... . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
CONTENTS
Tim Sweeney Archive
9
News
4.2 Feb 28, 2000 . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
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 posting in early 2000.
10
Chapter 2 1998 News 2.1 2.1.1
Oct 13, 1998 Unreal Cheat-Finding Challenge
I’ve seen two reports that people have found a way to cheat in Internet play. One person reported seeing a little tiny 1-inch tall player walking around named ”LilTinyChessPiece”, and another reported a player who never took damage. I’ve been scouring the code, and haven’t found any holes which would enable this kind of cheating, but I’d love to hear if anybody has found a way. If you find a way for players to cheat or crash servers over the Internet in Unreal, please email mailto:[email protected]. The first person to report a particular security hole in Unreal will receive credit and thanks here for helping to protect the Unreal community from cheaters. People who cheat in Deathmatch are lamers, but people who are motivated by simply discovering ways to cheat are doing valuable research. Note: I don’t consider the following things Unreal cheats: • Server administrators cheating on their own server. Since the admin is in control of the server, there are many ways he could dis11
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 spoofing, and so on. These aren’t Unreal-specific cheats, and I can’t stop them.
2.1.2
UnrealScript Notes
There was recently a ”to script or not to script” debate about the merits of UnrealScript vs pure C/C++. In this debate, several misconceptions were put forth, which I want to correct: 1. UnrealScript replicated functions (described in the http://unreal. epicgames.com/Network.htm) indeed return instantly, rather than blocking execution while waiting for network acknowledgement. Function calls are sent across the network using an asynchronous RPC-like approach, and are executed upon reception. They can either be sent wih guaranteed delivery and sequencing (by using the ”reliable” keyword), or without sequencing (using ”unrelible”). Unreliable replicated functions are most efficient, and should be used for non-vital events like hearing sounds. If one were to assume UnrealScript functions were synchronous and blocking, one would indeed draw incorrect conclusions such as this statement: ”That must make AIs in multiplayer games really fun, they fire at you and do an RPC, then freeze until they get a ping back from the client.” 2. As our licensees know, UnrealScript classes and C++ classes fully interoperate. You can derive C++ classes from UnrealScript classes, and vice-versa. For all actor classes, running ”Unreal.exe -make” automatically parses the UnrealScript classes, and generates C++ stubs for them, including:
2.1. OCT 13, 1998
Tim Sweeney Archive
13
News
• C++ variable declarations mirroring the UnrealScript ones, allowing variables to be accessed identically in either language. • C++ -> UnrealScript calling stubs, enabling C++ functions to call into UnrealScript functions. • UnrealScript -> C++ calling stubs, enabling UnrealScript functions to call into C++. Indeed, we invested a lot of effort into providing dual programming interfaces, enabling seamless sharing of objects and code between the two languages. Among other things, I studied COM, MFC/VB/ActiveX, CORBA/IDL, and JNI in order to determine the most efficient and least error-prone methods of cross-language programming. There is a lot of great research material on the net, for those who are interested. I suspect that people who have a low opinion of mixed-language programming have likely drawn their conclusions from JNI and CORBA/IDL which do indeed involve a lot of messy handle/id references and error-prone redundent declaration of objects. It doesn’t have to be this way. For an example of ”cross-language programming done right”, check out the ActiveX support in Microsoft Visual J++ and Visual Basic – they’re ultra-clean, automatic, and they involve no redundency. MFC also does a pretty good nearly-automatic job of cross-language ActiveX object handling. Mixed-language programming can be very fruitful, if it’s implemented properly. 3. Unreal performs all file loading and saving using serialization. Serialization is automatic for objects defined in UnrealScript. For objects and structures defined only in C++, such as the following function that serializes a vector. friend FArchive& FVector::operator<<( FArchive& Ar, FVector& V ) { return Ar << V.X << V.Y << V.Z; }
For programmers just learning about object-orientation, a mustread is: http://www.amazon.com/exec/obidos/ASIN/0201633612/o/
2.1. OCT 13, 1998
Tim Sweeney Archive
14
News
qid=908310340/sr=2-1/002-5033601-8164246 (Addison-Wesley Professional Computing) by http://www.amazon.com/exec/obidos/Author= Gamma,%20Erich/002-5033601-8164246, http://www.amazon.com/exec/ obidos/Author=Helm,%20Richard/002-5033601-8164246,
2.2 2.2.1
Oct 14, 1998 Network Objects Follow-Up
I’ve chatted with several people lately who have added insight to the discussion of multi-language programming and networking. One interesting topic mentioned was using the CORBA protocol to coordinate network games. CORBA is a high-reliability protocol with a fairly high amount of overhead and latency, due to its exacting nature and use of TCP. I see CORBA as a very suitable protocol for network game backbones. For example, if you were doing an Ultima Online style world with multiple servers that stay in synch, CORBA would be good for linking servers together in a high-reliability, non performance-critical way. But, CORBA isn’t suited for an actual realtime modem-based gameplay protocol, since it’s TCP based (which adds terrible lag under lossy conditions), and the protocol has enough overhead that it’s not going to be able to handle large amounts of data over the modem.
2.2.2
AWT
http://unrealscript.net/AWT/ is a graphical user-interface layer for UnrealScript, which has been making some cool progress lately.
2.2.3
Cheat Challenge Update
I’ve received a bunch of tips from two Unreal enthusiasts. Congratulations go to Mek @ PlanetUnreal and RisingSun for discovering and verifying two holes in Unreal, and to Mike Lambert for suggesting a potential 2.2. OCT 14, 1998
Tim Sweeney Archive
15
News
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.
2.2.4
Another Public Master Server
This just in: How about a mention of the OGN Public Unreal Master Server? It’s been available for almost two weeks and has no access restrictions, bandwidth or otherwise. The server is running @ master.ogn.org:27500. Server lists can be retrieved @ http: // master. ogn. org: 6669/ list/ game/ unreal . A page describing how to link to it can be found @ http: // www. ogn. org/ UnrealMaster – sky G. http: // www. qhunter. com/ http: // www. golightly. org/ http: // www. aurorablue. org/
2.3
Oct 22, 1998
2.3.1
Linux Unreal
http://www.linuxgames.com/ has reported a way to run the existing version of Unreal under Linux, using the Wine Windows emulator for Linux. They’ve included a screenshot and more information at this http://www. sgic.fi/~tj/unreal.html page.
2.3. OCT 22, 1998
Tim Sweeney Archive
2.3.2
16
News
Hired Guns
Want to see something cool and unique that’s being done with the Unreal 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 preview).
2.4 2.4.1
Oct 24, 1998 Almost there...
The latest Direct3D support is now integrated into the Unreal codebase. It will be in the upcoming 218 patch in ”public beta” form. It hasn’t gone through wide testing yet, but we and our partners have been testing it a lot internally on Windows 95 and 98. It’s looking good on the nextgeneration 3D cards (Riva TNT, Matrox G200, Savage 3D), though highlevel optimizations are planned that will boost performance further. The Voodoo2 multitexture code is in, thanks to the efforts of Jack Mathews at 3dfx. I’m doing some final Internet play testing and tweaking on the patch. My ”torture test” environment is an ISP connection at 24.4K with 400 msec ping. If it’s playable on that, it should be playable on anything. :) Yesterday’s testing revealed a few last-minute problems that I’m working on now.
2.4.2
More discussion on CORBA
mailto:[email protected] provided this insight into CORBA with respect to realtime apps: 2.4. OCT 24, 1998
Tim Sweeney Archive
17
News
In general, CORBA causes too much overhead and latency to be a server/clients gaming protocol. This is due to IIOP’s (the default inter-ORB protocol) use of TCP/IP, and the use of large packet sizes (compared to the dedicated bit-tuned gaming protocols being used in, for example, Quake2 and Unreal). Though support for IIOP is mandatory, an ORB vendor can deploy more efficient (or more secure) protocols between ’his’ ORBs, optionally using other network protocols. By default, CORBA calls are synchronous (that is, the calling object is blocked until a response is received from the called object). Such a connectionoriented call is best implemented using TCP. CORBA also supports so-called ’one-way’ operations, that enable the caller to continue processing immediately after making the call - the call is non-blocking. Here, it might make sense to use UDP as an underlying protocol, provided you deal with the unreliability at the application level (the ’call’ might not arrive at the client). Some specialized high-performance ORBs, such as Nortel’s RCP-ORB, < http://www.nortel.com/RCP-ORB/> , use other transport protocols than TCP for one-way calls. Most ORBs implement optimized mechanisms for ’intra-server’ and ’intra-process’ communication (not that relevant for multi-player gaming). I’ll post more thoughts on the topic in the future. With Unreal, distributed object models are already playing a role in multiplayer gaming, but only in a ”tip of the iceberg” sort of way. This kind of technology will expand very interestingly in the future.
2.5 2.5.1
Oct 25, 1998 Geting closer...
We’re gearing up for a big internal test session with 218 right now. The release date of the 218 patch will depend on the outcome. Note that 218
2.5. OCT 25, 1998
Tim Sweeney Archive
18
News
is not network-compatible with 217, so if you see our 2 test servers in GameSpy, please don’t try to join (you won’t be able to).
2.6 2.6.1
Oct 26, 1998 Direct3D Drivers
To use Unreal’s Direct3D support, you must have http://www.microsoft. com/directx/download.asp installed. You also need the latest Direct3D driver from your 3D hardware maker. Because Unreal uses many new Direct3D features, many hardware makers had to update their drivers for Unreal to work. Therefore, some of the drivers distributed with DirectX 6.0 have problems with Unreal (crashes or visual anomalies). Here are driver download sites for various brands: • http://www.3dlabs.com/drivers/ Permedia • http://www.3dfx.com/developers/drivers.html Voodoo, Voodoo Rush, Voodoo2, Voodoo Banshee • 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.nVidia.com/home.html Riva 128 (known problems), Riva TNT • http://www.rendition.com/download.html Verite • http://www.s3.com/bbs/0main/topindex.htm Savage 3D • http://www.trid.com/trident/html/DRIVERS.HTM (untested, probably doesn’t work) • http://www.nine.com/support/drivers/index.html (untested, probably doesn’t work) 2.6. OCT 26, 1998
Tim Sweeney Archive
19
News
Please keep in mind that Unreal’s Direct3D support is an early beta and isn’t yet working reliably on all 3D hardware.
2.6.2
Known Issues
I’ve update the list of http://unreal.epicgames.com/Bugs.htm, summarizing the problems people have found with 219. There are a bunch of items, but most are non-showstoppers. I’m working on them now. Overall, though, 218 is by far the best-received version of Unreal to date! New servers are popping up rapidly (50% increase in the past 18 hours), with player counts rising even faster.
2.6.3
Unreal 218 Gaining Support
After releasing the patch at midnight Sunday night, it was amazing to see how many Unreal servers had it up and running in less than an hour minutes. It will be interesting to watch new Unreal servers spring up on the net now that our Internet play quality is under control. In the not-too-distant future, we’ll have many more improvements in Unreal network play: performance enhancements, new features requested by the community, and several cool upcoming surprises. GameSpy currently shows 27 Unreal servers, and a couple thousand for Quake. Clearly, we got off to a very slow start while we learned the the ins-and-outs of Internet game programming; now Unreal is on a solid footing and we’re really beginning to pick up the pace! Level designers in the Unreal community have already started producing some great Deathmatch maps (see http://www.freshmeat.org/unreal/ for downloads), so we expect to see things accelerate in this area, too.
2.6. OCT 26, 1998
Tim Sweeney Archive
2.6.4
20
News
PlanetUnreal performance survey
If you’re using the new 218 patch, please fill out http://www.planetunreal. com/ Unreal performance survey. We’ll be watching Unreal players’ feedback in the survey, and looking at all the 218 bug reports sent to the mailto:[email protected] account. Everyone’s feedback will be taken into account for future improvements to the Internet play and other features.
2.6.5
More about 3D API’s
In an interview on http://www.voodooextreme.com, I gave my opinion in the ongoing OpenGL vs Direct3D debate, and I wanted to add some more information here. First of all, both our DreamForge partners working on the OpenGL support, and our Direct3D partner have both done a very high-quality job, given the constraints of Unreal and the 3D card drivers available. My feelings on the two 3D standards are based completely on their API’s and the quality of drivers available. Next, I wanted to give some more detail on the code. API support layer 3dfx Glide Direct3D NEC PowerVR OpenGL
Lines of C++ code 1711 3123 4049 5697
Now, the Glide is the simplest, because it’s aimed at the Voodoo family of 3D cards, which are very standard and straightforward to support. For programming to 3dfx cards, Glide is the ideal API. For people thinking ”If Glide is so great, why don’t other 3D cards support it?” The short answer is, if Glide supported other manufacturer’s 3D cards, it would pick up all the complications involved in real-world Direct3D and OpenGL programming: Testing for core capabilities, working around driver bugs, etc. 2.6. OCT 26, 1998
Tim Sweeney Archive
21
News
The Direct3D code is next in simplicity. It began as a working 1600 line driver, then expanded as it was optimized and support was added for 3D cards that lack key features. The Direct3D API follows the traditional Microsoft model of being not very beautiful code, but dealing with realworld hardware robustly, by providing a capability-querying mechanism and well-tested drivers. The PowerVR code is large because the PCX2 chip’s rendering approach is very different than what Unreal was designed for. This makes the implementation fairly complex, though the next-generation PowerVR, currently on-hold in the PC market while NEC focuses on the Sega DreamCast, is a great chip that’s more traditional in its architecture, and more optimal for Unreal. The OpenGL code is large because of optimizations and support for lots of real-world hardware. If reduced to plain-vanilla OpenGL, this would probably be the simplest and most stable driver of them all, because the OpenGL API is very straightforward.
2.6.6
Unreal 218 Patch is ready!
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 overseas modem players) reported major success with the performance improvements. 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.
2.6. OCT 26, 1998
Tim Sweeney Archive
2.7 2.7.1
22
News
Oct 28, 1998 Latest Happenings
Since the Unreal 218 patch was released, the number of Unreal servers showing up in GameSpy has increased by 225%. A huge thanks to everyone who is running Unreal servers now. It’s awesome to see the community grow and begin to reach critical mass. At any time, about 20% of the servers listed in GameSpy are shown as ”Not Responding”. I’ve been looking into this, and there are three reasons for this. One, the server has been shut down or crashed but hasn’t timed out and been removed from the list. Two, the server is switching levels, which prevents it from responding to GameSpy queries for 5-20 seconds. Third, the server is shown in GameSpy because a user running a LAN server (dedicated or non-dedicated) enabled the ”DoUplink” option to publicise their server to the world without realizing the consequences, but either exited or is on a LAN blocked off by a firewall. We’ll work with the GameSpy guys to adjust the timeouts so that fewer ”Not Responding” servers are listed.
2.7.2
Status of Direct3d - All Drivers
Some issues across-the-board with switching between fullscreen and windowed mode, and switching resolutions during gameplay. We’re looking into theses issues.
2.7.3
Riva TNT
Has lots of potential, but there are major problems with their Direct3D driver: rainbow colors, time-lag, w-buffering issues, missing textures. We are hoping nVidia will issue an updated driver soon. The ball is in their court now. 2.7. OCT 28, 1998
Tim Sweeney Archive
2.7.4
23
News
Riva 128
Their latest driver should run Unreal OK. The framerate isn’t very good, and there will be a lot of ”stuttering” since texture downloads are very slow on this hardware. Some users are reporting that creature polygons appear corrupted. Hopefully nVidia will fix thie error in their driver.
2.7.5
Intel i740
There are some problems with their currently-available Direct3D driver, but they have an internal beta driver which fixes many problems. Hopefully this will be ready for the public soon.
2.7.6
ATI Rage Pro
They have a beta Direct3D driver which runs Unreal pretty well (though it doesn’t appear to be available for public release yet). Multitexturing currently isn’t working with Unreal, because of a hardware limitation (it can’t multitexture a paletted base texture map along with a non-paletted light map).
2.7.7
3dfx Voodoo2
There isn’t any reason to use Direct3D for Voodoo2, since we support Glide natively and that tends to be more stable and faster, but their latest Direct3D driver does run Unreal pretty well. Their detail texture blending (D3DBLEND DIFFUSEALPHA) doesn’t work, which breaks detail textures. There are reports of missing lightmaps in some areas (not sure what’s wrong). 3dfx could get a performance increase here by implementing subrect Blts and hardware triangle-fan setup.
2.7. OCT 28, 1998
Tim Sweeney Archive
2.7.8
24
News
S3 Savage 3D
Works well with their internal beta Direct3D driver. Not sure when this will be available via the web.
2.7.9
Matrox G200
Works pretty well.
2.7.10
Rendition
Works pretty well.
2.7.11
Permedia
Only supports monochrome lighting due to blending limitations. Explosions are displayed with a black background (due to a bug in the current Unreal code). Fairly slow texture downloading – performance isn’t great.
2.7.12
Drivers we consider playable, in best-to-worst order
• Voodoo2: Fastest of all. • Savage/G200: Reasonable performance. Not as fast a fill rate as Voodoo2, but texture downloads are fast, and they support palettes, making for a steady frame rate. • Rage Pro/Rendition: Reasonable performance. High display quality in truecolor mode. The others should be playable pending public release of improved Direct3D drivers for their hardware. 2.7. OCT 28, 1998
Tim Sweeney Archive
25
News
On Permedia, Riva 128, and Rendition, you may get better performance using Unreal’s software renderer, especially if you have a Pentium II class processor. This isn’t such a bad thing, because the software renderer supports all of Unreal’s key features, including truecolor lighting and volumetric fog.
2.8 2.8.1
Oct 30, 1998 Unreal 218 patch information (RTFM!)
If you downloaded the 218 patch, please http://unreal.epicgames.com/ versions.htm. If you’re still experiencing problems with Unreal on your modem connection, you need to use the NETSPEED command described there, so that Unreal doesn’t try to use more bandwidth than you have available.
2.8.2
Resources for Server Administrators
Here are some resources to aid new Unreal server administrators in getting up and running: • http://unreal.epicgames.com/Master.htm: How to get listed in GameSpy and other querying tools (new). • http://unreal.epicgames.com/ServerTips.htm: Basic information about running an Unreal server. • http://megaboard.epicgames.com/: New ”Server Administration” forum. Steve Polge, Brandon Reinhart, and I will be answering questions from server administrators and people writing server-querying tools.
2.8. OCT 30, 1998
Tim Sweeney Archive
2.8.3
26
News
Unreal Multiplayer Ramp-Up
A lot of news sites have been picking up on Unreal’s multiplayer improvements: • http://www.next-generation.com/ • http://www.bluesnews.com/ • http://www.voodooextreme.com/ The number of public Unreal servers listed in GameSpy is now up to 51 as I write this, and has been growing at a rate of over 20% daily. While working on the upcoming 219 patch, I’ve been spending a couple hours each day playing Unreal online, especially on the servers running usercreated levels. The community has made some really impressive levels, and I’m glad to see that a lot of servers are now making use of downloadable levels, textures, sounds, and music.
2.8.4
Other Servers
In addition to the public servers listed in GameSpy, there are 14 extremely high quality, public servers on http://www.won.net/unreal listed in their own web-based ”server finder” site. I should also mention our other online partner, http://www.mplayer. com/action/games/unreal/, and the http://www.mplayer.com/action/unreal/ news site on MPlayer. -Tim
2.8. OCT 30, 1998
Tim Sweeney Archive
2.9 2.9.1
27
News
Nov 01, 1998 Unreal Grows...
More public servers keep popping up every day. Awesome! I noticed that the percentage of servers shown as ”not responding” has gone up, though I’m not sure whether that’s due to server crashes, or people accidentally having their LAN server listed in GameSpy when it’s not meant to be public. Server admins, if your server crashes unexpectedly, please email your Unreal.log file to mailto:[email protected] so we can investigate it. A reminder, server administrators can get help in the new ”Server Administration” forum on the http://megaboard.epicgames.com/. According to the feedback we receive, and in http://www.planetunreal. com/’s survey, 218 has fixed the past network problems and made Unreal playable on the Internet for the large majority of people. Still, we have lots of improvements in the works, which will further increase the game’s smoothness and responsiveness during network play, as well as a few new features that I’m not allowed to announce yet. :) The next patch, 219, will be purely bug fixes to 218 (no speed difference). After that, 220 will contain some more high-level improvements to many areas of the network code. Currently, there seem to be two sets of people who are still having some problems with Unreal on the Internet. One set has 28.8K-33.6K modem connections that experience an unusally high amount of packet loss. 220 should improve this a bit, but when you have upwards of 20% packet loss, gameplay is bound to suffer. The other set of problems is being reported by people with some unusual connections we haven’t been able to test on internally: people with dual simultaneous modem connections, people with connections that receive via satellite and send via modem, and some similar configurations. I haven’t determined what’s going wrong in these cases yet, but I suspect packet-order problems.
2.9. NOV 01, 1998
Tim Sweeney Archive
28
2.10
Nov 02, 1998
2.10.1
Unreal 219!
News
It’s now available for download http://unreal.epicgames.com/Versions. htm. The Epic Deathmatch servers will be shut down for the night, to provide more bandwidth for downloads.
2.10.2
The testing is going well
Ok, ok, you can stop now, that’s enough testers. :) Server performance has definitely improved since I last benchmarked it. My dual-processor Pentium II-300 is serving a 20-player game, copying 600 megs across the network, and running a 3dfx Unreal client at 800x600. The server is keeping up a steady 15 fps. I have more optimizations planned, though. On my 28.8K connection, gameplay has remained pretty smooth until I get into a firefight with 5-6 people, at which point the movement of other players starts to become unsmooth. We should be able to improve this significantly further in 220, with two protocol improvements. First, I’ll be improving the scheme for managing temporary objects like projectiles, which should reduce their bandwidth usage by around 30%. Second, Steve Polge and I working out a new variable priority predictor/corrector scheme for transmitting the movement of other players.
2.10.3
Testing 219
I have an Unreal 219 server up and running at unreal://208.212.53.3/ in case a few people want to help test. You can join in and play with 218; it’s fully compatible. 219 should be available soon, unless new bugs are discovered.
2.10. NOV 02, 1998
Tim Sweeney Archive
29
2.11
Nov 10, 1998
2.11.1
Latest News
News
The latest http://www.planetunreal.com/ survey shows a significant gain in gamers’ satisfaction with the latest 219 patch, compared to the previous ones. We’re now hammering on version 220, which includes significant new Internet play improvements, plus some core game improvements that the rest of the team has been working on. 220 won’t be out this week, but should be ready soon after. There seems to be one Internet problem in 219 that is affecting 10-15% of players. I haven’t figured out the cause yet, but the symptom is a ping time (visible with STAT NET) that swings around wildly, going from 200 to 1000 or more over the course of several seconds. Many of these players report that other games like Quake 2 don’t exhibit the problem–which indicates it’s not just a bad connection or ISP. I suspect packet-ordering problems, though I haven’t been able to duplicate it here.
2.11.2
The Roadmap
In the remainder of 1998, we will be releasing: • Unreal 219: Latest version. Download http://unreal.epicgames. com/Versions.htm. • Unreal 220: Further Internet improvements, core game improvements, bug fixes. • Unreal 221: Incremental fixes • Unreal 222: Offical (non-beta) patch; shareware version will be released. • Additional patches as necessary.
2.11. NOV 10, 1998
Tim Sweeney Archive
30
News
We also have some cool things in the works for 1999. Since Unreal first shipped, I’ve been working on Internet improvements and bug fixes, while the rest of the team has been working on a top-secret project we are referring to as ”Unreal Tournament”. There have been a lot of rumors and speculation about what this project will be. Some of the rumors are completely incorrect. For example, we are not using any alien technology recovered from crashed spaceships on Tournament. (We’re saving that for our next project). I’m also working on the new, enhanced UnrealEd, with lots of new features, improved stability, a plug-in interface, and other goodies. We don’t have a date for this, but I’m expecting a public beta around new years, with final release early in 1999. At some point, we’ll be publically releasing Unreal’s C++ interface so the community can start on .dll plug-ins for Unreal and UnrealEd. This will happen no later than the new UnrealEd public beta. It might be possible to release it sooner, however there are changes in the works which won’t be binary compatible, so user-created .dll’s would break and need to be recompiled. What can you do with Unreal .dll’s? Lots. Here are some examples: • Define new kinds of algorithmic textures that can be created in UnrealEd and used in levels. • Expose anything you can do in C++ to UnrealScript, for example the file system, ActiveX, more Internet functionality, etc. • Write performance-critical game support routines, such as AI. While it’s also possible to write game code directly in C++, the preferable way to do that is UnrealScript, since there is already a lot of game support infrastructure built into the language.
2.11. NOV 10, 1998
Tim Sweeney Archive
2.11.3
31
News
Server Administration
Remote server administration isn’t working in 219, but will be addressed shortly. 219 does have a few new features for local server administration. While running a server, click on the Unreal server icon and choose ”Show log window”. In the log, you can type: • SERVERTRAVEL < levelname> : Jump to a new server. • SAY < message> : Broadcast a message to all users. -Tim Sweeney
2.12
Nov 19, 1998
2.12.1
Unreal 220 Internet Improvements
I’m now down in Raleigh, North Carolina with the rest of the Unreal team. Things are really coming together for the top-secret project we’re working on, and Unreal 220 is starting to solidify. We don’t have a release date yet, but it could be as early as next week. The Internet play improvements in 220 are quite noticeable. Steve and I are using a new physics prediction scheme based on motion compensation. This improves the smoothness of other players’ movement in deathmatch games, especially in large, open levels like DmDeck16, where lots of players are visible. Steve has redesigned the moving brush code so that moving brushes now are now handled client-side. Platforms and doors are very smooth now. Finally, I’ve created a new scheme for managing temporary actors like projectiles, which reduces their bandwidth by about 30%. Steve and Brandon have also added a lot of other improvements, such as showing ping times, server name, and level name in the player list, showing the name of opponents when you point the crosshair at them in 2.12. NOV 19, 1998
Tim Sweeney Archive
32
News
a network game, a beep when chat messages come in, and color coding of messages.
2.12.2
Unreal Editor Progress
I’ve also been working on the new Unreal Editor, featuring a user-interface rewrite (moving over to C++ from Visual Basic). It’s now more than halfway 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.
2.12. NOV 19, 1998
Tim Sweeney Archive
2.12.3
33
News
Web Site Notes
A request of web sites providing collections of Unreal related files, such as the cool http://www.freshmeat.org/unreal/ page: Please link to the official http://unreal.epicgames.com/Versions.htm 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 http://unreal.epicgames.com/Versions.htm page, users are more likely to get the latest patch. Thanks! Cool Unreal related things I’ve seen recently... • http://unrealnation.com/unloaded/, a great ”overhead view” mod including some custom levels. It feels a lot like the classic arcade game Gauntlet. • http://www.astro.uni-bonn.de/~cloewe/unreal/, a totally cool stats tool for server administrators. • http://www.unrealed.com/ has grown to contain more and more useful UnrealEd resources.
2.12.4
Unreal mod notes
Mod developers who get the cryptic ”sandbox” error when trying their mods in network play: This error means you have a .upkg file that says server-side-only because you copied the one from IpDrv.u (which is SUPPOSED to be server-side-only). This usually prevents the mod from working, but sometimes just causes actors defined in the mod to not be visible to players. If you don’t have a .upkg problem, you won’t have a problem. If you do have a .upkg file, it should read: [Flags] AllowDownload=False ClientOptional=False ServerSideOnly=False
2.12. NOV 19, 1998
Tim Sweeney Archive
34
News
-Tim Sweeney
2.13
Dec 10, 1998
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.
2.14
Dec 11, 1998
Here is the http://unreal.epicgames.com/ReadMe220.htm 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.
2.15
Dec 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:
2.13. DEC 10, 1998
Tim Sweeney Archive
35
News
• ”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
2.15. DEC 12, 1998
Tim Sweeney Archive
36
2.16
Dec 14, 1998
2.16.1
Hard at work
News
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 networkrelated 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 backwardscompatible. 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 2.16. DEC 14, 1998
Tim Sweeney Archive
37
News
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.
2.16.2
That’s UnrealEd.net
The cool independent Unreal editing site I mentioned is actually http: //www.unrealed.net/, not UnrealEd.com.
2.17
Dec 15, 1998
2.17.1
Unreal Networking Code: Status
Unreal 220 incorporates the majority of the low-level bandwidth optimizations I’ve been planning for Unreal 1 and Unreal Tournament. I was just looking back at the initial shipping version of Unreal and comparing packets, and realized that we’ve achieved a bandwidth usage improvement of over 250% in both directions. This doesn’t mean we’re going to stop now...there are some minor protocol improvements planned, and also high-level game play optimizations that Steve and Brandon are working on, moving more logic to the clientside 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 http://unreal.epicgames. com/Network.htm, it was simultaneously praised for being a powerful and very general framework, and flamed because Unreal’s initial Internet play 2.17. DEC 15, 1998
Tim Sweeney Archive
38
News
performance was below gamers’ expectations. The critics were delighted to claim, ”this networking engine is a Grand Scheme that will never perform well in the real world”. They sure were wrong! Iit turned out that all the performance bottlenecks were in the low-level protocol, and were all completely fixable given sufficient R&D time. It took a lot of hard work to identify all of the inefficiencies in the protocol and come up with solid, general solutions. The key problems in game networking are data compression, error correction, and latency reduction. They turn out to be mutually opposing: • Standard data compression schemes (i.e. Huffman and arithmetic coding) work best when you have a large, well-known compression window, and large symbol tables. Sending symbol tables isn’t practical when you have a low-bandwidth, high-latency connection, and when your window history is questionable due to transmission errors. • Error correction schemes are tough to implement when you have low-bandwidth, high packet loss conditions (for example., most gamers’ modem-based Internet connections!) I went through 6 separate error correction schemes in Unreal, 5 of which all fell apart in various conditions. One big trap is getting into a feedback loop that saps away bandwidth and increases ping times. Another trap is retransmitting time-sensitive data when it gets lost, causing lag. These issues are tricky in bandwidth-intensive action games, because you need to support multiple tiers of reliability in packets, and some level of sequencing between them. • Latency reduction is another tricky issue, because of the way modems queue data: The larger a packet is sent, the more latency is induced in the buffering scheme. So, you want to send small packets to keep latency down. But, UDP packets have significant built-in overhead, so you want to send large packets to keep bandwidth up. In the end, I opted to go with several a custom bit-encoding compression scheme, which adapts itself to the type of data being sent, and intelligently crams it into the least amount of bits possible. This has worked 2.17. DEC 15, 1998
Tim Sweeney Archive
39
News
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 packetloss 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 http://unreal.epicgames.com/Network. htm document. Unreal 1 networking can be described simply as ”a small 2.17. DEC 15, 1998
Tim Sweeney Archive
40
News
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 nextgeneration engine, I’m going to experiment with a lot of new networking configurations. For example, the protocol could be used for a server-toserver 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
2.18
Dec 18, 1998
2.18.1
Unreal Tournament notes for mod authors
I’ve had several inquiries from mod makers about how hard it will be to ”port maps and mods from Unreal 1 to Unreal Tournament”. The answer is, port? What’s this talk of porting? This stuff just works. Steve Polge put a lot of effort into updating the Unreal 220+ game code so that it integrates seamlessly with Unreal Tournament. Both products install into the \Unreal directory, and are mutually compatible. So, you can install one, the other, or both – and existing maps and mods which are compatible with the latest version of Unreal, will be fully compatible. For convenience, Unreal Tournament ships with all of the script packages from Unreal 1 (including UnrealShare.u and UnrealI.u), all of the .utx files, and all of the .uax files. Unreal Tournament is a superset of the Unreal 1 with the exception of the Unreal 1 maps and music. All new UT content (lots of scripts, textures, sounds, game types, and new actors) are 2.18. DEC 18, 1998
Tim Sweeney Archive
41
News
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
2.18. DEC 18, 1998
Chapter 3 1999 News 3.1 3.1.1
Jan 01, 1999 Happy New Year
The team is now getting back together from the holiday and we’ll get back to Unreal 221 development first thing tomorrow (Saturday). We were on the verge of releasing the patch right before Christmas, but we’re now back to being a few days away, since I added some new features that need re-testing, and some additional bugs have been found. For me, the holidays were fun and productive. I hauled my computer up to Maryland for a one-week visit with my parents, and that provided a good excuse to work on engine improvements and new R&D in a zerodistractions environment. Without getting to deep into the details, here are some of the things I worked on: • Unicode Unreal. I finished up 16-bit Unicode support; now the Unreal code base can be recompiled for the ANSI (8-bit) or UNICODE (16-bit) character sets. This has several advantages. First of all, localizing a game for non-Roman languages (such as Japanese, Chinese, Korean, Hebrew, Arabic) is easy with Unicode. Second, we’re really interested in Windows CE, and that is a pure Unicode 42
Tim Sweeney Archive
43
News
OS. Windows CE is the native operating system of the Dreamcast, so Unicode is a natural stepping-stone along the Dreamcast porting path which we’re exploring. Windows CE is also used in tons of palm-top computers. Now, none of these palm-top computers are currently interesting from a gamer’s perspective, but if you extrapolate their grown–in terms of video resolutions, RAM, and processing power–along a Moore’s Law curve, they’re not that many years away from being comparable to low-end Pentium II PC’s today. I like to think that the GameBoy’s of the future won’t be a closed platform, but rather run a standardized OS like Windows CE. All Unreal data files are ”character set neutral”, meaning they can contain any mix of ANSI and Unicode characters, and they’re automatically converted/truncated at load time. Network play similarly ”just works” between the Unicode and non-Unicode versions. Regarding Unicode font issues (”who’s going to paint all those Japanese characters?”), Jack Porter has built a TrueType font importer into UnrealEd, which converts any Windows TrueType font to an Unrealcompatible font bitmap. This is an essential part of our Unicode efforts, but also ties into the new user interface he and Brandon are building for Unreal Tournament. There are lots of Unicode fonts with support for nearly all Windows-supported languages, so localizing games into all languages should be fairly painless. • Data compression. I spent a couple days experimenting with various compression schemes and found some interesting results. First of all, it’s fairly easy to achieve PKZIP-quality compression–the algorithms are well documented and easy to implement. Second, it’s nearly impossible to beat PKZIP by much of a margin. Beyond the standard algorithms (Huffman and LZH compression), I experimented with many variations, including: – ”Double” Huffman-compressing each character in a file then recursively merging compressed regions together into spans, with the goal of compressing ”different types of data” with different encoding tables. This approach came out neutral: there were huge gains in compression, but they were offset by having to store lots of Huffman tables.
3.1. JAN 01, 1999
Tim Sweeney Archive
44
News
– Trying Huffman compression in bases other than 2 (such as 3, 5, and 7): no overall gains. – ”Infinite sliding window”: An LZH-style scheme that spends a huge amount of CPU time on compression by analyzing an entire file for differences. Here, the gain was typically 10%, but it was unbearably slow to work with. – Arithmetic encoding. This is a Huffman-style scheme that employs some basic number theory to generate a compression table using arbitrary bases (other than base 2). This gets real gains of around 10% compared to Huffman, but is much slower to decode because it relies on arbitrary-precision integer math. I didn’t get the compression code into the Unreal master source (it was standalone R&D). I’m considering supporting compression for client-downloadable files in Unreal Tournament, to make it easier to go onto servers running custom maps. My most usable compression scheme got 4:1 compression on .unr and .u files (nice!) but no significant compression on textures and sounds. Unreal’s textures compress poorly for an interesting reason: they are already stored using palettes, which are a form of compression. Furthermore, the process of generating an optimal palette for an image yields an array of bytes which are distributed near-uniformly, which is the worst possible case for variable-code-word compression. I think the state-of-the-art in texture compression will be S3’s real-time S3T/DXT scheme, which is fairly lossy, but optimal for real-time decompression while rendering. And it’s 6:1 for all possible kinds of data. One interesting technique I played around with for texture compression is wavelet compression. The 2D wavelet scheme for textures is quite similar to mipmaps: to oversimplify a lot, you represent an nxn image as a sequence of 1x1, 2x2, 4x4, 8x8 ... nxn. Each bitmap is stored as ”signed differences” relative to the lower-res versions of the bitmap. Wavelets are a good starting point for lossy compression schemes, because the ”most visually noticeable” details are in the low-res bitmaps, and in the high-frequency portions of the high-res ones. So, it’s fairly easy to filter out unimportant details and compress what remains. Wavelets are also nice because 3.1. JAN 01, 1999
Tim Sweeney Archive
45
News
you can generate all your texture’s mipmaps from a single wavelet without any overhead. While I don’t think wavelets will play a role in our future texture-mapping plans, they look more useful as a way of storing and manipulating height maps and displacement maps. Wavelets provide a very efficient, ”level of detail”-aware form of storing 2D surface geometry. • 3D API’s. I spent a few days learning the basics of curved surface rendering, which turned out to be very interesting. I was going to do my research with Direct3D (under Windows NT 5.0 Beta 3 RC0) but the 3D hardware support isn’t quite there yet, so I took the opportunity to learn OpenGL using the software rasterizer and 3dfx’s OpenGL minidriver. Both renderers were extremely stable and easy to use. To my amazement, I never experienced a ”blue screen of death” or had to reboot–quite a difference from my past work with Glide and Direct3D! (Note: I haven’t been very closely involved in the Unreal Direct3D and OpenGL support, which has been developed by our partners, so this is my first really in-depth experience).OpenGL’s approach to window management turns out to be extremely simple and reliable. I went from zero to having a spinning cube up and running in under 30 minutes. The tools GL provides for polygon drawing are extremely simple and powerful. For just drawing a few lone polygons, glVertex() and its associated functions are super-easy. For drawing complex meshes, GL’s approach to providing separate client-side arrays for vertices, colors, and texture coordinates is very easy and efficient for multi-pass rendering, since you can swap out one table (say, texture coordinates) without affecting the others. OpenGL’s texture approach (glTexImage2D and glBindTexture) are also very simple and powerful. I remember back under DirectX5, trying to upload a texture to hardware. I spent 4 hours trying to figure out the code and rebooting my computer as it repeatedly locked up. I spent less than 15 minutes figuring out OpenGL texturing and implementing it. Comparing both API’s texturing approaches, OpenGL’s texture management is absolutely the right way to go. – It’s extremely foolproof–you call 3 textures to create, upload, and delete textures. Nothing can possibly go wrong! 3.1. JAN 01, 1999
Tim Sweeney Archive
46
News
– There is no bizarre/mysterious emulation going on. For example, in Direct3D you can modify a texture by Lock()ing it and writing to ”video memory” directly. But, on some hardware (like the Riva TNT), the hardware stores textures internally in a ”swizzled” format you can’t access directly. So some emulation thing has to go on behind the scenes where multiple copies of the textures are maintained and copied around. – OpenGL hides the inner details of texture management from the app, enabling the driver to be optimized for whatever style of texture management is best for a particular 3D card. In OpenGL, a driver writer has total control over texturing and can optimize the hell out of it. In Direct3D, the API hides the application from the hardware and vice-versa, which makes it impossible for a game or a hardware driver to implement good texture caching. Here’s a link to http://www.opengl.org/ and http://www.microsoft. com/directx. • Curved Surfaces. I became familiar with a bunch of different techniques. Curved surfaces pose the same kind of dilemma I felt when writing Unreal’s software renderer: there are lots of mutually incompatible approaches to choose from, but no really clear favorite. Each technique has some desirable strengths, but no technique combines them all.My first experimentation was with bicubic bezier patches, which are a great primitive for building curvy shapes without holes between patches (as with polygons, continuity can be guaranteed by having adjacent patches share vertices and control points). However, they require a fair amount of math for tessellation and, though continuity can be guaranteed, it’s hard to join patches together smoothly (with a continuous normal vector across adjacent patches), especially during animation. I’m pretty sure these will be a key primitive in the next-generation engine. Beziers are very intuitive to model with. The tensor-product math for bicubic bezier quad patches can easily be modified to enable ”bicubic bezier triangles”, which can share edges continuously with quads. I haven’t been able to find any references on this, but I derived the math, and it seems to work. 3.1. JAN 01, 1999
Tim Sweeney Archive
47
News
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
3.1.2
Other Updates
• We updated and coolified the http://unreal.epicgames.com/Partners. htm page, which lists all the announced Unreal engine licensees. 3.1. JAN 01, 1999
Tim Sweeney Archive
48
News
• Alexander Brandon updated the http://www.epicgames.com/alex/ music.htm. • Dave Carter’s http://www.nervedamage.com/ contains lots of cool resources for Unreal modelers and animators.
3.2 3.2.1
Jan 28, 1999 Unreal 221 Development Update
Unreal 221 development continues, with quite a lot of new features slipping into this version. Right now, Mark Poesch (the lead programmer of Wheel of Time) is visiting us here in Raleigh, merging in some of the improvements the Legend team has added into the Unreal engine for WoT and Legend’s upcoming Unreal level pack. I’m working on Unreal’s OpenGL support, and will soon get a version of the code to the 3D hardware makers who have some driver issues to work out. The Riva TNT is currently the fastest and most stable card, with the ATI Rage 128 looking very promising, especially in 24-bit color. I’m also extending the Unreal installer which shipped with the 220 patch, turning it into a full-blown installation program for future patches, shareware versions, and retail versions. I’m also contemplating extending it to support Unreal mods, which could then be distributed in a self-contained format (.uzip?) which Unreal automatically knows how to install. This would put cool mods just 3-4 mouse clicks away from users who are browsing mod sites like http://www.freshmeat.org/unreal/, 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 3.2. JAN 28, 1999
Tim Sweeney Archive
49
News
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 thirdparty licensees.
3.2.2
Unreal Tournament
The rest of the team is hard at work on Unreal Tournament, and we’re really happy with the way the game is shaping up. Unreal was such a huge, multi-faceted project that we weren’t able to focus on deathmatch as much as we would have liked. Unreal Tournament, with its identical gameplay style between single-player and multiplayer (the only difference being bots vs. human opponents) has given us a far more opportunity to polish the gameplay and the look-and-feel. -Tim Sweeney
3.3 3.3.1
Feb 10, 1999 Latest News
Progress on Unreal 221 and Unreal Tournament continues. We are making changes and improvements at such a fast pace that it has been hard/impossible to stabilize the code for the 3-5 days required to fully test a new patch. I apologize for the earlier false start we had with 221.
3.3.2
What we’ve been programming
I’ve been juggling work on the installer, OpenGL, and some core UnrealScript improvements. The installer is coming together, and is complete in terms of installing the retail game and patches, but more work remains to be done on uninstallation issues, and improved support for installing/distributing mods. Some of the latest UnrealScript improvements include a command-line script compiler, which can be used from 3.3. FEB 10, 1999
Tim Sweeney Archive
50
News
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 ingame 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 ingame 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 generalpurpose 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.
3.3. FEB 10, 1999
Tim Sweeney Archive
3.3.3
51
News
Linux Notes
We now have a command-line (windowless, console based) script compiler and server for Unreal, which has minimal dependencies on Windows. This is a first step towards a Linux port, and it also runs very well under Wine, with minimal overhead. This might be a good interim solution for Linux server administrators, before the full port is done. I just noticed in GameSpy that the top server on the list is titled ”CHiX Unreal NT Server (220) PORT UNREAL TO LINUX”. Hint taken. :) We actually have the Unreal 221 Core source compiling under EGCS 2.90.29, C++ templates and all. Getting the thing linking and running successfully will require a lot more work, which we won’t be able to focus on until UT ships, but the experience thus far has been very positive. -Tim Sweeney
3.4 3.4.1
Mar 19, 1999 Latest News
We’ve been going through many iterations of internal testing and improvements on the upcoming patch, which is now known as 223. Here is the latest http://unreal.epicgames.com/ReadMe223.htm. 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 betatested 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 3.4. MAR 19, 1999
Tim Sweeney Archive
52
News
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.
3.4.2
Level-Of-Detail Texture Mapping
I finally got the chance to write a rendering optimization I’ve been thinking about for a long time now, level-of-detail texture mapping. Unreal’s biggest performance problem in OpenGL has been texture management overhead, which causes frame rates to vary a lot (for example, jumping from 30+ fps down to 15 fps for a frame or two when new textures come into view). This is especially noticeable on on the Riva TNT, which has a very good fill rate and can handle large polygon counts, but is around 4X slower transferring textures to the card than Voodoo2. Solution: I create redundant versions of textures, scaled down 4X (in memory usage), 16X, 64X, and 256X. When an object being rendered is far away, I use a lower resolution version of the texture – which doesn’t cause visual problems (since the texture would be mipmapped anyway) but requires less texture data to be transferred. This has enabled us to boost the Unreal Tournament player models’ texture usage to 256K of texels per model. More info about additional levelof-detail features later...
3.4. MAR 19, 1999
Tim Sweeney Archive
3.4.3
53
News
Future of Programming Languages
Lately, I’ve been doing research on programming languages, in the interest of gaining new ideas to implement in the successor to UnrealScript for our next-generation (after Unreal Tournament) engine. Some of the topics I’ve been formulating are: • Garbage collection (see the http://www.iecc.com/gclist/GC-faq. html for background). UnrealScript uses a simple recursive markand-sweep garbage collector which is only executed when changing levels, along with some special-case code to garbage-collect destroyed actors during gameplay. Most implementations of Java use a background thread to run a generational garbage collector. Java’s approach is more general, but can cause pauses during execution as large amounts of garbage are purged, which is bad for frame-rate consistency. Java garbage collection presents a problem for object finalizers (the equivalent of C++ destructors), because the finalizer is executed at some random time after the object in question effectively becomes garbage, and finalizers of multiple objects are executed in random order. This limitation makes finalizers dangerous and not terribly useful. One work-around is to not support finalizers. Another work-around is to support them, but publish a list of ”things that aren’t safe to do from within a finalizer” (such as cause finalized objects to become rooted again, make assumptions about finalization order, etc). UnrealScript’s current solution is a mix of the two; finalizers must be native (implemented in C++) and are subject to those safety guidelines. Another general conceptual problem I have with garbage collection is that, often, the physical lifetime of an object (as defined by the garbage collector) often exceeds the ”practical” lifetime of an object (as defined by the semantics of the program you’re writing). For example, a window object in a windowing system is only meaningful when the window is open on screen; after the window has been closed, the object becomes meaningless even though it still exists and other objects might still be referring to the window. The general problem is that programmers often would like a ”way of explicitly 3.4. MAR 19, 1999
Tim Sweeney Archive
54
News
destroying an object and removing any other objects’ references to it”. C and C++ avoid this problem by making all memory management the program’s responsibility. Java avoids it by making the program responsible for determening whether an object you’re referring to is meaningful (for example by calling Window.IsOpen()). It would certainly be nice if object lifetime management and notifications became the full responsibility of the programming language, enabling programmers to instead focus on higher-level problems. The garbage-collection strategy that would be ideal, from the standpoint of predictable code and memory usage, is to finalize and destroy objects the exact moment they become garbage, i.e. when the last variable still referencing it changes. I’ve tried, very unsuccessfully, to find efficient approaches to manage such as system by tracking multiple reference counts, doubly-linked lists of twoway references between objects, etc etc etc, and haven’t been able to find an approach more efficient that performing a brute-force mark-and-sweep pass every time a reference to an object changes (plus optimizations such as reference counting to collect objects without cyclic references). Stated in graph theory, the question boils down to ”Given a graph and a particular directed edge of the graph, does removing that edge break the graph into two disjoint pieces?” Does anybody know if there is a graph-theory algorithm for determining this, which enables you to add a directed edge to the graph in constant time, and also remove an edge and determine disjointedness from that removal in constant time? • LISP defines a new kind of object called a ”function closure” which basically represents a pointer-to-a-member-function with several of its parameters bound to specific values (for example, binding the implicit ”Self”/”this” parameter to a particular object. This is a great object-oriented generalization of function-pointers, but the syntax becomes fairly complex in a statically-typed language (some issues you run into are recursively-defined closure types, and cyclic closure types). Microsoft’s Java extensions in Visual J++ include a simpler and more limited type of object called a ”delegate” which is a pointer-to-a-member-function bound to a specific instance of an object. I plan to experiment with these possibilities and implement ”something along these lines” in the next engine. 3.4. MAR 19, 1999
Tim Sweeney Archive
55
News
• Inner classes, as defined by Java, are a great feature for attaching objects together hierarchically. This is definitely a feature I want for the future. One example area where inner would simplify and generalize the code is Unreal’s actor lighting support. Currently, the Actor class has a bunch of variables related to lighting (LightBrightness, LightHue, LightSaturation, LightEffect, etc), and an enumeration LightType that describes the light’s overall mode of operation. While this is an improvement over past engines, and general enough for 1998-1999 games, it could be much better. Actors could instead reference a separate Light object which describes the lighting in a more general way. Instead of having a hardcoded enumeration for light effects (such as LE TorchWaver, LE Cylinder, LE Spotlight), all the different light types could be represented by separate classes (TorchWaverLight, CylinderLight, SpotLight) with the class supplying the appropriate spatial and volumetric lighting math. Additionally, the lighting objects could be made hierarchical, so you could modulate a cylinder light by a spotlight, and add a torch wavering effect on top. New light classes could be defined modularly to supply new lighting functions without modifying the engine source. While my plan for the next scripting language is gaining more clarity, there are still a lot of wide-open issues. For example, whether Java-style interfaces are necessary (since most of the same functionality can be obtained from inner classes), what the final garbage-collection strategy is, how similar do we want to make the language to Java, etc.
3.4.4
Visible Surface Determination
One of the biggest next-generation challenges for 3D programmers will be in solving the ”visible surface determination” problem for complex scenes. Doom basically used a densely portalized BSP scheme; Quake used a BSP in conjunction with precomputing the visibility from each BSP leaf in the world to every other leaf, trading off precomputation time in exchange for rendering performance. Unreal uses a sparsely portalized BSP tree and performs a software span-buffering pass to determine 3.4. MAR 19, 1999
Tim Sweeney Archive
56
News
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 http://www.opengl.org/Documentation/Version1.2/HPspecs/occlusion_ test.txt) 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.
3.4.5
Commentary on Cool Stuff
I just wanted to point out the following cool technical things. • 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 exceedingly clear, general, and well thought-out rendering capabilities are going to be the next quantum leap in 3D hardware acceleration acceleration, enabling true Phong/Blinn bump mapping and a tremendous variety of other features. My reaction to seeing this spec for the first time is reminiscent of first experiencing 3dfx’s Voodoo accelerator and the Glide API–it’s ”I can’t believe how powerful yet 3.4. MAR 19, 1999
Tim Sweeney Archive
57
News
simple this is to work with”. • http://teach.belmont.edu/ht/applet/htbu.html: This is the first generally useful new GUI control I’ve seen in years. Imagine the possibilities for using hyperbolic trees to browse the actor lists and server interconnectivity of huge interconnected online worlds. • http://dogma.net/markn/articles/bwt/bwt.htm: A new, unpatented approach to data compression; trivial implementations can easily beat PKZIP. -Tim
3.5 3.5.1
Apr 14, 1999 3dfx Voodoo3 Totally Rocks!
I just picked up a carload of the new Voodoo3 3000’s; we’ve put them to good use, as the team is now testing the upcoming 224 patch. The performance and graphical quality of the Voodoo3 are simply amazing. Though we’ve had a board for over a month, beta drivers and prerelease 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
3.5. APR 14, 1999
Tim Sweeney Archive
58
News
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
3.6 3.6.1
Apr 15, 1999 Important Unreal 224 Note To Mod Authors
Unreal 224 .u files aren’t backwards compatible with past versions of the engine. So you’ll need to take special steps to upgrade your .u files. To upgrade mods to 224, you’ll first need to export your scripts to *.uc files. You can do this in all versions of UnrealEd like this: 1. Bring up the UnrealEd class browser on the right side of the screen. 2. Click on the ”Load” button and load your mod’s .u file. 3. Click on the ”Export All” button and have UnrealEd export all of the loaded scripts to .uc files (including yours and the engine’s), creating a directory structure for all the .uc files: for example, the files from the Core package are in \unreal\core\classes\*.uc. If your mod is named XYZ, your .uc files will be exported to \unreal\XYZ\classes\*.uc.
3.6. APR 15, 1999
Tim Sweeney Archive
59
News
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
3.6.2
Maps, Textures, Sounds, Music are backwards compatible
...so there shouldn’t be any problem with existing user maps built with past versions of UnrealEd. I checked this by downloading a bunch of maps from 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 compatible, so they will refuse to load until the .u files they depend on are upgraded. 3.6. APR 15, 1999
Tim Sweeney Archive
3.6.3
60
News
Latest News
I’ve been awake for way too long, so please forgive my spelling and grammar! Internal testing of 224 continues. Things are looking pretty good, though we need to go through a couple more iterations before everything’s in perfect shape. The 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: 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 realtime strategy titles, that were not previously obvious choices for the engine.
3.6.4
Cool Stuff
While I wait for 200,000 lines of Unreal code to recompile, I wanted to point out some more cool things that seem to be under-appreciated. • http://www.winamp.com/ is a great MP3 music player for Windows; and its companion, http://www.shoutcast.com/ is a streaming ”Internet radio” companion. While I know MP3’s and Internet radio has been around for a while, WinAmp really deserves credit for its grassroots following and overall coolness factor.
3.6. APR 15, 1999
Tim Sweeney Archive
61
News
• Windows 2000 internationalization support. This pure Unicode OS will mark the first time Microsoft ships a single binary worldwide, which will be a great leap forward in making it easy to develop games (and applications, and websites...) for the international market. • http://www.plh.af.mil/ddvpc/melp.htm 2400 bits-per-second phonequality voice compresion. Speech compression research has been making major leaps and bounds lately, as quality voice compression ratios skyrocket. The latest set of algorithms analyze an audio stream and (to simplify things a bit) transform it backwards to vocal cord excitation. The resulting compression ratio is in the neighborhood of 100-to-1. This is a research subject Carlo Vogelsang (Unreal sound engine programmer) and I have been looking into lately, and it turns out to be very complex and math intensive. -Tim
3.7 3.7.1
Apr 19, 1999 Getting closer...
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 http://www.next-generation.com/jsmid/news/6387.html where Mark Rein shamelessly plugs the patch.
3.7. APR 19, 1999
Tim Sweeney Archive
3.7.2
62
News
Network Cross-Compatibility
(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 http:// unreal.epicgames.com/network.htm) 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
3.7. APR 19, 1999
Tim Sweeney Archive
63
News
makes our programming lives easier.
3.8 3.8.1
May 01, 1999 224 Progress Continued
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 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
3.9 3.9.1
May 02, 1999 STAT NET: Diagnosing your connection to the server
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
3.8. MAY 01, 1999
Tim Sweeney Archive
38 0 12% 11 126 1395 2600
0 14% 32 32 2031 2600
64
News
CHANNELS UNORDERED/SEC PACKET LOSS PACKETS/SEC BUNCHES/SEC BYTES/SEC 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: • PING: Round-trip time between you and the server, in milliseconds. Modem users will typically see 200-350 for in-country gameplay. ISDN/T1 users will be in the 50-200 range. Playing overseas results in enormous times, 600-1000 or more. This number represents the quality of the connection between you and the server, and really should be 300 or less for good gameplay performance. A bad connection on either end can hurt the ping time. • CHANNELS: Roughly, the number of objects that the server is actively updating to you. Proportional to how much combat is happening around you. • PACKET LOSS: Percentage of packets lost between the client and server. The higher the packet loss, the worse the performance will be, and the more you’ll see objects skipping around rather than moving smoothly. High packet loss can be caused by: – Using too aggressive a network speed on the client side. Try typing ”NETSPEED 2600” on the console to reign in bandwidth usage. – The server’s connection is overtaxed. This will result in heavy packet loss and a bad gameplay experience for everyone. Servers will limited bandwidth available need to set their play limit conservative (expect 5000 bytes per client per second), and also lower the MaxClientRate variable in Unreal.ini. A value of 5000 should be good for everyone. 3.9. MAY 02, 1999
Tim Sweeney Archive
65
News
– A bad connection anywhere between you and the server. – A bad connection between you and your ISP. • PACKETS/SEC: Number of packets being sent per second. The number on the left should be 13 or higher. If it’s significantly less, that means the server is either running too slowly, or experiencing high packet loss. Gameplay will be bad at 10, and unbearable at 5. The number on the right is proportional to your frame rate and you don’t need to worry about it. • BUNCHES/SEC: Number of objects being updated per second. Not important for tweaking. • BYTES/SEC: Bytes being sent per second. • NETSPEED: The network speed setting you set using the console NETSPEED command. Recommended settings are: – 2600 for a typical modem connection. – 2400 for a poor modem connection. – 5000 for an ISDN connection. – 20000 for a T1 connection.
3.9.2
Server Alert
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. 3.9. MAY 02, 1999
Tim Sweeney Archive
66
News
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
3.9.3
Unreal 224v C++ headers released!
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 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, 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
3.9. MAY 02, 1999
Tim Sweeney Archive
67
News
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 http://unreal.epicgames.com/UnrealPubSrc224v.zip. Unzip it into your \Unreal directory, and the proper subdirectories will be created (described in the http://unreal.epicgames.com/ReadMeSrc.htm). The C++ code compiles there and links to DLL’s in the \Unreal\System directory, read to run. Enjoy! -Tim Sweeney
3.9.4
Unreal 224v Released to the public!
The Unreal 224v patch is now available for download from our http:// unreal.epicgames.com/versions.htm, along with the release notes. -Tim Sweeney
3.9. MAY 02, 1999
Tim Sweeney Archive
68
3.10
May 03, 1999
3.10.1
Known Bugs
News
Having a problem with Unreal? Please visit the http://unreal.epicgames. com/Bugs.htm page to see if we know about it and are addressing it, and if there any any workarounds.
3.10.2
Future Patch
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 3.10. MAY 03, 1999
Tim Sweeney Archive
69
News
move forward with the Unreal Tournament code track, to keep up to date with the latest features. -Tim
3.10.3
Check out the Unreal news sites
• http://www.planetunreal.com/ has lots of news and tips about 224. • http://www.unrealengine.com/ is a news site dedicated to the Unreal engine. • http://www.unreal.org/ is a master index of Unreal resources on the Internet, and has tons of cool Unreal related links. I’ll be making a summary of reported bugs, workaround, and related feedback from the community later tonight.
3.10.4
OpenGL UnrealEd
Thanks http://www.planetunreal.com/ 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.OpenGLRenderDe 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 3.10. MAY 03, 1999
Tim Sweeney Archive
70
3.11
May 05, 1999
3.11.1
Maps that broke since 220
News
Some user maps such has http://www.planetunreal.com/dl/dl.asp?nalicity/ dmhellshrap.zip 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 mailto:unreal224@ epicgames.com. -Tim
3.11.2
Quick Notes
We’ve been going through the Unreal 224 bug reports and addressing lots of issues people have pointed out. Here’s the latest status. • Creative Labs EAX 3D sound support is fixed for 225. • We’re working with Aureal to get A3D 2.0 support into 225, which is very likely to happen. • I fixed the cause of the ”out of memory” errors that tended to happen when the console was pulled down on some machines. There was a problem in UnrealScript with switch statements operating on strings, which caused this and some similar problems reported by licensees. Thanks to Mark Poesch of http://www.wheeloftime.com for tracking this one down. 3.11. MAY 05, 1999
Tim Sweeney Archive
71
News
• Under some conditions, alt-tabbing between fullscreen and windowed play would cause the in-a-window game window to be collapsed to zero size. Fixed. • I optimized the network visibility code by about 25%. Server admins are reporting notably more CPU usage per player with 224 than 220. I haven’t tracked this down, but I’m going through a lot of code to measure and improve the server performance. Many other fixes, tweaks, and incremental improvements are in the works. See the http://unreal.epicgames.com/Bugs.htm page for more info. -Tim
3.12
May 08, 1999
3.12.1
Latest progress
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
3.12. MAY 08, 1999
Tim Sweeney Archive
72
3.13
May 19, 1999
3.13.1
Unreal 225 musings
News
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 bitstream writer, and replication condition caching code), and a new timestamping 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!
3.13.2
”Make Something Unreal” Contest
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!
3.13.3
Things That Are Cool
• http://msdn.microsoft.com/ssafe/: Anybody who is programming on a large project without using a source-control system is nuts! 3.13. MAY 19, 1999
Tim Sweeney Archive
73
News
SourceSafe provides a central repository for all code, and enables programmers to check out files and work on them without their changes ”colliding” with those of other programmers. SourceSafe also tracks all changes to all files since the beginning of a project, which has been incredibly useful in developing Unreal, because it enables us to examine our past code changes when tracking down bugs. Finally, SourceSafe is excellent for managing ”branched” projects: when we split Unreal 224 apart from the Unreal Tournament codebase, SourceSafe managed the files’ shared history automatically. • http://www.glsetup.com/: Now that Microsoft has publicly committed to dropping the ball on 3D hardware driver distribution with DirectX7, GLsetup is the only hope for game developers who want their game to work on users’ computers out-of-the-box. The PC is already plagued by driver problems, and the classic symptom is users having to go to the web and download new drivers to get new games working. The world would be a much better place if Microsoft took a leadership role in driver updates, by keeping the DirectX redistribution continually refreshed with new QA-certified drivers, thus assuring that new games always work ”out of the box” – if that happened, PC gaming would be a lot closer to the level of reliability of console games. But Microsoft isn’t doing that, and GLsetup is a grassroots effort to solve the problem. -Tim P.S. Check out http://www.unrealnation.net/, the cool in-depth Unreal news site.
3.13. MAY 19, 1999
Tim Sweeney Archive
74
News
3.14
May 29, 1999
3.14.1
For server administrators only: Unreal 225e Patch
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 mailto:[email protected] 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: http://unreal. epicgames.com/Files/UnrealPatch225e.exe. The general Unreal 225 patch for everybody including users will be available in a few days. -Tim
3.14.2
On engine licensing
In this http://www.msnbc.com/news/274561.asp#BODY, 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.” 3.14. MAY 29, 1999
Tim Sweeney Archive
75
News
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
3.14.3
UnrealEd ”Runtime Error 20005” Experimental Fix
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:[email protected] 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.14. MAY 29, 1999
Tim Sweeney Archive
76
3.15
May 31, 1999
3.15.1
Latest News
News
• 4 out of 5 users have reported success with the experimental UnrealEd fix – it made those nasty ”Runtime Error” messages go away. If you’re having problems with UnrealEd not starting up, grab this file! • The other one reported an error message relating to Threed32.ocx which I fixed in http://unreal.epicgames.com/Files/UnrealEdFix3. exe. • There was a master server outage/problem today. If you weren’t seeing servers in Unreal’s new server browser or GameSpy today, don’t worry, the problem was at the master server and it has been fixed. • Aussies, check out the http://www.unrealed.net/ozunreal/ for Australian level designers!
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.
3.15.3
New 225f Patch for server administrators only
This should fix the UActorChannel::ReplicateActor crash and some smaller problems.
3.15. MAY 31, 1999
Tim Sweeney Archive
77
News
It’s backwards-compatible with Unreal 224-225 clients. If you have any server crashes, please email your Unreal.log file to mailto:unreal225@ epicgames.com. Only download this if you are running an Unreal server: http://unreal. epicgames.com/Files/UnrealPatch225f.exe. -Tim
3.15.4
Server 225e Patch Feedback
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!
3.15.5
UnrealEd Experimental Fix 2
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 http://unreal.epicgames. com/Files/UnrealEdFix2.exe. Please let us know what happens by emailing mailto:[email protected] 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
3.15. MAY 31, 1999
Tim Sweeney Archive
78
3.16
Jun 01, 1999
3.16.1
UnrealEd Follow-Up
News
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.
3.16.2
Server Cheats?
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:[email protected] 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:[email protected] (no prizes for this, we’ll just fix the security holes!)
3.16.3
UnrealEd for 3dfx Voodoo3 bundle owners
The version of Unreal that shipped with 3dfx’s Voodoo3 bundle didn’t include 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 3.16. JUN 01, 1999
Tim Sweeney Archive
79
News
example c:\Unreal). Then just run c:\Unreal\System\UnrealEd.exe to start editing. -Tim
3.17
Jun 06, 1999
3.17.1
Direct3D Improvements
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
3.17. JUN 06, 1999
Tim Sweeney Archive
80
3.18
Jun 19, 1999
3.18.1
Unreal Direct3D
News
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: 1. Dramatically less memory usage. My Direct3D code wasted tons of hidden, ”behind the scenes” memory while swapping textures into video memory, leading to lots of virtual-memory swapping. 2. New texture management code, better optimized for Unreal’s texture usage patterns. I had been relying on Direct3D’s built-in texture manager, which is slowed down by its generality. 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.
3.18. JUN 19, 1999
Tim Sweeney Archive
3.18.2
81
News
Summary of things I learned about Direct3D
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, 3.18. JUN 19, 1999
Tim Sweeney Archive
82
News
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
3.19
Jun 30, 1999
3.19.1
Direct3D Is Happening
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, http: // www. planetunreal. com/
3.19. JUN 30, 1999
Tim Sweeney Archive
83
News
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
3.20
Jul 01, 1999
3.20.1
226 Progress
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.
3.20.2
Recommended Reading
http://www.amazon.com/exec/obidos/ASIN/0387947752/002-3430157-9555648 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. 3.20. JUL 01, 1999
Tim Sweeney Archive
84
News
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.
3.21
Jul 03, 1999
3.21.1
On Our World Domination Plans
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 describes, the http://www.digitalo.com/ team is building a ”virtual reconstruction” of the http://www.planetunreal.com/index.asp?images.asp? interviews/images/vrnd1big.jpg. 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, http://www.unrealengine. com/, is covering lots of other Unreal engine projects that fall way outside 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 wellknown 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 3.21. JUL 03, 1999
Tim Sweeney Archive
85
News
are pitching completely non-game projects incorporating the Unreal engine to investors.
3.21.2
What’s really happening here?
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 stateof-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.
3.21.3
The Economics
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 3.21. JUL 03, 1999
Tim Sweeney Archive
86
News
(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 highvolume 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.
3.21.4
The Result: General-Purpose Solutions Win
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 3.21. JUL 03, 1999
Tim Sweeney Archive
87
News
grow. The ramifications are: • Specialized software and hardware loses out to general-purpose. The company that focuses on generality (for example, a CPU, or a 2D+3D graphics accelerator, or a general-purpose game engine) has the expectation of higher sales, and can make so much more of an R&D investment that special-purpose solutions can’t compete (for example, 3D-only accelerators, or a once-off engine powering a single game). • Volume and increasing R&D investment enable 3dfx and NVidia to sell millions of $150 graphics cards that outperform SGI’s $50,000 solution which sells 1000 units. That has the effect of crushing SGI’s business model, even though companies like 3dfx aren’t even consciously trying to compete with SGI. • When a company like Epic or id Software builds a 3D engine, we do it with the expectation of it powering games that sell a few million copies, between our games and licensee projects. We make money from each one, and that realization drives investment in making more and better tools. This gives our engines a price, performance, and feature advantage over ”in-house” engines made specifically for one game, and over less-capable engines designed for niche markets. We amortize our R&D investment over ~10X more units sold. This licensing model has already proven successful with mainstream game developers, but now it’s starting to overflow into non-game markets too. We have this great 3D engine, why not use it for your architectural walkthrough? • As a result of widespread interest, thriving ecosystems develop around successful general-purpose products. For example, there are hundreds of web sites dedicated to 3dfx hardware, and lots of developers optimizing their games for 3dfx. There are many hundreds of web sites covering Unreal and licensee projects; thousands of kickass aspiring level designers building maps and making them available online; many licensees building games; and lots of other cool 3.21. JUL 03, 1999
Tim Sweeney Archive
88
News
projects that tie into the engine, such as mods and TC’s, and the research projects like Notre Dame. The community has a multiplicative effect on growing the platform.
3.21.5
Where we go from here
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
3.22
Jul 10, 1999
3.22.1
The AMD Athlon Rocks!
My new 550 MHz http://www.amd.com/products/cpg/athlon/index.html (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.
3.22. JUL 10, 1999
Tim Sweeney Archive
89
News
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: • I want to be able to buy dual-processor Athlon workstations from major manufacturers like Dell and Gateway. • I want MMX, 3DNow! and SSE code generation support in Visual C++, with native SIMD C/C++ datatypes like float2, float4, and short4, making the compiler manage all register allocation and code generation. • I want http://www.kryotech.com/sgindex.asp! 8-) -Tim
3.23
Jul 12, 1999
3.23.1
New Downloads & Links Pages
By popular request, the links on the tech page have been updated and cleaned up. I added: • New http://unreal.epicgames.com/Downloads.htm page: An index of all the official files here on the tech page, plus links to dedicated Unreal download sites. If you’re looking for the latest PC or Mac patch, UnrealEd patch, Fusion maps, or whatever, look here. 3.23. JUL 12, 1999
Tim Sweeney Archive
90
News
• New http://unreal.epicgames.com/Links.htm page. Links to some of the major ”hub” web sites related to the Unreal community, Epic, our partners. I also wanted to mention the supercool new download site, http://www. unrealfiles.com/, check it out. -Tim
3.24
Aug 14, 1999
3.24.1
DirectX7
Some people have been asking about our plans for supporting the upcoming 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 Unreal Tournament patch with complete DirectX7 optimizations. This has been the plan all along. DirectX7 has lots of cool new features. The ones which Unreal Tournament will exploit are: • Improved texture management. • Hooks to enable 3D card drivers to perform their own texture management to improve performance. • Optimized polygon path for significantly faster polygon rates. • Windows 2000 support. -Tim
3.24. AUG 14, 1999
Tim Sweeney Archive
91
3.25
Aug 16, 1999
3.25.1
Unreal Tournament development note
News
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
Sep 14, 1999
3.26.1
Unreal Tournament demo schedule
To quote http://www.voodooextreme.com/ quoting me :), here’s the Unreal Tournament demo release plan: • Windows 3dfx demo this week. • Windows Direct3D/OpenGL next week. • Linux Glide/OpenGL soon after. • Mac timing not figured out yet.
3.25. AUG 16, 1999
Tim Sweeney Archive
3.26.2
92
News
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 texture management. The API’s simplicity has also improved, which is something you don’t often 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 function calls and interfaces. I’m very glad to see the IDirect3DTexture, IDirect3DViewport, and IDirect3DLight interfaces gone, and replaced by much simpler state-setting code. Direct3D’s abuses of object-oriented programming 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 backwardscompatible 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
Sep 22, 1999
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 3.27. SEP 22, 1999
Tim Sweeney Archive
93
News
on the upcoming Unreal Tournament demo with Direct3D and OpenGL support, coming in the next few days. One thing we’ve found on DirectX7 is that NVidia TNT2 performance is not fill-rate limited until you get to very high resolutions. During testing, performance at 640x480 seemed a bit slow, but as we increased the resolution, the frame rate was hardly impacted at all. So 1024x768 seems to yield the best overall experience on this card. I’ve enabled support for 32-bit color textures under Direct3D, which significantly improve the graphical quality, with a 10-15% frame rate impact. The Direct3D code now uses vertex buffers, which speeds up mesh and text drawing a bit.
3.27.2
What about OpenGL?
We’re still maintaining OpenGL sypport, though it’s not as much of a priority 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 enable 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. I’ve been maintaining the Unreal / Unreal Tournament rendering code under both Direct3D and OpenGL simultaneously for a while. They used to have approximately equal performance back when I was using Direct3D’s ”driver-managed textures” (similar to the one and only OpenGL option for texture management, which is transparent to the application). Unfortunately, the performance wasn’t very good, and the memory usage was nuts because our game uses a huge amount of textures, and the automatic texture management in Direct3D and OpenGL had to keep duplicate copies around as ”backing store” to the copies in video memory. 3.27. SEP 22, 1999
Tim Sweeney Archive
94
News
However, I recently rewrote my Direct3D code to manage textures explicitly. I create a limited number of textures of all possible sizes, forced to be in video memory, and then at runtime swap my actual game textures into those ”video memory textures”. This way, I have complete control over texture management, and can make optimal decisions about where to put textures, based on the constraints of my app, such as: • Texture usage patterns. • Decompressing textures at glTexImage2D time using my own internal formats. • Having a background thread load them off disk speculatively and stick them in video memory when needed.\ • Other nonlinear, possibly time-variant priority factors. When I replaced D3D’s default texture manager with my own code, Unreal’s performance and memory usage under Direct3D improved very significantly, to the point where it’s not worth bothering playing the game in OpenGL anymore. So, my question is, does anybody have plans to add an ”extended version of glBindTexture” which lets the application tell the OpenGL driver, ”allocate this texture in video memory, keep it there, and never swap it out”? If an option like this existed, I could do the same kind of high-level optimizations as I did in Direct3D, and probably get a comparable increase in performance. Obviously, video memory is a limited resource, so at some point those glBindTextures will fail if video memory fills up, and have to return an error code. This is a bit lower-level than GL’s existing glBindTexture mechanism, but I think it’s justified by the need to support apps which use huge quantities of textures and have to manage them carefully in order to maintain realtime frame rates. For example: If the GL EXT BIND TEXTURE 2D VIDEOMEMORY string is exposed, then you can replace a call to glBindTexture( GL TEXTURE 2D, MyBindId ) with glBindTexture( GL TEXTURE 2D VIDEOMEMORY, MyBindId ) and the texture is guaranteed to be allocated in
3.27. SEP 22, 1999
Tim Sweeney Archive
95
News
video memory and never moved around by the GL driver’s texture manager. For my application, glPrioritizeTextures(?) isn’t a viable solution, because it still requires extra backing-store copies of textures to be kept in system memory so they can be swapped in and out. In addition, implementing my own texture manager on top of the existing, unextended glBindTexture isn’t at all efficient, because I don’t have any way of knowing how many textures I can allocate before they start spilling out of video memory, and in addition most GL drivers do lots of extra internal memcpy’s in the process – and with big textures, having lots of unnecessary 256K memcpys (for 256x256x32-bit textures) just kills performance. Such a solution would benefit Unreal engine games on Windows, Linux, and possibly Mac such as Unreal Tournament, Duke Nukem Forever, Deus Ex, Wheel of Time, etc etc etc. As well as other developers’ texture-intensive games that use OpenGL, such Starsiege: Tribes (the developers have been running into this same issue).
3.27.3
Experiencing poor Internet play on your Voodoo3 3500TV?
As http://www.voodooextreme.com/ reports, the Voodoo3 3500TV’s WebTV installer does some evil things to your Internet setting, causing many games (including Unreal Tournament and Quake 3 Arena) to experience poor Internet play: Hello, We are aware of the problems that the Voodoo3 3500TV is experiencing with online games. Many of these problems can be cured by removing WebTV, however that will disable the Visual Reality software. The problem usually can also be cured by removing the Internet Explorer 5 upgrade from Windows98. While these are just a work around, and not really fixes, both options usually will cure the problem until 3dfx releases a real fix. We are currently working with Microsoft to try and figure 3.27. SEP 22, 1999
Tim Sweeney Archive
96
News
out whether the problem is due to Microsoft software (WebTV and IE5) or 3dfx software (3500TV drivers and Visual Reality). Thank you for your patience, Aaron D. Patton 3dfx Interactive Email Support -Tim
3.28
Sep 29, 1999
3.28.1
More Hardware Troubleshooting
• We received some more confirmations of Unreal working better on TNT’s with the Creative Labs unified drivers using Glide than Direct3D. If you have a Creative Labs TNT card and have having performance problems, try that. Especially if you have under 128 megs of RAM. • Lots of reports of slowdowns from users with Monster Sound’s who have enabled the ”Advanced Options / Audio / Use3DHardware”. If you’re having this slowdown, disable Use3DHardware and try again. Then please email mailto:[email protected] and let us know whether that helped. I’ve seen three confirmations from users that their problems (huge slow down) went away after disabling this. • 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 almost exact proportion to our ”supposed” video memory texture allocations. Thus the game uses an extra 12-26 megabytes of system memory–a very inefficient allocation of resources. This is a big surprise, 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 3.28. SEP 29, 1999
Tim Sweeney Archive
97
News
our henchmen at NVidia and Microsoft and see if we can track this down...
3.28.2
Direct3D Anomalies
We’ve been looking at the feedback on Direct3D performance and investigating some strange reports. Recently, we’ve mainly been testing on 96-meg and 128-meg machines (I have a Celeron 400, Jack Porter has a K6-2 450). On these machines, TNT1 performance is good – average 28 fps at 648x480, 25 fps at 800x600. The TNT2 performance is significantly better. However, upon removing some RAM and testing Direct3D on a 64-meg K6-2, the ”precache” time increased by about 5X, and performance dropped to a few frames per second. These performance drops don’t occur in the software renderer, and don’t occur in Glide. Something is going wrong between Unreal, Direct3D, and the TNT’s Direct3D driver, and we’re investigating. Overall, the feedback indicates a very wide variance in performance among TNT users, much more so than with any other card. Our internal testing has indicated this too; for example, we’ve found (and worked around) a lot of driver bugs that only happen on one machine, and not others with otherwise similar configurations. Don’t Try This At Home Dept.: Some TNT users have reported that tweaking their BIOS’s ”AGP Aperture Size” improves performance on 64-meg machines. We have tried this and couldn’t find any differences on our 64-meg test machine. Others report that the Creative Labs unified drivers (with TNT Glide support) outperform Direct3D on their cards. If anybody finds definite improvements or workarounds, or has insight into what’s happening, please email mailto:[email protected] and let us know. Thanks.
3.28. SEP 29, 1999
Tim Sweeney Archive
3.28.3
98
News
Athlon In The House
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
3.29
Oct 01, 1999
3.29.1
TNT Users, Try This!
Tweaks: • Play in 16-bit color, which is significantly faster than 32-bit color. • Turn the detail options down in the Preferences/Video menu. • Use the ”-” key to reduce the HUD size. • In Preferences/Game, turn off the display of your weapon. • If you have enabled Advanced Options / Audio / Use3DHardware audio support, TURN IT OFF for now! Big driver performance problems. Experimental improvement for the brave: • Try http://www.geforce-fr.com/drivers/win9x_nv3.34.exe (thanks to http://www.anandtech.com/ site for the link). • Try putting this new http://unreal.epicgames.com/D3DDRV.DLL into your \TournamentDemo\System directory. Please back up your existing one first!
3.29. OCT 01, 1999
Tim Sweeney Archive
99
News
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
3.29.2
Latest Findings
We’ve been benchmarking UT performance and memory usage on many 3D cards, and we’ve found the source of the performance problems on 64-96 meg machines with TNT/TNT2 cards. Our measurements indicate that the TNT/TNT2 drivers consume up to 25 megabytes of page-locked system memory with UT, while other Direct3D cards don’t. On machines with 64-96 megs, that kills performance, as one would expect. The game runs, but data is swapped to the hard drive so frequently that playability is compromised. We’ve been comparing with other 3D cards and aren’t seeing the issue on the Rage 128 or Voodoo3 under Direct3D. System-wide memory allocations measured with SYSMON.EXE on a 64meg Celeron running Windows 98 SE: • TNT D3D: 51 MB baseline, 122 MB playing UT in 16-bit color, 134 MB playing UT in 32-bit color. • Rage 128 D3D: 55 MB baseline, 107 MB playing UT in 16-bit color, 109 MB playing UT in 32-bit color. • Voodoo3 D3D: 51 MB baseline, 100 MB playing UT in 16-bit color. 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. OCT 01, 1999
Tim Sweeney Archive
3.29.3
100
News
Links
Unreal Technology in the news: • http://www.msnbc.com/news/318085.asp?cp1=1#BODY - MSNBC • http://www.newsday.com/plugin/ccov0929.htm - Newsday Cool Sites: • http://www.unreality.dk/ - Cool Unreal site & community host in Denmark. • http://www.gamespy.com/ - The GameSpy empire’s new portal site. Check out their http://www.gamespy.com/stats/index.shtm page, where Unreal Tournament is #6 and rising quickly. Hopefully someday we’ll overtake that 3-year-old QuakeWorld thing. :-) -Tim
3.30
Oct 02, 1999
3.30.1
Unreal Tournament players overtake QuakeWorld at #5
Top Game Servers By Players from http://www.gamespy.com/stats/index. shtm @ 7:52 PM EST
Game Servers Players ================== ======= ======= Half Life 1502 4344
3.30. OCT 02, 1999
Tim Sweeney Archive
Quake II Starsiege TRIBES Quake 3: Arena Unreal Tournament Quakeworld Kingpin Unreal Turok 2 Descent 3
101
1628 589 1040 423 623 127 134 20 8
News
1711 1162 1156 520 517 256 144 43 23
-Tim
3.31
Oct 06, 1999
3.31.1
Windows 2000 RC2 Rocks!
I recently upgraded to Windows 2000 Release Candidate 2, and wanted to mention that it’s extremely solid! With NVidia’s latest Windows 2000 TNT/GeForce drivers, DirectX7’s Direct3D and OpenGL both work flawlessly. What’s cool about the new OS: • High-performance DirectX7 Direct3D and OpenGL support. • USB mouse support – mouse movement is very smooth. • Much more stable than Windows 98, especially for software development. • Good administration tools, more powerful than NT4 and far easier to use. • Great international support. • Dual processor support. • Plug and play. 3.31. OCT 06, 1999
Tim Sweeney Archive
3.31.2
102
News
Windows 2000 Internationalization
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 matter 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 confusing array of incomplete features such as supporting Unicode in a few API’s but not all, weird and undocumented multibyte character set handling, and mixed ANSI/OEM file system conventions. Localizing Windows 9X apps is a very difficult undertaking. On the other hand, Windows 2000 is by far the most thoroughly internationalized 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 development 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
3.31. OCT 06, 1999
Chapter 4 2000 News 4.1
Feb 22, 2000
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.
4.1.1
Common Questions I’m Asked
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: • Steve Polge, creator of the ReaperBot mod for Quake. • Brandon ”GreenMarine” Reinhart, early Unreal mod maker and writer of cool UnrealScript programming tutorials. • Jack ”mek” Porter, Unreal mod maker and PlanetUnreal news correspondent. • Alan Willard, maker of cool Unreal and Quake levels. • Shane Caudle, amazing artist and level designer who was building his own Quake TC. 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 emphasis 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 algorithms 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 understanding them brings clarity to lots of real-world problems you’ll encounter. 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 includes the editor (on CD#2) and all the http://unreal.epicgames.com/ 4.1. FEB 22, 2000
Tim Sweeney Archive
105
News
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 information. 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 retail version), you don’t need a license agreement while you’re prototyping 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.2
Programming Languages
Ever since my http://www.gamespy.com Developer Week article, ”http: //www.gamespy.com/articles/devweek_b.shtm”, I’ve been getting questions about whether we plan to ”do something about it” and define a new programming language. The answer is, we’re already doing that to a certain extent with http://unreal.epicgames.com/unrealscript.htm, which is a high-level, object-oriented, platform-independent language with some cool extensions aimed at game code development. As an engine developer, we’ll always be involved in language design to a certain extent. In the future, the scripting language could evolve into a 4.1. FEB 22, 2000
Tim Sweeney Archive
106
News
simpler form, more true to the ”scripting” term: controlling sequences of in-game events. Or, the scripting language could grow to subsume even more of the engine code. We’ll be evaluating these options anew with each major iteration of the engine, doing whatever is most appropriate for the technology, recognizing the benefits and drawbacks of going with well-known proven tech, versus creating newer, better tech.
4.1.3
Also...
• The cool soon-to-be-public site http://www.linuxnewbie.com/ already has posted a http://www.linuxnewbie.org/nhf/intel/games/ unreal_tourney.html on how to get started with Unreal Tournament 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 starting 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
4.2
Feb 28, 2000
Check out the http://www.gamespy.com/articles/moddevweek_b.shtm on the state of mod development, by our own Brandon ”GreenMarine” Reinhart. This is the first feature in http://www.gamespy.com/ new http:// www.gamespy.com/articles/moddevweek_a.shtm feature. Upcoming articles in the series feature Jesse Taylor from the Infiltration mod team for Unreal Tournament, and David ”crt” Wright of Rocket Arena for Quake 3 and Unreal Tournament.
4.2. FEB 28, 2000
Tim Sweeney Archive
107
News
Now is an exciting time for mod development, as the best teams of enthusiasts are earning tremendous praise, opening up serious biz opportunities. 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 enjoyment, 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 Unreal 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 pressurecooker environment, only good games and good ideas survive. -Tim
4.2. FEB 28, 2000
Related Documents
Tim Sweeney Archive - News Archive
August 2019 60
Tim Sweeney Archive - Interviews
August 2019 33
Archive
November 2019 45
Aesopian.com Archive
May 2020 30
Program Archive
December 2019 82
Opinion Archive
May 2020 29More Documents from ""
John Carmack Archive - .plan 2000
August 2019 53
Jesus Christ Is The Answer -macedonian
June 2020 34
Otago Y7 Boys Cross Country 2009
June 2020 28
