I have just downloaded Unity 5, and played around a bit with some of the features. Now, I feel like doing a small game. But, I am not sure how to design a game based on the design principles Unity uses. Since I know a bit about object-oriented programming, I thought Unity might use this in the game design. But, after looking at it, I realize it’s the opposite. Seems to me, it is like you are adding a specific, specialized action/event to the component when a certain event was activated, so the game object will react to that event according to the script I write.
Like, I have the Left Arrow, Right Arrow, and Down Arrow keys on the keyboard set for “Move left”, “Move right”, and “Crouch”, respectively. I could write a script for each particular action, and then add them together into a game object. So, I would write a “Move left” script, “Move right” script, and “Crouch” script, separately, and add all of them one by one to a Cube game object. That would make me trigger the script actions based on what buttons I pressed.
Is this how a game is built in Unity? Is this where the components are added one by one based on functionality, until it has many components that correspond to different events (input events, triggers, etc.)? Is this what people would call, “component-based programming”? Or, I need to start from creating a “small minimally-viable” game engine within Unity using scripts and go from there?
Component-based architecture does not conflict with the concepts of object-oriented programming. In fact, the most important aspect of OOP is encapsulation. Creating classes that implement a focused bit of functionality for use as a component is an excellent example of encapsulation. And you can still use inheritance, but you tend to avoid defining game entities as part of an inheritance hierarchy, since that’s not too flexible.
You would not likely create completely separate components for moving left versus right, unless you had game entities that needed one but not the other (not likely).
There are no right or wrong ways of implementing a game. Your goal should be to create maintainable code that’s easy to debug, satisfies the requirements of your game, and performs well. Anything beyond that is a subjective style issue.
I’d download some of the sample games on the asset store for examples of typical approaches.
Go for small, component based architecture. I wouldn’t reccomend splitting left and right. I would reccomend splitting input and movement. I typically make these abstract classes.
Class just started, and all hell broke loose today.
Thanks for everyone’s response, especially the small, component based architecture. I think I got what a game object should have. I will go look at what E__ffervescent linked me.__