Is Unity any easier than UDK?

[ryanzec]

I agree that using kismet alone is not true programming however creating code with UnrealScript is programming. I feel this whole "scripting vs real programming" is just an elitist emotion. Whether or not you are coding in a low level language like ASM or C or a high level language like C# or a scripting language like PHP or UnrealScript, programming is programming, period.

[MadMax]

[Jessy]

[FlamingHairball]

[quote="MadMax"]

[CocoKool]

It appears clear that both engines have limitation due to the lack of access to source code, this makes it impossible to change core game engine functionality, and many of the data structures, and data formats are simply unchangeable. This is a given and has to be worked around as part of the development process using one of these platforms.

The UDK is a very feature rich development platform with almost every single feature needed to create a AAA game. It shines in the FPS genre, and can be adapted for other genres. It does not feature source code access, and that access is available for a very high cost, that only a publisher could afford to pay up front.

Due to it's high level of functionality there is much to learn and the complexity of the editors is high, but so is the amount of functionality, and while some may be unhappy with the ergonomics and usability of the menus, (yes it is true that there are many "hidden" features, meaning it's not always straightforward to find an option and this means long menu expeditions) the features are there to be exploited! All of them even the most advanced like Lightmass, FaceFX, SpeedTree, Kismet (yes node based programming rules, well most of the time), Swarm (distributed job processing). So there is allot of "bang for the buck".

The reason why studios license UE3 in such high numbers is because development cost of these features alone represent many millions of man hours and millions of dollars invested, and also talent that is many times not available. It cuts development time by years, even though it costs a big sum of money.

Looking at the documentation, the engine is clearly not designed to be as abstract as possible, requiring the developer to work around the concepts and limitations (as already pointed out). The UDK requires developers with no source access to "reverse engineer" the mechanics of the engine to make the necessary adaptations to other game genres or concepts that are absent from the built-in. This in contrast with Unity that is designed with abstraction and composition (addition of functionality) in mind. In UDK many times you start with an advanced object and restrict or subtract functionality.

Unity while a great development platform for Indie AA and casual games (with some real effort in shaders and great quality Materials you can get to AAA level, just not with the same ease as with UE3/UDK, any FPS specific comparison is mostly unfavorable to Unity), it's strongest selling point is the ability to deploy to the huge amount of platforms PC/MAC/Iphone/Wii.

It does not feature the same level of advanced features, or editor tools. And while it can provide in the Pro version a lower level of access to the rendering system and provide the ability to add missing functionality, it still does not feature source code access. So while it may provide a lower level access to add missing features, in the UDK those features are (mostly) not missing.

Please don't take this in the wrong way, while i think Unity is a great platform, and having the basic version available for free is a huge contribution to the indies by the Unity team, the Pro version simply does not feature enough advanced features. Some of the features that are Pro only should not be, since any well established open source engine provides the same level of functionality. Let me be specific:

Render-to-Texture Effects
Full-Screen Post-Processing Effects
Realtime Shadows
External Version Control Support
Video Playback and Streaming

IMO these features should be part of the Basic version. The Pro version should provide more advanced features like Global Illumination, Facial animation, a good AI library, Cloth, Destructible Environments, etc... (perhaps the nVidia APEX engines will be integrated into Unity 3.x), however the unity team does not disappoint and lets test the Pro version for a full period of 30-days. But the features pointed out should really be part of the basic package, or a royalties based license.

The development process is easier since you start from a blank sheet and use composition to add functionality. The engine is abstract enough that starting from a GameObject and adding components it's possible to create and save (in the form of prefabs) complex game functionality. So it is more of a straightforward design process vs the UDK "reverse engineer" process. However it is not as feature rich as the UDK and the addition of any advanced functionality requires that you license the C, C++ or Objective-C plugin functionality.

In conclusion, both platforms have their shortcomings, that can be in a way or another worked around. The UDK is "the state of the art", it's a fully-featured advanced AAA solution, it's complex and powerful. Unity is a simpler (the editor is straightforward) less feature rich, but more expandable and far reaching deployment platform, a Pro Unity license and a good asset creation team, together with an original gameplay idea can do miracles. Amazing work can be done in either platform!

Is Unity easier to learn than UDK?
Yes, because there is less to learn up front and it's a higher level of abstraction and composition process that is the way the brain likes to work. But as you advance your project development, there is a need to have advanced functionality that is not out-of the box. Having great tools like the UDK does is very helpful, but it's not a magic solution.

[cannon]

I'm wondering, are the UDK's tools as editable as Unity's?

I've always found Unity's editor GUI being programmable in the same scripting language that you write your game in as a remarkable design. Being able to very easily create your own tools in C# by extending Unity allows for some very productive and customized workflows.

[CocoKool]

[RuThaN]

@roberdan - 1 thounsand engin vs. 1 milion engin
It could have been compararable, income is same, if you sell 10 000 licences per 1 thousand and if you selling 10 licences per 1 milion. Unities way is better for human society.

Scripting vs. programming.
Scripting should be easier to learn and more productive, but non universal, its simlar as GPU horserpower float operation vs. general purpose processors.
Scripts can be also very hard programming, i professional game development is good make very quick stable engin in lowlevel C/C++ and use some highlevel scripting language as LUA or Python for game mechanics, as is spells, character abilities, AI behavior etc. If scripts fail, you still can can compile and run game. How fetch out C tentacle to LUA is theme for tomes. LUA implementation can be also quick, unlike very slow Unreal script, Unreal script evolution in last 10 years was lazy.
Theoretically levedesigners can be also scripters, but its bad idea, you dont save time.

@CocoKool - Great post, good work.
I want only accent on difference between full Unreal 3 and UDK - see my first post - http://forum.unity3d.com/viewtopic.php?p=230088#230088
In case of complex gamestyles, you will probably have problems with UDK.

[MadMax]

[CocoKool]

[RuThaN]

CocoKool -

UT 3, rather UT 3.5 - i spoke about UDK (newest UT 3.5), but i dunno if you can buy fullsource of UT3, probably yes for enormous cost. For 1+ milion, AFAIK, you receive only tools and headers, in implementation crisis some gameplay element maybe piece of source.

My list..
1) I spoke with my technical friends (Mafia, Vietcong etc) in their eyes its realy impossible, its as you do game code for some Pentium III PC max. You can do maximaly something as Borderlands, simply scripts games, some realtime strategy, racing game. Im designer i working on very complex AI system based on psychology model - impossible. Physic based melee combat impossible. No-action rpg impossible, simply i have to beleive in skills of my friends, we are on same boat with my.
Working on complex games is very hard and this is knife upon your neck too closely..
In fact, i explored all of UT3 mods and i didnt found some "scripting hell".

2 and 3) You cant write file stream or read file stream expect Unreal based formats, you cant creat own Items tool, Spell tool , AI behavior tool, Dialog tool etc, with own data format, you cant use XML files or start on DB server (SQL compact is one dll). Because this is impossible, also saving is problem. Wide datastructures in ini files is hell, how much ini files, you can have only 1, can have ini file 300 MB?

4) Editor is usable, industry standard, but far from ideal, Crysis or Far Cry 2 editor on other level, old Quake editors are more intuitive and egonomic and have few powerfull features which Unreal havent.

---
Add Scriping to GameEngine / Middleware is also possibility how sold engin without whole sourcecode - best protection of know-how and bugs or wild code orgies arent so visible.
But scripting isnt miraculous solution. You working in high level, and scripter can say, sorry, but its impossible, because scripting system isnt this parameter, it will hard, i have write engin coder.. so we throw away this design. Two systems instead one. You can implement 20 spells in hardcode or try created universal system for one milion.

Very good coder will very quick scripter, time is money, everytime. You need good coders for both and after you can ask, hey boy want you like more game mechanics or renderer,AI,physic / tools programming?

[CocoKool]

1) Well it may be that in your case it's unusable. I have no idea of what you want to implement, so i really can't argue with you in this one. The way i see it, it's perfectly possible to have sophisticated AI behavior. The path and locomotion systems are easy to use, UDK use a navmesh spacial representation, that helps easy certain problems from manual waypoint systems. I have no idea what you are going to implement, BT, HTN, etc... so i really don't have a way to provide a counter point.

2 and 3) There are 5 or 6 INI files if i recall correctly. You can also use TCPlink and use a database, there's a database connector out there for UT3 mods it should be a straightforward port.

So it's not really an optimal solution, but it's possible to work around it. But it's one of those simple things that just nags and it would be so simple to eliminate the problem. Send an e-mail to tim sweeney

[myunity]

(my opinion)

When player is playing the game does not think that you programmed it with Script or C# or C++ and it is not important that with which engine this game is made.he/she want just play and enjoy and have some exciting time.if you can come your player to 3d virtual world and compliance his/her needs.

and all of this things never happen,unless u have the last technology(UDK) or a good and new idea.

thanks.

[tonyd]

[RuThaN]

1) Ok you can start working, invest lots of time&money and after few months you hit scripts speed limit. You will cut gamedesign and make game a bit stupid, because scripts are too slow. 5x slower isnt such problem, but 20x is realy too much.

Pathfinding and basic bots behavior, very isnt advanced AI.

2) TCPlink, solution for multiplayer game data exchange, this is hack, probably with bad latence. Epic can in newer versions of UDK disable this features. Add user data support is very easy, i think so this is question of scope.


Send mail to Epic, on Epic forum works censorship, im afreid so support of community is limited.