next »

[enthrallstudios]

Honestly, while Unity 3D and UDK are both nice, they definitely have their drawbacks. I personally advocate writing your own engine depending on your project and skill level. If you use UDK and you make a wildly successful game, then you will lose a lot of money in royalties. With Unity you pay 1500 per platform, and to release on consoles you have to have a very expensive license. Web-published Unity games most-likely won't make much money, or get many players interested due to the negative view towards web-based gaming.

On the technology note, UDK operates on very old programming concepts where you just have base classes that you inherit from, but this is unwieldy and inefficient. Also, UnrealScript is kind of ridiculous, and Kismet is horribly inefficient. Unity is much better on the scripting side allowing the use of C# Javascript or their own Boo Script. also, Unity works on the notion of a component-based system which is nice. That being said though, Unity is quite under-powered next to all the other available engines.

Ease of use wise, Unity is much easier to grasp and complete complex tasks with, because it is an Engine written specifically for this generation. Unreal Engine has been being rehashed for quite a long time, and still sticks with old ideas. There is a lot more work to do in Unreal to get the same output as Unity from my experience.

On the note of writing your own engine, it really depends on what you want. If your graphics will be simple and not require the insane amount of detail that you can achieve with UDK, then writing your own engine is doable. You will likely end up with much better toolsets that are tailored for your game, and you don't need to learn someone else's APIs. The worst think about Unity is working with it's physics engine, specifically if you want to make something more 2D in nature.

Basically,if you want to make an FPS that has 2 teams and few players on each team, the go with UDK if you are time constrained. Unity is great for absolute beginners who just want to make a game, or people who have a simple concept like a racing game, or one of those rolling-ball puzzle games. If you want to make something a little different, and are willing to put your heart and soul into a project, use some nice libraries out there and write your own engine. You will thank yourself when you are done.

For those of you who are worried about multi-platform support, just write your code using pure C/C++ and make sure your libraries do the same. Stay away from .Net. The most you will have to do is rewrite the rendering layer again to have support for Direct X and OpenGL.

[Richard Kain]

Alternatively there's likely another engine or framework out there that you could use out of the box that is much more suited to your desired workflow and still has the features you wanted from Unity such as cross-compatibility etc.

You have several good points, but this isn't one of them. Cross-compatibility is one area where Unity really is leading the pack. While there are some cross-compatible engine solutions out there, they are few and far between. And most of them only allow for easy porting between two, maybe three platforms. With Unity there is almost no platform that they can't seem to get it to run on. Unity games currently run on the two most popular operating systems, with work in progress on getting them to the third. It supports the two most popular OSs for smart-phones and tablets. It has its own browser plug-in, and supports exporting for Chrome's NACL. And Unity games have been ported to every major home console.

If you build your game in Unity, you can be comfortable that there is a way to get it on almost any platform, with minimal extra effort. It is easily Unity's strongest selling point.

I do agree that there are better options in terms of targeting specific genres. If you wanted to make a first-person-shooter, obviously UDK would be a better option. It is an engine original designed with FPS titles in mind. While it is flexible enough to branch out into other genres, FPS is the seat of its power. One of Unity's better features, it's generalized flexibility, is also a drawback. For certain genres it takes more effort, simply because the engine wasn't designed with that specific genre in mind.

But this is the price of generalization over specialization. It could actually be overcome if more people used Unity's tool scripting to create more targeted variations of the engine.

[moi]

On the technology note, UDK operates on very old programming concepts where you just have base classes that you inherit from, but this is unwieldy and inefficient. Also, UnrealScript is kind of ridiculous, and Kismet is horribly inefficient.

Yeah, WTF went throught thier head?
Why not make your own engine using REAL languages such as HTML5 or C#? I didn't one this morning and it puts the shame on the unreal engine (more like moroneal engine, amirite?)

[J-Snake]

Writing your own is only a good idea in these cases:
  2. There is something extremely specific you want to do with your game that a normal engine won't let you, and that thing is very important to your vision. This situation is actually more rare than people think, I think.

My vision is technical perfection in game-mechanics and visual-flow at the same time. This is actually the main reason why I still haven't jumped to unity. It doesn't provide access to the game-loop. I would prefer to roll my own interpolated fixed-timestep. At least xna allows greater low-level control.

[enthrallstudios]

Yeah, WTF went throught thier head?
Why not make your own engine using REAL languages such as HTML5 or C#? I didn't one this morning and it puts the shame on the unreal engine (more like moroneal engine, amirite?)

I this you misunderstood my point there. My issue with UDK is the overall design. Instead of using the more efficient Component-based design (like what Unity employs), UDK just supplies a couple base classes.

With a component-based system, it makes it easier for developers to decide exactly what functionality they want. It's also much easier to add functionality in this setup. Also, if they were to follow a purely-aggregate component system then it would be much faster and use less memory.

My issue with UnrealScript is that it is a previously unknown language. Allowing basic scripting is considered good practice, and is much better when it's similar to languages that modders would know. That is why Lua and Python are used a lot as scripting languages.

I'm not saying UDK is bad per say, it's just not the best solution for every game type. For example, people try to make MMO's with it. This sounds like a great idea until you realize that you have to hire a very experienced developer or two, buy an actual Unreal 3 license, and end up rewriting all of the networking code. This is just one example.

UDK just isn't the best option for a small team of developers.

[Matthew]

That being said though, Unity is quite under-powered next to all the other available engines.

This isn't really the case with Unity 3.5, and certainly isn't the case with Unity 4.  

.  The production muscle required to surpass Unity's performance limitations is probably beyond the reach of most small teams.

[enthrallstudios]

This isn't really the case with Unity 3.5, and certainly isn't the case with Unity 4.  See this realtime Unity 4 demo, for instance.  The production muscle required to surpass Unity's performance limitations is probably beyond the reach of most small teams.

Pretty good demo. Unity seems to have increased the rendering capabilities of the engine since I last used it. How is it doing as far as iPhone performance? It used to be quite slow. It may not be the most powerful thing out there but you are right that most small companies won't use the full power that it seems to have. I was just talking in comparison to something like Unreal.

At the end of the day, my point still stands that with a custom setup, you have a lot more power and possibilities, although it does require more a lot more work depending on what you need.

[EdgeOfProphecy]

Even if you're not using the editor, you get Unity's cross-platform, hardware accelerated rendering. Including via the browser plugin which many people already have installed (which also gives gamepad support and mouse capture).

But there's plenty of other cross platform render frameworks out there which would probably be more suitable in this case.

Then why aren't people using them?

People are, you really think Unity is the only engine people use?  

Besides anyway, my point isn't that other engines are better than Unity, I use Unity plenty enough myself and really enjoy it, just check out my blog, so dont take offense.  What I'm getting at is that different engines are more suited to different workflows and different tasks.  Why go to all the effort of writing your own engine within Unity just to circumnavigate most of Unity's main features and try to force it to fit your workflow when all of its design works against it.  Alternatively there's likely another engine or framework out there that you could use out of the box that is much more suited to your desired workflow and still has the features you wanted from Unity such as cross-compatibility etc.

I apologize, I didn't mean to sound so attacky in my post.  I'm just tired of the "Hurrrr Unity is terrible" hipsters (which you are not).

Yes, there are other engines that people use, lots of them in fact.  No engine is a magic bullet, they're always coded to make a certain sort of thing, and they do have their own workflows and limitations that must be taken into consideration.  I would certainly not use Unity for every project, but I do think it's still a pretty compelling engine even if I have to do some non-trivial customization to get it to do what I want.  It does depend entirely on what you want to do with it, though.

[Graham-]

On the technology note, UDK operates on very old programming concepts where you just have base classes that you inherit from, but this is unwieldy and inefficient. Also, UnrealScript is kind of ridiculous, and Kismet is horribly inefficient.

Yeah, WTF went throught thier head?
Why not make your own engine using REAL languages such as HTML5 or C#? I didn't one this morning and it puts the shame on the unreal engine (more like moroneal engine, amirite?)

You can bind out to C++ in UDK, then just call back in to do fancy stuff if you want it.

[Matthew]

Pretty good demo. Unity seems to have increased the rendering capabilities of the engine since I last used it. How is it doing as far as iPhone performance?

Good, I guess!  I actually haven't touched Unity iPhone stuff personally in 3.5, although games like Dead Trigger are awfully impressive.

And it's certainly true you have more control--and therefore more potential performance for your particular game--if you do stuff yourself.  I think there's a lot to be said for rolling for your own, especially if you're approaching game development as a holistic challenge/hobby/lifestyle/whatever.  It's a great way to learn, and if you strongly value learning it's an obvious path.

But from a practical production standpoint I think the magnifier is getting hard to match.  Let's say you can get 2x the performance of an engine if you write code as specifically as possible.  The trick with that number is it assumes your intelligence and abilities are equal to the engine programmers' intelligence and abilities.  And when engines like Unity have 40+ really smart people working on them, your situational edge starts to get undercut by the sheer pool of brainpower behind the engine technology...

[ferreiradaselva]

On the technology note, UDK operates on very old programming concepts where you just have base classes that you inherit from, but this is unwieldy and inefficient.

EVERY game engine(modern game engines at least) operates this way! even Unity3D. Maybe you don't see the base class, but it is there! You MUST oparate this way, because if you want a list(or "vector" if you prefer), the items must be descend of the same class.

[TobiasW]

I think enthrallstudios' point was rather that Unity3D is quite big on component-based objects.

[ferreiradaselva]

If you mean this, my point is still valid:

"For example, generally composition is favored over inheritance and the component system makes composition so easy that it seems that inheritance is redundant. I realize you have to inherit from internal Unity classes like MonoBehaviour but I'm referring to inheritance of user created classes.

Similarly polymorphic behaviour doesn't require an abstract base class, you can just replace 'component A' with 'component B' to get different behaviour."
Source: http://answers.unity3d.com/questions/31272/game-architecture-best-practices.html

Taking the last paragraph and some video tutorials I saw, I realized that Unity is a Construct Classic, but 3D.

[Steve_Turner]

Unity is an extremely flexible engine. It comes with out of the box workflow and editor tools and handles the major engine pipelines effectively and efficiently.

In the past to make a game you would have to sit down and spend several months developing your engine for just the bare bones functionality of your game. Now you can get Unity and can immediately start programming your game.

I love engine programming and architecture but ultimately I like making games more. It's just not efficient to sit around reinventing wheels when there are teams of world class engineers already doing it for you.

The time you save just from debugging is critical. With Unity you are using software that is being utilized and tested by thousands of developers. That alone can help you identify bugs with the engine or bugs with your code.

[st33d]

Split bugs discussion into new thread. Carry on...

[EdgeOfProphecy]

On the technology note, UDK operates on very old programming concepts where you just have base classes that you inherit from, but this is unwieldy and inefficient.

EVERY game engine(modern game engines at least) operates this way! even Unity3D. Maybe you don't see the base class, but it is there! You MUST oparate this way, because if you want a list(or "vector" if you prefer), the items must be descend of the same class.

I haven't been following your posts that well throughout this thread, but have you ever looked at the UDK?  It contains MAD inheritance hierarchies that are deep deep deep.  Like 15 classes deep.

He's not griping about having any inheritance, just that the UDK's usage of it is arguably a bit over the top.

Unity's inheritance hierarchy is considerably more shallow, relying more heavily on components to add complex functionality to a specific class.  This trends toward horizontal relationships in code rather than vertical ones.

[moi]

I have to agree that the UDK devs have gone a bit overboard with the inheritance thing. And it does make their engine very hard to mod for. I know that from experience.
But i wouldn't call that "very old programming concepts ", that would makes me look like the type of indie hipster who would like to get married to unity (and also to my ipad/imac)

[Tuba]

I think this thread is appropriate to ask: What are the CONS of using Unity?

WiiU support was just announced and a lot of people seem to be happy about that, which made me realize that Unity can already export for pretty much every console out there, but not one seems to use it. Why?

I can see why a programer would prefer something else, I do. I hate how you can't do everything by code in Unity, it's weird for someone used to "more traditional" engines. But it's still a cheap engine that can do pretty much everything that other engines can, so why most big studios stick to UDK and other expensive engines?

[Graham-]

UDK offers more power. 750k or whatever it is is nothing to a AAA.

[ham and brie]

WiiU support was just announced and a lot of people seem to be happy about that, which made me realize that Unity can already export for pretty much every console out there, but not one seems to use it. Why?

There are console games that have used it, e.g. Rochard.

But for larger console games than that, Unity's somewhat unproven, so switching to it would be a big risk. It's only in the last couple of years that it's become comparable to something like UDK. If more developers gain experience using it for smaller projects, larger projects will probably follow, but that takes time.

There are other cheap console game engines too. The Wii U deal for Unity is similar to Sony's PhyreEngine which PS3 developers can use. Except PhyreEngine I think is full source and licensed for cross-platform releases (e.g. Dark Souls).