Phosphor Alpha Tech Demo 09x

[DemoCoder]

Well, my reason for preferring it is that Quake engine games simply seem to react quicker. When I press the fire button, or move, I feel like I actually did it at that moment. I do not feel "disembodied" and "floating" within the game world.

When I play Unreal engine games, I have this feeling like I am Michelle Kwan ice-skating through the world. When I fire weapons, I don't feel instant feedback. Other players also don't seem to react as fast either. I don't think it has anything to do with movement speed either. Something about the Quake engines makes me feel "grounded", it's hard to explain.

I'm not saying that Quake is a better *GAME*. The game, in fact, sucks ass. If it weren't for 3rd party licensees and mod-makers, I think the Quake series would have killed Id. But the engine is rock solid and netcode feels better IMHO.

No way does Unreal work better at 28.8k. At 28.8k, every byte counts and roundtrip time is a killer. Unreal's state replication scheme wastes latency and bandwidth compared with the way Quake encodes packets, because it is more general. This leads to a much longer prediction/client side simulation window, which gives that "disembodied" feeling.

Quake has client side prediction as well, ever since QuakeWorld and "pushlatency". But the amount of prediction latency required, I think, is lower. The more you have, the more out of sync you are with what's actually happening.

 

[KimB]

When I play Unreal engine games, I have this feeling like I am Michelle Kwan ice-skating through the world. When I fire weapons, I don't feel instant feedback.

This is precisely why I prefer the Unreal engine games. I always found that they gave me more feedback as to what the lag actually was, allowing me to adjust my gameplay accordingly. With the Quake-engined games, I had a much harder time attempting to judge where people were, because I didn't get any immediate feedback as to what the actual lag was.

And as for playing on the 28.8, I guarantee you it was better in Unreal/UT. The main reason is that in Half-life and Quake2, particularly, I had an exceedingly-hard time keeping a stable connection (The connection was at 28.8, btw, not because of my modem, but because of the phonelines...meaning it wasn't just 28.8, but unstable 28.8).

 

[antlers]

I certainly didn't want this thread to become a UT vs. Q3 flame war. I will cheerfully acknowledge that JC is probably the best at some of the specific "hard" problems in building an engine. I just wanted to point out that TS produced a very nice game development platform with architectural features that have allowed it to "age" very gracefully.

 

[jb]

Unreal's netcode is based on a state replication paradigm which makes it very easy to program, but which makes it also very easy for mod makers to screw up by replicating too much or inappropriate information. It also isn't as efficient as hand coded packets.

Actaully network replication is the #1 issue mod makers have with the UT code. Its hard to understand, difficult to implement and impossible to master All joking aside its a big issue and the most common topic that is posted about it the Scripting forms. I dont know how many times I have thought I understood it only to find YAC were I have to change my thinking in order to get the stuff to work in a network game. Heck I have soo wanted to do a single player style just to avoid replication issues

I do agree with you as I too have notice that every quake based game I have played feels fluid in on-line games where as UT games still feel a pit "pooky". UT2k3 is suppose to make even more inprovements on this so we shall see....

 

[alexsok]

I certainly didn't want this thread to become a UT vs. Q3 flame war. I will cheerfully acknowledge that JC is probably the best at some of the specific "hard" problems in building an engine. I just wanted to point out that TS produced a very nice game development platform with architectural features that have allowed it to "age" very gracefully.

That's correct.

The Unreal engine was built in such a way that u could update all or most of it's components without actually rewriting it (i remember reading on one interview a long time ago where Tim said that u could do absolutely massive changes to the renderer, without actually rewriting it).

With that said, the Unreal II engine contains quiet a bit of new code and many components have been either updated or rewritten, to the point that some people and websites call it "new engine".

 

[antlers]

The Unreal engine was built in such a way that u could update all or most of it's components without actually rewriting it (i remember reading on one interview a long time ago where Tim said that u could do absolutely massive changes to the renderer, without actually rewriting it).

Well, Unreal shipped with a software renderer, a PVR renderer (soon abandoned) and a Glide renderer. Later came a D3D renderer, a Metal renderer, and an OpenGL renderer (followed by a completely different OpenGL renderer, and another).

 

[alexsok]

Well, Unreal shipped with a software renderer, a PVR renderer (soon abandoned) and a Glide renderer. Later came a D3D renderer, a Metal renderer, and an OpenGL renderer (followed by a completely different OpenGL renderer, and another).

Yeah, but the core renderer remained pretty much the same... although it underwent through some major changes.

 

[DemoCoder]

Quake also had pluggable renderers.

 

[alexsok]

Quake also had pluggable renderers.

Yep, but there weren't many of them...

Unreal on the other hand had too many of them!

 

[Bigus Dickus]

Well, my reason for preferring it is that Quake engine games simply seem to react quicker. When I press the fire button, or move, I feel like I actually did it at that moment. I do not feel "disembodied" and "floating" within the game world.

That feeling, for me, has been in every on-line FPS at one point or another. I distinctly remember playing railgun-only (rail arena) matches in Q2, where I would hit the fire button, count "one Mississippi," and then see and hear the railgun fire. Typically, the rail trail wasn't even in my line of sight anymore, but shifted to the side. Very difficult to get good that way.

That was on a T1 connection, btw, and I've really noticed no difference between Q2, QIII, and UT as far as how lag is perceived. When connecting to a server with a high ping, they all feel equally "disembodied." Even so, UT always had the best gameplay, depth of immersion, and the ability to use such widly varying strategies during multiplayer matches.

 

[DemoCoder]

I never play regular UT or Q3. Even on Q1, Q2, I always played mods. Threewave CTF, Counter-Strike, Team Fortress, Rocket Arena. Basically, I find playing against bots boring, and regular DM or CTF is boring as well now. I don't really like UT's mix of weapons.

UT might ship out of the box as a better game, but it's still dwarfed by Quake mods like Counter-Strike.

BTW, I never had the pausing/delay problems you sited, even when I only had 64k ISDN. I did however had *huge* problems with Unreal net-play when it first came out. Let's not mention the problems I had with non-glide based vid card performance. UT is now more polished, but Quake has been solid for alot longer.

 

[Bigus Dickus]

Well, I don't like playing against bots either... so that part of the equation is a non-issue for me. I play mostly CTF now, and played a good mix of DM and CTF in the Q2 days. I didn't play much Unreal, so I can't compare it's play with the others.

What I can compare is UT, Q2, and QIII, and I have never noticed a discernable difference in the way lag behaves, not in the past three or four years anyway.

Gameplay and weapons is, naturally, a personal preference. But ID's games just aren't "magical" when it comes to connecting to a high ping server... if the latency is high, it's just high, and you'll feel it.

BTW, wasn't CS a Half-Life mod?

 

[Saem]

BTW, wasn't CS a Half-Life mod?

It uses either the Quake or the Quake2 engine.

A lot of folks will say there were a lot of changes and additions, in actuality there was little or no change to the engine and it was a whole lot of game code.

 

[Nagorak]

I guess I would sum it up like this:

JC = Depth in one area (e.g. visibility, lighting)
TS = Breadth in many areas, modeling, animation, special effects, tools, etc

Actually, I more or less agree. JC tries to make his engine really good in a few areas, meanwhile TS tries to make the most complete engine possible even including Lipsinc support, hehe.

UT might ship out of the box as a better game, but it's still dwarfed by Quake mods like Counter-Strike.

Ok...I'm sorry but Counter-Strike wasn't successful because it used the Quake2 engine (except maybe that it could run a PoS 200 MHz Pentium). Suggesting that is just ridiculous. If Half Life had been based on the Unreal engine, then I doubt the success of CS would have been seriously hindered.

I can't really relate to your complaints about lag in UT. I've never had any issues with it. It seems to play just about equally to Quake II (I can't compare 3 because I can't stand to play it even on a LAN, let alone online).

As to who has more licensees...does anyone know where we can find a list?

 

[KimB]

Only Tim Sweeney has nothing to do with the artist side of things (just like JC doesn't...).

I think Tim Sweeney is better at pure "computer science." That is, he's better at designing the programming interface for those who develop for his engine. Personally, I think that this is more important in the long run (And is something that I certainly feel John Carmack will need to get just as good at...), as when programs lengths increase, so does the challenge in programming. Only in designing a complex program in an extensible and flexible fashion can that program be put to maximum use as it expands.

That is, given a limited amount of man-hours developing for a very complex program (including graphics, AI, netcode, physics, etc.), the program that is designed to be easier to extend will be better in every way, assuming that the same design concepts go into the program, of course.

 

[DemoCoder]

Designing APIs isn't computer science, it's software engineering/architecture.

 

[KimB]

Computer science mostly deals with the fundamentals of computing, the fundamentals of computer languages, and so on.

It's the fundamentals of computer language part in which I feel Tim Sweeney has the lead on John Carmack.

 

[DemoCoder]

You mean theory of computation/automata theory. Maybe TS is better, but I doubt it. Carmack wrote his own scripting language for Quake1. It was a quick and dirty hack to get the job done. For Quake2, Carmack fell back to C++ since the quake scripting language was too slow and too primitive. He didn't want to spend so much time on a scripting language just to duplicate what C++ could give him, as long as you need not worry about downloading rogue dll's that will kill your computer.


Then for Quake3, he went to a VM approach with C again, to get safe client downloadable code, only he didn't write it. The fact that he didn't write it doesn't mean Carmack doesn't have the knowledge or skills to write it, just that it's not worth the effort to duplicate work that's already done in the open source world.

I could write my own XML parser if I wanted, or my own JavaScript interpreter, but I don't need to, because they are already provided. Carmack could use EcmaScript/JavaScript for DOOM3 by using the publically available Rhino libraries from Netscape/Apache. The fact that he didn't bother implementing a javascript runtime himself is no comment on his capability as a programmer.

In fact, I would say that Sweeney wasted his time putting so much effort into UnrealScript when there are plenty of suitable language standard open-source interpreters/vms floating around that he could have just taken and modified. It likely delayed Unreal significantly. The result is nice, but all the effort was hardly justified I think. It's like reinventing Java or .NET. There's hardly any point, and there is no real innovation in UnrealScript that other languages don't already have.

In fact, there is nothing really difficult about writing scripting languages. Once you understand the basics of parsers and syntax representation, the rest isn't rocket science, just tedious. The basic process is well understood and taught on freshmen/software college CS level. That's why so many languages exist.

On the other hand, efficient visibility determination and global/unified lighting algorithms are an area of continuing research. These are not taugh in undergraduate Computer Graphics classes. Education in this area comes from reading research papers and engaging in actual research.

 

[KimB]

In fact, I would say that Sweeney wasted his time putting so much effort into UnrealScript when there are plenty of suitable language standard open-source interpreters/vms floating around that he could have just taken and modified. It likely delayed Unreal significantly. The result is nice, but all the effort was hardly justified I think. It's like reinventing Java or .NET. There's hardly any point, and there is no real innovation in UnrealScript that other languages don't already have.

Well, according to Tim, the main reason he decided to put the scripting language into the game was because he felt none of the existing languages translated well to games.

One of the main things that he introduced, if I remember correctly (this is remembering from interviews, btw...I haven't looked at more than a few dozen lines of Unreal Script, let alone programmed any), the main one among them is the concept of state. That is, built-in ways to perform different behavior when the object is in a different situation.

In other words, TS designed the language to be elegant in the way it is used in programming for a game.

 

[antlers]

Democoder makes it sound like Unrealscript is just any scripting language. Yet it's probably the primary basis for all of Epic's licensing success (which is considerable, although surpassed by id's). It combined a Java-like VM (fast enough to run the AI code) with Simula-like states and a network-transparent call model that was eventually quite efficient. Also supported persistence and class versioning. All wrapped up in a nice IDE. It's a little bit beyond the capabilities of Javascript or any other off-the-shelf scripting language.

The object model built in Unrealscript was quite successful as well. The Unreal engine is incredibly customizable without having to modify any native code at all.

Yes, JC focused his efforts in different areas. That doesn't mean one is right and the other is wrong. They have both been very successful (although JC was successful sooner).