Wrestling with the sheer size of Unity

One thing I have trouble with in Unity is the sheer size of the thing. Every time I open it up to do something that I think should be fairly simple, I end up having to go hunt through documentation, google for other people's struggles with the same thing, and eventually find out the very specific way in which something has to be done. Surely it shouldn't be this difficult to do simple things. Unity likes to tout that they "take the pain out" and "solve hard problems". How about making the things that should be easy, actually easy?

I find Unity intimidating in its sheer size, flexibility and freedoms. I think because Unity has done a great job of opening it up for creative expression, it doesn't have many limits and is like a vast ocean-like canvas waiting for you to express yourself onto. But then you feel lost in a great expanse of possibilities and it's a real struggle to set limits and reign the system in to focus on a certain outcome. When you have in mind "I want to do this" you now have to wrestle with trying to screen out all the other stuff that isn't relevant, narrowing down to find an extremely specific required solution, like finding a needle in a haystack.

I do understand that in order to provide all the high-level stuff and sheer scope of functionality, Unity has to be extremely organized and structured and needs all this framework to locate things in specific places. But now when you want to just do something simple, it becomes much harder than it should be. You have to find the exactly right extremely picky little flag in some obscure documentation page otherwise you have no chance of making something happen.

For example I just made a little animation clip and I just wanted to play the thing on an object when a certain event happens. How hard could that be? Well jeez, several documentation pages and unity answers and forum posts later and I finally get this co-routine state-machine thingy working to launch the animation and wait for it and do something afterwards. Waaay more picky and complex than it seems it should've been. Just one of many examples.

It seems like each time I want to achieve something I first have to even "locate" where the information is about how to do that, then figure out the extremely specific way that Unity expects you to do that thing, and then write the very technically cranky code that makes it happen. I think if you are a professional programmer who loves all this pain, then you maybe don't have as much of an issue with it. But in becoming so broad and so general-purpose and so huge, Unity has in a way made the simpler things much scarier and more difficult.

Like for example, why can't I just click on an object in the scene and get some kind of menu that implements a basic behavior or control system or basic animation in a matter of seconds? Why do I now have to resort to all kinds of typing and clicking just to get simple stuff to happen? When you look at what is involved in making even the most basic thing happen, it's a bit ridiculous the hoops you have to go through.

I do think Unity has done a much better job now with 2D in particular in providing tools that overcome a lot of the issues but maybe what it still boils down to, the real pain-point that isn't properly addressed, is in the area of "how do I make something happen?" Unity has tacked on impressive Timeline editing and the superbly over-complex Animator and all this other sophisticated stuff, and keeps missing the boat on the simple things. Like implementing basic AI, the most basic simple animation, basic control systems, basic interaction. It's so long winded.

I had spent some time away from Unity doing web design stuff and because it's a focused limited kind of system, you basically get to know simply html and css and a bit of scripting and you're done. You can layout the page quickly and add elements and configure things pretty quickly. I was doing that all day then came into Unity and all I needed to do was add a couple of icons on my game screen and ..... OMG. Right off the bat, even without doing anything at all, there was just this impression of being lost, being overwhelmed. It seemed strangely daunting and off-putting. This simple little thing should've been a quick 1-minute addition, and when I got to doing it it turned into like 20-30 minutes at least, to do it "the unity way". Faffing around with texture settings and UI widgets and scripting events and all this crap.

Now, I have considered maybe that I don't know the tool well enough. Yet I've been playing with it for years now. In some ways Unity has made things easier on the high-level editing front, adding more tools, but on the level of creating behavior and action and interaction, it's still a matter of a) go do some complicated very specific programming after wading through documentation, b) use some limited and longwinded "its not programming" visual tool which is even slower than programming for producing basic results, c) hunt around for 3rd party apps that have all kinds of strange quirks and limits requiring you to have to learn an entirely new system every time.

I thought to myself, maybe it's just me, maybe I need to learn Unity more, maybe I just am not familiar enough with it. But I'm not sure that's it. There's SO MUCH to become familiar with. The learning curve is very high. And I see Unity now focusing on futuristic "automatic AI" machine learning toys that's supposedly going to save us all from having to create behavior by hand. It seems like a gimmicky overshoot and is ignorant of the very basic needs of users to do simple little things in an easy and efficient way.

Unity seems to have become this sort of high-level tool for advanced developers, and whenever they want to appeal to the indie or less advanced developer they throw some new tools at it to "keep their distance" rather than getting into the very intimate personal space of how someone completes the most basic of tasks prevalent in most games. Just to get a simple 2d sprite animating - ridiculously complicated. Just to get an object to move back and forth, jeez, either some weird animation timeline or scripting needed. Just to make an object clickable and so something when you click it, now you're doing fricking physics raycasts and writing up state machines in code just to try to make it do something. It's pretty ridiculous how far removed Unity is from "simple and easy".

Anyway, enough for now. Anyone else feel this way?

 

Honestly, that's never crossed my mind. I've found it to be pretty well segmented.

I do think the Animation system is heavy on prerequisites and bloaty, especially when dealing with UI but you definitely don't need to sift through pages of documentation to play a simple animation on anything. With even a basic understanding of it this should be simple for you. If this is a real issue for you then I'd suggest going through the Learn section on Animation tutorials and getting a better grasp of the workflow so it becomes more natural. It's possible you're just experiencing burnout and failure bias, maybe because of a lack of results?

I think you've made a good assessment that you don't know the tool well enough but part of the issue is that Unity has added a huge abundance of new complicated features that most people do not need or want. Basically if you're one of those people then avoid those systems and things work much better. Timeline is IMO not worth the time investment to adopt yet - at least for production.

Good news is that a lot of stuff is going to be strippable via Unity Package Manager in the near future, so you won't have these issues.

In the end, you have to decide what to spend your time on and it sounds like you've spread yourself too thin and not learned anything well enough to do anything rapidly. Personally, I roll pretty much everything myself and use Unity systems only when required. When investigating whether I should adopt a new feature I explore it thoroughly and make a choice when I'm done so I don't waste my time.

 

I feel what is missing is a snippet project containing simple pieces of codes to do the most common things so I don't have to google 10 links

 

I’m pretty well versed in terms of programming and doing complicated things. It’s not that I can’t figure it out or don’t know how to. It’s more to do with, why should I have to go to such great lengths to do such basic things? It really should be a matter of a few clicks to get some object doing something meaningful, not having to dip into scripting and the like.

 

The actual solution is that the package manager gets more love (External repositories) and we as a community just have packages to solve the simplest of problems.

 

Simple problems require simple solutions. If you find yourself using a specific code snippet a lot, just put it on github or make a unity package you can import.

 

It's a very flexible engine with a lot of power. Getting a bit lost is normal when starting out, and will get easier over time.

I don't understand your Animation example. Playing an animation is a single function call, and I don't see why touching scripting would be considered "great lengths".

You have to "faff" around with texture settings as it's really not possible for Unity to read your mind and know what you are going to use the texture for. Textures can be used for images, tile maps, storing per-pixel data, lookup tables, etc.

Many of us (including myself) don't even use Unity for game development, so introducing AI (and probably requiring the introduction of concepts like players, enemies, allies, etc) builtin to unity wouldn't make any sense.

 

I don't feel this way.

It works just as any big software product (that has been in development for over a decade) would. Meaning you need to spend some time learning and getting hang of it and should be ready to check the docs.

I find that the engine is fairly well documented, and documentation is of very high quality. It almost at Qt level.

So I don't see going through the docs as a hassle or intmidating, as this is something I'd do ALL The time while programming.

 

Also generic behavior creatio and edition is still a hard problem hardly solved. HTML works because it's anrrow and specific (a layout). But unity is supposed to make all sorts of game, unlike rpgmaker or even game maker. So far the easier it is to edit behavior, the more close, narrow and specific the editor is.

 

I have felt somewhat similar. Some things definitely seem to be more complicated than needed. I've also found that the resources available are out of date or contradictory very quickly.I think part of that is every year there is a complete re hauled version of unity made available. The other main issue is there is so many ways to do something and not really a right way , that there isn't a lot of consensus so you end up doing everything a little bit different from everyone else. It seems that buying pre made assets is the way to go and really alleviates all that stress.

 

Um ok, now compare getting an animated object to do something with physics and get it run on all platforms without using Unity.

I think it's pretty easy.

 

I agree the animation system is a pain to use. I don't use it very often, but when I do I find it very tedious and unintuitive for reasons I can't exactly put my finger on.

Other than that though, I find Unity to be incredibly easy to prototype in. I can open a new project, whack up some scripts and get stuff happening in no time. It's true what they say - and it's the first of the main two reasons I like Unity - that Unity is a very 'open-ended' development environment that 'doesn't make any assumptions about what you're doing' - although that seems to be often used as a generic excuse in forum discussions for the lack (or wholly unsatisfactory implementation) of some complex yet basic feature that almost everybody needs.

I think you raise a good point - some things in Unity feel like reinventing the wheel every time you create a new project - but you don't really show how it's conceivable to solve the problem. I think the best solution, which is the second reason I like Unity, is the fact that it'[s possible to create almost any kind of editor tools - although it's definitely arguable that a lot of things to do with editor scripting leaves much to be desired, and also that it's not really a solution for people who aren't really comfortable doing scripting in the first place.

I think that in the end it's worth keeping in mind that the act of creating a game involves two main things: designing and creating a game concept, and programming the tools and game logic that are required to make it happen. And in some sense it's very difficult to strengthen one's ability to operate more easily in either of these spheres without requiring more from the other. To be able to offer all the game designers out there more options, the 'game logic creation interface' has to become more abstract. And to offer a programmer a greater measure of flexibility in terms of creating an artistic experience, necessarily more artistic handiwork is required.

I would say that Unity caters best to small teams of people with different skills, or individuals who can quite easily deal with both of these things. Right now I don't think Unity (or any other game engine) offers a generic solution for people who are either uncomfortable programming the game (or the editor) or those who are uncomfortable with the artistic role of 'experience detail management'. For these people, until some AI assistant gets made that can translate a wide range of simply formulated requests into a complex implementation, only specific implementations of a game engine editor will do, and for this unfortunately they require someone else to implement it for them.

 

When you don't already know how to do something due to lack of exposure etc it typically means having to hunt through documentation and find problematic half-answers on forums etc until you finally come to a clear picture of how to do it. It shouldn't be that hard to do the simpler things. I mean, I realize you have to "learn" some stuff but it'd be far quicker and easier to do the simpler stuff in-editor without scripting and document-hunting.

 

I get what you're saying. I think the difficulty, though, comes with asking what things fall into the category of 'simple, no-coding' tasks that should be covered.

You just want to bind an animation to an event. What would the ideal workflow be for you?

1. Drag model into scene
2. Right click in Scene view, choose 'Animation -> Add Animation'
3. Animator component gets added to object
4. Component has dropdown for 'Activation'
5. Choose event from dropdown
6. Publish

That sounds fine. Until you consider alternate paths that people may want to take, or even you yourself might want to do as the project evolves. What if you want all animations to play on start, and swap in a different animation when that object is selected by the player? What if you want to randomly pick from a set of animations? What if you want to play a sound effect, too? What if you want to add multiple animations depending on conditions of that model (arms always go to "hold weapon ready", but different stance depending on how many legs, for example)?

I've only published two assets so far (currently working on a third) and one thing I've learned is that it's very difficult -- almost impossible -- to make things generic enough that they'll work out of the box for everyone without extra coding. I think that's why, despite its initial learning curve, the Component system works so well for Unity. You have to write code for most meaningful interactions, but I honestly can't think how else it should work to be able to accommodate everyone.

 

I think Input should be in that category. It's required for every game on every platform but it requires a complex cascade of game objects and scripts and probably raycasts and physics components. It's easy once you learn it all, but it's the very first thing new users need to do and Google shows an enormous amount of overwhelmed people who don't know where to start. Unity Answers is filled with the same input related questions over and over again.

If there was a UI system for connecting inputs (keyboard, mouse, touch) directly to gameObject transforms and properties, it would greatly contribute to giving users confidence to dive into more complex tasks.

 

Unity's Input system is pretty archaic. You're absolutely right in that regard. Unity is at least well aware of this and has been working on a new system for what seems like 5 years now. I honestly believe it's taking so long because they're finding it difficult to create a system that's as intuitive as everyone is demanding while being as powerful as everyone needs.

 

And as soon as they solve the "simple" question, it will lead to new "simple" thing lacking, it will never end, worse it will build up on top of the facility made.

Take for example making it simple to have an agent follow the player "without getting stuck on environment™", that's the navmesh, but user as complained that:
- it's not easy to have flying creatures
- it doesn't work on planet type of terrain
- it's limited to parallel ground
- you can't make "descent" like 3D level
- You can update it manually easily, at your own rate, without adding some code that fetch many different things.
- It's hard to make dynamically area with specific cost for specific instance when they are in a specific state.
I can assure you even if they solve these aspects, there will be a specific trivial case, maybe popularize by a random fulgurant success of the years (currently BOTW and Fortnite draws attention), that everyone will want to implement and emulate. It's always simple, but simple on top of an engine that already hide complexity.

That's why you have the asset store to provide competing solution. Making games is just not simple.

 

Unity shouldn't have any of these gameplay-related things in the engine by default. If you want a cube to move you can write a script, do an animation, or download some tween asset from somewhere.

This is one reason they need visual scripting. It's something they've been delaying for a long time - probably because someone important there doesn't want it.

I could just attach a 2kb graph file to this post with a bunch of graphs that do everything you want in many different ways, but I'm not about to dump a bunch of .cs files here. We could give you a full FPS system at 20kb that doesn't require a 500mb download from the asset store.

 

Unity is very much the Blizzard of game engines. It's not that they don't want it to be there. It's that they don't want to make a poor implementation only to be forced to support it for years because people have become familiar with it and don't want to move to a proper implementation.

If you need an example of this problem just look at UnityScript and how long they had to continue providing support.

 

I think a proper implementation is a fantasy. They said that with the UI system and that has issues, and even the new prefabs system has problems. They should just get something that works and release it. If it's a package, they can always update it, just like any asset store item. We should have had VS and a new input system years ago.

 

I never said it would be problem free. I said it would be a proper implementation. For examples check out and compare the existing Input API and first prototype replacement API to the latest prototype replacement API. The latest prototype is miles ahead in implementation. It's just a matter of ironing out the the majority of the bugs in the system now.

 

The way it maybe can be implemented is to have different ‘levels’ of configurability. You start out with the easy, fast, simple things like right clicking some object in the scene and choosing animate > patrol or whatever it is basic stuff from the menu. This gets the ball rolling for all the people who DON’T want to configure it any deeper. Then those that do, you go to the ‘advanced’ mode which opens up a more detailed representation of the system, a deeper level, and now you can configure it much more precisely to behave in different ways and have hooks into your custom scripts or whatever. Keep it simple at first for the people who just want it simple, then the other people can also use it for quick prototyping and expand on it with their more advanced skills.

Like if I’m making a 2D platformer, ok, I could throw an object in the scene and I want it to just walk back and forth on the platform... how hard should that be? Couple of clicks later and the thing is walking back and forth. But doing that in Unity right now... it’s gotta be something involving scripting or animating clips or state machines or some other wizardry which simply should not be a “requirement” for the people who just want that fairly simple and quick functionality.

I think Unity comes at these things from the opposite end, they come from the big-picture down, and try not to be too small-picture or specific, in order to keep things open. But I think that’s a problem because it’s so general-purpose that what could be really simple specific things now automatically turn into much more complicated things than they need be.

Today for example, I imported some sound effects and I thought ok, how do I make this sound play when the level begins? Well....erm.... ok.... I guess I have to go read some documentation first. So now I’m hunting around on google and in unity pages. I arrive on some audio page and now it’s talking about how extraordinarily powerful the audio system is and Doppler effects and multi-channel mixing and all this other advanced stuff.... what about just getting a sound to play? Well now it turns out you have to add a fricking “audiosource” object and now you have to somehow hook it up with your sound effect clips and then you have to go read more documentation to find out how to actually get the thing to play proper syntax n’all, and now it turns out you are gunna need a copy of the audiosource component so now you’re adding another variable and finding the ‘component’ and storing it and then finally coming up with something that actually PLAYS the fricking sound. Instead of like... here’s a sound... click on a dropdown to play it at the start of a level. Ok? How hard is that? So now I’m much more well versed in Unitys amazing advanced audio system but hey.... didn’t NEED to be. I just wanted to do something very simple, it ended up taking like half an hour to set it up.

So why can’t we just start out our development with very simple building blocks and then “drill down” into the elements that we want more control over, instead of having to start at the bottom with all the nitty gritty details and “build it up” from there? Start with something much higher level and when you’re not happy about its limitations, you click some box and a whole bunch of new finer-grained configurability shows up. And you want to get really advanced, you click some other box and now you can hook up your custom scripts and really go to down getting the thing to behave very uniquely. It seems to be a vast majority of game-building tasks are really quite simple building blocks and yet there are so many unnecessary steps interposed to get TO that simple state of something happening. Sure you have tons of freedom to make something super advanced but when you don’t NEED that, it’s a pain, because now you have to wrestle with the beast and try to tame it when all you should be doing is eating a sandwich and clicking some buttons.

 

Or just drag the audio clip into the scene and hit play....

 

Doesn’t work when you have a 1-scene game with multiple levels embedded in it, now does it. I was simplifying my example, because I actually was getting sounds to play on certain events not just level start, and it certainly was not simple or quick to do it.

 

There are some REALLY basic funcitons that I think everyone can relate to and need to use, which should be extremely efficient and easy to implement.

1. Get some stuff to show on the screen.
2. Play some sounds when it does some stuff.
3. Make the stuff move around in some basic way or be interacted with.
4. Get some stuff to react to the environment or other objects in some way.
5. Do some basic multi-frame animation.

All this stuff should be super easy, GUI-driven, extremely efficient and involve next-to-no scripting whatsoever. Right now I don’t know that this is possible without a whole litany of steps and procedures including scripting.

Visual scripting also is not the answer. It’s usually nothing less than a different way of presenting logic, and usually you spent far more time basically translating text code into visual form clicking the mouse a hundred times over and dragging silly lines and trying to figure out what the heck the spaghetti on the screen actually means. It’s hard to read, it’s cumbersome, it’s very slow for doing basic stuff like setting up some variables and doing simple math, and it typically ends up being slower than writing the code in text form. There has to be a more intuitive interface than that.

 

I disagree. Doing things in a GUI is OK when you only want to do something simple and only ever want to do something simple. But a game is never that simple, you eventually need to add more and more and more functionality. You'll find that you need to rip all this stuff out and implement it in code using coroutines and other stuff to make sure it's all intractable and intelligent.

You'll also find that doing things in a GUI soon breaks and is incredibly hard to debug when something goes wrong. What if you delete a sound file or a menu or a level or something else you thought was no long used... you'll end up with bugs that you won't immediately notice because the engine can do nothing else but assume that you wanted to do that. With code you get an null reference error when you try to use it. Amazing!

Trust me, Unity is pretty easy, there's a couple key concepts that you'll need to learn if you want to get game logic going. That's not a bad thing as it will empower you later on to make that jump from simple to complex. Embrace the learning experience.

 

https://assetstore.unity.com/packages/essentials/tutorial-projects/3d-game-kit-115747
https://assetstore.unity.com/packages/essentials/tutorial-projects/2d-game-kit-107098

https://unity3d.com/fr/learn/tutorials

Visual scripting IS NOT only node base scripting

 

I have not used the visual frameworks like playmaker, etc....

Is this not exactly what op is asking for? Well there seem to exist quite a few of those with very good ratings. Its just not something that Unity provides out of the box.

 

The detractors make some good points but wanting something easier is human nature.

Computers used to require patching hundreds of cables to accomplish one task. Programming used to require an intimate knowledge of the hardware. Getting a pc on a network used to require fiddling with jumpers on the add-in card. All along the way, the people who had invested the time to learn the systems protested loudly that it was becoming too easy and others should just learn the 'proper' way to do it-- but this is not how progress is made.

Unity itself was a huge step towards enabling many people to make games. It was built on the backs of software that came before it like GameMaker, AMOS, and Director on the Amiga. Eventually someone is going to create that program that makes game making 'code-less'. It will probably require some form of AI, but it will happen.

imaginaryhuman is simply asking for the next thing, and I would rather see UT do it than someone else.

 

Wanting things easier is fine, if there is a way to improve the usability of Unity, then that can only be a good thing. Its just that the suggestions given seem to be tailored for implementing very specific and basic functionality for very specific types of game. As neoshaman pointed out, that functionality stops being useful when your game becomes even slightly different. I don't think making Unity an easier engine to learn how to build platformers in is very useful for most users.

For audio sources, having an AudioSource is completely intuitive to me. Obviously audio has to originate from somewhere, and you can change the position visually. Playing an AudioSource is just a single function, Play(). You don't have to touch any of the other stuff.

 

While intimate knowledge of the hardware may no longer be necessary to start it's definitely necessary to progress past a certain point as a game developer. I think people have this tendency to look at games as an easy field to get into but it's one of the more demanding fields.

Most normal application developer don't have to fit their core logic into the 16.67ms (33.3ms for 30 FPS) period between frames. While we may not have to count CPU cycles now we do have to make our code and data fit into the CPU cache lines to maximize performance on platforms where the hardware is fixed for years at a time.

We've had ways to make games for years without writing a single line of code. We've even had ways to make them without any knowledge of the core concepts behind programming. Including with this very game engine.

Where this whole situation gets interesting is when you read the OP's post and discover that he's aware of the easier alternatives... but wants nothing to do with them. It's hard to blame Unity when the user is actively refusing to use the methods that are already available to them.

 

What easier alternatives? I would like to stick with Unity but I would just prefer that it not make things so unnecessarily complex when you're trying to do basic stuff. Doesn't seem too much to ask.

I'm also not looking for tutorials or basic game templates and the like. I don't have a problem programming complicated stuff. Hey I've been doing programming stuff for like 30 years now and sharpened my teeth writing graphics libraries in 68k assembly language by hand. And I also know that Unity saves a TON of time already compared to how things used to happen, having to write graphics code and physics code and all that kind of stuff by hand. It's now much easier, not having to mess with lower-level opengl code and the like. But as someone else said we ARE gradually progressing toward easier and easier tools and higher and higher levels of simplicity. Sooner or later we will see much more automated and intuitive and simpler/flexible tools that take even more of the pain out of having to go into code. I think the programming side of it, although I'm perfectly capable of doing it, is simply far too complicated and time consuming. As soon as I see that I am going to have to a) go hunt through documentation and b) write yet more code, I know instantly that this means more time being drained and more complexity and more frustrations.

 

Sounds like you found a problem to solve. Make some tools that solves it and sell it to the masses

 

Unity wants you to go to the Learn section, try some examples, watch a vid. It really is easy, but you are going about it the wrong way.

There are hundreds of titles released a week in varying states of quality made in Unity by developers with as little as a couple of week's experience. We are talking about kids that can barely code. So I don't think Unity has a problem.

If what OP has said about it being too much, then he probably should start with the C# programming language and .net then tell me what's too much. And that's long before Unity is even an issue.

Unity's own staff do not know their own engine fully. That would require more free time than any of them want to spend. Nobody fully knows Unity. I'm still learning as I go, but I only learn what I need.


Another example: I want to learn a simple new hobby - say, bow and arrow. I bet you it would take me a lifetime to learn and I would not learn it all. That is an observation that works for everything.


So with that in mind, you should build a strategy around:
a) using Unity more often than once a week
b) only learn what you need to do

If you do that, then a couple of weeks are more than sufficient to give you what you want. If 2 weeks of regular and sensible development isn't sufficient to progress, I recommend a change of engine.

 

Anyway, unity events are designed exactly for what he has been complaining.
Just declare a variable in a trigger script, put it into one of monobehavior callback and then just drop a script into a automatically created visual interface, in the editor, click and point to select a method of that script to activate, bam trigger to any other objects.

 

Been thinking about that ;-)

 

Great toolmakers take pains to ensure their tools are easily productive, somewhat foolproof and efficiently capable of producing great outcomes. By that measure, Unity is not nearly a great toolmaker.

 

All the commercially successful games people have been putting out would seem to suggest otherwise.

 

Talented people can always create great works, regardless of the tool. Deeeds never suggested otherwise. He was stating that it isn't an efficient tool, nor easily productive. That may or may not be true but no one wants to be frustrated with their tools.

 

And still, you're here, and not on some other "great toolmaker"'s forum having trouble with the most basic functions you try. Well. So they may know something about toolmaking.

 

There isn't exactly a large selection to pick from.

 

Just because people ARE putting out successful games doesn't mean it was as pain-free or efficient as it could've been. HOW you get there and the fact that you go there are two different things.

 

This is the easiest as it gets. If you want easier you need to use an engine which can be clicked together. If you know of an easier engine that's got Unity's capabilities and is easier, please do link it.

Making Unity easier will come at cost of bloating in the core engine and that is just not something Unity is stupid enough to do.

What they are doing instead, is adding functionality to package manager, new standard assets and do on. These bolt-ons are precisely what gives the ease of use, and utterly correct in my view.

Recently they significantly upgraded the docs to have hot mouseover links and tooltips.

 

Well. I think there is: https://en.wikipedia.org/wiki/List_of_game_engines

 

But this also list private engine like ubisoft's Anvil or frostbite, they you have to remove 2d only engine, and then engine that don't support enough platform or even has no visual editor, and those who only serve a single purpose or genre.
That is:
- unreal
- virtools
- godot
- game maker
- unity
- leadwerks
- Xenko
and then many of those aren't even free.
I would say game maker, Godot and unreal are the real contender here. And they are not easier ...

 

But what does "patrol" even mean, in the context of an engine that's intended to be used for all genres of games and some non-game uses as well? Even sticking to games, it could mean:
* Nothing, for the many games that don't have enemies moving around in space.
* Travel on a path set by the level designer, regardless of what happens.
* Travel on a path set by the level designer, until a player comes into LoS, then switch to another mode like attacking.
* Navigate around the level without a specific path, until a player comes into LoS.
* Travel on a path set by the player (RTS games, for example).

And every part about that movement - the speed, how it animates, how it reacts to environmental changes on its path - all depend on the type of game as well.

Tools like RPG Maker are easier to use because they make a much more limited subset of games. And there are packages for Unity that do that (support a specific genre). But the engine as a whole is too broad to have a single meaning for something like "patrol".

 

people are very quick to forget that unity has taken away 99% of development pain when it comes to the features that are there and the quality they are implemented at. Being able to build an empty scene and run it on so many platforms would take any of you many months and even then it would have far more bugs than you could imagine.

Unity is easy. Period. Could it be easier? sure. But is that what the majority of the customers want? Probably not. I want them to keep up with the trends, continue to optimise and make an engine that enables me to produce my best.

 

I think your assumptions are wrong. Because the premise was simple, are there alternatives? Yes there are. The price, feature set or platform support weren't part of the premise.
You have a lot of alternatives, now, of course you can be picky and don't count the pricey ones where you have to put a sizeable downpayment on the table, but that wasn't the original question.

 

But most alternative are literally not affordable nor simple, which was heavily implicit given the stated topic, context matter Your move!

 

Within the context of this thread Game Maker is definitely easier. Remember the OP is being overwhelmed by the options available to a developer in Unity. He doesn't just have to deal with the Unity API. He has to deal with the Mono framework too. GM has a far simpler engine API and it doesn't have a framework like Mono.