Unity's documentation isn't perfect, but its better than most of the stuff I've had to deal with in the past.

The documentation usually tells you if something is going to negatively impact performance in a significant way. But it is hard to measure these things when so many people use them so many different ways. Unity Pro comes with a profiler which can be used to test the performance of things, if you want to go that route.

Yeah, I know documentation tends to fall behind. At work, we develop an ~18 y.o. platform - not gamedev, but the complexity I suppose can be thought of as approximating an engine - documentation is what it is (blerg)... I didn't factor it into my original post, but I've only worked with opensource frameworks in the past, where investigating what is actually happening behind the curtain is trivial.

Performance wise, the component architecture allows you to get rid of all of the crap you don't need, so it is usually fast enough for the vast majority of people's needs. You are right that data and logic aren't strictly separated. Unity's workflow often puts data in a file or in the scene, but it isn't so much tied directly to the code.

But MonoBehaviours are pretty heavy-weight objects. It seems to favor fewer/bloatier components per GameObject, compared to the ECS approach. You are right though, I should spend some more time looking into how others have gone about it. I suspect I might be trying to shoehorn something into Unity's CA, but I'm clinging to the wrong mindset.

I'd spend less time worrying about performance and more time trying to find tools that are in you price range and work well with your workflow.

Certainlly, but I do believe there is a sweet-spot between performance and good coding practices. Finding it seems difficult with Unity3d; a lot of the resources are geared towards simple how to:s or unsubstantiated claims (thinking mainly about claims about reflection being slow in unity, where afaik, a single, likely flawed benchmarked is referred to over and over).

Btw Libgdx, SDL and XNA are all APIs, not engines. They will give you much more flexibility, but will take a lot more time to learn and get anything finished. If you're absolutely set on not using Unity, some alternatives are Cocos2D, GameMaker, Love, Torque, Godot, RPG Maker, the list goes on and on.

Sure, libgdx, sdl etc are frameworks - but I got started much quicker with both libgdx and sdl. XNA was probably a pretty slow start, first time I ever tried something game-y - I remember liking the API design though.

I'll give Unity3d another couple of months, for sure - but it ultimately depends on the new employer.

Thanks for the feedback!

Speaking of good example projects from the asset store - any good ones to recommend, from a code organization and component design POV?

The few I've looked at are mostly geared towards one custom MonoBehaviour per GameObject type, and sometimes following the pattern of extending from a parent class, eg MovingBehaviour is extended by PlayerBehaviour and EnemeyBehaviour; imo, that is precisley one of the issues CA attempts to solve.

Cryamore is using Unity for a 2D game, and once we built a fairly straightforward set of 2d-related utils for our specific game style (like using y-axis movement to push/pull things in z-order), it's been really smooth sailing getting things working with very little interference from the system. The biggest hump to get over is using the tools like they're intended (going with the paradigm vs against it). That was my particular struggle, the more I've learned the easier it's gotten to make things happen with little to no engine complaints.

Going with the flow of Unity is definitely something I'm struggling with; we've been leaning towards instantiating and wiring prefabs from a single GameObject's all-code MonoBehaviour ("the director"). From what I've gathered this is a pretty common pattern in unity(?). Alternatively, spend some type writing custom editor widgets, because setting up GO references between MonoBehaviours was clunky from within the Unity editor.

Cryamore had gone under my radar, but it's looking pretty awesome, judging by the trailer and tumblr dev blog! I remember how blown away the 7 year old me was the first time I played The Legend of Zelda on the NES :)

Approximately, how many MonoBehaviours go in to, say, a normal mob? I'm used to decomposing data/logic into highly specialized components/systems - a simple game entity in a 2d context typically has 10-15 components (interaction with systems is harder to estimate, but ~20).

Does it feel right for you? I spent a lot of time with Unity when they made it "free". I don't like it at all. There isn't anything wrong with it, but it just doesn't work with the way I code. If I was doing stuff on a team that might change things, but since I'm all alone when making games I prefer to use C++/SDL/OpenGL.

I did not find the tutorials or the documentation very helpful. All those black-box components are great if you don't care what is going on, but what happens if there is a problem? No source code to read, no way to debug the component logic, and no way to know what is going on inside there expect experimentation.

Does it feel right for you? I spent a lot of time with Unity when they made it "free". I don't like it at all. There isn't anything wrong with it, but it just doesn't work with the way I code. If I was doing stuff on a team that might change things, but since I'm all alone when making games I prefer to use C++/SDL/OpenGL.

Well, it's engaging enough to spend two full weekends with it, but - as it looks now - I'm probably not going to use it outside work, except maybe for some tooling. Your sentiments pretty much echo my own. I experimented with my own component design some years ago, but I ultimately abandoned it when I discovered ECS - as it turned out to be a much more natural fit for my brain, and the component design started to feel a lot like OO in different clothing; solving some problems, exhibiting a couple of cool perks while also spawning a host of new issues.

The black-box nature is probably my biggest *real* concern, along with lacking documentation, but I will face my fear. I will permit it to pass over me and through me.

I find it amusing that 'people' are willing to bend and twist and jump through hoops to recommend Unity for anything. It is very touching.

And 'they' never stop to warn the 'infidels' that life without Unity will mean that those unfortunate non-Unity using SOBs will have to write everything from agonizing scratch..

It is not true!

-> http://www.slant.co/topics/341/~what-are-the-best-2d-game-engines

Yes, there are people who use Unity for 2D games. I even know several projects that uses Ogre for 2D games, some of them very successfully.

But, if all you need is a 2D game engine I think you 'ought' to pick an engine especially optimized/geared for 2D.