Question about FF's programming...

[FlamingLlama]

Did you do most of this work through LUA scripting and then just embedding that in maps?
Have you had to make any significant changes to the source code, if any?

[Circuitous]

Lua is only used for map objectives, everything else is coded... and yeah, the source has been heavily modified, which is what's making the Orange Box conversion a bitch.

Jon can tell you more.

[Ihmhi]

Our coders actually fixed a lot of the Source engine bugs that were in the SDK at the time.

The problem is that all of this heavy modifying is going to make converting to the OB a real bitch, because we can't just transfer over stuff as easily. It wasn't really written the way it was supposed to be. -.-

[FlamingLlama]

I've heard it said that UT3 is suppose to be easier to mod because has it's own unrealscript language, but it seems to me that the high end potential for UT3 modding is way below that of source if you don't have access to the source code - Unless their scripting language is ridiculously powerful, and I doubt that.

Is source still a bitch to try and mod for, or has the community and documentation matured tot he point where it's worth considering over UT3?

One of the main things I like about the source engine is it's potential for photorealism in environments. Apparently some kind of radial lightmapping that UT3 or quake don't use.
The downside I noticed with source is that it doesn't have any dynamic lighting.... So I wonder if the two are incompatible (although I did notice, to my surprise, and FF has coded in dynamic lighting... Was this really difficult, or was the support already there and just had to be turned ?).

I've been thinking about creating my own simple map based mod on an original concept, and haven't been able to decide between the two engines.

Let me know if my conclusions are wrong here:
Source:
Pro: Steam distruption
Pro: Large userbase of source owners.
Pro: Able to make sweeping changes to the source code.
Pro: Photorealistic environments.
Pro: Better netcode and physics support online.
Con: Aging engine that isn't nearly as powerful as something like UT3.
Con: Poor documentation and lack of community support (so I've heard).
Con: Lack of dynamic lighting as powerful as UT3.

UT3:
Pro: Easier to get into with unrealscript.
Pro: More graphical goodies to work with.
Pro: it's considered an industry standard so learning it may help you if you later get into the business.
Con: All your maps look like overshadowed and overcontrasted paintings, where every object and playermodel has an unnatural "sheen" to it.
Con: Possibly not as much power over modding unique things, because there are limits to what you can do with unrealscripting.


Tough call. If you guys tell me that programming for source isn't that bad, so long as I'm willing to tough out the increased difficulty, then I'd probably favor making my mod on the orange box version of source. I just don't like the way any games that use UT3 look, they fail to convince me that they are real places with real objects and people.

[mervaka]

i'll tell you now, i'm learning C from the ground up in my own time, and in dabbling with C++, i can tell you its a royal pain in the arse. its not something you learn overnight. you wont get past copying and pasting stuff. i tried the same thing 5 years ago with HL1.

[Nezumi]

Gah, I still have it stuck in my head that UT3 is called Unreal Tournament 2007. So I was all like 'Don't you mean Unreal Engine 3, not Unreal Tournament 3?'

But yea. I've seen some Unreal Engine 3 games that manage to get away from the typical way Epic makes everything look, like Tom Clancy's Rainbow Kitten Adventure*, which looks a lot more realistic (if less detailed) than UT3 or GoW.


*Rainbow 6 Vegas II

[Crazycarl]

Steam distribution: no, mods don't get distributed on Steam. Valve has recently hand-picked a few mods to get hosted on Steam, but it's not automatic.

On aesthetic differences: Source can do shiny, contrasty stuff, and Unreal can do realistic; it's just the textures and the shaders that are included in the game. If you are going to do your own art for your mod, you make the decisions. If you aren't willing to do textures, models, etc, your maps will naturally look a lot like the game you are modding. Your Source maps only look as "photorealistic" as you are skilled.

The kind of dynamic light FF has has been around since HL1. It's just not used much because it has a large effect on frame rates. However they do keep updating the engine, adding HDR with EP1 and projected shadows with Orange box. Valve only adds features to Source when they need them. So if they really wanted robust dynamic lighting for some game, they'd make it work.
It's kind of pointless to rate engines on which is more "powerful". Just pick one based on what features it has, and how it meets your needs.

Documentation for the Source SDK is almost totally community-based. So unless somebody cares to write up what they've learned about modding on the wiki or elsewhere, you won't find it.

Coding: I don't know a lot about coding for either engine, but if you are doing simple things like adding a few weapons, either system should allow that pretty easily. Both will have a steep learning curve, once you move beyond tutorial level.

As for what looks good on a resume, it depends what the company is looking for. They will literally search all their resumes for certain keywords, and only read the ones that match their search. Regardless, having shipped a completed mod would be a great help in landing a job.

[trepid_jon]

I think if you're looking for a game job, you're better off with getting Unreal experience just because so many companies license that engine.

I like UnrealEd and especially its awesome sub-tools, Kismet (badass logic editor) and Matinee (badass animation and cinematic editor). But there's something about Source that always brings me back to working with it. I guess it's probably because I started "real" development with HL1, so it's what I'm used to.

Anyways, Source allows a lot of code changes, but there are still some areas of the engine that modders don't have access to. The Orange Box source code has more engine availability than the old Source SDK code, though. And you definitely have a lot more at your disposal than most of the other engines.

Honestly, I'd say go with Unreal or Crysis unless you want to do more core code changes that Source allows. CoD4 even has a good SDK, but the level exporter sucks ass and it's pretty much all scripting (which is either good or bad, depending on how you look at it).

[AaronJer]

Originally Posted by Nezumi

But yea. I've seen some Unreal Engine 3 games that manage to get away from the typical way Epic makes everything look, like Tom Clancy's Rainbow Kitten Adventure*, which looks a lot more realistic (if less detailed) than UT3 or GoW.

It's CALLED Tom Clancy's Technicolor Pirate Sweepstakes. And I still think it would look a lot more realistic with the Source engine, mostly because you wouldn't have problems like falling out of the map... things are more solid in Source, which always make it seem more realistic.

And remember that time you got half-way lodged into a box? That wouldn't happen in Source.

[chilledsanity]

Our coders actually fixed a lot of the Source engine bugs that were in the SDK at the time.

The problem is that all of this heavy modifying is going to make converting to the OB a real bitch, because we can't just transfer over stuff as easily. It wasn't really written the way it was supposed to be. -.-

That's the goddamn truth. I guess I'm a lightweight in that I don't delve in the code much, but I use the hell out of the SDK, each Civil Protection episode I make is like a minature mod for the game.

FlamingLlama: I'm skeptical that Valve has better netcode that UT3 since their games have designed to be multiplayer only ever since Unreal Tournament. It really depends on what you're trying to do as to what's the better choice for you. I make machinima and the Source engine is really a no brainer given my needs. As for your other lists:

Source:
+Great flexibility in terms of character behaviors. Faceposer is the whole reason I film in HL2 to begin with. You can have characters sit, jump, pick up and drop items, interact with their environment, etc
+Good backwards support
+Lots of existing real-world props to work with
-Valve frequently leaves bugs that never go fixed, will break existing features with updates. I actually run the Source SDK offline using an emulator so it won't auto-update on me and fuck me over like it has in the past


UT3:
+Apparently UnrealEd is easier to use than Hammer
-Unless you want to scrap it from the ground up, I think the art direction in UT3 is godawful. It's like they took perfectly good graphics, then desaturated them, blurred half the screen, and made the contrast and bloom too high
-Antialiasing can be a bitch to get working in the game and impossible on older cards
-As I understand it, requires more steps for getting scene files to playback

[Agent Buckshot Moose]

Originally Posted by mervaka

i'll tell you now, i'm learning C from the ground up in my own time, and in dabbling with C++, i can tell you its a royal pain in the arse. its not something you learn overnight. you wont get past copying and pasting stuff. i tried the same thing 5 years ago with HL1.

C/C++ wouldn't be so annoying if the compiler messages (from GCC anyway) weren't so cryptic. Oh and array bounds checking would be nice as a compiler option...

[Shadow00Caster]

QUAKE ENGINE FTW!!!

[trepid_jon]

Originally Posted by Shadow00Caster

QUAKE ENGINE FTW!!!

Boo.

[Shadow00Caster]

HOW DARE YOU BOO TEH HL's DESIGN CONCEPT ENGINE

/shame

[FlamingLlama]

FlamingLlama: I'm skeptical that Valve has better netcode that UT3 since their games have designed to be multiplayer only ever since Unreal Tournament. It really depends on what you're trying to do as to what's the better choice for you. I make machinima and the Source engine is really a no brainer given my needs. As for your other lists:

They do. Valve not only has better pings in general, but they have client side hit detection, which means someone playing a sniper in TF2 aims for the head of a jumping and running scout, and if he sees that he hits the head then the scout got shot in the head.
This is also the only kind of code that makes it possible to reasonably hit people who are dodging back and forth around corners quickly, because all you have to do is snipe them when you see them pop up.

Why other games haven't adopted this approach towards anti-lag compensation technology still baffles me.

In UT3, it's the opposite, if you pick up the sniper rifle you're forced to lead your target - not because the bullet takes time to travel - but because there is a delay after pressing the trigger before the gun actually shoots. And the worst part about this kind of lag leading is that it's never consistant, so it's not even something you can just learn to deal with. It changes from server to server, depends on how many people are in the arena, and changes based on the map type.
And if someone is dodging around corners you have less chance of hitting them than you reaosnably should because you are forced to predict when they will come out before you can actually see them.

Valve's netcode was a HUGE reason why TFC and counterstrike became so popular over other online games, and why even thier mods continue to outperform many commerical games in terms of active online players.

[chilledsanity]

They do. Valve not only has better pings in general, but they have client side hit detection, which means someone playing a sniper in TF2 aims for the head of a jumping and running scout, and if he sees that he hits the head then the scout got shot in the head.

Then why the hell is melee hit detection so off in FF? Also I have to agree if you're looking for a job in the game industry, UT3 is likely the better way to go.

[richard nixon]

I'm not sure about Llama's comment. I play UT3 all the time (on PC) and the UT3 sniper rifle is one of my favorite weapons in the game. I've never noticed any situation that when I had my crosshair on someones face and I shot and then they moved, they didn't die or get hit. I've also patched to the latest version, 1.3 I think. But I usually just run and gun and most of my kills are usually mid to sometimes long range. Or it could be because if they are running or jumping around I try to shoot a little ahead of their head but I do that in about every game so I doubt that has anything to do with it.

I have had problems with UT3 hit detection with the BioRifle, Shock Rifle's Secondary Fire, and the Link Gun's primary Fire.

If anything the sexyness of the engine would be well worth it. Better than Cryengine2 but only in performance..not looks, of course. Plus I can't even play Crysis MP because of how laggy the servers get and how awful the hit detection is.

[Nezumi]

Originally Posted by chilledsanity

Then why the hell is melee hit detection so off in FF?

The melee weapons in source are hitscan, and it's just really hard to hit someone. It's not a netcode problem. If someone's all up in your face, and filling 90% of your screen, but you aim just under their arm you're not going to hit them with a crowbar swipe (which is stupid).

[Adamido]

^^^^^^^^
Can we fix it?


In b4 Bob.

[mervaka]

i've been in a situation in UT classic before where i've shot myself in the back with the minigun, because i was lagging and running forwards in a straight line while firing..