I am also a long time developer working in business software programming in my day job.

I started with Unity in its Version 3.5 days. I absolutely hated it at first, the editor was overly complex for me, and the engine itself was really subpar back in these days (it still is compared to others, but its catching up IMO). I took 1.5 years off Unity and started using a different engine. While this engine was giving me much better results graphically, the editor was just unusable. Old school crap that made it hard to even place a single object. How anyone would go through the ordeal to create a full level in this editor is a mystery to me.

I really tried to like the engine and create something in it... but after the 1.5 years, I went back to Unity, and it did click with me.

Its the editor. It really allows you to be productive, once you "get it". I then started to use C# instead of Unityscript, and somehow the C# API also clicked with me. Don't get me wrong, there are just as many things that seemed counterintuitive or downright crap in the API to me. Sometimes you have to work with stupid workarounds to achieve a result because the engine does not support it.

But compared to other engines on the market, its still the better choice. If only for an editor that actually steps out of your way when you try to be productive in it once you learn how to use it.

I have now started using Unreal engine 4 for a new project. And while I again like the results achievable better than what I was able to achieve with Unity out of the box... things are just so different in it than in Unity.

Again, for me, the main adjective I would give to working in Unreal is "uproductive"... that might be me still being an Unreal newb getting to grips with the engine, or because what Unity did was actually make the work in the editor easier but neglecting other, more important parts of the engine...

Still, you are able to throw together a prototype in Unity and code the behaviour scripts necessary in hours, if you already have all the assets and a good plan. I couldn't think of a way to do that in Unreal. Everything seems to be so much more involved. The GameObjects in Unity are pretty much drag and drop, while the Blueprint System in Unreal seems much clunkier in comparison (again, could be me just not "getting it").

You can create many things in the Unity editor that need outside tools in Unreal (best example is cubemaps... without the PS plugin or the ATI/AMD Tools to create DDS files, not possible in Unreal. In Unity, just provide 6 images, and let the editor do the work).

But of course YMMV. I found that for me as a programmer, programming seldom is the time sink. I can program relatively fast in any environment, and I find it quite easy to adapt to most languages. I find the other aspects much more involved, setting up stuff in the editor, creating assets where necessary. Most probably because I don't have the years of expierience and a degree in it.

Still, that means for me number one priority in an engine is to make the assets and leveldesign part as easy as possible, with being able to program productively a distant second place. If programming gets more involved , so be it (in which case C++ in Unreal is much worse IMO. Unity lets you get away with much less code than Unreal IMO)... I am reasonably fast with programming either way. That means engines like CryEngine, that have like an ANCIENT, almost unusable editor fall to the wayside for me. I don't have a whole studio of guys that can try to come up with a pipeline and write the tools to "replace" the unproductive editor with something else.

So yeah, maybe try to step outside your own shoes and think about what would make your artist friend more productive. Chances are he will have MUCH more work to do than you as a programmer, depends on the project you are working on of course. But with the engine taking away lots of the low level plumbing, if the game is actually reasonable simple, the code might not be so hard to do anyway, while the amount of assets and level design needed might still be quite overwhelming.

If he is able to work faster in Unity, and you just "don't like it because the code looks unclean", but can work in it, maybe you should give in and let him have his way.

I can tell you, I have written A LOT of C# code for my last Unity project. Worked like a charm. There are times you need to get inventive with stupid workarounds as the engine just will not let you do what you need to do, but I gess you get these moments with all engines (or you start to waste time re-coding parts of the low level code of the engine, which is also not very productive).

And the normal work in Unity, once you get the hang of the component paradigm of it, is quite smooth. You can even combine it with normal OO if you are clever about it.

Try Unreal Engine.

I also bounced off Unity several times at first, especially coming from more code-centric frameworks like XNA. Eventually you get used to it, and it's really not that bad. It's really easy to write bad unity code, so you do have to be careful to keep things clean. But that's not all that different than your own code.

And you'll definitely butt heads against certain portions of Unity. Like it's physics, or wonky garbage collection. But it's pretty nice for a designer or artist to be able to drop in art, and then go and tweak settings on scripts without having to modify the script. And Unity's heavily used, so it's very easy to come across a blocker, and find the solution via a very quick websearch.

You will find that every engine/framework will have their little quirks and nothing will ever give you the 100% solution. With that in mind, its probably going to boil down to how much hoops you are willing to jump through to get your project off the ground. Try a few of the engine recommended in the previous post with a small project ( if you have the time ) and see how each work for you. Everyone workflow is going to be different, so what suits me may not suit you, so don't expect to get a wholehearted answer saying the engine is the be all to end all. Also, I like how the phrase re-inventing the wheel get tossed around, sometimes its more than that, maybe the wheel had flat spots and make for a bumpy ride. Unity didn't just magically appeared out of nowhere? Game engines existed at the time Unity was started, so imagine if the developers of Unity didn't 'reinvent the wheel'.

The good reason is it gives them more fine control. The bad reason is it makes them feel superior and smart. (I'd rather not reinvent the wheel.) The third reason is not bad and it is simply that some people can't get their heads around Unity.

Good point. I do like having not only control but also _understanding_ of what's going on. But you have to draw the line somewhere, else we would all still be writing in assembly. =)

I've been game programming for over a decade and used Unity for three of those years. Unity is the least-of-all-evils that I've seen so far (and *everything* is evil). It's pretty good in almost every way, but there is always a little hassle hanging around every dark corner.

As far as your first impression goes, it just sounds like you're complaining because it's not doing things your way right away. But of course it isn't, because it wasn't written by you. Nothing complex lacks a learning curve, so we must constantly learn and get used to doing things in ways we think are "weird" at first. Unity is more flexible than it appears at first glance, but if you haven't bothered to try, you will never learn.

You have to start off with at least one Scene with one GameObject with one script on it, but after that you can programmatically set up everything else. Or you can build scenes right in the editor. Or mix approaches. It's up to you. You can put scripts on GameObjects like usual, and you can run a single MonoBehavior which calls into a huge pure-C# game which only uses Unity as a presentation layer, or you can go the "normal" approach of composing behavior directly with MonoBehaviors. The amount of flexibility is pretty crazy compared to other "engines" I've used which force you into one and only one way of doing things.

This is exactly the kind of advice and voice of experience I was hoping for. Thanks!

I also hadn't considered creating a single behavior and just dropping down into code and do everything that way. Interesting idea.

Overall, I like unity, but as I've become a more advanced programmer, I find it more constraining.

In what way? Can you share an example?

If you decide to opt-out of using unity's phyics, level-design pipeline, animation, and rendering/materials, then you're better off using something else. If you're only ignoring 1 or 2 of those, it's probably better to stick with unity.

Good point. Having never really completed a game, apart from some small tests and prototypes, I think whole development pipeline (code, level design, animation, modeling, etc.) is something I have greatly underestimated, or even just didn't think about very much.

All of them offer tradeoffs. You use their system and do things according to their patterns. This comes with the consequences that their patterns may not be the best fit for your game, and pairs nicely with "not invented here" syndrome.

+1 for the mention of NIH. =)

I wouldn't worry too much about your first impression. There's an easy way for you too find out: just make a simple game in Unity, finish it and then look back and reflect. It doesn't have to take long, you could probably do it in a weekend.

I think this is the single best piece of advice in this thread.

The first time I started up Unity I was like dude...? Where the hell is my main? Where do I start typing!?

This was also my first thought. Glad to hear I'm not alone. =)