I have a question i’d like to discuss, just to make sure and figure out what is possible.
I’ll give my example : a very simple soccer game.
For the moment, I have some simple code running on the main player and a friend of him. But in the end, i’ll need reusable (adaptable) code for the other team players.
I’m also realising how complex my code is (well not that much, but it doesnt feel very comfortable) since it is full of “if”, and makes a massive use of Object properties. It’s also getting confusing when objects have to give each other some reaction (i’m in this state, now you have to wait for me to be in this other state, so 'ill change my state and tell you to change yours at the same time, etc…)
I dont need to use half of these properties (since other objects dont have to care about them), AND i’d like to be able to code it in an Object oriented manner, for relevance and elegance of the code itself.
So this is my question :
-how am i supposed to use Class for an object : if i make a Class Object for my Player, what should be the instanciation of this class? Should there be inheritance of the class?? How does this work?
-Rather than a Class, should I consider the logic bricks as a Class, and just separate every single part of the behaviour (movement, action, reaction) as smaller python parts with simple functions?
I’d really prefer the Class way, but maybe am i wrong.
You are not supposed to do that at all.
A game object is already an object.
You can replace this object with custom class via “object replacement”. This would allow you use classes as much as you can. Finally I do not see a real benefit in this. Others might see it different.
Do not worry about classes. This is “just” implementation.
I think it is much more worth to separate logic into multiple independent parts (similar to your examples).
It does not even matter if you implement them in Python or in logic bricks or a mix of both. It is only important that it does what it should do.
BTW: Describing what it should do (and what not) is fairly hard ;).
What you need to define are the interfaces between this logic elements.
Your problem description sounds like a large, undocumented and confusing interface between player and npc. The npc should not care if the player exist or not. The NPC should not care the states of the player.
The NPC should care what he can do with the player (interaction).
E.g. sending messages, reading and writing properties.
Such things should be reduced at a minimum to keep this interface as small as possible.
Actually i’ve already designed the game as objects behaving like they should do, considering other objects only when needed (the ball doesnt really care who it belongs to, but will follow it if it at a moment it has to).
But it misses some separation between each part of the code for an object (i’m figuring it out now that it gets a little bit more complex than “a guy running to take a ball”). That’s why i wondered how to deal with that.
I’ll separate each part as much as i can, thanks once again
You could inherit a custom class to a game object. I don’t know if you can write directly to a game object, but you might be able to (i assume it won’t be read only)
