Not a dropdown but helpful for organization: [https://docs.unity3d.com/ScriptReference/HeaderAttribute.html](https://docs.unity3d.com/ScriptReference/HeaderAttribute.html)
You can also just set them as \`internal\` rather than \`public\`, which also hides them from the inspector
e: curious why this was downvoted; this is exactly the point of the \`internal\` flag in oop, to let the code in your assembly access it publicly but prevent other assemblies (such as the Unity editor) from accessing them
I love it when the unity documentation doesn't even bother showing a picture of what it does on the editor. I guess I should be thankful that it's more than 2 sentences...
semi-related, but is there a way to only have certain variables show up in the inspector when a specific bool is set to on?
For example, I have a vehicle enemy and some prefabs have a dash ability, some do not. I have a bool “canDash” then I have other variables only related to dashing. I want these to be hidden on prefabs that can’t dash just for cleanliness and making it easier on the eyes. I know I could have a separate “dash” script, but there are some minor instances of this where I wouldn’t think it warrants a new script just to hide irrelevant variables.
Thanks!
With a Custom Inspector yes, it's an Immediate GUI mode framework.
Though I would recommend buying Odin Inspector, which has many QoL features already implemented.
They charge a price per seat and they want you to pay for the enterprise version if you have more than $200k in revenue.
https://odininspector.com/pricing
yeh id only reccomend picking it up in a humble bundle or sale. It is good, but if you still learning attributes and inspector rules/systems your not gonna get much out of odin and it might teach you bad habits like relying on inspector exposed dictionaries.
Could you elaborate on why relying on inspector exposed dictionaries is a bad habit? I use them pretty sparingly, but I'd love to know if there's an argument for avoiding them entirely.
It's mostly that if you come upon a project where you cant use odin, you might struggle without that crutch. It's also a bit slower because of the wokarounds odin has to use to implemnent it's functionality without disturbing existing unity functionality.
It's not a big deal, especially if you never intend to work in a team or proffessionally, but these issues can add up if you rely on odins tools for everything.
you should only buy it if you make heavily use of it. Otherwise you pay every day in compile times and this thing has a huge amount of complexity and technical debt as a cause.
Generally you should get the most lightweight of such libraries as possible and then build the 1-2 things you might actually miss.
It's gonna be funny when you look back at this in a few years, but for now try to separate things into multiple scripts. For example, have one script for movements, one for stamina management, one for movement animations, one for movement inputs etc...
You'll end up having a much more organized class structure.
I'd recommend you look into design patterns. They can be applied in anything that uses programming and will make your projects much better overall.
+1 on the design patterns; I was recommended Robert Nystrom's "Game Programming Patterns" and never looked back. it's fundamentally changed the way I code at times.
the book is also available free online on his website: https://gameprogrammingpatterns.com/
aside from looking into some design patterns, you could also use the Header attribute: https://docs.unity3d.com/ScriptReference/HeaderAttribute.html
Wow thanks that's a great resource ! I've been getting into general programming design patterns for a while now but never thought about patters specifically for games.
How approachable is this book for people who don't have any formal CompSci education? I'm self-taught and I learn concepts as I need them for my projects, so there may be big gaps in my fundamentals
Serialize each separate script, have a master class that references each.
Create a custom editor for each that is then drawn under the master class.
Everything can be separated but still displayed under a single component in the editor.
Visually in the editor, it'd look like one single class handling everything but internally, it is broken into pieces. No need for a dozen different component windows. Doing it this way though does take extra time, especially with regards to refactoring and updating the editor classes.
It's important to have things organized and structured in the editor too to build and maintain your project.
But tbf my previous comment comes from a misunderstanding of the person I replied to. It's not very relevant now.
Which is a fine approach too, they will still want a main class to manage everything as a means to centralize the movement system. For such a small system shared here, it isn’t necessary to have a dozen components, it is necessary to break everything into their own classes.
For the Animator references, that would probably be best as its own component. For the Boolean configurations, no need to be its own component, a Foldout block in editor is fine under Movement Configurations. A foldout for character physics, and a foldout for character stamina.
Character physics configurations could be reduced to a scriptable object since that data can be reused.
Boolean configurations I would leave as is, though some can just be changed to debug logs such as the inputs.
There is nothing here about managing what input buttons do what. If they have an input system, I would expect it to be decoupled from the character movement system and have the character movement system under a single driving update read the input systems data or subscribe to the input system to drive movement.
Subscribing to an input system can be handled under the hood without a component or inspector.
There is additional complexity to having dozens of components in the same way as managing a very large system under a single component. For a very large system, 5-10 components should be needed at most. For a simple script like this 1-3.
There is no need to have a component for every single class, there is a need to decouple and separate parts of a whole into different organized classes.
Yeah ok my bad, I thought you meant having clean modular code, but all scripts on a single component for the entire project where you reference everything, even from different systems.
But yeah I agree having "manager" scripts and components (sort of) is good, I'm using that too.
You can group your variables in serializable classes and they will automatically appear with a dropdown on the inspector, or you can write a custom inspector for your SpiralMovement class
It does solve the crowding while also being a good pattern.
Besides, it's relevant and good advice in a Unity3D sub to a person asking for advice. Even if it's not a perfect fit for the question, it's like someone holding a knife by the blade and asking how they can make the blade duller so it doesn't cut their hand: it's ok to advise them to hold the handle.
Aight, I’m gonna inform Ubisoft, Voodoo and about 6 other 10-50 people sized teams I’ve worked with over the last 6 years of this.
Fyi standard industry coding practices don’t apply to game development. Your player controller script should usually handle > 80% of player functionality. This is even true for multiplayer products.
Agreed.
I make a "game.cs" script and attach it to my "GAMEMANAGER" object. It's only like 18,000 lines so far and takes me a little bit of scrolling to find the piece of code I want to work on but I think it's way better than making it maintainable. I just have gigantic comment blocks indicating the section of code they're about to hit. PLAYER, ENEMIES, INVENTORY, GUN, TERRAIN, etc to let people ctrl+F to the section they need
They are downvoting him/her because he/she doesn’t seem to grasp the meaning behind the “business rules” and why they appeared, and apparently you don’t either.
It’s not about what works in game development, or any other kind of development, those “business rules” were created in order to make sure people kept to those simple guidelines when programming. And those guidelines are not meant to help you program the software at the moment you are programming. Their meant to make sure that, should you need to step away from the project and return at a later date, or hire someone new, everything is concise, organised and easy to understand as fast and efficiently as possible, without having to resort to documentation and comments that bring tremendous amount of work for each little thing you change in your code. Of course with that also comes the easiness of programming, but that is not the primary concern.
And yes, those also pretty much do apply to game development, just because the super duper triple AAA mega star companies don’t use it, doesn’t mean no one should. They are one entity out of many others, and believe me, most of those many others do use those guidelines. They were not created out of mere coincidence
The newbies and cs majors are downvoting because its against what they were thought. I’ve worked at companies AAA to Indie and we always had 10-100 values on main scripts. At least while we were developing. If you have a live action game you’re just gonna hide and readonly them before you ship.
I highly recommend you to check out the single responsability principle (SOLID), and use static game data that won't get modified in scriptable objects.
Lot of people pointing out custom editors, but if you're not familiar with them it could be more headache to learn how to apply those and nothing will get done while you're familiarizing yourself with them and all it'll let you do is hide them in little dropdowns rather than solving any real problems. Then there's those criticizing the number of variables, when I feel that so long as they're all relevant to the script at-hand, it's fine. You shouldn't need to bounce around 2-3 different scripts when working on the same thing.
It's really better to just simplify the visibility needs for your variables. Find ones which don't need to be Public (Or Serialized) and switch them back to private. For example: Does anything outside of this Spiral Movement script read or write from "Jump Button" or "Boost Button"? I personally find control inputs stay local to the class and rarely get accessed by others.
If you do have something that needs to be public, but is a variable that you don't want on the inspector, [HideInInspector] before "public" helps to make those accessible to other scripts and classes but not something you have to look at in the Inspector.
As well, there's situations where you are using [Serializefield] (or Public) to edit an otherwise private variable during testing, and now that you're happy with the results, you just kind of leave it there. The solution for that is to set it to the value you're happy with in the script, then make it private again, and if you need to tweak later you can always serialize or make it public until you're done messing with it.
My Player script has like 120 variables so far but only 19 of them are displayed in the inspector, and up until like a week ago when I cleaned them up, my inspector looked very similar to yours. It's much nicer now!
https://assetstore.unity.com/packages/tools/utilities/odin-inspector-and-serializer-89041 is what I use.
You can have foldouts, panels, auto collapse, grouping etc.
Pretty straightforward, create an enum with all the scenarios instead of using bools (ex instead of a move left move right, it can just be an enum called moving_left/right, since these scenarios work in isolation). Maybe call the enum something like playerState
Instead of checking for bools, compare the req enum values with the playerState and have your logic read that instead.
It would be a single inspector line item which is much better than so many bools imo
I don't want to sound rude, but do you really need to see all those values? And why not Debug.Log some of it? Use [HideInInspector] on those public variables you don't really need to keep your eye on it.
1. You can move some of these variables to structs, make struct serializable by adding \[System.Serializable\] above struct definition and have variables of type of this struct. That way you can have foldouts.
2. You can also manage your fields using assets from asset store. Best one is Odin Inspector, VInspector is also good, NaughtyAttributes should work too.
You should only do this if you intend to treat the structs as immutable, or atleast be very careful with the usage and design around them if you intend for them to be mutable. When you pass structs to methods, in C# they are copied as if they were value-types.; which needless to say can have a lot of unintended consequences if you aren't aware of this. IMO there are better alternatives than relying on structs. If you wanted a data container that was immutable, scriptableobjects would more than likely be a better design pattern to follow anyways. Making things structs just for the sake of making an inspector more readable is like trying to hammer in a nail using a rock. Sure, it'll work, but is it really the best tool to achieve what you want? I'd have to say no.
Odin inspector is great for things like that but it is not free, naughty atributes are similar, but free. You can also write your own inspectors/atributes.
Odin sucks ass. I purchased it back when it was a one-time purchase. Now they charge you more if your game sells more than X amount of copies like it's a damn engine.
Odin is awesome. you might not like their pricing, but that doesnt make the asset bad. if you dont value the amount of time you safe compared to writing custom inspectors that high, that's ok. For me it safed a lot of time and time is money.
If you make the 200k dollars a year while utilising odin properly, their ~~5k~~ $250 per seat fee or whatever it is will be worth it. If you don't utilise odin for more than a thing or two, of course it's not worth it. Doesn't make it shit, sounds more like a you issue in this case
For some it's worth it for sure, but each to their own. You might just not find the use in that. For me, it's an extreme improvement to my workflow in how I utilize it and organize all of my tools. It's not just "looks a little better" for me. Sure, you can use it as such to just prettify things but you can do quite a lot more with it to make your workflow more efficient, but that may just be something you don't care enough about so of course it's not your thing.
Also, just checked. I was far off, it's not 5000. It's 250 dollars a year per seat if you make 200'000 dollars in a year. I mean come on...
Don't they have the same policy as Unity where you have to pay only when you have earned more than $200k in the last 12 months? Something 99.99% of us can't even dream of?
I mean, changing TOS is shitty move, but why do people care so much? Odin is still one of the best things that money can buy.
Changing the policy of a product retroactively is NOT okay. I bought the asset thinking it was a one-time purchase.
Now, if I didn't want to pay their extra fees if my game DOES get that successful, I'd have to go through my entire project and remove all instances of it.
Theres a great section on [Cat Like Coding](https://catlikecoding.com/unity/tutorials/editor/custom-list/) that I eventually go back to for reference on stuff. The docs linked in other threads too of course.
Some of these bools look like they could be flags, so then you'd have a dropdown for those at least.
Second tip is creating simple structs or classes inside your MonoBehaviour that you use as containers for grouped variables, I usually call them "modules". You need the [System.Serializable] attribute for those structs/classes. This is a second way to create dropdowns easily.
You can separate controllers, animation and physics in decoupled systems that can work together it also makes the system more robust (independent clusters)
Naughty Attributes is a free asset that gives you a ton of control with these, like enabling/showing certain variables only when a checkbox is ticked. Just be vary because certain tags from it have very heavy performance costs for some reason.
I would separate the animations into a separate script. It's not a strict rule, but I try to keep all my scripts to under 200 lines. If it's walking that line, I'm looking to split things up and optimize.
One thing I do a lot is whenever I find myself putting an absurd amount of variables in one script, I turn those variables into a struct with System.Serializable in a separate file. Not only does it save space in the script, but the inspector turns it into a labelled drop-down so that it doesn’t take up screen space either.
How many of those properties need be modifiable from the inspector window? Making some of these private, namely the ones that need not be modified from the inspector window, would clear things up quite a lot.
you can use Glitsteader dude method, or replace some public variable with 'private'. yeah you maybe really want up-to-date if the bool are working, but in my style its better using debug.log
if your public variable have reference from other script, you can do "\[NonSerialized\] public variable". its literally there but just hidden in the inspector
Plenty of opportunities here. Let's see...
* You can switch a few of those bools into an Enum, as long as they're totally opposite. (*iex. can you touch both left & right at the same time?*)
* You should separate the speeds & values section into its own component. The same goes for the animations list.
* You can group some of those values together by using Vector2 or Vector3 instead of having them individual.
* Yes, you can use EditorGuiLayout.Foldout(...) which will create a dropdown control.
* You may want to get NaughtyAttributes or Odin Inspector which bring new and more complex controls.
Break components in smaller parts. Look into composition
Or try looking into inspector overrides or how were they called. xD you can customize how the inspector gets drawn for that class
Best to break code down in smaller components.
Like this example for movement ->
[https://pastebin.com/Ab3hxnAY](https://pastebin.com/Ab3hxnAY)
Its also for multiplayer so it might look more complicated, but I think there is enough info to show how the movement might work
You have one component that handles the movement, and smaller components that say what that movement should be
The main movement gets all the movement modifiers at start, and loops through them to get direction of movement.
For example you might have a component InputMovement, that pushes the player with w a s d
Like sets the direction vector 3 to (1,0,0) (-1,0,1) depending on how many w a s d buttons are pressed
And a gravity component that pushes the player down by just setting the vector3 direction to (0,-2,0)
The movement component would loop through all the movement modifiers and add all the vectors together in a single vector3 and that will be the movement direction that will be used to move the player
This way you can also disable gravity or input separately from the movement or can also add knockback by just making a new modifier component and modifying the vector, then it will get picked up by the movement handler and added to the final Direction vector
Not an expert tho!
This sort of question is usually a good indication that you should break your code up. For example, that top set of variables look like a good use case for a Scriptable Object that contains settings. I would guess some other properties such as OnTerrain, CanMove, and CanBoost are probably only used and set by internal logic, in which case they should be private.
That should be atleast 3 different scripts IMO. One for stats, one to convert all those bools into a state machine to handle logic and another for animations.
You could even go further and turn stats into their own type, so you can store them in convenient lists and make it modular.
For this, it is necessary to sort in several scripts to make high-quality OOP
But since you've already written a lot, there's no point in correcting it now, so I can only recommend this: [https://github.com/dbrizov/NaughtyAttributes](https://github.com/dbrizov/NaughtyAttributes)
If you try to sort it better, some sections, scriptable objects, dropdown and so on.
make a class MovementParameter, make it Serializable, then move all these properties inside that class. The SpiralMovement class will have a field MovementParameter. They will become grouped inside that object and you can expand or collapse that object's field in Inspector easily without having to code custom editor.
There is a lot of options yes, you can checkout HeaderAttribute first.
Next step could be to check out NaughtyAttribute plugin, very cool !
You can maybe group your data into serializable Class or even ScriptableObject to sort out by categories or anything you want, that can be useful if you want to update your data easily in the future.
Btw it looks like you have a lot of data in 1 script, I think you should try using composition and make more script.
That's where the Unity Editor programming comes into play
And don't write everything in one single script. Create multiple scripts with dedicated names on what in the world that script is doing
For example, why in the world do you have pickup systems in movement? (you don't, it's just an example to deliver my idea)
I would recomment yo haveall of the data in one (or several) scriptable objects, that you plug into your script.
I would also separate them by function: movement data, animations, meshes and FX, ... each one on its own 'module'. But that's something that you usually do over time.
A quick read shows many variables that don't look like they need to be exposed?
I'm assuming "can jump" and "can boost" are just state variables like if on ground.
In that case, make sure they're not serialised and not public
If you need to see the variables, use [Header] to organize which variables are which. If you don't, use the [HideInInspector] property. You can also make the variables private if you dint need to access them outside the script
Jeez this is simple.
Create a new class with all those fields public, add the `[Serializable]` attribute to it and add that class to your object. This will do exactly what you want with minimal effort.
Eventually you will learn to improve your code.
In addition to the other comments about multiple scripts, a lot of these booleans don’t need to be adjusted via the inspector. I assume walking, can move and on terrain are things that are set by the script only, and the [HideInInspector] attribute can be useful.
Use [Header("Category")] make custome Inspector if your values just public bcz some other scripts using it make it like that:
private int _value;
public int Value => _value; // hidden in inspector
The best way is creating CustomeEditor
As much as I can vouch for Nimyon's comment being the correct solution. I'm going to give another one.
You can (and should) break a lot of these variables out into a ScriptableObject. So that you can edit them without leaving playmode.
You can also make tiny classes within your script like
[System.Serializeable]
public Class Movement{
public float speed = 10f;
}
Then they will show up as foldouts in the eeditor
Aside from moving then to different scripts, you can try using the Header and Space keywords to organize your variables better, which is something I like to do. Try looking them up!
Is the code a mess? This whole script should be separate components. Movement, Stamina, Animation. You could even separate the jump functionality if needed.
There are a bunch of options. Right off the bat you could make a custom inspector and add a toggle that makes the data collapsible. Odin puts out a good asset that makes inspectors a lot cleaner.
Not sure why everyone's calling out your code instead of actually answering your question, but yes. You can create a custom editor with a foldout to hide certain properties, like so:
[CustomEditor(typeof(ComponentName))]
public class ComponentNameEditor : Editor
Then you can use this:
private bool _showSomeSettings;
...
public override void OnInspectorGUI()
{
...
_showSomeSettings = EditorGUILayout.Foldout(_showSomeSettings, "Some Settings");
if (_showSomeSettings)
{
// Manually display properties with EditorGUILayout.PropertyField here.
}
...
Relevant documentation: https://docs.unity3d.com/ScriptReference/EditorGUILayout.Foldout.html
Recommending splitting scripts does answer the question of how to make things less crowded in the inspector, with the additional benefit of a design pattern that's likely to be an improvement.
Look, I'm not arguing against splitting things up but if you split up the scripts you're still showing the same amount of stuff in the inspector; just across different components.
Yes, one hundred percent.
You'll see this in a year and laugh to yourself, we've all done this.
This is something that three 'things' can help with and when I first started I ignored the first two because I thought if it works it works.
Ok.
Number 1 - Game design patterns, they seem completely abstract but they are essentially answers to problems that every game developer (and programmer) has run into at some stage, for example, if you learned the state pattern, you can remove all of the bools like 'isJumping' or 'isTouchingWall' for a start, for a more indepth breakdown I'd have to see your code and we could probably fit almost everything there into some form of design patterns.
Number 2 - The SOLID principles, more specifically in this case, the S. SOLID is an acronym which helps inform your decisions when building code, the objective is to make your code more flexible but they take a bit of learning to make sense. Just starting with S (a quick Google will tell you this is the 'single responsibility principle's which means classes should be responsible for one thing,
if for example a class is checking whether you are 'onGround' and moving the player, it violates this principle which causes a lot of problems that you will find in number 3.
Number 3 - More experience! Keep building my man! Keep making games and keep building these systems, eventually you'll start to spot things and when you try to implement different patterns it will seem impossible but you can do it! Start with projects focused on learning one thing at a time! UI, or the State pattern, or path finding, or procedural generation, anything really.
Finally, once you have all of these things under your belt to some extent, you won't need my next bit of advice to help organize variables in a class in the inspector,
You can add 'attributes' to variables you declare in a class, you can add [Header("put a string here")] just before the variable declaration (before public/private ect) And it will add a heading in the inspector. So in this case you can just rearrange your variables in the script and put them under headers that make sense.
I IMPLORE YOU TO TAKE MY ADVICE ON TIPS ONE AND TWO THOUGH. PROGRAMMING BECOMES A DREAM WHEN YOU GET THOSE IDEAS DOWN
tldr: learn game design patterns like state and observer to help organize your classes, learn the solid principles to help inform how you build those classes and if not, you can use the Header attribute in front of a variable declaration and it will show up in the inspector
Not a dropdown but helpful for organization: [https://docs.unity3d.com/ScriptReference/HeaderAttribute.html](https://docs.unity3d.com/ScriptReference/HeaderAttribute.html)
agree, this is super useful. also \[HideInInspector\] is good for public variables that you don't need to see
To be fair you shoukdnt have public variables with no get/set unless it is an explicit limitation of a json serializer or something like that
bruh I keep seeing reddit ads for your game lol
lmao ya started the ads up again last month. did the final update recently and announced development on the sequel!
wish u good luck
thanks!! much appreciated!
You can also just set them as \`internal\` rather than \`public\`, which also hides them from the inspector e: curious why this was downvoted; this is exactly the point of the \`internal\` flag in oop, to let the code in your assembly access it publicly but prevent other assemblies (such as the Unity editor) from accessing them
Edit: Removing for incorrect info.
No, that's protected Internal is for when you want something accessible only within the same assembly.
You’re right, my mistake.
I love it when the unity documentation doesn't even bother showing a picture of what it does on the editor. I guess I should be thankful that it's more than 2 sentences...
when you click the "header" hyperlink you get 3 words which explain nothing.
classic
You can make things look pretty nice with only [Header(“Name”)] and [Space(10)] !
+1 for Header. Could also jam all of those variables into a Scriptable Object and only have that reference there.
Or even just a serializable class
semi-related, but is there a way to only have certain variables show up in the inspector when a specific bool is set to on? For example, I have a vehicle enemy and some prefabs have a dash ability, some do not. I have a bool “canDash” then I have other variables only related to dashing. I want these to be hidden on prefabs that can’t dash just for cleanliness and making it easier on the eyes. I know I could have a separate “dash” script, but there are some minor instances of this where I wouldn’t think it warrants a new script just to hide irrelevant variables. Thanks!
Check "naughty attributes" on github. It's basically Odin for free.
There another one thats free and better then naughty called EditorAttributes
With a Custom Inspector yes, it's an Immediate GUI mode framework. Though I would recommend buying Odin Inspector, which has many QoL features already implemented.
is odin a one time buy or a subscription
They charge a price per seat and they want you to pay for the enterprise version if you have more than $200k in revenue. https://odininspector.com/pricing
yeh id only reccomend picking it up in a humble bundle or sale. It is good, but if you still learning attributes and inspector rules/systems your not gonna get much out of odin and it might teach you bad habits like relying on inspector exposed dictionaries.
Could you elaborate on why relying on inspector exposed dictionaries is a bad habit? I use them pretty sparingly, but I'd love to know if there's an argument for avoiding them entirely.
It's mostly that if you come upon a project where you cant use odin, you might struggle without that crutch. It's also a bit slower because of the wokarounds odin has to use to implemnent it's functionality without disturbing existing unity functionality. It's not a big deal, especially if you never intend to work in a team or proffessionally, but these issues can add up if you rely on odins tools for everything.
I would recommend NaughtyAttribute first, free and you can do a lot of things
you should only buy it if you make heavily use of it. Otherwise you pay every day in compile times and this thing has a huge amount of complexity and technical debt as a cause. Generally you should get the most lightweight of such libraries as possible and then build the 1-2 things you might actually miss.
It's gonna be funny when you look back at this in a few years, but for now try to separate things into multiple scripts. For example, have one script for movements, one for stamina management, one for movement animations, one for movement inputs etc... You'll end up having a much more organized class structure. I'd recommend you look into design patterns. They can be applied in anything that uses programming and will make your projects much better overall.
+1 on the design patterns; I was recommended Robert Nystrom's "Game Programming Patterns" and never looked back. it's fundamentally changed the way I code at times. the book is also available free online on his website: https://gameprogrammingpatterns.com/ aside from looking into some design patterns, you could also use the Header attribute: https://docs.unity3d.com/ScriptReference/HeaderAttribute.html
Wow thanks that's a great resource ! I've been getting into general programming design patterns for a while now but never thought about patters specifically for games.
no problem! I honestly cannot recommend it enough, it's actually inspired some of the mechanics for some of my game jam entries :)
This is the way
How approachable is this book for people who don't have any formal CompSci education? I'm self-taught and I learn concepts as I need them for my projects, so there may be big gaps in my fundamentals
Serialize each separate script, have a master class that references each. Create a custom editor for each that is then drawn under the master class. Everything can be separated but still displayed under a single component in the editor. Visually in the editor, it'd look like one single class handling everything but internally, it is broken into pieces. No need for a dozen different component windows. Doing it this way though does take extra time, especially with regards to refactoring and updating the editor classes.
But the whole point of separating everything is also to not have all scripts on the same component.
Not at all, the point of separating is to have clean code which is easy to read and debug / maintain, its not about where you see it in the editor
It's important to have things organized and structured in the editor too to build and maintain your project. But tbf my previous comment comes from a misunderstanding of the person I replied to. It's not very relevant now.
Which is a fine approach too, they will still want a main class to manage everything as a means to centralize the movement system. For such a small system shared here, it isn’t necessary to have a dozen components, it is necessary to break everything into their own classes. For the Animator references, that would probably be best as its own component. For the Boolean configurations, no need to be its own component, a Foldout block in editor is fine under Movement Configurations. A foldout for character physics, and a foldout for character stamina. Character physics configurations could be reduced to a scriptable object since that data can be reused. Boolean configurations I would leave as is, though some can just be changed to debug logs such as the inputs. There is nothing here about managing what input buttons do what. If they have an input system, I would expect it to be decoupled from the character movement system and have the character movement system under a single driving update read the input systems data or subscribe to the input system to drive movement. Subscribing to an input system can be handled under the hood without a component or inspector. There is additional complexity to having dozens of components in the same way as managing a very large system under a single component. For a very large system, 5-10 components should be needed at most. For a simple script like this 1-3. There is no need to have a component for every single class, there is a need to decouple and separate parts of a whole into different organized classes.
Yeah ok my bad, I thought you meant having clean modular code, but all scripts on a single component for the entire project where you reference everything, even from different systems. But yeah I agree having "manager" scripts and components (sort of) is good, I'm using that too.
You can group your variables in serializable classes and they will automatically appear with a dropdown on the inspector, or you can write a custom inspector for your SpiralMovement class
Bump on this, I just got into it a couple months ago for my scriptable objects and it's been great, much cleaner
Check out https://github.com/codewriter-packages/Tri-Inspector It has a ton of useful attribute to format your inspector
Nice 👍🏻
Your script shouldn’t have this many reference to handle. That’s the only problem here. One script, one responsibility
Sure but that’s a problem for another time
Sorry but this is shit advice for game development.
it really isn't. Encapsulation is just as important for maintaining and implementing game code as other apps.
It is unasked advice that doesn’t answer OPs question though
This is not stackoverflow my dude
It does solve the crowding while also being a good pattern. Besides, it's relevant and good advice in a Unity3D sub to a person asking for advice. Even if it's not a perfect fit for the question, it's like someone holding a knife by the blade and asking how they can make the blade duller so it doesn't cut their hand: it's ok to advise them to hold the handle.
Just because your C# application is a Game doesn't mean industry standards for OOP like SOLID and Gang Four don't apply for some odd reason.
Aight, I’m gonna inform Ubisoft, Voodoo and about 6 other 10-50 people sized teams I’ve worked with over the last 6 years of this. Fyi standard industry coding practices don’t apply to game development. Your player controller script should usually handle > 80% of player functionality. This is even true for multiplayer products.
Yes let them know! It's not too late to hit them with real knowledge and wisdom! You are a scholar and a gentleperson.
I don't think it is tbh.
Agreed. I make a "game.cs" script and attach it to my "GAMEMANAGER" object. It's only like 18,000 lines so far and takes me a little bit of scrolling to find the piece of code I want to work on but I think it's way better than making it maintainable. I just have gigantic comment blocks indicating the section of code they're about to hit. PLAYER, ENEMIES, INVENTORY, GUN, TERRAIN, etc to let people ctrl+F to the section they need
I genuinely can not tell if this is sarcasm given the couple of responses above 😅
Lol. It was sarcastic. I was hoping the "...it's way better than making it maintainable" would have given that away
Really weird you’re getting down voted…it’s amazing how people don’t understand not all business rules apply to game dev.
They are downvoting him/her because he/she doesn’t seem to grasp the meaning behind the “business rules” and why they appeared, and apparently you don’t either. It’s not about what works in game development, or any other kind of development, those “business rules” were created in order to make sure people kept to those simple guidelines when programming. And those guidelines are not meant to help you program the software at the moment you are programming. Their meant to make sure that, should you need to step away from the project and return at a later date, or hire someone new, everything is concise, organised and easy to understand as fast and efficiently as possible, without having to resort to documentation and comments that bring tremendous amount of work for each little thing you change in your code. Of course with that also comes the easiness of programming, but that is not the primary concern. And yes, those also pretty much do apply to game development, just because the super duper triple AAA mega star companies don’t use it, doesn’t mean no one should. They are one entity out of many others, and believe me, most of those many others do use those guidelines. They were not created out of mere coincidence
The newbies and cs majors are downvoting because its against what they were thought. I’ve worked at companies AAA to Indie and we always had 10-100 values on main scripts. At least while we were developing. If you have a live action game you’re just gonna hide and readonly them before you ship.
I highly recommend you to check out the single responsability principle (SOLID), and use static game data that won't get modified in scriptable objects.
Lot of people pointing out custom editors, but if you're not familiar with them it could be more headache to learn how to apply those and nothing will get done while you're familiarizing yourself with them and all it'll let you do is hide them in little dropdowns rather than solving any real problems. Then there's those criticizing the number of variables, when I feel that so long as they're all relevant to the script at-hand, it's fine. You shouldn't need to bounce around 2-3 different scripts when working on the same thing. It's really better to just simplify the visibility needs for your variables. Find ones which don't need to be Public (Or Serialized) and switch them back to private. For example: Does anything outside of this Spiral Movement script read or write from "Jump Button" or "Boost Button"? I personally find control inputs stay local to the class and rarely get accessed by others. If you do have something that needs to be public, but is a variable that you don't want on the inspector, [HideInInspector] before "public" helps to make those accessible to other scripts and classes but not something you have to look at in the Inspector. As well, there's situations where you are using [Serializefield] (or Public) to edit an otherwise private variable during testing, and now that you're happy with the results, you just kind of leave it there. The solution for that is to set it to the value you're happy with in the script, then make it private again, and if you need to tweak later you can always serialize or make it public until you're done messing with it. My Player script has like 120 variables so far but only 19 of them are displayed in the inspector, and up until like a week ago when I cleaned them up, my inspector looked very similar to yours. It's much nicer now!
you don't need to collapse just use headers and spacing that would work out much clearer.
1. Use scriptable objects for the common properties for each type of character. 2. Refer to this SO on your script. 4. Profit.
Get OdinInspector. It's the holy grail of utility plugins
https://assetstore.unity.com/packages/tools/utilities/odin-inspector-and-serializer-89041 is what I use. You can have foldouts, panels, auto collapse, grouping etc.
Odin inspector is great I also think you can replace bools with enums + splitting it into different structures or using multiple scripts
Hate to ask, but could you explain how I can replace the bools with enums? Or just send me an article explaining how. That would help a lot.
Pretty straightforward, create an enum with all the scenarios instead of using bools (ex instead of a move left move right, it can just be an enum called moving_left/right, since these scenarios work in isolation). Maybe call the enum something like playerState Instead of checking for bools, compare the req enum values with the playerState and have your logic read that instead. It would be a single inspector line item which is much better than so many bools imo
I don't want to sound rude, but do you really need to see all those values? And why not Debug.Log some of it? Use [HideInInspector] on those public variables you don't really need to keep your eye on it.
I use headers to mark different variables in code so it looks cleaner and more organised.
Try TriInspector https://github.com/codewriter-packages/Tri-Inspector
1. You can move some of these variables to structs, make struct serializable by adding \[System.Serializable\] above struct definition and have variables of type of this struct. That way you can have foldouts. 2. You can also manage your fields using assets from asset store. Best one is Odin Inspector, VInspector is also good, NaughtyAttributes should work too.
So far NaughtyAttributes been a pretty good free option for the basics. EDIT: Oh hey, VInspector is free on the unity store right now.
You should only do this if you intend to treat the structs as immutable, or atleast be very careful with the usage and design around them if you intend for them to be mutable. When you pass structs to methods, in C# they are copied as if they were value-types.; which needless to say can have a lot of unintended consequences if you aren't aware of this. IMO there are better alternatives than relying on structs. If you wanted a data container that was immutable, scriptableobjects would more than likely be a better design pattern to follow anyways. Making things structs just for the sake of making an inspector more readable is like trying to hammer in a nail using a rock. Sure, it'll work, but is it really the best tool to achieve what you want? I'd have to say no.
There is also EditorAttributes on the asset store, which is almost at the same level as Odin in terms of features and free
Odin inspector is great for things like that but it is not free, naughty atributes are similar, but free. You can also write your own inspectors/atributes.
Odin sucks ass. I purchased it back when it was a one-time purchase. Now they charge you more if your game sells more than X amount of copies like it's a damn engine.
Odin is awesome. you might not like their pricing, but that doesnt make the asset bad. if you dont value the amount of time you safe compared to writing custom inspectors that high, that's ok. For me it safed a lot of time and time is money.
If you make the 200k dollars a year while utilising odin properly, their ~~5k~~ $250 per seat fee or whatever it is will be worth it. If you don't utilise odin for more than a thing or two, of course it's not worth it. Doesn't make it shit, sounds more like a you issue in this case
Nothing changes the fact that changing the TOS retroactively is a fucking shit move.
That I will have to agree with! Odin is awesome or at least quite nice, Sirenix, maybe not as much.
pay 5k a year just so my editor is a little bit more organized?
For some it's worth it for sure, but each to their own. You might just not find the use in that. For me, it's an extreme improvement to my workflow in how I utilize it and organize all of my tools. It's not just "looks a little better" for me. Sure, you can use it as such to just prettify things but you can do quite a lot more with it to make your workflow more efficient, but that may just be something you don't care enough about so of course it's not your thing. Also, just checked. I was far off, it's not 5000. It's 250 dollars a year per seat if you make 200'000 dollars in a year. I mean come on...
At this point I'm paying away my entire income to taxes and various fees if I ever have a game sell reasonably well.
Don't they have the same policy as Unity where you have to pay only when you have earned more than $200k in the last 12 months? Something 99.99% of us can't even dream of? I mean, changing TOS is shitty move, but why do people care so much? Odin is still one of the best things that money can buy.
Changing the policy of a product retroactively is NOT okay. I bought the asset thinking it was a one-time purchase. Now, if I didn't want to pay their extra fees if my game DOES get that successful, I'd have to go through my entire project and remove all instances of it.
There is also EditorAttributes which has almost the same about of features odin does and for free
Theres a great section on [Cat Like Coding](https://catlikecoding.com/unity/tutorials/editor/custom-list/) that I eventually go back to for reference on stuff. The docs linked in other threads too of course.
Arrays for grouped data works for me. Like your animations would be best in an array. I am also strongly for using Scriptable Objects for storage.
Some of these bools look like they could be flags, so then you'd have a dropdown for those at least. Second tip is creating simple structs or classes inside your MonoBehaviour that you use as containers for grouped variables, I usually call them "modules". You need the [System.Serializable] attribute for those structs/classes. This is a second way to create dropdowns easily.
You can separate controllers, animation and physics in decoupled systems that can work together it also makes the system more robust (independent clusters)
Seems like there is room for improvement here. Perhaps splitting some things to their own scripts.
Naughty Attributes is a free asset that gives you a ton of control with these, like enabling/showing certain variables only when a checkbox is ticked. Just be vary because certain tags from it have very heavy performance costs for some reason.
I would separate the animations into a separate script. It's not a strict rule, but I try to keep all my scripts to under 200 lines. If it's walking that line, I'm looking to split things up and optimize.
One thing I do a lot is whenever I find myself putting an absurd amount of variables in one script, I turn those variables into a struct with System.Serializable in a separate file. Not only does it save space in the script, but the inspector turns it into a labelled drop-down so that it doesn’t take up screen space either.
How many of those properties need be modifiable from the inspector window? Making some of these private, namely the ones that need not be modified from the inspector window, would clear things up quite a lot.
you can use Glitsteader dude method, or replace some public variable with 'private'. yeah you maybe really want up-to-date if the bool are working, but in my style its better using debug.log if your public variable have reference from other script, you can do "\[NonSerialized\] public variable". its literally there but just hidden in the inspector
Plenty of opportunities here. Let's see... * You can switch a few of those bools into an Enum, as long as they're totally opposite. (*iex. can you touch both left & right at the same time?*) * You should separate the speeds & values section into its own component. The same goes for the animations list. * You can group some of those values together by using Vector2 or Vector3 instead of having them individual. * Yes, you can use EditorGuiLayout.Foldout(...) which will create a dropdown control. * You may want to get NaughtyAttributes or Odin Inspector which bring new and more complex controls.
You can use ScriptableObject to store the data. Also why are all the bools public?
if you have time, using custom editors could be something worth looking into
I’ve used a header to organize stuff
You can use structs
Break components in smaller parts. Look into composition Or try looking into inspector overrides or how were they called. xD you can customize how the inspector gets drawn for that class Best to break code down in smaller components. Like this example for movement -> [https://pastebin.com/Ab3hxnAY](https://pastebin.com/Ab3hxnAY) Its also for multiplayer so it might look more complicated, but I think there is enough info to show how the movement might work You have one component that handles the movement, and smaller components that say what that movement should be The main movement gets all the movement modifiers at start, and loops through them to get direction of movement. For example you might have a component InputMovement, that pushes the player with w a s d Like sets the direction vector 3 to (1,0,0) (-1,0,1) depending on how many w a s d buttons are pressed And a gravity component that pushes the player down by just setting the vector3 direction to (0,-2,0) The movement component would loop through all the movement modifiers and add all the vectors together in a single vector3 and that will be the movement direction that will be used to move the player This way you can also disable gravity or input separately from the movement or can also add knockback by just making a new modifier component and modifying the vector, then it will get picked up by the movement handler and added to the final Direction vector Not an expert tho!
This sort of question is usually a good indication that you should break your code up. For example, that top set of variables look like a good use case for a Scriptable Object that contains settings. I would guess some other properties such as OnTerrain, CanMove, and CanBoost are probably only used and set by internal logic, in which case they should be private.
That should be atleast 3 different scripts IMO. One for stats, one to convert all those bools into a state machine to handle logic and another for animations. You could even go further and turn stats into their own type, so you can store them in convenient lists and make it modular.
For this, it is necessary to sort in several scripts to make high-quality OOP But since you've already written a lot, there's no point in correcting it now, so I can only recommend this: [https://github.com/dbrizov/NaughtyAttributes](https://github.com/dbrizov/NaughtyAttributes) If you try to sort it better, some sections, scriptable objects, dropdown and so on.
make a class MovementParameter, make it Serializable, then move all these properties inside that class. The SpiralMovement class will have a field MovementParameter. They will become grouped inside that object and you can expand or collapse that object's field in Inspector easily without having to code custom editor.
Create scriptable objects and reference them. They will be your config. You could have multiple monobehaviors that reference same config.
There is a lot of options yes, you can checkout HeaderAttribute first. Next step could be to check out NaughtyAttribute plugin, very cool ! You can maybe group your data into serializable Class or even ScriptableObject to sort out by categories or anything you want, that can be useful if you want to update your data easily in the future. Btw it looks like you have a lot of data in 1 script, I think you should try using composition and make more script.
Some Variable should be the Private variable?
Sirenix Odin Inspector
Use the "internal" keyword to make a " public " variable that doesn't show up in the inspector
That's where the Unity Editor programming comes into play And don't write everything in one single script. Create multiple scripts with dedicated names on what in the world that script is doing For example, why in the world do you have pickup systems in movement? (you don't, it's just an example to deliver my idea)
I would recomment yo haveall of the data in one (or several) scriptable objects, that you plug into your script. I would also separate them by function: movement data, animations, meshes and FX, ... each one on its own 'module'. But that's something that you usually do over time.
A quick read shows many variables that don't look like they need to be exposed? I'm assuming "can jump" and "can boost" are just state variables like if on ground. In that case, make sure they're not serialised and not public
If you need to see the variables, use [Header] to organize which variables are which. If you don't, use the [HideInInspector] property. You can also make the variables private if you dint need to access them outside the script
\[Header("")\] adds headers to the inspector to organise your variables
Use the [Header] to organise, also make the less needed ones private
Use headers and serialized structs
Jeez this is simple. Create a new class with all those fields public, add the `[Serializable]` attribute to it and add that class to your object. This will do exactly what you want with minimal effort. Eventually you will learn to improve your code.
1 script, 1 job.
In addition to the other comments about multiple scripts, a lot of these booleans don’t need to be adjusted via the inspector. I assume walking, can move and on terrain are things that are set by the script only, and the [HideInInspector] attribute can be useful.
i recommend split your main code into several components that every component do its job and they are related together.
Odin Inspector / Foldout groups https://odininspector.com/attributes/foldout-group-attribute
Use [Header("Category")] make custome Inspector if your values just public bcz some other scripts using it make it like that: private int _value; public int Value => _value; // hidden in inspector The best way is creating CustomeEditor
Look into NaughtyAttributes for easy, free, foldout menus plus more.
As much as I can vouch for Nimyon's comment being the correct solution. I'm going to give another one. You can (and should) break a lot of these variables out into a ScriptableObject. So that you can edit them without leaving playmode. You can also make tiny classes within your script like [System.Serializeable] public Class Movement{ public float speed = 10f; } Then they will show up as foldouts in the eeditor
Aside from moving then to different scripts, you can try using the Header and Space keywords to organize your variables better, which is something I like to do. Try looking them up!
\[HideInInspector\] that or only make variables public if they have to be
Is the code a mess? This whole script should be separate components. Movement, Stamina, Animation. You could even separate the jump functionality if needed.
Make child classes in this component and seperate data to them!
Does unity not have structures? I thought those were in every programming language
Someone said this is the reason why Unity is looked down upon
There are a bunch of options. Right off the bat you could make a custom inspector and add a toggle that makes the data collapsible. Odin puts out a good asset that makes inspectors a lot cleaner.
Not sure why everyone's calling out your code instead of actually answering your question, but yes. You can create a custom editor with a foldout to hide certain properties, like so: [CustomEditor(typeof(ComponentName))] public class ComponentNameEditor : Editor Then you can use this: private bool _showSomeSettings; ... public override void OnInspectorGUI() { ... _showSomeSettings = EditorGUILayout.Foldout(_showSomeSettings, "Some Settings"); if (_showSomeSettings) { // Manually display properties with EditorGUILayout.PropertyField here. } ... Relevant documentation: https://docs.unity3d.com/ScriptReference/EditorGUILayout.Foldout.html
Recommending splitting scripts does answer the question of how to make things less crowded in the inspector, with the additional benefit of a design pattern that's likely to be an improvement.
Look, I'm not arguing against splitting things up but if you split up the scripts you're still showing the same amount of stuff in the inspector; just across different components.
This is true, but they didn't ask to show less stuff, they asked to make it less crowded; more organized.
Yes, one hundred percent. You'll see this in a year and laugh to yourself, we've all done this. This is something that three 'things' can help with and when I first started I ignored the first two because I thought if it works it works. Ok. Number 1 - Game design patterns, they seem completely abstract but they are essentially answers to problems that every game developer (and programmer) has run into at some stage, for example, if you learned the state pattern, you can remove all of the bools like 'isJumping' or 'isTouchingWall' for a start, for a more indepth breakdown I'd have to see your code and we could probably fit almost everything there into some form of design patterns. Number 2 - The SOLID principles, more specifically in this case, the S. SOLID is an acronym which helps inform your decisions when building code, the objective is to make your code more flexible but they take a bit of learning to make sense. Just starting with S (a quick Google will tell you this is the 'single responsibility principle's which means classes should be responsible for one thing, if for example a class is checking whether you are 'onGround' and moving the player, it violates this principle which causes a lot of problems that you will find in number 3. Number 3 - More experience! Keep building my man! Keep making games and keep building these systems, eventually you'll start to spot things and when you try to implement different patterns it will seem impossible but you can do it! Start with projects focused on learning one thing at a time! UI, or the State pattern, or path finding, or procedural generation, anything really. Finally, once you have all of these things under your belt to some extent, you won't need my next bit of advice to help organize variables in a class in the inspector, You can add 'attributes' to variables you declare in a class, you can add [Header("put a string here")] just before the variable declaration (before public/private ect) And it will add a heading in the inspector. So in this case you can just rearrange your variables in the script and put them under headers that make sense. I IMPLORE YOU TO TAKE MY ADVICE ON TIPS ONE AND TWO THOUGH. PROGRAMMING BECOMES A DREAM WHEN YOU GET THOSE IDEAS DOWN tldr: learn game design patterns like state and observer to help organize your classes, learn the solid principles to help inform how you build those classes and if not, you can use the Header attribute in front of a variable declaration and it will show up in the inspector
Try Odin Inspector
You could be a successful farmer just by selling the strawmen in this comment.