Let's talk character controllers...

I feel like you may be trying to speak a bit outside your wheelhouse here.

 

Wouldn't be the first time!

 

That's not even close to the only relevant question.

User-facing functionality is not the only thing that matters. There's a heck of a lot of work between grabbing something off the asset store and shipping a complete, polished title of significant scope. Your controller will often impact multiple facets of that.

If you want to ship stuff of significant scope and you want it to be of quality then it's pretty important to realise that "functioning as intended" is the starting point, not the end.

 

Features aren't the point. How they integrate with the rest of the game is the point.

Someone mentioned an inventory system. Think for a moment about how that integrates not just with character controls, but also with the rest of the game. How are items authored? How are they put in levels? How do you know if an item is already collected if you reload an area?

These things all have a functional side. But they also have workflow considerations which will impact far more dev work than just making the functionality work. An experienced programmer or designer will think through the whole project impact of multiple approaches before picking what is best as an implementation approach.

An Asset Store vendor can't do that because they don't know anything specific about your game. The best they can do is make assumptions based on common cases.

Tweaking settings won't help with this. And they have plenty of limitations elsewhere, too.

Why would you recreate it? It's a generic solution made to please many projects. That significantly increases complexity, and is completely unnecessary if you're making something which just has to fit a specific game.

Also, if it's going to take you a year to recreate it then "mastering" it in less than a week is dubious at best.

And here's something I'm not seeing raised. As a learner there's a lot to gain by making your own stuff for the sake of learning. You'll learn a lot more by making your own simple controller than by figuring out how to use someone else's fancy one. So if that matters to you then consider your higher level goals. (And if you're a beginner I don't feel that "ship a commercial game" is necessarily the best starting goal. You wouldn't charge for tickets to your guitar lessons...)

 

By the way, I can illustrate the issue with asset store character controller assets using space kit as an example.

Let's say I'm doing something and I need a spaceship to be displayed in background.
Let's say that I'm not doing lowpoly but actually want PBR material/realistic.

Let's say, I'm looking for something that vaguely resembles Sulaco or Legend of Galactic Heroes spacecrafts.

Spoiler

Basically menacing, not built for comfort or looks, rusty and with peeling paint in places.

I can likely produce a design, model and textures myself, but with that not being my primary skill, I'll probably working at 10% efficiency of the trained artist, and it will take long time and will be painful. Meanwhile it is not an important piece, so investing into it doesn't make much sense. So....

I go to asset store.

Here's how it should go:
I scroll through the packages find one with spaceship, look through watermarked images of models it includes, and here we are - sulaco look-alike. I look for a video to see if texture detail is in line with the rest of the game, click buy, plug it into the scene, and live happily ever after.

In this scenario I save time in exchange for money.

------------
Here's what's gonna happen if the developer takes it too seriously. Be aware that this is not aimed at you (as I never bought your kit), but just for illustrative purpose.

I find a cool looking asset desiged by somebody who apparently worked at NASA for ten years, then spent 15 years learning modeling and art to dedicate their life to making fictional spaceship, and is essentually a spaceship god at this point. The asset is high rated, and highly reviewed, after looking for an example, I fail to locate the "faux-Sulaco", but, while still unsure, I decide to buy it. Because, hey, it is high rated and stuff. And I fail to spot words "modular kit".

Upon the purchase it turns out to be extremely thoroughly done modular kit with thousands of parts, multiple pdfs, and every possible ship part in existence catalogued. However, I need to build the ship myself using provided editor.

I spend a week looking through it, and fail to produce what I had in mind. No faux-Sulaco for me.

In this case, I wasted my time instead of saving it.
--------------
Here's what could happen if I fail to locate the kit in this scenario and seek a compromise.

After looking through asset store and failing to find anything suitable, I give up on correctly looking ship, and instead make it into a black sillhouette, which happens to be suitable for the use case...

More time than scenario #1, less time than scenario #2.
------------

Basically, the issue with asset-store bought stuff like controllers is that you're likely to encounter scenario #2. In programming, there's a balance between development speed/simplicity and extensibility/flexibilty/comlexity. Meaning an inflexible solution can be quickly created, while something that can be updated for many different uses and is developed with flexibility in mind often takes more time to develop and ends up more complex.

Because a sellr of an asset store package is interested to make the package as appealing as possible to large number of people, so they'll be making a kit or configurable script.

To use this kind of product you'll need to understand the alien logic used by the developer, find documentation and tweaks you'll need and then spend time experimenting until you do it right. If you know how to program, the time spent learning the system can very quickly outweigh benefits you get.

 

My point there had a specific context, which was whether there was a non-bridgable gap between popular games and asset store product capabilities. One should not operate on vague correlations when it's possible to measure things practically.

These are imprecise assumptions. The same requirements and difficulties apply when writing your own code, except that chances are the dev of the asset has already thought of (or been made aware of) many different use cases. After all, it is their job.

I think you are also applying theoretical perfect case to your argument. Assets are not usually used by very experienced programmers, not do programmers typically know exactly how the code might need to be changed and modified down the line as a game develops. Even the best programmer will probably apply a 'good general principles' approach at the start, which is exactly what (good) asset store creators do, and they have much more experience conceiving such principles than most.

The whole point of an asset is to enable you to pick and choose what you want, and if you decide you need something in the future, you can easily enable it. And a good asset does not introduce complexity to one system simply by the fact of another system being there as well, and organizes things to enable someone to easily apply a specific context to their work.

Unity has tons of features, yet nobody is unduly bothered by unnecessary features being available in the editor that they don't need. They simply ignore them.

I strive to make my kit work the same way. For example, I have added a character to demonstrate entering and exiting a ship, and it uses the same radar, weapons, and health as the spaceship. Because I wrote the code properly, there is no spaceship mechanics in the inspector of any of the components applied to the character.

Fair, but this is a question of goals. I don't think it's unreasonable for a beginner to want to ship a game, it's up to the customers to decide if it's worth it or not. There's a difference between being optimistic about your abilities and jamming a few assets together so that you can scrape a few dimes together.

Also, I have seen people who are well experienced with Unity who struggle to create games (though they may be very good at their particular field) and beginners who simply have the vision, consistency and industriousness to create compelling gameplay in very short order.

There are not only 2 scenarios here. If the kit is actually capable of creating the ship you need, it's very likely you could put it together in short order. Again, assuming the principles of the kit are not completely out of whack. It seems like in your scenario you misjudged what it was capable of.

An asset creator needs to demonstrate how to use a kit, and to be able to communicate to customers fairly well what it is and isn't capable of. Nothing is perfect, but this is a solvable problem.

I think the argument for being able to create an inflexible solution quickly is too focused on the start/prototype phase as well. Prototypes are easy, but by the time you add all the little (and big) details and sub-features you require to finish your game, and rewrite your 'inflexible' solution 5 times to be able to work with the other systems you develop over the course of the game, the week or two required to learn, enable and configure all these systems in an asset is minuscule by comparison.

 

Unflexible code is not maintainable. So thats a no go.

A well designed maintainable code base is easy to extend and pivot if so needed. Thats the difference with asset store code. Asset store code is bloated with all these features that you might not need. While your own code is written for easy maintainability if so needed.

 

Completely depends on the asset. I have had assets (publisher linked below) that were very modular in design allowing you to add or remove features by simply adding or removing the components that provided them.

https://assetstore.unity.com/publishers/10305

 

Microsplat comes to mind. They have a core asset than you can extend it with plugins.

 

Maintainability and number of present features are not polar opposites.

 

Only if you have thought about modularity, composition, abstraction, yadda, yadda.

 

No, I'm really not. To the contrary, I get the impression that you think Asset Store vendors are somehow perfect, because...

This is not reflective of the vast majority of experiences I've had with the Asset Store.

More broadly, in response to that whole post, I just want to reiterate: making something function is not the hard part. Assuming that a developer can do so reliably is not a "theoretical perfect case", it's "being competent". Going from "a bunch of individually functional features" to "a complete, polished and shippable product" is where the real work in a commercial product often is.

If that's "the whole point" then it's missed the point. As a customer who ships products, all I care about with an off-the-shelf solution is whether or not it helps me ship more quickly and/or with better results. I honestly don't care about how easy it is to turn on a new feature, because in isolation that tells me nothing of value. Making something function in a game is a tiny amount of work compared to the rest of what has to be done between there and getting it into a quality, shipped product. Prioritising ease of your first few steps over efficiency for the rest of the journey is short sighted at best.

None of that is to say that off-the-shelf stuff is a necessarily bad idea. I use it myself, it often can work quite well. But a character controller is fundamental enough that I lean heavily towards writing my own.

 

That's false.
"Unflexible" code will keep doing the thing it was designed to do from now on till the end of time. Also, due to being simpler, it will have higher maintainability. Less code means less code to babysit. Flexibility costs resources, and that's why KISS/YAGNI exist.

"IF" it is capable.

In my scenario I want a ship, and not a ship constructor. So the "happily ever after" scenario is the one where I got the ship without doing extra movements.

A constructor offers features I do not need, has higher complexity because of them, and requires time to learn them.

In similar way, if I want a banana in my game, I need a banana, and not "customizable generator of every fruit on earth".

 

No unflexibile code means its hard to extend and build upon. Thats unmaintable.

 

Something that already works and perfectly performs its function does not ever need to be extended.
Likewise, a code that already has clearly defined function is "built upon" by being CALLED and USED.
Extending is not maintenance.
Maintenance is having to revisit the piece of code due to api change to ensure that it continues to work.
Ideally, code should have zero maintenance code.

A good example of well written code is Math.Sqrt. You can't extend that. You can use it. You can build upon it. You likely only need to write it once and will almost never need to revisit it.

That's how it should be done.

 

No adding a new feature into the game and its impossible or very hard todo that is unmaintainable. So if your character in unmaintainable its also unflexible.

 

Having that "asset flip feel" imho has nothing to do with using assets or not, it's about having proper artists and gamedesigners on your team that make sure the project is a well desgined cohesive whole in the end, and not a jumbled together mess. You can have that "asset flip feel" even without using a single 3rd party asset. It's just a contrived way of saying "bad".

If Valheim's code is a mess, I'm scoring that as a point for the art-and-design-are-more-important-than-a-pretty-code-base school of thought. Which always seems to be a weirdly unpopular opinion around here, and no doubt will be met with the counter argument of "Any finished game is still better than a game that never makes it to release because it crumbled under the weight of the tech debt that the artist coders created". To which I can only reply that there are various released games that have S***ty artist code under the hood but are stable and good, and there are games with fancy industry standard codebases that don't make it to release or they do and no one cares about them because of lacking artistic merit. Having all roles well filled is always preferable of course, but I don't think getting hung up on code maintainability etc. past KISS and YAGNI (which I agree are super useful) is worth it to the extend that often is recommended around here.

 

Both code AND art are super-important. And I will say it: equally. Although there are games with trash art and good code features and with trash code and good arts, it is not the norm. You need both to have a decent game.
And I'm not talking about either expensive design or super-architected code. Extremes on both ends and on both art and code are bad.

I agree on the getting hung up on "clean code" and other idiotism are just idiotic. Getting s**t done is more important. But on both fronts. And obviously, finding a fun mechanic is way more important than clean code or any art you can find.

If it's not fun, you don't have a game no matter how stylish it is or how well-architected your code is.

 

Nope. That's not how it works.

Scenario #1:
"We're implementing a new character controller, but in case we'll ever need to update it, let's implement IRotatorController, IWalkController, IJumpController, and others and have the component derive from it, and also hide it behind a facade, while instantiating the componnet through a factory based on a yaml configuration file! Surely, nothing can go wrong with that"

Scenario #2:
"Let's implement absolute bare minimum we need and keep it readable. A single float for heading and that's it."

Six months later you need to update the code.

Scenario #1:
"What in the hells is IWannaPoopController, why is it part of every message and what do we have twelve factories in this thing?"

Scenario #2:
"Been six month, but given that this thing is simple as a brick, I can see how it works in a glance so I can code in a new feature"

In my opinion, Scenario #1 is the wrong way to do it, and Scenario #2 is the right way to do it.

As you can see, this is YAGNI/KISS. Yagni stands for "You ain't gonna need it" and means not to add features you don't need, and KISS stands for "Keep it Simple, Stupid", and means you shouldn't overcomplicate the code unless you can't live without it.

In my opinion, scenario 1, where you explicitly code in extensibility is the wrong way to do it, as in doing so you create technical debt. New object hierarchy means more documentation, one more system to monitor and babysit, which drives both development and maintenance costs up.
In scenario 2: You create the absolute minimum thing that works, and lower complexity means that it is easier to maintain and modify BECAUSE it doesn't have as many parts as the "extensible" solution.

The reason why this approach is recommended, because programmers are normally humans.
"To err is human" (and to arr is Pirate), meaning in many cases when making some assumption about the program, you'll be wrong. So, you, as a human, will decide "i totally need a plugin system for this!", will code extensible class hierarchy, and will waste time for something you don't need. This is one of the early OOP traps, by the way - it is possible to spend inordinate amount of time coding "beautiful" class hierarchy while not work is being done.

KISS/YAGNI forces you to avoid doing anything other than bare minimum, and in doing so create a "lazy evaluation" equivalent of programming for features. You think you will need it, but you don't need it right now, so you don't implement it right now. Time passes, and turns out you were wrong and didn't need that thing at all. As you can see this also prioritizes adding new features through writing code and not, say, subclassing and overriding. In fact, with this approach iti s frequently a good idea to keep shallow class hierarchies, as in 2-3 levels deep at most, or no inheritance at all.

Why KISS/YAGNI? Because humans are more likely to make incorrect judgement about things they need in the future.

Now, going back to the controllers....
"Roll your own" is Scenario #1, meaning KISS. "Complex Solution from the Asset Store that will require a year to clone it" is Scenario #2.

 

We do a VR game whi

You still don't get it. I'm not talking bout writing features that you might need in the future I talk about writing maintainable code that's easy to extend.

For example through modular sub systems that are agnostic, by using for example a event bus we talked about earlier.

 

That's scenario #2 in my previous comment. "Absolute bare minimum and keep it readable."

 

In my opinion version of controller was made by ownself is better. I like the controller in Valheim too. It's nice and very polished.

When I created my own one I found some tutorials about how to do something like that.

I think that the best and simple way to move character is: https://www.patreon.com/posts/astro-kat-moving-21343562
To make camera you can watch videos in this channel: https://www.youtube.com/c/SharpAccent/playlists
There are many ways to do it. Find what you need.

 

I'd assume someone asking if they should use a character controller asset or not is probably someone who doesn't feel confident to make their own.

In that case I'd say, grab a few from the store and try to get them as close what you want as you can. If you really need customization to get things right from there, either take the time to learn how to do it or get help.
While most asset store examples might be too generic and clunky to be really useful, for anybody who is learning the basics seeing examples of others work can be a big boost to learning. Much easier to start from something than nothing.

Don't waste a second thinking about anything other than, "does this feel the way it needs to feel?" DOesn't matter how you accomplish that one bit.

 

I actually haven't worked in it in awhile due to other priorities but I did start one.

https://forum.unity.com/threads/decided-to-play-around-with-making-a-character-controller.1111906/

 

Yep, and now Unity provides these for free:
https://assetstore.unity.com/packag...sets-third-person-character-controller-196526
https://assetstore.unity.com/packag...sets-first-person-character-controller-196525

Although, these weren't available when this thread started.

 

Didn't I post one on the forums? Probably @Ryiah with their intense searching fu can find it as I had no luck.

 

It’s been in my experience that in pre-made assets there’s a certain level of obfuscation built into them that makes them more difficult to adapt than to write from the ground up.

Also, since I’m in it for the journey and not the destination I really enjoy the process, but that’s just me.

 

(Bringing this thread back to life...)

It seems the consensus is that one should create character controllers and as much assets as possible oneself.

There's just a few problems with that for my own use-case: I'm a decent programmer, have been doing it professionally for most of my life in a multitude of languages and projects. But I have no artistic skill what so ever. I can't model and rig a character in Blender (or anything else) if my life depended on it. So the asset store is great for me in that regards. I can find all kind of characters, models, buildings and whatnot that would take months or even years for me to create.

Then on to the character controller itself. While I can make it, can use different animations for different states, and everything else, it will still take me a lot of time. I am, after all, only a team of one person. And while good animations can easily be bought on the asset store, I don't have the faintest idea on how to blend them together, how to seamlessly go from one animation to another. Not to mention how to integrate inverse kinematics solutions needed to get good grips around weapons, holding shield, and the like. And I definitely can't tweak animations if needed. Again, all this can be learned but it will take valuable time when I could be working on the important parts of my game (story, interactions, dialogue, etc.).

So enter the pre-made character controllers on the asset store. Sure, some might need time to learn how to use, but will it take as much time as making my own? Especially if I find one that does basically all I want already.

There's also the middle ground, like taking something basic and simple (for example the free Unity-made third-person starter asset character controller) and expanding on it for the other actions needed, like melee, ranged weapons, spells, and such. But then I come back to getting all the animations, states and IK working which is still a bit of a hassle for me.

And how the inventory is handled, how the fighting is handled, what stats- or skill-system, or indeed what character controller I use to make it all come together doesn't really matter. All I want is to get the world and the story I have in my mind into the game. The tools to do that, are they really that important?

And with all that in mind, should I still make my own character controller? Should I expand some simple existing controller? Or use a complete one like Invector or Opsive?

 

I wouldn't consider it unless you are fine with the quality out of the box. Like you would ship a game with the invector controller - unaltered - and be good with it.

 

Consider this: I was playing Horizon: Forbidden West the other day. This is a flagship, system seller blockbuster game made by top developers with a huge budget. Despite this, every time a character hands the player a quest reward the camera focuses on their heads and shoulders so that the object changing hands is off-screen. In the vast majority of cases the character doesn't say what they're giving you, either.

They're picking where to put their effort and where it's not worth it. Every shipped game does it. If they can use tricks like the one I described above then we absolutely should, too.

The blunt truth in this situation, which also applies to small teams, is that something's gotta give.

Off-the-shelf engines and assets and better tools in general certainly allow solo devs and small teams today to aim far, far higher than in the past. However, I still strongly recommend that the thing that gives is scope, rather than control. As a solo dev, are you really able to aim for a game with a scope where players are going to care about detailed animation blending, accurate IK, the difference between a tweaked and un-tweaked animation? The challenge of operating at such scope isn't getting the functionality built in the first place, it's getting everything integrated in a way that supports you with the huge amount of work that represents your world and your story, and then actually doing all of that work. I'd be very careful about where I outsource my control over that to 3rd parties, partly because it can increase risk, and partly because in some areas it's quite difficult to estimate how much effort it will save. (Prototyping your content pipeline is a good way to address some of that, and is a great idea even if you're building everything yourself.)

If your world and your story are what matters, and you're a solo dev, then I'd strongly suggest figuring out the absolute bare minimum of functionality you need support those things, and stick to buying / implementing that. It's usually a lot less than people think (example), and will still usually take a lot more work than estimated.

In short, rather than thinking "how can I most easily get a high quality animated character controller with lots of animations and IK", I'd instead be thinking "how can I make my game with simple animations, and maybe such that I can add an extra layer of animation later?" Because the work isn't just in making some piece of functionality to begin with, it's in integrating it with all of your game's content.

 

You know, that reminds me.

Detroit: Become Human. Cinematic experience. But.

The character controller can get stuck in furniture.

During timed sequence.

 

I agree with this post. I am also a solo dev (just a hobbyist though) and I definitely feel this post.

One thing that sort of helps me temper my expectations a little - next time you play an 'indie' game all the way through, take the time to watch the credits.

With a few exceptions you're going to see not one, not two, but dozens of people involved in making most games. Even the real small indie teams are going to be 5-6 people. An artist, a music guy, etc.

Making everything on your own is daunting so you have to pick where it's going to make the most impact to use assets vs doing it yourself, and you're likely going to have to abandon some ideas and reduce the scope along the way ..

 

For sure!

On top of your tip there, I also suggest identifying the games you're comparing yourself against, and then going and looking at their credits. Big games often have thousands of people involved. And sure, many of those people do things other than making the game itself, and many of them work across many games, but all of that stuff still has to be done, and all of the relevant skill still needs to be available.

On a AAA game the player character is often a full time job for a team of people. A solo or small dev crew has less resource available than that for their entire game.

Have fair expectations of yourselves.

 

How comfortable are you with the idea that a complete solution may take an approach that doesn't fit well with the way you want your character to behave?

 

Well that kind of depends...

I got RPG Builder through a Humble Bundle a couple of years ago, and that's is too complete and doesn't fit with me personally at all. So I'll not go that way.

I got the Opsive controller with the spring sale going on now, and that's not too bad, it feels quite good but have other aspects that might put it out of the list.

I also got Game Creator 2, and for a "complete" solution it actually feels quite okay. Especially with all its add-on that add basically adds all the things I need. Yes it might not be a perfect fit, but It's not impossible to go around that.

As for simpler solutions, I really like the feel of the Unity third person starter controller. It will require a lot more work to get everything I need out of it (adding melee and unarmed fighting for example), and doesn't have any kind of stats, skills, abilities or item system with it or integrations, which means I either have to code them myself or use something like the Infinity PBR Game Modules asset which have all of that.

And of course the way that @angrypenguin recommended, write it all myself even if it's not very polished. I can do this, I have the programming and software development skills to do it (I have been programming, as a hobby and professionally, for over 30 years now ), but I would rather focus on the more "game" aspects of the game, like the story and worldbuilding.

To be honest, it just feels like there's too many options available, and I'm just stuck deciding the direction I should go and what set of tools I should use. I really should pick one option and stick with it, no matter where it might lead.

And I'm sorry for rambling on a little, but it's kind of nice to get all these thoughts out of my head and get some opinions and thoughts of others more experienced in this field (which I am pretty new at).

Oh, and I kind of forgot to answer your question:

As I said in the beginning it depends. Mostly on how "complete" asset, framework or controller I am using. I would feel less comfortable with a more complete solution, like Opsive and (I guess) Invector. And more comfortable with modifying and tweaking something like the Unity third-person controller and the Infinity PBR game modules.

 

That sounds like a perfect reason to just pick some stuff and get on with it. We can blather on here philosophising about what's "best" 'til the cows come home, but if you're doing this for fun and the bit you're passionate about is the world and story, I'd take the straightest path to get to doing those things. Passion projects only work while you're passionate, after all. ;-)

A few of those don't belong on a character controller. Which brings me to a good reason to have a go with other peoples' stuff: it's a fast way to get exposed to solutions for things and learn from them.

Whatever you try first doesn't have to be your forever solution. If it doesn't work, change it.

 

I'd go with the unity standard and add your own stuff from there.

The "universal" controllers that come with swimming, fighting, inventory, interaction, etc... all are going to do such in a way that will be 1,000% more complicated than you probably need because they are built for broad applicability.

Something that they have spread across 10 systems with code that will take you weeks to figure out so that you can either debug it or extend it is something you can probably write your own simple system that satisfies exactly your needs and nothing more in a couple days.

I don't think the 3rd party stuff is a waste because it can be used for examples. Like if one has a switch for directional movement during combat for example, and you don't want to figure out how to just do that little nugget of behavior, you can borrow from them.

The big time cost that I see is never authoring code or content, but debugging and extending it down the line. That's where others people code or overly modularized "do-everything" systems fall apart.

Such has been my experience with that sort of thing anyway. I also don't think its bad to spend a couple weeks experimenting proper pipeline if its something you'll work on for a year or more. That seems pretty normal.

 

My personal preference is to always use a physics-based controller,. Doesn't have to be active ragdoll and all that, just a simple capsule collider will do. I always want the player to be able to push things around and also get pushed back (in proportion to it's size and weight). Anything using Unity's CharacterController component, on the other hand, is treated like some immovable static geometry.

Lets say I want to make a giant shadow-of-the-colossus boss (I actually did this once). I have a CharacterController on my player. I can't really use a CharacterController for my boss because that would mean the boss just has a giant capsule collider and that player needs to be able to walk between the bosses legs, climb up it's arms, and all that. Maybe I could do ragdoll-style colliders for more precise collision, but I can't control it with character collider either. Maybe rigidbodies? When the player hits a kinematic rigidbody, it seems like the player just pops- magically appears at some location where the collision is resolve. If I used dynamic rigidbodies, one slight touch of my tiny, little player character sent the boss flying across the sky. Neither of these worked at all.

Anyway, lots of asset store character systems are base on the Unity CharacterController component, but I find this problematic when you start to try to build interactions between the player and other moving objects.

 

Hey, check out this character controller example with manual physics calculation!
https://github.com/aleksandrpp/CompetitiveController

 

In that case I'd add the Kinematic Character Controller to your list of assets to check out. It went free a while back when the author was hired by Unity. It's intended to be a base for creating your character controller.

https://assetstore.unity.com/packages/tools/physics/kinematic-character-controller-99131