The latest PlanetUnreal survey shows a significant gain in gamers' satisfaction with the latest 219 patch, compared to the previous ones. We're now hammering on version 220, which includes significant new Internet play improvements, plus some core game improvements that the rest of the team has been working on. 220 won't be out this week, but should be ready soon after.
There seems to be one Internet problem in 219 that is affecting 10-15% of players. I haven't figured out the cause yet, but the symptom is a ping time (visible with STAT NET) that swings around wildly, going from 200 to 1000 or more over the course of several seconds. Many of these players report that other games like Quake 2 don't exhibit the problem--which indicates it's not just a bad connection or ISP. I suspect packet-ordering problems, though I haven't been able to duplicate it here.
In the remainder of 1998, we will be releasing:
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:
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.
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:
-Tim Sweeney
It's now available for download HERE. The Epic Deathmatch servers will be shut down for the night, to provide more bandwidth for downloads.
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.
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.
More public servers keep popping up every day. Awesome!
I noticed that the percentage of servers shown as "not responding" has gone up, though I'm not sure whether that's due to server crashes, or people accidentally having their LAN server listed in GameSpy when it's not meant to be public. Server admins, if your server crashes unexpectedly, please email your Unreal.log file to unreal218@epicgames.com so we can investigate it.
A reminder, server administrators can get help in the new "Server Administration" forum on the Epic Message Board.
According to the feedback we receive, and in PlanetUnreal's survey, 218 has fixed the past network problems and made Unreal playable on the Internet for the large majority of people. Still, we have lots of improvements in the works, which will further increase the game's smoothness and responsiveness during network play, as well as a few new features that I'm not allowed to announce yet. :) The next patch, 219, will be purely bug fixes to 218 (no speed difference). After that, 220 will contain some more high-level improvements to many areas of the network code.
Currently, there seem to be two sets of people who are still having some problems with Unreal on the Internet. One set has 28.8K-33.6K modem connections that experience an unusally high amount of packet loss. 220 should improve this a bit, but when you have upwards of 20% packet loss, gameplay is bound to suffer. The other set of problems is being reported by people with some unusual connections we haven't been able to test on internally: people with dual simultaneous modem connections, people with connections that receive via satellite and send via modem, and some similar configurations. I haven't determined what's going wrong in these cases yet, but I suspect packet-order problems.
If you downloaded the 218 patch, please read the release notes. If you're still experiencing problems with Unreal on your modem connection, you need to use the NETSPEED command described there, so that Unreal doesn't try to use more bandwidth than you have available.
Here are some resources to aid new Unreal server administrators in getting up and running:
A lot of news sites have been picking up on Unreal's multiplayer improvements:
The number of public Unreal servers listed in GameSpy is now up to 51 as I write this, and has been growing at a rate of over 20% daily. While working on the upcoming 219 patch, I've been spending a couple hours each day playing Unreal online, especially on the servers running user-created levels. The community has made some really impressive levels, and I'm glad to see that a lot of servers are now making use of downloadable levels, textures, sounds, and music.
In addition to the public servers listed in GameSpy, there are 14 extremely high quality, public servers on World Opponent Network listed in their own web-based "server finder" site.
I should also mention our other online partner, MPlayer, and the Unreal Kingdom news site on MPlayer.
-Tim
Some issues across-the-board with switching between fullscreen and windowed mode, and switching resolutions during gameplay. We're looking into theses issues.
Has lots of potential, but there are major problems with their Direct3D driver: rainbow colors, time-lag, w-buffering issues, missing textures. We are hoping nVidia will issue an updated driver soon. The ball is in their court now.
Their latest driver should run Unreal OK. The framerate isn't very good, and there will be a lot of "stuttering" since texture downloads are very slow on this hardware. Some users are reporting that creature polygons appear corrupted. Hopefully nVidia will fix thie error in their driver.
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.
They have a beta Direct3D driver which runs Unreal pretty well (though it doesn't appear to be available for public release yet). Multitexturing currently isn't working with Unreal, because of a hardware limitation (it can't multitexture a paletted base texture map along with a non-paletted light map).
There isn't any reason to use Direct3D for Voodoo2, since we support Glide natively and that tends to be more stable and faster, but their latest Direct3D driver does run Unreal pretty well. Their detail texture 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.
Works well with their internal beta Direct3D driver. Not sure when this will be available via the web.
Works pretty well.
Works pretty well.
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.
The others should be playable pending public release of improved Direct3D drivers for their hardware.
On Permedia, Riva 128, and Rendition, you may get better performance using Unreal's software renderer, especially if you have a Pentium II class processor. This isn't such a bad thing, because the software renderer supports all of Unreal's key features, including truecolor lighting and volumetric fog.
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.
To use Unreal's Direct3D support, you must have Microsoft DirectX 6.0 installed. You also need the latest Direct3D driver from your 3D hardware maker. Because Unreal uses many new Direct3D features, many hardware makers had to update their drivers for Unreal to work. Therefore, some of the drivers distributed with DirectX 6.0 have problems with Unreal (crashes or visual anomalies). Here are driver download sites for various brands:
Please keep in mind that Unreal's Direct3D support is an early beta and isn't yet working reliably on all 3D hardware.
I've update the list of Known Issues, summarizing the problems people have found with 219. There are a bunch of items, but most are non-showstoppers. I'm working on them now. Overall, though, 218 is by far the best-received version of Unreal to date! New servers are popping up rapidly (50% increase in the past 18 hours), with player counts rising even faster.
After releasing the patch at midnight Sunday night, it was amazing to see how many Unreal servers had it up and running in less than an hour minutes.
It will be interesting to watch new Unreal servers spring up on the net now that our Internet play quality is under control. In the not-too-distant future, we'll have many more improvements in Unreal network play: performance enhancements, new features requested by the community, and several cool upcoming surprises. GameSpy currently shows 27 Unreal servers, and a couple thousand for Quake. Clearly, we got off to a very slow start while we learned the the ins-and-outs of Internet game programming; now Unreal is on a solid footing and we're really beginning to pick up the pace!
Level designers in the Unreal community have already started producing some great Deathmatch maps (see Unreal Resources for downloads), so we expect to see things accelerate in this area, too.
If you're using the new 218 patch, please fill out PlanetUnreal's Unreal performance survey. We'll be watching Unreal players' feedback in the survey, and looking at all the 218 bug reports sent to the unreal218@epicgames.com account. Everyone's feedback will be taken into account for future improvements to the Internet play and other features.
In an interview on Voodoo Extreme, I gave my opinion in the ongoing OpenGL vs Direct3D debate, and I wanted to add some more information here.
First of all, both our DreamForge partners working on the OpenGL support, and our Direct3D partner have both done a very high-quality job, given the constraints of Unreal and the 3D card drivers available. My feelings on the two 3D standards are based completely on their API's and the quality of drivers available.
Next, I wanted to give some more detail on the code.
| API support layer | Lines of C++ code |
| 3dfx Glide | 1711 |
| Direct3D | 3123 |
| NEC PowerVR | 4049 |
| OpenGL | 5697 |
Now, the Glide is the simplest, because it's aimed at the Voodoo family of 3D cards, which are very standard and straightforward to support. For programming to 3dfx cards, Glide is the ideal API. For people thinking "If Glide is so great, why don't other 3D cards support it?" The short answer is, if Glide supported other manufacturer's 3D cards, it would pick up all the complications involved in real-world Direct3D and OpenGL programming: Testing for core capabilities, working around driver bugs, etc.
The Direct3D code is next in simplicity. It began as a working 1600 line driver, then expanded as it was optimized and support was added for 3D cards that lack key features. The Direct3D API follows the traditional Microsoft model of being not very beautiful code, but dealing with real-world hardware robustly, by providing a capability-querying mechanism and well-tested drivers.
The PowerVR code is large because the PCX2 chip's rendering approach is very different than what Unreal was designed for. This makes the implementation fairly complex, though the next-generation PowerVR, currently on-hold in the PC market while NEC focuses on the Sega DreamCast, is a great chip that's more traditional in its architecture, and more optimal for Unreal.
The OpenGL code is large because of optimizations and support for lots of real-world hardware. If reduced to plain-vanilla OpenGL, this would probably be the simplest and most stable driver of them all, because the OpenGL API is very straightforward.
You can read the release notes and download the patch from the Patch Page! Our test session went well, and the participants (including a lot of modem players, and even some overseas modem players) reported major success with the performance improvements.
Epic's two deathmatch servers have been upgraded to 218: Deathmatch 1 and Deathmatch 2. However, since our T1 line is going to be very saturated with people downloading the patch, performance probably won't be very good on our server for the next several days.
We're gearing up for a big internal test session with 218 right now. The release date of the 218 patch will depend on the outcome. Note that 218 is not network-compatible with 217, so if you see our 2 test servers in GameSpy, please don't try to join (you won't be able to).
The latest Direct3D support is now integrated into the Unreal codebase. It will be in the upcoming 218 patch in "public beta" form. It hasn't gone through wide testing yet, but we and our partners have been testing it a lot internally on Windows 95 and 98. It's looking good on the next-generation 3D cards (Riva TNT, Matrox G200, Savage 3D), though high-level optimizations are planned that will boost performance further.
The Voodoo2 multitexture code is in, thanks to the efforts of Jack Mathews at 3dfx.
I'm doing some final Internet play testing and tweaking on the patch. My "torture test" environment is an ISP connection at 24.4K with 400 msec ping. If it's playable on that, it should be playable on anything. :) Yesterday's testing revealed a few last-minute problems that I'm working on now.
William van der Sterren provided this insight into CORBA with respect to realtime apps:
In general, CORBA causes too much overhead and latency to be a server/clients gaming protocol. This is due to IIOP's (the default inter-ORB protocol) use of TCP/IP, and the use of large packet sizes (compared to the dedicated bit-tuned gaming protocols being used in, for example, Quake2 and Unreal). Though support for IIOP is mandatory, an ORB vendor can deploy more efficient (or more secure) protocols between 'his' ORBs, optionally using other network protocols. By default, CORBA calls are synchronous (that is, the calling object is blocked until a response is received from the called object). Such a connection-oriented call is best implemented using TCP.
CORBA also supports so-called 'one-way' operations, that enable the caller to continue processing immediately after making the call - the call is non-blocking. Here, it might make sense to use UDP as an underlying protocol, provided you deal with the unreliability at the application level (the 'call' might not arrive at the client). Some specialized high-performance ORBs, such as Nortel's RCP-ORB, <http://www.nortel.com/RCP-ORB/>, use other transport protocols than TCP for one-way calls. Most ORBs implement optimized mechanisms for 'intra-server' and 'intra-process' communication (not that relevant for multi-player gaming).
I'll post more thoughts on the topic in the future. With Unreal, distributed object models are already playing a role in multiplayer gaming, but only in a "tip of the iceberg" sort of way. This kind of technology will expand very interestingly in the future.
Linux Games has reported a way to run the existing version of Unreal under Linux, using the Wine Windows emulator for Linux. They've included a screenshot and more information at this Unreal in Wine page.
Want to see something cool and unique that's being done with the Unreal engine? Check out the Hired Guns preview. The Devil's Thumb team is really pushing the engine, and has implemented a beautiful user-interface design featuring multiple game windows. I look forward to playing this game. (Thanks PlanetUnreal for pointing out the preview).
I went ahead and modified Unreal's streaming protocol to read and write bit-oriented streams rather than byte-oriented streams. This has led to an additional increase in bandwidth efficiency. Compared to 217, upstream bandwidth is now utilized 25% more efficiency, with downstream bandwidth boosted by approximately 35%. I've also been tweaking the priotitization of actors, and gaining some incremental improvements in smoothness from that. I really look forward to releasing the new patch in a few days and hearing what people think!
Unreal's separation of network support into three layers, UnrealScript replication/RPC, the low-level transport protocol, and the TCP/IP driver, has really made the optimizations manageable. While monolithic C-style code has a reputation for being more optimizable than a layered, object-oriented design, the experience I've gained on Unreal mostly indicates the opposite. It's great to be able to rip out one module (like Unreal's low-level transport) and replace it with a better and more efficient implementation, without breaking all the code it interfaces too.
I've chatted with several people lately who have added insight to the discussion of multi-language programming and networking. One interesting topic mentioned was using the CORBA protocol to coordinate network games. CORBA is a high-reliability protocol with a fairly high amount of overhead and latency, due to its exacting nature and use of TCP. I see CORBA as a very suitable protocol for network game backbones. For example, if you were doing an Ultima Online style world with multiple servers that stay in synch, CORBA would be good for linking servers together in a high-reliability, non performance-critical way. But, CORBA isn't suited for an actual realtime modem-based gameplay protocol, since it's TCP based (which adds terrible lag under lossy conditions), and the protocol has enough overhead that it's not going to be able to handle large amounts of data over the modem.
AWT is a graphical user-interface layer for UnrealScript, which has been making some cool progress lately.
I've received a bunch of tips from two Unreal enthusiasts. Congratulations go to Mek @ PlanetUnreal and RisingSun for discovering and verifying two holes in Unreal, and to Mike Lambert for suggesting a potential third one. Also, thanks all the players who provided observations they saw of potential cheating online. I'll write more about these techniques after the next patch has been released, and the holes plugged.
In the meantime, if you too have figured out how to cheat in Unreal, pat yourself on the back, you outsmarted me! But also, please resist the temptation to cheat on the public deathmatch servers...it spoils the fun.
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/
I've seen two reports that people have found a way to cheat in Internet play. One person reported seeing a little tiny 1-inch tall player walking around named "LilTinyChessPiece", and another reported a player who never took damage. I've been scouring the code, and haven't found any holes which would enable this kind of cheating, but I'd love to hear if anybody has found a way.
If you find a way for players to cheat or crash servers over the Internet in Unreal, please email me. The first person to report a particular security hole in Unreal will receive credit and thanks here for helping to protect the Unreal community from cheaters.
People who cheat in Deathmatch are lamers, but people who are motivated by simply discovering ways to cheat are doing valuable research.
Note: I don't consider the following things Unreal cheats:
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:
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.
friend FArchive& FVector::operator<<( FArchive& Ar, FVector& V )
{
return Ar << V.X << V.Y << V.Z;
}
For programmers just learning about object-orientation, a must-read is: Design Patterns: Elements of Reusable Object-Oriented Software (Addison-Wesley Professional Computing) by Erich Gamma, Richard Helm,
Added by Hyper: Continue to oldest news