ok i have this problem: i understood its a good thing to try to avoid making all your objects/variables/etc public but while building my game it seems its becoming very tedious

sometimes the way around it its pasing the parameters and its often elegant but too many times it makes things just more heavy (for me at least)

what if i have to read the mouse click while checking if i have a menu/tooltip/mouseover open (inside my menu class) and then checking if my mouse position correspond at a game location or a interface (inside my mouse class) and then checking if the mouse position in game correspond to an interacting object(so i have to check map class and object item) ?

seems to me like keeping everything not public just make this simple if check a quest while im thinking "ok screw this i make everything public and gg"

is there a way around it?

Making variables private may not seem worthit at first, but it does if you want better error checking. You can use setters and getters to track whether or not a variable is being modified the wrong way.

At the end of the day it's YOUR code - write it how you wish! Correct OOP implementation is essential when you're gonna be working as a team. In all other situations, if you REALLY want to just make it easy (?) for yourself, that's entirely down to you.

Personally I think using getters/setters looks cleaner but again, that's just an opinion. It's the same as writing a book - everyone uses the same language, but writing styles are completely different. Arguably some are cleaner than others but hey.. :P Alternatively, write a function that returns a bool detailing whether those things are true? I'd just give each object in your game a function called ProcessInput that accesses a globally accessible mouse position (why not a singleton for your mouse class? There's only ever one mouse!) that you can access in each of your game object's functions.

If what I'm saying is completely irrelevant, ignore me. :P Gl mate

At the end of the day it's YOUR code - write it how you wish! Correct OOP implementation is essential when you're gonna be working as a team. In all other situations, if you REALLY want to just make it easy (?) for yourself, that's entirely down to you.

Personally I think using getters/setters looks cleaner but again, that's just an opinion. It's the same as writing a book - everyone uses the same language, but writing styles are completely different. Arguably some are cleaner than others but hey.. Alternatively, write a function that returns a bool detailing whether those things are true? I'd just give each object in your game a function called ProcessInput that accesses a globally accessible mouse position (why not a singleton for your mouse class? There's only ever one mouse!) that you can access in each of your game object's functions.

If what I'm saying is completely irrelevant, ignore me. Gl mate

no i was already trying to do as you say, its just that i was a bit depressed cause its going slow and the more i progress the more i have to manipulate large number of things and the less they are accessible to me

right now with this menus its pretty much simple as idea i just want to write a sort of "properties" of my item (and later i add options for the player to do some stuff)

it took like 2 min to write the code for the windows and 2 hours to unlock the properties or pass them, and check if this is accessible, and check if i have other windows open, and pass past actions, and check with interface, and pass map variable and so on :/

If too many places in your code want access to some things, you should not make it public, but think about changing the design to decrease that number to the minimum. You should not intermingle input and processing of data in such a way that you "have to read the mouse click while checking if i have a menu/tooltip/mouseover open", as you can easily read input and then distribute the data where its needed.

Btw., getters and setters are not much better that making everything public. Its better to try following the "tell, dont ask" principle and only get/set if there is no other way around it. That means instead of inspecting the private parts of an object, then deciding outside the object, then changing it, you just call a method on it to let the object do what you want from it.

yes, good advice, ty

but as an example how to handle the most common part of a game?

i understand that in some case like input and interface witha good design you can solve many issues... but what about the core of your game?

items are called really so often, at least in the player interaction, drawing part, game logic, and eventually enemy ai

from my beginner point of view it seems equally bad design making a class "tree" and then implement in that class "enemySeesTree" "enemyAttackTree" "pahtingAvoidTree" "playerClickTree" "playerShotTree" and other 200 like this...

Well, it would belong to the enemy/player and not the tree to decide what it does then. And if a class gets too big you can find a way to split it up.

You also maybe dont need a special tree class, but could use a single one for all kinds of scenery.

from my beginner point of view it seems equally bad design making a class "tree" and then implement in that class "enemySeesTree" "enemyAttackTree" "pahtingAvoidTree" "playerClickTree" "playerShotTree" and other 200 like this...

Yes, but you don't do that. You could have an Object class (or whatever) that has a bounding box which defines its geometry and position, and then your AI code could - for instance - check if the enemy can see the tree, by using the enemy's position and raycasting a visibility ray to the tree taking into account possible obstacles of the environment, so that the enemy can't see through walls, or through fog, etc... Then the AI could decide to e.g. move towards the tree, or attack it if it is close enough, etc.. think in terms of abstractions and responsibilities, it's not a perfect solution but it makes it much easier to reason about complex systems like game logic and generalizing different types of game objects by pinpointing their similarities and their differences.

the problem your having with OO is sort of why component systems came in to existence - instead of having private variables with getters and setters you can have a set of "components" which all have their own data and systems to handle them..

ie if you wanted a tree you might make a game object (that lets you have a vector of components possibly) and attach a "render" component which has info about the mesh (or image/texture if 2d), if you wanted the tree to have collision you might attach a "collider" component, if you want to make the tree have anything you make a component for that thing you want it to have.. then you change the variables of those components within systems that you make to handle them - ie RenderSystem handles the render component of every game object - a single system can use and act on any amount of components you want

then rather than having so many game object types you really rely on one type that just lets you add and remove components - if you want some type of new behavior available you can make a new component type and add a handling case to either one of your existing systems or make a new system for handling it

ie - if you want objects to be able to have health, mana, attack, defense you could make a component for each set of data and make a "CombatSystem" which handles these components

by the way "components" in general are just structs of data so there are no getters and setters - I have seen classes too but usually these classes still have the main component variables as public.. you can do it however you want - maybe you want all components to have a function to clear their contents or something - thats fine

I have done a lot of OO games and I really prefer the composition style much more - just my experience though.. kind of a pain to get started with it but once you have it working its really easy to add new stuff/behavior to the game objects