separate player logic in to it's own class

[MrPancakes]

hey all, I have a question about separation of logic I hope someone can answer.

simple scenario:

I have a scene called "level1" and another one "level2", for obvious reasons I wouldn't want to write all the player logic in both of these ( jumping, animation, audio etc)

What is the suggested way in Phaser 3 to pass in the player class in to let's say Level1? importing it? using the scene manager?

Help is appreciated, thanks

[AdamRyanGameDev]

Have you considered functions that sit (globally) outside of preload/create/update?

Or have i misunderstood?

[MrPancakes]

17 minutes ago, AdamRyanGameDev said:

Have you considered functions that sit (globally) outside of preload/create/update?

Or have i misunderstood?

I have considered many things and they would work I guess, but I wanted to know the standard Phaser 3 way to separate logic 
I assumed it would be something in the lines with:

I have a class that extends some Phaser modules and / or that I would dependency inject some 

The class would now have it's own update/create/preload methods where I can put logic in

I would import / add the player in to the scene and then they would run in the main update/create/preload.

[PsichiX]

standard procedure (framework agnostic):

create class for Player logic that have methods for subscription and unsubscription into game events and methods for changing player state. in every scene you create player instance, attach sprite to it and subscribe to events, and on exit from scene unsubscribe from events and dispose its resources.

[MrPancakes]

24 minutes ago, PsichiX said:

standard procedure (framework agnostic):

create class for Player logic that have methods for subscription and unsubscription into game events and methods for changing player state. in every scene you create player instance, attach sprite to it and subscribe to events, and on exit from scene unsubscribe from events and dispose its resources.

oh ok, I just assumed the engine would have helper methods for this more in the plug and play direction. Thanks for the heads up.

[jorbascrumps]

I tend to create a new class that extends `Sprite` and attach whatever extra functionality I need.

[PsichiX]

@jorbascrumps generally good practice is to separate logic from rendering, so it is better to treat player logic as controler for its sprite, not making it extension of sprite.

Let me just ask you: you do that because of simplicity or why exactly?

[raaaahman]

On 25/03/2018 at 11:24 AM, Kaffesumpen said:

I have a scene called "level1" and another one "level2", for obvious reasons I wouldn't want to write all the player logic in both of these ( jumping, animation, audio etc)

PsichiX answer makes total sense to me, but I wanted to come back on your declaration: why do you separate different levels into different scenes? In most games, levels share so many similarities that you would probably have to duplicate lots of code doing these. It would be a lot easier to load different levels' datas into the same scene.

Maybe your game is not so classical and kind of demands it, but I'm having trouble to find an example where you'd want the player to act exactly the same in a totally different kind of scene...

Quote

oh ok, I just assumed the engine would have helper methods for this more in the plug and play direction. Thanks for the heads up.

I don't believe engines should enforce game logic, firstly because you should be able to make any kind of gameplay without being influenced, but also because it will make your game to heavily coupled with the engine, making your life hard either to port your game to another engine, but either to adapt to the engines future changes.

On 26/03/2018 at 1:13 AM, PsichiX said:

@jorbascrumps generally good practice is to separate logic from rendering, so it is better to treat player logic as controler for its sprite, not making it extension of sprite.

I've not really dived into Phaser 3 for now, but I remember that in Phaser 2, the Sprite class has a Body property when you activated some physics engine. I found it super counter-intuitive, because sprites objects did have more stuffed into them than just their display responsibility... (I believe they did have health and ammunition counters to...)

I don't know how are physics bodies handled now, and I hope it would be more natural to give some 'entities' classes bodies and sprites without any being coupled to the other.

[MrPancakes]

36 minutes ago, raaaahman said:

PsichiX answer makes total sense to me, but I wanted to come back on your declaration: why do you separate different levels into different scenes? In most games, levels share so many similarities that you would probably have to duplicate lots of code doing these. It would be a lot easier to load different levels' datas into the same scene.

 

No, no duplication all logic are in classes and are imported as needed. A scene in my head is a empty canvas where I add stuff, makes sense that all levels have there own scene as they use different tiles, different monsters, different events etc. If you use the same scene and clean it out or remove stuff between levels I guess thats ok to if you like that.
 

Quote

I don't believe engines should enforce game logic, firstly because you should be able to make any kind of gameplay without being influenced, but also because it will make your game to heavily coupled with the engine, making your life hard either to port your game to another engine, but either to adapt to the engines future changes.

That's a very opinionated answer about how game engines should handle logic, more handholding makes faster development in a smaller and stricter box. it also speeds up new developers added to the projected to become more effective. It has it's downsides as well ofc but It's all what the game/team needs and it's neither good or bad.

[PsichiX]

in my opinion (and this is very common practice) scene setup should be done in declarative way, for example by keeping scene descriptor in some JSON file (or any other format if you want) and Scene class just gets this scene descriptor and produce game objects with renderables and their logic bound to them, based on scene descriptor. by that you make only one generic scene class that just builds your scene and manage lifetime of gameobjects respectively to game events. That architecture gives you less duplicated code (because scene game actions are just functions that are called, instead of having boilerplate to manage common functionalities in every scene).
Also worth mentioning: old phaser teaches very bad practice, that you put your player and enemies logic into scene, when gold rule of single responsibility says: your game object/component should do ONLY those things that belongs to it, that changes it's state. For example: common mistake i saw was to place player and enemies logic inside game scene logic, instead of making separate classes for player, enemy and scene and put their logic into their classes and then let their inistances to manage their own state, not allowing to any outside instance modify it's state any other way than my calling their public API. What you do in that case: your player can move around and be killed when touches enemy, so your player class have API methods for initialization (where it subscribe to game events, such as game update, or input handler), killing (when enemy touches player, it calls player kill() method for example). enemy class API has methods for initialization to subscribe to game events and probably update event, where its AI processes the world around. Scene just holds instances of player and enemies and triggers game events, and all of that created at startup from declarative scene setup.

[MrPancakes]

3 hours ago, PsichiX said:

in my opinion (and this is very common practice) scene setup should be done in declarative way, for example by keeping scene descriptor in some JSON file (or any other format if you want) and Scene class just gets this scene descriptor and produce game objects with renderables and their logic bound to them, based on scene descriptor. by that you make only one generic scene class that just builds your scene and manage lifetime of gameobjects respectively to game events. 

Do you load the entire game data at once then so its cached and ready or you still lazy load in items when certain events trigger  ( like switching level ) ?

[PsichiX]

assuming that every scene is an asset, i'm loading only those scenes config that i will use - i'm saing "scenes", because game object templates (called "prefabs") are scenes too, but you can attach them into some already loaded scene node.

Let me give a live example, how i'm doing all of that and how easy it gets to modify declarative scene config:

http://playground.oxygencore.io/#/ry24CjEKM

look at game.json file - this is game scene and there i just declare how scene and it's game objects are set up. Somewhere there you can find PrefabInstance component that just gets already loaded snake prefab (which is just a small scene) and insert it in that node as its child.

[MrPancakes]

18 minutes ago, PsichiX said:

assuming that every scene is an asset, i'm loading only those scenes config that i will use - i'm saing "scenes", because game object templates (called "prefabs") are scenes too, but you can attach them into some already loaded scene node.

Let me give a live example, how i'm doing all of that and how easy it gets to modify declarative scene config:

http://playground.oxygencore.io/#/ry24CjEKM

look at game.json file - this is game scene and there i just declare how scene and it's game objects are set up. Somewhere there you can find PrefabInstance component that just gets already loaded snake prefab (which is just a small scene) and insert it in that node as its child.

Interesting thanks for sharing.

[raaaahman]

8 hours ago, Kaffesumpen said:

No, no duplication all logic are in classes and are imported as needed. A scene in my head is a empty canvas where I add stuff, makes sense that all levels have there own scene as they use different tiles, different monsters, different events etc. If you use the same scene and clean it out or remove stuff between levels I guess thats ok to if you like that.

Oh, I never thought doing it in this direction.

Quote

That's a very opinionated answer about how game engines should handle logic, more handholding makes faster development in a smaller and stricter box. it also speeds up new developers added to the projected to become more effective. It has it's downsides as well ofc but It's all what the game/team needs and it's neither good or bad.

Of course that's opinionated. Each technique has its pros and cons... But since you were asking to separate Game Logic from Display Logic it sounds strange to me that you want to somehow remerge it in the framework after that. I'm not arguing what you should or shouldn't do, of course, and maybe Phaser 3 can do that ...