I've been with Unity for a while now, and I've tried out UDK.

Honestly, as a beginner, I think you'll have a much easier time with Unity, and the price to pay is very little.

Unity does lack some graphical capabilities that UDK has, but Unity is overall much more innovative when it comes to the user interface. Very easy to use once you grasp it, and grasping it isn't very hard. Unity 4 is coming out with some pretty good looking features as well, including rendering and graphics boosts. I think the graphics difference between Unity and UDK will be mostly insignificant soon enough, as Unity improves.

UDK doesn't seem to have any detailed and straight-to-the-point documentation on how to make a game. I think it was made more specifically for mods, not just making games. Even with hours of searching and playing around with it, I couldn't figure out how to do some very simple things, like making a simple 'player' that can move with WASD. I could do that in 2 minutes with Unity, clean and easy, but UDK seems to insist on making me inherit from pre-made classes in a maze of not-very-explanatory documentation and web searches. For a programmer, this is kind of like a slap in the face; I want to program my game my own way.

Unity also has the capability of targeting multiple platforms, including Android, iPhone, XBox360, PS3, and Wii. Unity 4 is introducing quite a few exciting new things, including building for Linux and Adobe Flash Player, and as previously mentioned, graphics and rendering updates.

So I'm of the opinion that Unity is better for making games, not mods. Unity has great organization of your scripts and assets, very easy and straight-to-the-point user interface, and lots of very helpful and nice people in the community (I'm not saying the UDK community is rude). Also, it supports scripting with C# and its own, easy-to-use UnityScript language.

Though my experience with UDK is limited, I have many reasons to say Unity is a very good engine, and I think you'll have a much easier time getting into Unity than you would UDK. I'd take it over UDK any day, because it just seems much more innovative, and there are lots of exciting things going on in the Unity community.

Hopefully I don't sound like a "Unity fanboy" because of this. Just wanted to offer my personal experience with the two engines.

Irrilict was a mess. Nothing worked very well. Basically made by a group of guys who just copied everything Quake2 did. Anytime you see an engine, and all the supported functionality revolves around what quake did, and quake file formats AVOID AT ALL COSTS! Forum is full of 'tard know-it-all, OSS zealots, who can't help you with anything when it comes to making games.

This is a tad unfair. Admittedly I do find the API a little messy and fiddly but it is good enough to get you started quickly with cross platform C++ games development. Something that UDK and Unity can't really achieve to the same extent (being closed source).

GTKRadiant (which is on the list) is not a good editor in 2013

Lol, I perhaps agree, but it also shouldn't be overlooked completely. Especially for coders who have no time to learn a full on modelling tool. Plus with the 1.5 version, it can export a map to Wavefront .OBJ making it quite acceptable for blocking out the majority of my level.

Being C++ and Open Source are just 2 irrelevant implementation details. The engine was a bunch of random components thrown together with outdated technology. The animation system was a joke and just did everything quake did with no concept of any modern techniques like blending or bones (although they had started patching that in eventually). It's what I would expect a bunch of hobbyist to build after reading a bunch of tutorials and source code releases. Just because someone has a webpage and a project up on sourceforge doesn't mean it's any good, or worth your time. A turd is still a turd. Regardless of source code license.

UDK and Unity are cross platform, and can support custom C++ code in different ways. Since most proper game code is created with a scripting language with a C++ engine doing the system work anyways, this is a moot point.

GTKRadiant (which is on the list) is not a good editor in 2013

Lol, I perhaps agree, but it also shouldn't be overlooked completely. Especially for coders who have no time to learn a full on modelling tool. Plus with the 1.5 version, it can export a map to Wavefront .OBJ making it quite acceptable for blocking out the majority of my level.

You can block things out much easier in a proper modeling tool, with a better tools, more accuracy, and not be stuck on an old integer power of 2 coord system. This is a tool from the early 1990s that was made specifically to for a specific game engine and it's quirks. I don't know why you would want to drag in a big OBJ brush mesh and then have to rebuild it from scratch in a proper scale (so lighting and physics work accurately with a proper meters based unit scale). Why do something wrong so you can go back and do it right later?

I also used to live in the BUILD editor that was used for the Duke3D engine games. Great editor. But it has no use editing anything else. It's from a bygone era 2 decades ago.

I don't know why you would want to drag in a big OBJ brush mesh

I dont know if you have used *Radiant, but it is split up into multiple smaller meshes if required.

and then have to rebuild it from scratch in a proper scale (so lighting and physics work accurately with a proper meters based unit scale). Why do something wrong so you can go back and do it right later?

Though you find open-source an "irrelevant implementation detail", because Radiant is open-source, it is very easy change the scale that the exporter saves the .obj file as. (Though you will need to be able to compile the thing and thus have a fair knowledge of C and C++ rather than just a scripting language).

I also used to live in the BUILD editor...

Would be pretty good if it exported to .obj.

Tbh, any tool that makes it easy for a non artist to get their ideas across is good. Afterall, Maps can't be build in Unity alone.

You're arguing just to argue and speaking from inexperience.

Yes I've used radiant. If you bothered to read anything I wrote, I said I used to live in it. I know it inside and out.

It is a very poor modeler, because it's not a modeler, it's a level editor for a specific old set of games. You can't create any arbitrary shapes because brushes are not free form polygons. They are abstractions over polygons. You could only create shapes that were legal in the games it was made to edit, where the shapes were used for both the graphical display, and the collision mesh. When you are done, you feed your brushes to the BSP compiler that took all the plane definitions that made up a brush, and spit out a quake level.

You cannot easily change that just because radiant is OSS. You'd have to rewrite the entire program from scratch. It's not a general purpose 3D modeler. It's a brush editor. This is not what a proper 3D modeler does.

So when you get your import your radiant created data into your modeler, it's all junk and you have to go over it again. You have to rescale everything to fit a proper scale (not that 2,4,8,16 crap), and then you have to redo all your crude shapes that radiant couldn't handle. Then you have to open up every submesh and redo the UVs into the proper floating range (0.0-1.0) instead of the world space coords + manual offset that radiant used.. You have to go over everything from scratch. So it's not helping anything to use it as a first step.

In modern times we can build a crude collision mesh, and then a new layer with the actual displayed geometry with proper floating point vertex coordinates, and whatever shapes we can dream up. No reason to use an outdated and useless old iD game editor. just like there is no reason to use an old EGA, 320x200, 16 color paint program to make sprites.

As for BUILD, what are you going to do with a bunch of LINEDEFs and SECTORs in an obj file (which aren't in the OBJ spec)? They are useless outside of BUILD.exe ;) There is not a single bit of relevant data in there to use anywhere else.

As someone who has barely tried UDK (because it really felt counterintuitive) I think what Sir Mac Jefferson said pretty much sums it up:

UDK doesn't seem to have any detailed and straight-to-the-point documentation on how to make a game. I think it was made more specifically for mods, not just making games. Even with hours of searching and playing around with it, I couldn't figure out how to do some very simple things, like making a simple 'player' that can move with WASD. I could do that in 2 minutes with Unity, clean and easy, but UDK seems to insist on making me inherit from pre-made classes in a maze of not-very-explanatory documentation and web searches. For a programmer, this is kind of like a slap in the face; I want to program my game my own way.

I tried CryEngine as well and it's the same story. With both UDK and CryEngine I started them up, loaded one of the included levels and played around for a while. You're basically just playing Crysis or Unreal Tournament 3 at this point. Then I found a guide on how to add a custom weapon which was easy enough. Now I wanted to start making an actual game. Something simple like Tetris or Asteroids to get me started. This is where I found no help or guides and couldn't even figure out where or how to write the first line of code.

If you search for UDK on youtube you find all these amazing demos, but they are mostly made by experienced game developers or just artists using the engine to showcase a single level or map. Finding examples of the simple games you would expect to make as a beginner is not so easy.

With Unity it was a completely different experience for me. Not only is there huge amounts of tutorials available, but you also build your game from the ground up instead of adapting (mod) an existing game to fit your needs, at least that's how I felt when fiddling with UDK or CryEngine. In my fairly short time with Unity I've prototyped all kinds of different games and game concepts and it's been a smooth ride so far.

I'm just a hobbyist so the pros/cons on the different pricing structures doesn't apply to me at the moment. My goal is to create a few games on the side and if I see potential, I will consider becoming a full time game developer. And if I do that then Unity seems superior to me. I need at least $100 000 a year to consider making games full time and that's a lot of money lost to royalties with the UDK pricing structure compared to the fairly cheap one time cost of the different Unity versions. It's like having a publisher taking his share of your profits vs not having one.

As for Unity Free vs Unity Pro debate, there's always a ton of posts on the official Unity forums regarding the lack of features in the free version, but I recently upgraded to Pro and there's perhaps 1 or 2 features I use in 1 or 2 of my games. The rest doesn't use any Pro features. Most of the posts however are from people not actually producing games or content, they're just on the forums whining. Sure if you're making the next Gears of War or Battlefield you need HDR, tonemapping, bloom, depth of field, render textures etc. etc. But you're not. Nobody is. You're making small games fit for a single developer or a small team.

Honestly I would prefer it if they kept the $100 Unity Indie version instead of the free version because $100 was just enough to keep a lot of the mod makers and plain posers out of the forums, but I understand the business decision behind it. You still find a lot of quality threads on the Unity forums. Just look at the recent DX11 competition entries to see what Unity 4 is capable of in terms of graphical power. There's a lot of stuff there similar to what we've been shown in the Unreal Engine 4 demo.

When you are done, you feed your brushes to the BSP compiler that took all the plane definitions that made up a brush, and spit out a quake level.

You do not need to send it to a bsp compiler. You can export it straight to .OBJ (or load in the .map directly if you write a parser and tackle the plane equations) i.e.

http://www.katsbits.com/tutorials/idtech/make-models-from-bsp-maps-or-brushes-advanced.php#gtk15

You could only create shapes that were legal in the games it was made to edit

The outdoor areas in Doom 3 were made in an older version of Radiant and they are probably still better than the majority of levels created by indie developers using any other tool.

You cannot easily change that just because radiant is OSS.

Of course you can. It has brush, face, winding, vertex structs which can easily be used / modified for pretty much any task I would likely perform if I was using blender for making maps. The code is also relatively structured and flexible so anyone with knowledge in C++ can tweak it.

Anyway, what would you suggest instead? A non-artist spends weeks learning something like 3DS Max or Maya? I dont know if this is some snobbery or what but if a developer wants to make a game without any experience in art, this old ID editor is still one of the easiest routes to take for artwork that is good enough for most indie games.

Anyways, this is off topic to the thread so I am going to stop here. I would just like to state that the tools used to create older AAA games (like Quake III) should certainly not be ignored by indie developers because they in most cases still provide greater functionality than required.