koobas.hobune.stream
Do you tend to have scripts to mark prefabs
Granted, the title is somewhat bad, but let's say you have a GameObject that represents your player.
The player has a 'Health' script managing its health, a 'PlayerMovement' script handling its movement and an 'Inventory' script, managing its inventory.
Do you also have a 'Player' script on your GameObject representing your player, which gives you easy access to all the other components that a player always has (so you only need a reference to this script to access all the player's other scripts)? Do you maybe even create all the other scripts in the 'Player' script's 'Awake' method via 'AddComponent' instead of dragging them onto the GameObject at edit-time?
Or do you think a component shouldn't describe the GameObject it is attached to at all; it should only add behaviour to it?
you're right, the title isn't the best ;)
this really should be in the forums, but...
unity uses a component model where each component is a separate class. try to keep functionality related to a particular type of object in its own class (script). by all means extend them though - you may have a number weapons or pickups (or both!) which share common variables/functionality - search 'inheritance'.
whether you want to add them all via code or in the unity editor is up to you... for speed of development, you may want to add them in the editor, but there's no right or wrong way.
regarding the na$$anonymous$$g, whether it's a component, method or variable name - ALWAYS use something which describes what it does. if you're struggling with a sensible name, you've probably got bigger issues! try to keep methods limited to one thing too - search 'single responsibility'.
i see. to the point in your last paragraph, yes - the Player script would get references to everything it needed on the Player prefab - that's a common approach. however, accessing everything via this class isn't necessarily the most straightforward. static variables aren't so evil as to totally avoid them, but you could be overcomplicating things...
i don't know enough about the other components on your player or any use case so it's impossible to suggest anything more specific. as you're aware, there's often more than one way to do something ;)
Yes, that there's nearly always more than one way of doing something is indeed right ;) .. However I often try to get some opinions from others to avoid potential difficulties, I hadn't thought of before. And sometimes you even get some inspiration on how to solve other problems, too. So "overcomplicating" is certainly true, however you also learn a lot if you ask more than what would seem helpful at first.. At least my experience. But as you suggested, I also posted the question on the forum and maybe I'll get some more more people into the discussion there.
But thanks a lot for your answer again! I appreciate every form of contribution to my questions...
If you want things to follow (or avoid or in any way react to) the player character in a different way from how they react to other things, you'll have to mark it in some way.
You could tag it "Player", but string comparrisons are hard to debug and slow, so comparing the tag of every gameobject any script collides with or otherwise sees with "Player" might be something you'll want to avoid.
There's some solutions. You could subclass the components on your player object - I$$anonymous$$ have PlayerHealth : Health on your player character - and look for that when you need to react to the player. You'll probably want that anyways, since the player's health script probably needs to send messages to the UI in some way the other health instances doesn't (unless your UI is listening to a specific instance).
You'll also probably have a Game$$anonymous$$anager class or something like that which controlls the general state of your game. If that's the case, that could provide access to the player character for other scripts.
Finally, there's the proposed solution of a Player script. I would use if it does anything else than being a dummy marker. You'll probably end up having some unique player behaviour that's not a part of any general scripts anyways. In that case, using the Player script as you posted is probably the easiest way to do these things.
On the whole spawning scripts vs. adding them on Awake - using the RequireComponent is probably the safest way of ensuring that the correct scripts are in place.
I believe RequireComponent takes an arbitrary length list. So, I'd guess you're limited by the upper size of array, or 2^31-1 components.
Which should be just about enough.
Not prefabs, but logical objects or "entities". Yes, I always have some leading or main component on the root gameObject. Then i either derive from it, or keep it sealed and just add components, which often derive from some base class of mine (like EntityComponent). Usually I will also create my own Update method called by some manager that holds all of my Entities, so it's easier to control or pause the game (without changing the engine timeScale), save the game or do whatever level related tasks that should not affect eg. the controller part (inputs, gui, camera etc). So often when i refer to the object, i don't refer to the GameObject, but this main component. That's how i diffrerentiate between actual game objects (car, mine, rocket) and supporting objects (camera, game manager, texture generator)
Thank you very much Panga$$anonymous$$i!
This seems exactly what I want to do, except you could frame it way better than me. And while I'm reading your explanation I think it is very useful as well. It combines the flexibility of an Entity-Component-System with the advantages of classes being the main entities in "classic" program$$anonymous$$g. And it made me realize that having a main script for every prefab isn't the best way to go... So really thank you very, very much again! I'll just leave the question unanswered for one or two more days, for maybe there's an even better answer (though I honsestly doubt it), but I guess you can see your answer already as the accepted one ;) !
