Unreal vs Source.

[aevirex]

So this is really new to me that you open Unrealed hit a button and have a map

It is not like you open the new Material Editor and can't edit anything (if you want to I'll make a screenshot of the MatEd). About the power of the new engine, I (Hourences was involved) was able to implement a technique that saves up to 12,5% (actually more due to DXT compression) of the texturesize on your hdd on the first day I started with UE3 (no, knowledge of UE2.5 doesn't help much with the new MatEd).

One thing that makes Source popular among mappers is imho the inability of most to do prefabs in programs like Max, Maya, ... If you want to make a decent map for UT2K4 you need custom models and textures. Tbh I think most things can be achieved with both engines, it is just the time you lose to things that are not important when you want to design a level.

At the end, take the number of sold licences...

[von*ferret]

Go with Source - it is harder to work with at some parts but you at least understand what it does. I don't know too much about the Unreal Engine it self and less i do know about UE3 but I know that it is a satisfying feeling to know every number you put in a vmt file yourself by name and can adjust everything as you need and wish, while some of the newer sdks seem to go into the direction of a "let's throw together some prefabs"-editor. It is the difference between writing html and a php backend your self or going to myspace and click on a template and make it extra uggly...

You obviously don't understand completely the level of customization and editing that goes into anything you put into unreal. And why it is more superior than source is that even if source had the level of power Unreal has, its not wsiwyg. In unreal you see your changes immediately. Source you still have to save and exit out of separate files to see your changes. Unreal's package is simply put together better. Everything is accessible from the editor. Other then photoshop and a modeling program, the editor does it.

[hessi]

i remeber saving dds files put into some package and while somebody changes the package you didnt see a change in your max or maya editor. so its not that perfect. when i change a tga and just click 1 button my model is updated. without having to re-/unpack.

though i think we discussed WYSIWYG. technical limits due to technical decissions. and decissions means there people thinking of a problem evaluating all possibilities and then chosing the one that fits the best. unreal did take its fast all in one package while source takes its raytracing and radiosity features which results in a not 100% WYSIWYG

though i dont miss a lighting preview in my editor. i already know when a lightsetup works or not. though if something does not fit i can recompile. if you are a tweaking pussy and change things 100 times you wont be happy (of course) but as long as you are having experience you maybe need to compile 3 times to get a perfect/acceptable look of something. and even then: you can compile a single region if the overall process takes too long. copy paste stuff into a temp file and you are done.

reloading resources in hammer works not 100% smooth. reloading materials works fine but reloading models isnt supported at all. thats something valve could work on, but as i would possibliy agree with their management: as long as we can live with those handycaps and make a great game we dont change it and spend more time on the game itself.

maybe thats why unreal games are kind of lame (ctf, dm and thats all) while halflife has always been a freaking cool story.

[ReNo]

maybe thats why unreal games are kind of lame (ctf, dm and thats all) while halflife has always been a freaking cool story.

Or maybe its because UT games are multiplayer focused, and HL games are single player focused? UT doesn't really need a story, as it isn't a story driven game. Besides, it's crazy to suggest that spending time on tool development is somehow going to be to the detriment of a game's story, I can't imagine the tool programmers are the ones penning the script.

[von*ferret]

How does an easy pipeline that allows you to quickly update and import models and materials hinder a story development? There are plenty of games that us Unreal tech that does a great job telling a story/driving singleplayer game mechanics. Look at gears. While the story is pretty generic, it did its singleplayer game enormously well. Its DM maps are amazing to boot.

[Pericolos0]

maybe thats why unreal games are kind of lame (ctf, dm and thats all) while halflife has always been a freaking cool story.

that not true at all? Do you realise how many games use the unreal engine? Only a small fraction of those are multiplayer shooters. I don't believe the story of a game has anything to do with the level editing tools provided.

[hessi]

i was talking of unreal tournaments and shizzle those games that provide the engine so ppl can use it for their mods.

[Rick_D]

this thread is gay.

[hessi]

then why do you post or even look in here? D:

[Hourences]

Source not being 100 percent (or actually 10 percent) WYSIWYG-thing because it has radiosity and the like is absolute rubbish. Its simply because the tools were badly designed, not because it can handle radiosity.

What does radiosity matter in the end? Once lighting has been baked into lightmaps it doesnt make any difference what kind of lighting it was, for example if it had radiosity or not, because its just baked into an image and projected onto a wall. Unreal does exactly the same, Unreal already uses lightmaps since 1998 and already managed to show lightmaps in the viewport back. Blaming the radiosity is lame.

And you may be able to set up your lighting blindly, I often do my lighting blind in Unreal too, but the average guy cant do this, and the inability to simply quickly check his lighting can be a huge hassle for such person. You do not only design tools for the experienced people.

Regardless if you can or cant light a scene out blindly, a preview is NEVER bad to have.

And the story has totally zero to do with the tools.

And a thing not discussed yet is Kismet, visual scripting of gameplay and other elements in a level. You make pawns do stuff by adding event and action nodes and connecting them.

[Rick_D]

Because you guys are just arguing aimlessly because you like different tools, and the OP wanted some UED forums, not a debate about UED vs Hammer, two totally different editors for two totally different engines.

[JamesL]

I disagree Rick, and I think you're talking about the thread below this in the forums. Spellbinder created this thread so we _could_ argue about exactly this

I have used Hammer, Radient, Serious Editor, Renderware and a crapload of other bespoke editors/packages, but I've never touched Unreal (yet). Listening to others somewhat passionate descriptions of each and why they love/hate them is very interesting. Keep going pls lads.

Out of interest are there are Modern Warfare (CS basically) type mods for Unreal? Fu*king Space Marines do my head in.

[Pericolos0]

What does radiosity matter in the end? Once lighting has been baked into lightmaps it doesnt make any difference what kind of lighting it was, for example if it had radiosity or not, because its just baked into an image and projected onto a wall. Unreal does exactly the same, Unreal already uses lightmaps since 1998 and already managed to show lightmaps in the viewport back. Blaming the radiosity is lame.

I disagree here. Something about unreal lighting I never liked is that it always has this typical unreal look. It tries to emulate radiosity like shadow effects in corners but ends up more cartoony looking. The lighting may be baked in both engines, but they look alot different. Source's lighting model is incredibly realistic, to such extent that it even uses the colors of materials for reflecting light of surfaces. point a light at an orange wall and it will reflect orangy light on the rest of your environment.

And you may be able to set up your lighting blindly, I often do my lighting blind in Unreal too, but the average guy cant do this, and the inability to simply quickly check his lighting can be a huge hassle for such person. You do not only design tools for the experienced people.

Then why do so many beginning mappers seem to not have much problems with creating decent looking lighting in their source maps? The radiosity model makes your lighting always almost look nice, you don't have to do retarded things like placing omni lights in shadows to make them look right etc.. When working on a source map, you'll be tweaking your light setup, but definitely not as much as the tweaking you need to do in an unreal map.

[Hourences]

Ha

I disagree here. Something about unreal lighting I never liked is that it always has this typical unreal look. It tries to emulate radiosity like shadow effects in corners but ends up more cartoony looking. The lighting may be baked in both engines, but they look alot different. Source's lighting model is incredibly realistic, to such extent that it even uses the colors of materials for reflecting light of surfaces. point a light at an orange wall and it will reflect orangy light on the rest of your environment.

This is totally next to the point. Your argument is an artistic argument about which of the two looks nicer, and yes radiosity obviously looks nicer. The point however was the Source doesnt show lighting in the editor and the reason given for that was "it has radiosity" which I countered by saying that technically there shouldnt be anything that holds the engine back displaying lighting in the viewport because in the end, it are only lightmaps..whats on the lightmaps and which engine produces nicer looking lightmaps is an whole other discussion.

Then why do so many beginning mappers seem to not have much problems with creating decent looking lighting in their source maps? The radiosity model makes your lighting always almost look nice, you don't have to do retarded things like placing omni lights in shadows to make them look right etc.. When working on a source map, you'll be tweaking your light setup, but definitely not as much as the tweaking you need to do in an unreal map.

Good, so then youre either saying:

A.) That if Source did had lighting previewing then the Source levels would look even better and could be made a lot quicker than now. What I mean is that if people can get lets say 8/10 quality using a retard system, what would happen when they would put the same amount of work and time in a highly efficient system? 10/10? And that wouldnt be a lot better?

Or

B.) That lighting previewing wouldnt be a great addition to the engine and is useless because your current setup also works "just fine"? Apperantly the whole world thinks differently because alot of developer tools are becoming increasingly WYSIWYG.

I dont know how many times you tweak your lighting in Unreal but I usually place a light blindly, change all numbers just once, rebuild, tweak them and Im done but of course Im not the average developer.

I only tweak lights an average of once or twice after placing AND I can tweak these lights in matter of minutes. In Source you need to wait quite a while, boot up the game and so on. Even IF you have to tweak your lighting less in source than it would still take you more time to adjust it since I can tweak everything in nearly real time. In the time I need to tweak my light 20 times and check the results you just did so once, hows that for efficiency.

What a lot of tool and engine programmers fail to realize is that every single second and every single mouseclick is important. And I critize Unreal for that too. There are a lot of tools and features in UE3 which are highly unoptimized and take too much time to use. If a simple and often used tool requires two seconds then thats one second too much, and on the course of an entire level a designer can lose up to an hour or more that could have been invested in actual polish and development. Every click and second matters.

[Pericolos0]

Ha

This is totally next to the point. Your argument is an artistic argument about which of the two looks nicer, and yes radiosity obviously looks nicer. The point however was the Source doesnt show lighting in the editor and the reason given for that was "it has radiosity" which I countered by saying that technically there shouldnt be anything that holds the engine back displaying lighting in the viewport because in the end, it are only lightmaps..whats on the lightmaps and which engine produces nicer looking lightmaps is an whole other discussion.

Yeah I might have mistook your point there . I don't disagree with you that displaying lighting in the editor is so much more useful. The reason I havn't been doing more unreal mapping is because I'm still spoiled by HL2's lighting

Good, so then youre either saying:

A.) That if Source did had lighting previewing then the Source levels would look even better and could be made a lot quicker than now. What I mean is that if people can get lets say 8/10 quality using a retard system, what would happen when they would put the same amount of work and time in a highly efficient system? 10/10? And that wouldnt be a lot better?

Or

B.) That lighting previewing wouldnt be a great addition to the engine and is useless because your current setup also works "just fine"? Apperantly the whole world thinks differently because alot of developer tools are becoming increasingly WYSIWYG.

Point A obviously, Placing my lights in hammer would be so much nicer if I had a lighting preview of my previous compile.

I dont know how many times you tweak your lighting in Unreal but I usually place a light blindly, change all numbers just once, rebuild, tweak them and Im done but of course Im not the average developer.

I only tweak lights an average of once or twice after placing AND I can tweak these lights in matter of minutes. In Source you need to wait quite a while, boot up the game and so on. Even IF you have to tweak your lighting less in source than it would still take you more time to adjust it since I can tweak everything in nearly real time. In the time I need to tweak my light 20 times and check the results you just did so once, hows that for efficiency.

What a lot of tool and engine programmers fail to realize is that every single second and every single mouseclick is important. And I critize Unreal for that too. There are a lot of tools and features in UE3 which are highly unoptimized and take too much time to use. If a simple and often used tool requires two seconds then thats one second too much, and on the course of an entire level a designer can lose up to an hour or more that could have been invested in actual polish and development. Every click and second matters.

true, level editing tool definitely need a scripting language like in 3d studio max (maybe some already have?) where the level designer can make easy macro scripts himself for stuff he often uses.

Anyways no point in writing a book here, I agree with most of the stuff you say!