@JoeyMorani - Create an object to hold all of that data - it could store a rectangle, the texture, and the collision type (enum or similar). When you check collisions you can skip all bounding boxes with a certain collision type (NoCollision) for example
I accidentally left my phone unplugged all night so the battery was at 6% when I got to work and plugged it in. An hour and a half later it was at 5% :(
I've never really used the PC to charge fully (only supplemental while listening to music, etc.) - do these things not charge as well when plugged into a PC vs a wall outlet?
So for example, you can rotate the sprites that represent Arms to look like hes swinging his arms as he walks, or you can have separate pictures of the whole character for each frame of the walk animation
The most common approch to GameState algorithm is to have some game states and program can freely choose to run any one of them, this means there is a GameDirector which has a pointer to current running state, and in each update cycle it'll call 'currentState->run()`.
in this approch GameDirector...
after reading all those comments to refresh my mind why I did get the downvotes,
I can see there are many things wrong with my approach.
but still I think I need more advise about what things are usable and what are not.
I mean do you completely disagree with that architecture?
well, again, prefer to pass a reference in the constructor
rather than calling getInstance everywhere
@Gajet you're still young, and a student
which is probably why some of these stylistic things don't make immediate sense
it mostly comes from experience working with large projects where you're working with lots of other people
classes that getInstance everywhere wind up being tightly coupled, and it gets to the point where if you need to change one thing you wind up having to modify 200 other classes that are coupled too tightly to that one thing
besides I can't really imagine anyone going to change anything about that director class which doesn't lead to complete change in application structure...
@Jimmy I was just saying same class could manage states too
In computer programming, cohesion is a measure of how strongly-related each piece of functionality expressed by the source code of a software module is. Methods of measuring cohesion vary from qualitative measures classifying the source text being analyzed using a rubric with a hermeneutics approach to quantitative measures which examine textual characteristics of the source code to arrive at a numerical cohesion score. Cohesion is an ordinal type of measurement and is usually expressed as “high cohesion” or “low cohesion” when being discussed. Modules with high cohesion tend to be prefera...
well, I'll say I've put game state (or workflow state, since I mainly do business apps) management into the "main" class of many projects before. But there's definitely stuff you can change
and it's better not to have state management code mixed with other stuff
for example, if you need transitiosn between states, or a state-stack so you can have a pause-menu on top of your game screen