Hi,
I'm usually organizing my objects so that in the primary class, there are no media objects at all.
This started when I had issues serializing a player object because it contained picture objects, in LOVE2D.
Since then I'm strictly dividing "raw data" and everything else (textfields, images, sounds, ...), resulting in a "Character" class and a "CharacterScreen" class for example.
While going with this approach I see myself getting more and more lost in bad code. Where do I save whose turn it is to hit? In the "Character" class? The information whose turn it is is not essential to the player's data, so no. Put in in the "CharacterScreen" class? I guess not, because this should only contain media, not data that's essential to the game.
So what now, do I create a "Fight" class, which stores the turn? (That's what i actually did). I also created a "FightScreen" class of course. This strict kind of thinking has got out of hand by now, and I'm not able to debug my current application, because attributes/funtions from one "logical" object is spread over several classes.
A fight in my game starts from a button element on the screen, transitions into the fight object, reads the players stats, computes some shit, and end up in some sprites which check something each frame. I'm not even sure anymore what happens where.
Am I going into a completely wrong direction with my approach? Or is it maybe the nature of scripting languages, that you can/should just put everyting into one object, while more traditional language like Java would fit better for me?
Captain Obvious is welcome
Comments
It seems programming in layers is ok, but it's only useful if you store all the logic in the middle layer (between data and presentation).
Is this even possible in Gideros? Most of my logic/action usually happens in Eventlisteners of display objects...
And then each class for most of UI, like popup class, scrollview class, etc
And then game logic classes, like super class Enemy and subclasses EnemyFish, EnemyChicken, etc
And in my case Enemy classes would include both visual and logical things.
But i guess you could also do it your way.
In that case most probably you would have Enemy super class which inherits from EventDispatcher and subclasses like EnemyChicke which inherits from Enemy class.
And then EnemySkin super class which inherits from Sprite, and then specific subclasses, like EnemyChickenSkin. And those skin classes can be used by Enemy classes, which will be used by GameScene, or again separating GameScene and Game classes, for one to control UI things and other the logic
So you could either have:
1) GameScene control Enemy which controls EnemySkin
or
2) GameScene which controls scene ui and Game class which controls game logic
Likes: Holonist
Can I add an eventlistener to a textfield that always changes the text when the according value changes?
I.e. can the player object signalize to the textfield that it's hp has changed? (when both are NOT in the same object)
The best way is to create a function updatePlayerHP, where you update both hp value and textField.
The worst way is to update it in ENTER_FRAME, set bool as value changed etc and upde
The middle way would be to create your own custom event.
Like if you have Skin class responsible for UI, it could listen to HP_CHANGED event, and player logic class would dispatch it on UI class (or you can find any other common class to dispatch event onto, unfortunately you can't broad cast events that easy)
Likes: Holonist
I treat the sprites as fixed objects - I dread adding or deleting them. I don't like using too many events.
I use switches to make the main game do different things - like self play, reset game, set level, etc.
It seems to work well for the type of games I like - it looks a little more how a classic arcade game works rather than a classic computer game.
Likes: Holonist
https://deluxepixel.com