Does Unity need a better out of the box AI toolset?

What if Unity had a richer set of AI tools built in e.g:

• Behavioural Trees
• Environment Query System
• Blackboard (Simple System allows NPC's to share information e.g. Spot's player)
• Blueprint Style Node Based Graphical Code Generation System
• ...
• ...

It's main competitor Unreal has at least the above and probably more out of the Box.

What default AI toolset would make your Unity game AI development a lot easier and quicker?

Are there already AI tools that you would love to see brought into Unity as default tools?

 

It's a poor craftsman that constantly blames his tools...

 

You know I'm getting the impression you would be happier with a different engine.

 

It's poor tools that force you to re-invent the wheel!

No way, I would have nothing to complain about (well apart from the UI) and it would just show off my lack of professional 3D modelling, shading and AAA game development skills and probably run like a one legged dog on my aging hardware.

 

No unity does not need a better AI toolset, people should know how to program it themselves..if they don't they shouldn't call themselves programmers.

 

At the same time why should we have to re-invent the wheel? Having a basic framework to simplify the process is no different from having a game engine. Yet I don't see people claiming that you can't be a game developer if you don't know how to build your own game engine.

 

Azmar, do you have a car or bike, did you build it yourself from scratch or a kit?

So instead of making our dream games we should build the tools to make the games first, that's like suggesting people who want to go on holiday build their own kit car/boat/plane first.

I can understand that as developers we will want to customize tools and tweak them to make our game development pipeline more streamlined (and Unity is great for doing this) but do we really need to keep re-inventing the wheel?

 

I believe that's why we have the Asset Store, though. You don't have to reinvent the wheel if someone else already has. But you have the option to use their asset, or create your own from scratch (which you can then re-use in any of your subsequent projects).

I think this is a much better option than including anything and everything in the core package. I'd prefer to not have to download a 10GB editor every update just because people want things included in the box.

 

You're right. At the same time though that doesn't stop Unity from developing their own solutions for things already covered by assets on the store. User interfaces, networking, etc. They even have a visual scripting tool on the roadmap now.

 

It would be absurd to learn a new AI system based on Unity, like shooting yourself in the foot if Unity goes down or your job asks for you to implement a AI system in Unreal Engine or whatever future engine. Great because you only know how to do some random asset kit from the unity store, not know how to code it and now a useless developer when it comes to AI.

A shader is nice, because everyone will use graphics and easier to make more general where us programmers don't really need to learn or care about it. AI is not a car or bike, its so incredibly specific to each game and forever growing that it should be programmed yourself the most optimized way. I don't want to use someone else's buggy AI or AI that is not perfect to my needs. Spending time learning all these AI kits in any way, just takes away my time spent developing a real AI system that is optimized vs a general AI system i gotta learn from scratch and bang my head against the wall to try and make it work.

 

Fair point. I guess in my head I'm seeing the number of broken and partially implemented features and wishing attention focused on those, rather than on new features. I do understand they may be separate teams altogether.

 

We need to build the dev tools first. For some reason I completely neglected that when I got into Unity (probably because several people told me Unity already had all that was needed). You have to build the dev tools or find the tools already built (asset store perhaps).

If you're doing something trivial... the next Flappy Bird and so on you can definitely just jump in and knock out the game easily with Unity "out of the box". The more ambitious your game (not graphics I mean the game as in the amount of interaction, greater importance on AI and so forth) the more you will need to build your tools.

It's like your bike example... if you want a stock bike go to Walmart. Get a bike like everyone else If you want a stock kind of game use Unity as is or use kit assets as is. If you want a custom bike you gotta either hire someone to build it or build it yourself. Same for games.

 

You seem to be under the impression that we're suggesting Unity implements a specialized system. What is being suggested here is nothing like that at all but simply an expanded toolbox to create those systems. After all it isn't like a behavior tree would restrict you from another engine. In fact both Unreal and CryTek have behavior trees built-in now.

There is a big difference between being unable to build your own toolbox from the ground up and wishing we didn't have to do it ourselves every time (or at least for every organization). Why re-invent the wheel for a basic concept that can easily be implemented once and the source code provided?

 

All the suggestions in first post are covered by asset store by the bucket load. Asset store is one of the primary reasons to choose Unity. For example, you can't get Final IK for UE4 and would have to code it from scratch. There's so much on asset store that UE4 doesn't actually have solved at all, and people forget this.

As for AI, that's a hard question to answer. Navigation is practically the only area of AI where one size could potentially fit most situations. The rest, not so much. As for blueprint style stuff, Unity has plans, plans within plans and so on. Probably connected by little spaghetti wires.

 

@Ryiah, you are a perpetual Devil's Advocate. I never know which direction you're going to go on an issue, and I believe sometimes you take the side counter to mine just to create stimulating conversation.

 

What happens though when other companies start offering those custom bikes for the same price that Walmart was offering that stock bike? I don't want to continuously bring the competition into this discussion, but they are essentially doing just that.

I blame the distinct lack of fun discussions on this forum as of late.

 

"What if Unity had a richer set of AI tools built in"

I WOULD BE SO PISSED Arowx!!!
TELL THEM NOT TO DO IT!!

 

I'm sure @Ryiah is an ENTP-A like me ..

In answer to @Arowx of course, if they used a variation of Mecanim for a visual state tree AI system that'd be awesome.. It's like asking, do you want free money no strings? Of course we'd want something like that.

 

A built in behaviour tree and FSM system would be nice. Not strictly essential, but nice.

 

Would rather have them spent time on something else. Really brilliant solutions on the asset store for most of these.

Wouldnt mind if they add them though. In the end i always end up coding most of the AI myself....

 

No, I'm an INFP. At the same time though I do love a good discussion and the information that comes from it can be great.

 

Really it all depends on what you mean by tools.

I have no real interest in AI tools because the actual AI stuff is simple IF you have the necessary data to work with. If you mean tools to more easily get information out of the environment so our own AI routines can make use of that info... that would be good. However, very recently I had a eureka moment that gave me a glimpse into the Unity Way.

One of the biggest challenges for me moving (trying to move) to Unity has been how abstract things work. It's like all of the vids showing people plopping in 3D models quickly making a nice scene. I'd see them happily working away in the editor and think "Sure that is quick n easy and nice they can play in the editor all day and night building perty places... but what good is it in the end?" Because it seemed like just "islands of visual content" floating in a void: no details, no attributes, no underlying game data to back them up. No way to define a region and add some basic data to it (a name, a message, etc). Basically just stuff to look at.

I might be wrong but through time I have come to believe this is actually how you are supposed to develop in Unity: any data you need should be added visually to the scene in the Editor. To someone who is used to working from the data structures up and finally ending up seeing something on screen this just seemed very strange and sorta hackerlike. I kept thinking "there has to be another way. I am just not understanding this. Missing something somewhere. Where the hell are the hooks to get some data backing up these floaty GameObject thingamabobs?!"

Like I spent massive amounts of time digging through the Editor menus, watching videos and reading articles trying to understand how people were actually adding the data structures they needed to the scenes they were creating. Then finally (only recently) it hit me! It had been right there in front of my eyes all of the time and I missed it because I kept looking past it. When people were playing around in the Editor adding empty GameObjects, colliders and so forth that was their way of adding hooks for the data to the scene. In fact, it seems to be the only way. Visually. In the editor.

So anyway @Arowx I think everything is in there that is needed. Basically just fill your scene with empty game objects and colliders so you can add all of the data you need to easily do your AI. If you want to define hiding spots for your NPC slap GameObjects on the relevant parts of the scenery and so forth. If you want to define events at certain locations slap more GameObjects into the scene.

Basically just plaster the hell out of your scene with GameObjects to add any and all data you need to query your game world. Now that I see it this way it almost is starting to make some sense and seems a whole lot less cryptic. Used to always seem to me like half of the equation was missing.

And if this is still not really the Unity Way then I think it is just never gonna click. lol At least with this new lightbulb moment I can understand why people want to play in the editor all of the time and how they are actually hooking some dang data to their scene.

 

What the what now!?!? I'm an AFOL, but lost as to what those terms are.

 

The difference is that Epic dogfood's Unreal and needs those tools for their own games. They also have a development model allowing outsiders to take major roles in the development of the engine and tools.

Unity would need to have its own gaming division in order for those specific features to appear in the engine. Or a development model that is incompatible with the company's goals. Otherwise the Asset Store is the more time/cost efficient and democratic approach for adding very specific features that people want.

 

And at same time a very good reason to avoid it.

 

Myers-Briggs personality types. I will say no more, and let the two to three hours of wiki walks that may ensue be completely your fault if you go to research it.

 

His eyes are beginning to open. Hallelujah.

Everything is a GameObject. Drag and drop solves all things. That is the unity way.

 

The power of components compel you. The power of components compel you.

 

Ha ha! Well I mean I knew some of it. Obviously, I know you add components to your "real" game objects (player, enemies and so forth) and in those classes you can define data and behaviors.

But for the life of me I couldn't see how in the heck you were supposed to actually work with this abstract "stuff" that is stuck out in a scene. Like say, you had a large terrain but wanted to designate certain areas of it for certain purposes (could be an entrance to a cave or maybe you just want to display a little message showing the name of this particular spot so need some meta data for that and so forth).

If everything was built up from data we'd have the underlying data structure first. The data would drive the visuals. But when you are doing the visuals first it just never clicked for me where the heck the data was at. And I thought surely we are not suppose to fill the game world with a bunch of GameObjects for this stuff. I did think of doing that but I thought that just seems so weird. So I figured there must be some other way that for whatever reason I just was not seeing in any example any place. It just seemed kind of amateurish / inefficient to me to load up the scene that way. Not sure how exactly to explain it.

Going to Unity has been just a huge shift for me. But yes completely agree that hallelujah I finally get it. LOL! Just used to data driving things. Not this sort of hybrid approach. Really it is kind of like the visuals drive everything here. Which is why I could never quite get the Editor thing. I just wanted to jump into the code and stay there completely. Which I did find out can be done to a large degree as well. BUT it is nice to finally see that yes you really do just throw GameObjects all around. They are for anything and everything.

 

Anything simple I've always just written straight in code. Super fast and flexible, integrates with anything your code can touch, which is... everything.

Past that, do you realise that RAIN is free?

I mean sure, it'd be rad if Unity had already done literally everything out of the box, but there will always be things that we can point at and say "hey, I wish that was built in!" Since it's impossible for Unity to literally build all of the possible things it's pretty cool that there's enough of an ecosystem around that things like RAIN are readily available. And I don't just mean because it's free. I mean there's an Asset Store (not to mention private sellers, too) with all sorts of stuff that we can get that provide way more value than they cost.

Here's an example: Instead of spending weeks building a dynamic sky with day/night cycle into something I was building a few weeks ago, I paid less than $100 to buy one and had it integrated before lunch. That was at work, so total cost... under $200? Even as a hobbyist, consider the value of the amount of my time it would have taken to achieve the same on my own. It would delay a project by weeks at the absolute best! So yes, it'd be nice if it was one of the free things that was just there when I installed Unity, but that's not a realistic desire for all things, and being able to grab stuff off the shelf and have it working in a couple of hours is literally the next best thing.

 

AI is surprisingly easy to write, especially if your game doesn't need it to be too smart. Heck, you could write AI agent that moves around randomly and stops each few seconds to "rest", then move to player/attack him with a projectile when he's close enough or he sees him (a simple raycast) and people would get impression that he is patrolling terrain and attacking any undesirables such as the player.

 

Honestly, of all the stuff you need to write - I've found AI stuff to be some of the easiaest. The hardest parts really do come out of box with the navmesh and navmeshagent - although you can certainly replace these if you choose.

The reality is that player expectation for most AI behaviour is so friggin low, that for most games I'd be shocked if you can't write most of it in less than 100 lines. "get player position. if player in range, attack. If not in range, move toward player". If you want to get fancy you could coordinate AI, "get player position, foreach enemy get random point in sphere * random + player.position". You can get some really fancy effects if you start sorting stuff!

I actually spent a little time recently considering if i should bother with a state machine for some AI, I wanted some sort of fancy effects like a "when the villager notices you, he grows suspicious, beckons other villagers to gather, points to player, spreads suspicion across gathered" and stuff where behavior spreads across other AI. It honestly all ended up being so simple that it just seems sorta silly.

But if you really want state machines couldn't you just use mecanim state machine behaviours and the like right out of box?

Come on dude, seriously?

public static class Blackboard{ public static Vector3 LastSpottedPlayerPosition; public static float TimeStamp; }

like -- come on... if you made this like 5 lines instead of one you could even avoid the static stuff!

 

@frosted Completely agree. Game AI is very simple. We deal with simple metrics and it really doesn't take much to surpass the AI commonly found in games. Things get more involved when dealing with groups but not by much. Basically just layers depending on what you want to do.

The main question is will anyone really notice and appreciate the extra work you have done on the AI? I think that is where the challenge is. In providing the feedback to the player that this is not your run of the mill cannon fodder enemy or whatever. And in making them appreciate it.

 

For most things yeah, like your regular NPC based go do stuff it's sooo simple.. But if you want the AI to be deterministic based on a wide range of actions and related responses based on user input reflection. It's not so simple..

Like everything that is ever done in the world of games, it really depends on what YOU are trying to achieve. If I was just doing a bogo standard RPG, it wouldn't exactly be difficult.

 

I agree with that. Basically every aspect of the game from audio to graphics to AI, mechanics & interaction and so on a person needs to decide how much effort to invest. And where to make trade-offs to make the project doable in a reasonable time-frame.

If everything is done at standard game level or below it will be much easier but probably not worth playing. If everything is done at the extreme edge of best of the best there will probably be no game to play. The more you go beyond the bog standard Indie norm definitely the more effort and time is required. That's why for me having my main interest in AI and interaction 80% of my effort will be toward that end and 20% on everything else. It is the only way for me to be able to reach my goal and actually complete things.

 

I love writing my own AI code, but I can see how including some AI code with Unity would make it easier for a lot of people. At a minimum, a native class for finite state machines and a native class for behavior trees would catch a lot of typical AI use cases for most people.

A blackboard class is a bit more specialized, though. I don't think there would be a good one size fits all use case for a blackboard AI class. For example, I use a blackboard in each large ship in my space game so individual turrets don't need to scan (SphereCast) for nearby enemies. I use the blackboard as a optimization thing. Other games may use a blackboard to coordinate groups of troops. The concept of a blackboard is awesome, but I am skeptical about making a built in blackboard class that tried to catch every use case.

Similarly, utility AI is really important staff, but that may be difficult to abstract into a generic solution that tries to satisfy every use case. There are books on the topic of game AI, and most of game AI is not generic use case stuff. Even the FSM and BT examples can sometimes be more efficient using custom code instead of a generic FSM or BT class. But like I mentioned above, I do think a lot of users would benefit from Unity adding native FSM and BT classes.

 

OK How would you implement a cover mechanic so Enemies / NPC's could use cover.

Note: Unreal has a built in Environment Query System where you can configure a test that will find cover within a region around a NPC with a given observer. You end up with the Unity equivalent of:

Code (CSharp):

1. Vector3 FindCover(Vector3 enemy, Vector3 pos, float radius);

You could go the Unity GameObject route of every scene element prefab needing to have cover areas, you sphere cast for the cover areas send them the position of the enemy and they return a set of vectors and you find the nearest one on the navmesh (and exclude the ones not navigable to e.g. in house as door is outside of radius).

It's workable but very clunky, Unity already has Umbra occlusion voxel data this combined with navmesh data and an enemy position could produce a quick enviromental query or cover system.

Now repeat for 100 villagers, 100 enemies and the 100 troops the player has and hit 60 fps!

 

How many games need a FindCover function? The FindCover function would be useless in my space game, since there is no static terrain. I can definitely see the use of a FindCover function in a game like Unreal Tournament, but would it be a useful function for other types of games? And how much would we need to lock into other native elements in order to get that function to work as expected? Again, an Environment Query System would be one of those things I see as a custom edge case rather than a common core feature.

 

Do all 100 villagers, 100 enemies, and 100 troops really need to always know their nearest cover?

 

I like these sort of questions, they are extremely relevant to my interests. People spend so long telling so-and-so's to ditch their AAA MMO idea, because it would take them 10 years (if at all) to make their dream game, and then a thread comes up about whether or not we should have this and that toolset built in and suddenly it's like "well if you were a real dev, you wouldn't need that".

We need tools. Good, sharp tools and lots of them, ready-to-go. Tools that are easy to use and take the right shortcuts. Tools that fit into a fast workflow. Tools that take us 90% of the way there. There's always room for more.

On the subject of AI, it is anything but easy to code. I've coded state machines (easy to start with but quickly becomes a mess if your agent is anything more 'intelligent' than a doorknob). I also coded a behaviour tree system, which I finally finished but lacked an easy way to use (I never did get around to working on the noodle graph I had in mind). A good AI is anything but easy and can be quite unintuitive as it becomes more complex.

For some quality npc behaviour, forget state machines. Behaviour trees IMO are a good, basic, versatile tool and I'm not surprised that UE included it as a basic functionality. I would definitely like to see it built in. I haven't looked at or bought BT assets from the store, there may be some good ones but it would definitely be good to have it built in.

 

This greatly depends on the game you're making.

 

Until they are out of the conflict zone, in theory the villagers might need to find the best cover from both sides or end up as human shields or collateral damage.

No once they find initial cover they will spend time moving there, then need to lie low (villagers) or find the next cover point to advance to (troops/enemies) or escape to (villagers). Also if a trooper/enemy finds a good cover position in range they could set up there.

If we take modern weapons into account then we would probably be talking about at least a 200-300m wide area with about a 1 km initial range (snipers).

With medieval weapons a similar width but probably about 300m initial range (long bow).

 

Yes but my point is that if Unity can make a system that performs well at higher Unit counts then using it for smaller unit count games becomes a no brainer.

Unity has a multithreaded core now, in theory the AI subsystem/modules could be working away while the gpu is busy rendering the last frame.

 

@Arowx that is a great example. Honestly, I'd have to sit down with some graph paper and do some doodling to come up with a couple of designs to test out.

There are multiple ways to implement the stuff so that is what adds some time. Basically, there may be at least a dozen ways to the end goal but that is not necessarily a good thing because generally we'd like the best way. And of course even that best way may change depending on the specific circumstances.

With Unity I could see throwing out GameObject HidingSpot beacons at the locafion of the hiding spots. Using events these could fire once every 2 to 7 seconds "Hiding Spot here at location X, Z, Y".

But as soon as I thought that... my mind goes to well do we really need hundreds of units of various kinds all receiving these events? Seems a bit much. So then my next thought is to build a sort of EnvironmentIntel thingy that subscribes to such events. In this case, it would receive the various HidingSpot beacon broadcasts and add them to list of HidingSpots. The various units can then simply query that EI with a call to GiveMeAHidingSpot(HereIsMyLocation). The EI can run a quick check and let the Unit know the closest hiding spot.

However, if we can assume there may not always be a path to the closest hiding spot (perhaps due to roads blocked and such from combat debris) we may want to return a list of the 3 to 4 closest hiding spots in order of close to far. And of course the hiding spots would need to periodically check and see how many units it is serving. When at max capacity it would need to send out a NoLongerAvailable event and stop broadcasting the HidingSpot beacon.

Again this is off the top of my head thinking while replying but in general is how I think through such things. Start with the braindead obvious approach and clean it up while thinking through it.

This certainly may not be the best way to do it but I'd add this to my R&D list of viable options to explore.

 

Or you could do cover the standard way by baking it into your pathing maps.

 

Man, I feel like a bitter old man with a cane - shaking it at the kids, "just learn to code it yourself! Kids these days are so entitled!"...

"back in my day we had to cobble games together with some mud, duct tape and a TI-84!"

 

I don't see how that is the standard way. I guess for Unity and maybe UE it is? But if it is the standard way... a solution already available... then I don't see why the question even came up.

 

If we were aiming at a TI-84, behaviour trees would no longer be relevant ;D

 

I'll expand on that then. It's the industry standard way. Now, there are probably a dozen different ways to actually implement cover systems, with the biggest differences being how much setup is required and what constraints there are in the geometry.

In fact, most problems involving where to go are best solved using pathfinding. It's not hard to construct a 3D level where the Euclidean distance and path length aren't even remotely close.

 

Ha ha. Well that is actually kind of funny that nobody here said to bake it into the pathfinding. I guess that means most folks here have no clue what the pro AAA are doing or son't realize Unity can do it. lol I figured Unity didn't even have support built in to deal with cover systems. I just (as in now) did a search and found a lot of articles on building cover systems in different ways (generally applying a scoring mechanism) as well as a couple of Assets on the UA store for cover systems.

In short: if there really is a standard to bake it into the pathfinding then the issue is that is not common knowledge in the Unity community. Or people just like to roll their own for the fun of it.