Phosphor Alpha Tech Demo 09x

Yes, but he could have easily taken the grammar and runtime for an existing language and adapted it (i.e. what NVidia did with Cg) Adding "state" is, is just another way of doing polymorphic dispatch. You're just selecting which method to execute based not only on the runtime type of the object it is invoked on, but also the "state" it is in.

I'm just tired of people rolling their own completely new syntax for yet-another-programming-language. Build on the existing foundations I say.
 
antlers, I'm not saying JavaScript off the shelf fulfills the need, but you can take off the shelf grammars and runtimes and modify them to suit your needs.

UnrealScript has some nice concepts, but was it really needed to deliver Unreal? The most popular online FPS in the world right now is Counter-Strike, and it is written as a DLL in C. For all the nice features UnrealScript delivers, it hasn't been able to overtake any of the Quake mods in popularity.

So editing and making Unreal mods might be supercool and easy, but I highly doubt it is delivering such significant development and time-to-market benefits that licensees would choose Unreal engine over ID because of it.

More over, if it made mod development so clean, elegant, and easy to do vs writing a C++ or C mod for Quake engines, why aren't there significantly more awesome mods for Unreal vs Quake? You'd expect hobbyist devs to flock to the best development platform, right?


It's a question of where you put your resources. Game players care about visuals and gameplay, not what language the game was written in. Sweeney spent a significant amount of time trying to write a cool development platform, and not enough time making Unreal the best looking engine. Unreal2/UT2k3 is going to get blown away by Doom3 engine titles, and even if Doom3 mod development sucks and is drudgery and a pain, Doom3 mods will still be more impressive. Game players won't care that "writing scripts for UT2k3 is cool, and look at all these features of the dev platform". They will simply look at D3's visuals and look at UT2k3 and there will be a huge differential.

I think we've all played the leaked UT2k3 demos, and I've got to say, frankly I am unimpressed.

I think Monolith/LithTech made the same mistake. So much time spend on engine features that they could put on a marketing "check list" for developers, and not enough time spent on improving the core visualization algorithms.
 
nVidia is hardly using an existing runtime for Cg :)

UnrealScript is probably about as close to Java as Cg is to C.


Yes, language-level support for states isn't magic, but neither is hand-coding a network protocol.

What might be magic is knowing that it's a good idea to put a byte-code compiled, object-oriented language with language-level support for states and network transparency at the core of your game engine.
 
antlers4 said:
nVidia is hardly using an existing runtime for Cg :)

UnrealScript is probably about as close to Java as Cg is to C.

No, but they are using a modified C/C++ yacc grammar for Cg. Cg's syntax is a modification of the C grammar with C++ bits thrown in (some stuff added, some stuff removed). You can go get the Cg compiler source code yourself and look at the yacc grammar vs the ISO grammars.

Of course the runtime isn't the same. The ANSI runtime is not for GPUs. NVidia had to provide their own runtime library for GPUs like normalize(), etc.

What might be magic is knowing that it's a good idea to put a byte-code compiled, object-oriented language with language-level support for states and network transparency at the core of your game engine.

It's a no brainer if you have the resources to devote to it. Every single game engine I have seen has had its own scripting language going back to the days of MUDs. They are usually either LISP based, TCL based, C-syntax derivatives, or in the case of Tribes, looks like Perl/PHP.

But IMHO, Epic hasn't spent enough resources on making Unreal a state of art 3d engine visually. Is Epic a middleware company, or a 3D engine company?

Depth, rather than Breath, like I said..
 
Actually, there are significantly more awesome mods for UT than Quake. Basically, all the good mods for Quake were also done for UT (because it was much easier), plus some more mods as well.

I won't argue that Counterstrike is the most popular FPS--but I will attribute that entirely to the incredible popularity of Half-life and the fact that Half-life was the first game that made net play possible for the brain dead, or perhaps I should say, Internet newbie. (Half-Life's popularity, in turn, I'll attribute not to the underlying technology--very good technology, though it was--but to the game design.)

I think the investment in tools did pay off for TS, not in Unreal, but because it got Epic into the licensing big leagues despite a lot of disadvantages that Epic had relative to id--no FPS track record, initially poor netcode and Direct3d support--and a smaller publisher backing them up. If Unreal didn't have the tools, Epic would be remembered now as the studio that developed that pretty FPS also-ran.
 
DemoCoder said:
But IMHO, Epic hasn't spent enough resources on making Unreal a state of art 3d engine visually. Is Epic a middleware company, or a 3D engine company?

I think with UT 2003 and Unreal 2 (and maybe even America's Army?) Epic might be state-of-the-art on the PC for a little while at least.

Perhaps you disagree--I actually don't play that many games. Are there better looking ones available for the PC?
 
I'm willing to bet that Unreal Tournament 2003 will be state of the art until Unreal 2 (which has more of a focus on pretty graphics than high framerates), and Unreal 2 will be state of the art until DOOM3, but even then U2 will have some things over DOOM3 (in particular polycount, though I think I'll prefer DOOM3's shadows and realistic lighting...).
 
DemoCoder said:
UnrealScript has some nice concepts, but was it really needed to deliver Unreal?

Nope not at all. However at that time Tim new that with Uscript it will give developers and mod authors the tools they need to quickly develope new content. So it gave Unreal self life via its mods/licensing


The most popular online FPS in the world right now is Counter-Strike, and it is written as a DLL in C. For all the nice features UnrealScript delivers, it hasn't been able to overtake any of the Quake mods in popularity.


CS popularity has nothing to do with the code base. The aging HL (modify q1/q2) engine helped as it did not put heavy strains on the users PC thus the average Joe sick pack's PC could play CS on his PC which was not top of the line. Also as we have said the network play was very smooth. These helped to make CS an option for more of the community. If you look at the vale page where they have the results of the hardware survey you can see that a majority of the users are using GF2mx cards!

CS introduced many new elements that had been absent from on-line gaming. Something about playing as the good guys vrs bad guys thing appeal to people. So I feel that CS popularity is more based on the ideas and features the mod itself had vrs the code base.


So editing and making Unreal mods might be supercool and easy, but I highly doubt it is delivering such significant development and time-to-market benefits that licensees would choose Unreal engine over ID because of it.

Well look at America's Army. Here is a new game that's out now before Epic gets their version of UT2k3 out. That shows some time to market savings of the Unreal style :) Also you have other games coming based of the UT2k3 engine (Y project, unreal2, splinter cell and raven sheild for example).

More over, if it made mod development so clean, elegant, and easy to do vs writing a C++ or C mod for Quake engines, why aren't there significantly more awesome mods for Unreal vs Quake? You'd expect hobbyist devs to flock to the best development platform, right?

Well there are :) Actually I know of 3 mods for UT that have went professional. Only one is public info and that was Tac Ops. The other two I can not say for now. But the UT community has had more mods/mut developed for it vrs the Q3 base. Not saying that Q3 mods were not as good. There just was not as many which kind of helps to understand why people like Unreal Script. And no I am not talking about one guy releasing 30 mut that do basically the same thing. I am talking about the number of different mod teams out there.

However UT has limits that some mod teams did not want to deal with. 300 world ploys is about the max you can have before frame rates go into the crapper. Then you have to base a lot of your artwork of 256 color textures which is just ugly. Replication is a pain with UT. Ect...


It's a question of where you put your resources. Game players care about visuals and game play, not what language the game was written in. Sweeney spent a significant amount of time trying to write a cool development platform, and not enough time making Unreal the best looking engine.

I talked to Tim about this and he said that was not his goal with UT2k3. Epic has went to considerable length to make UT2k3 more friendly for mod teams and developers and that is very good thing. As a leader of the mod team I have had access to the restricted area of the UDN for some time now. We are not the only ones either. This helps us to understand the changed and hit the ground running. We have been given some hands on training and a chance to talk to Epic staff one on one and in groups on all sorts of issues regarding the new engine. The self life of any product will be very short if you don't support you development community. Sweeny knows this and has taken this support to the next level IMHO and that is a very wise thing to do.

Besides looks arent everything. You have a lot more to worry about. Like AI, how does AI differ in the two? Phyics? Perfromance? Network Play? Lots of other things to consider.

I am sure game developers that have used Quake engines in the past will stay with doom (Raven). I am sure developers that have used Unreal will stay there too (Ion Storm). However its the new people that will be interesting to see where they go. You have 4 new groups already coding on the new Ut2k3 engine so that shows at least a start (again AA, Y Project, Splinter Cell, Raven Sheild)



Unreal2/UT2k3 is going to get blown away by Doom3 engine titles, and even if Doom3 mod development sucks and is drudgery and a pain, Doom3 mods will still be more impressive. Game players won't care that "writing scripts for UT2k3 is cool, and look at all these features of the dev platform". They will simply look at D3's visuals and look at UT2k3 and there will be a huge differential.
I think we've all played the leaked UT2k3 demos, and I've got to say, frankly I am unimpressed.

First of all I think its foolish to say that when you have only played leaked builds that were far from complete. I have had a chance to play something a lot more recent when I was at Epic. Night and day difference. Granted some areas your correct but once again look at the Q3 vrs UT debate. Q3 better engine potential for better visuals. But as it was posted here some people like UTs look. Same will hold for Doom3 UT2k3. Doom3 has an more advanced engine but that does not mean every title done on it will look better.

I think Monolith/LithTech made the same mistake. So much time spend on engine features that they could put on a marketing "check list" for developers, and not enough time spent on improving the core visualization algorithms.

Actually I think the AvP2 had some really neat things based off their engine. Sure it was not the greatest...but better in the past.


BTW my mod has been featured on both the Id Extremities CD and the GOTYE UT CD so I do have some info on the mod scene as well as coding in both games. Not trying to brag just saying a have some knowledge in the subject and I an not trying to be a fan boy and rant :)
 
jb said:
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....

Can we say excessive mod?

nice mod, hard to play on anything but a LAN though with all the packet travel it does.
 
I can't believe it...there are even engine fanboys *cough*DC*cough*.

Just because Carmack does something one way, doesn't make it the right way!

What does the Unreal Tournament engine offer over the Quake engine? If we say Quake 3 has better graphics, then the only thing Unreal Tournament has going for it is Unreal script. So, yeah, it sounds like TS really wasted his time on that...since that's probably one of the main reasons people actually licensed his engine rather than just going with id's.

The other thing the Unreal engine has going for it is the fact that it's constantly updated, whereas id's engines seem to be static releases with no updates...but we'll just leave that out of the equation.

Democoder, you're giving JC a lot of credit for things he had nothing to do with. Counterstrike and Half Life, for example, sure they're based on his engine but that is not the source of their success. For that matter, I personally feel Deus Ex was a totally better game than Half Life and it was based on the Unreal engine...so I guess we can add that to TS's tally then??? The point is, the success of these games has nothing to do with the quality of the engine.

If you want to view the success of an engine, you need to look at people licensing it. True, id still has more licensees than Epic. However, until the Unreal engine, they had virtually all of the licensees for 3d games. In the era of Doom, Quake, Quake 2 you basically had 2 types of 3D engine games: 1) id's engine, 2) propriety engine, with propriety engines being far in the minority.

If you look at the scene now that's no longer the case. It's quite common to play a game based on the Unreal engine. In fact, you'd have to go out of your way not to have played a game based on it. That seems pretty successful to me, and how do you explain that success if the Unreal engine really offers nothing over the Quake3 engine?

I'm not saying that Carmack doesn't have his moments, nor suggesting his engines are anything but good. But, both he and TS have been following their separate paths for some time now. That doesn't mean one approach is right and the other is wrong, that just means they are different.

As far as comparing their coding skills, its not even really possible to do. I'm sure their both good...but I seriously doubt one is better in all ways than the other. And for all we know there may be other programmers out there who are better.

The bottomline is id was around first, but that doesn't mean Epic hasn't also contributed to the 3D scene.
 
All I'm saying is, in 3D engines, all I care about are performance, visuals and gameplay. As a dev, I can appreciate UnrealScript, but it doesn't change the fact that ID's engines *look better* and IMHO, play better on the net. Moreover, ID engines scaled way better on 3D and CPU hardware. Unreal was highly non-scalable and a dog on non-glide systems until recently.


Yes, JC and TS have separate talents. But the subject of this board is *3D Technology* and in that, JC is superior IMHO. UnrealScript has nothing to do with 3D. It could run equally as well on a text based MUD.


If TS continues to pour effort into dev tools and not enough into the core rendering technology, his engine will become a footnote in history.

Human beings are impressed far more by visuals, and end users simply don't care about what dev tools the user's used.


BTW, don't even bring up America's Army as an example of success. I was super-anticipating that game as a counter-strike killer and network play is a total DOG. Just go read the support forums. The lag is incredibly bad on most servers. The training missions are cool, until you complete them.
 
DemoCoder said:
All I'm saying is, in 3D engines, all I care about are performance, visuals and gameplay. As a dev, I can appreciate UnrealScript, but it doesn't change the fact that ID's engines *look better* and IMHO, play better on the net. Moreover, ID engines scaled way better on 3D and CPU hardware. Unreal was highly non-scalable and a dog on non-glide systems until recently.

Yes, JC and TS have separate talents. But the subject of this board is *3D Technology* and in that, JC is superior IMHO. UnrealScript has nothing to do with 3D. It could run equally as well on a text based MUD.

Well, as I said, I think Tim Sweeney's major problem in this area was a lack of foresight when designing the renderer for the original Unreal. Primarily, I don't think he felt 3D accelerators would take off nearly as quickly as they did. Based on the capabilities of the software renderer, I have a hard time saying he isn't as good at programming for 3D graphics. Additionally, given the heavy software rendering focus, it's amazing to me that Unreal can actually compete with Quake3 graphics-wise.

So, from a certain perspective, I don't think Tim Sweeney is any less as good at programming for good graphics as John Carmack. He just doesn't have the foresight.

I think the real test on how good TS's programming talents, as they directly relate to graphics, will be after UT2k3 is released (hopefully this week we'll see the demo...).
 
DemoCoder said:
Yes, JC and TS have separate talents. But the subject of this board is *3D Technology* and in that, JC is superior IMHO. UnrealScript has nothing to do with 3D. It could run equally as well on a text based MUD.

I sort of disagree...this is about 3D technology, but isn't the true test of 3D technology what games come out of it? And that gets back to the development tools, etc. Anyway it's a moot point. ;)

Chalnoth said:
So, from a certain perspective, I don't think Tim Sweeney is any less as good at programming for good graphics as John Carmack. He just doesn't have the foresight.

Lack of foresight or just bad luck? No one really expected 3d hardware to take off, and not so quickly. Maybe his only mistake was not revising his engine prior to UT. But then again, if UT hadn't come out when it did, would Epic be in the same situation it is in today?

Anyway you could be right, I'm just playing the devil's advocate. :devilish:
 
The only thing is that UT wasn't originally meant to be a separate game, but just an expansion pack. Tim Sweeney has also broken compatibility with previous versions of their level files with the updated engine, and I would imagine it's because of changes to the renderer.

It would have been just too much work to ask people to redesign everything based on a new renderer after it was decided that UT was to be a standalone game, not an expansion pack.
 
I just have to say this... the comments above are begging me to do it... If the Unreal engine is programmed as good as everyone says it is, there shouldn't have been 'that' much of an issue to rip the guts out of the renderer. Then again... maybe not :)

Anyway, JC and TS just made different trade offs with their engines in regards to visibility. The Quake engines just preprocess a hell of a lot more than Unreal. The Quake engines always has ungodly slow map compiling times (due to vis and lighting calcs), while the Unreal was substantially better. However, at the same time Quake's hardware rendering runs faster than Unreal's. It should be remembered, like Unreal, Quake's visibility was designed for software rendering.
 
Colourless said:
I just have to say this... the comments above are begging me to do it... If the Unreal engine is programmed as good as everyone says it is, there shouldn't have been 'that' much of an issue to rip the guts out of the renderer. Then again... maybe not :)

Well, as I said in the above post, I think the reason this wasn't done for UT was for map file backwards-compatibility. It would have been nontrivial to improve the renderer while still providing compatibility with existing art.

Anyway, JC and TS just made different trade offs with their engines in regards to visibility. The Quake engines just preprocess a hell of a lot more than Unreal. The Quake engines always has ungodly slow map compiling times (due to vis and lighting calcs), while the Unreal was substantially better. However, at the same time Quake's hardware rendering runs faster than Unreal's. It should be remembered, like Unreal, Quake's visibility was designed for software rendering.

Actually, the Unreal engine does a hell of a lot more computation when it comes to visibility calculations. This is the primary reason why it doesn't scale well with video cards or CPUs. It was done in this way so that the software renderer didn't need to use any z-buffer. The portal system in Unreal/UT is also user-defined, so that the engine doesn't need to do much calculation on visibility when compiling the level (I'm not really sure how Quake-engined games handle portals, unfortunately...).

The main reason Quake-engined levels compile so slowly is due to the radiosity lighting calculations. Radiosity takes so long to calculate properly that even few professionally-rendered scenes use it.
 
Back
Top