CODEWITHSUNDEEP
c#unity-game-enginebehavior-tree
Giora Guttsait
Giora Guttsait

Reputation: 1300

Want to start unity, need some basic idea of how to unity-fy some of my class ideas

This is a repository of mine, specifically the skill-system classes. I'm mostly doing work in XNA, which these classes work fairly well with.

These classes aren't finished, they're concepts for improving a previous game of mine, following some instructions from a previous post.

I know about Unity's ESC(entity component system) approach, and I know the basics of what GameObject is and how components work, sorta.

The classes I've wrote manage stuff like effects on units, and how they are applied.

The flow is: Behavior -> Effect -> Ability

For example, IBehavior is the interface for behaviors.

I have several abstract classed: ActivatableBehavior which is an abstract for all single proc behaviors
TogglableBehavior is base for, obviously, togglable behaviors
LimitedTimeBehavior is base for timed behaviors
Likewise, I have DurationBehavior and TickBasedBehavior which derive from LimitedTimeBehavior.

How would something like this be implemented in Unity?

If it helps, my game is supposed to be rather simplish, Little Fighter 2 style, server-client based and so on...

If this Question is too broad and/or not clear enough, say what's missing and I'll try to add it!

Upvotes: 1

Views: 117

Answers (1)

Draco18s no longer trusts SE
Draco18s no longer trusts SE

Reputation: 15941

Just because Unity has an Entity-Component system doesn't mean you have to use it. You could just as easily attach a single script to the main camera and do everything inside that script, treating it as your main game loop (I've worked on a project like this).

I don't really encourage the creation of Components which describe a tiny piece of behavior for a GameObject and interact back and forth with other Components. e.g. all of your IBehavior objects would be used exactly as you're already using them: only called and stored within your Entity class. Making them Components in their own right means attaching and removing them from GameObjects at runtime, which isn't the most efficient of procedures (removing one uses Unity's Destroy() method and sends the component to be garbage collected, which Unity is Not Very Good At).

The ECS Unity has is much better at a broader level, implementing the world and the actors within it, leaving the behavior pattern to a subsystem managed within those GameObject's attached scripts. There are benefits to splitting one behavior into two, as exemplified by the default character controllers. One script which simply moves the character around and a second script which tells the first which direction to move in. That way, the same motor can be used by both AI units and the player just by swapping out the input script. But having a separate script to handle every kind of input ("this script handles [E], that one [space]" etc.) and sub-behavior ("this script, when attached, causes the unit to search around for the player, that one makes them attack" etc.) is unnecessary.

You'll find various AI systems on the asset store that work like this: two or three scripts attached to a GameObject which then have their own internal ECS to manage the AI state machine or behavior tree (typically the AI state machine, the character motor, and a pathfind navigator) where every AI state and action is a script, but not one that inherits from Component (e.g. MonoBehaviour).

Upvotes: 2

Related Questions