Advertisement Jump to content
Sign in to follow this  
dworm

the public syndrome

This topic is 1826 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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?

Share this post


Link to post
Share on other sites
Advertisement

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.

Share this post


Link to post
Share on other sites

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 

Share this post


Link to post
Share on other sites

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.. tongue.png 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. tongue.png 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 :/

Share this post


Link to post
Share on other sites

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...

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

So one thing that gave me trouble was that I always confused "You should only make what needs to be public public" with "You shouldn't have very many public things". 

 

You may actually *Need* quite a few public properties/methods etc.

 

Imagine writing a library... the library is meant to perform a particular task (or set of tasks) configuring and telling the lib what to do may require a large amount of public properties/methods... but anything that is not required to configure or utilize the lib should not be public. Take C# windows.forms for example, the are hundreds of public properties/objects... but every single one of them performs some kind of data transfer from the assembly using the lib to the assembly implementing the lib... you have to know that there are even more objects/methods/members that the lib doesn't expose... if it had exposed all the things the end user doesn't need to know about it would be that much more difficult to utilize.

 

You also have an internal scope to work with as well. Internal scope is pretty much equivalent to public when working within the same assembly. 

 

Just remember, scope and limiting scope is just a tool meant to help you organize your code, you won't see much (if any) performance difference between an object properly scoped and one that is entirely public, but you will find it easier to figure out how it's supposed to work/ how it is working. 

 

The reason the rule is in place is because you want to make code as independent as possible.. Objects should only be concerned with their own particular responsibilities. 

 

 

 

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) ?

 

 

 The menu/tooltip shouldn't have to be responsible of keeping track of the mouse... it is only concerned with Displaying and allowing the user to interact with a menu... it shouldn't even care what happens when a particular option is selected. as long as it reports that an option has been selected it's done it's job.. something else can take care of what to do about it. A good way to acomplish this is to use events, Object O spawns a menu, it sends it a list of options to display and a list of delegates that corrospond to each option, the menu displays the options and if one is selected calls the appropriate delegate. 

 

 

 

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...

 

 Remember, every distinct action/logic HAS to be defined Somewhere... you can only generalize to a point and somewhere along the line actual implementation has to occur. In this case I'd probably have events: onSighted(object sightedBy), onClick(), onCollision(object source) pathing would likely not be an event, but instead a method that return a pathing weight... getPathWeight(object pathingObject)

Edited by Paragon123

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!