Zone-level extension vs Room-level extension

Post here your questions about SFS2X. Here we discuss all server-side matters. For client API questions see the dedicated forums.

Moderators: Lapo, Bax

valr2
Posts: 6
Joined: 29 Jun 2022, 09:23

Zone-level extension vs Room-level extension

Postby valr2 » 11 Nov 2022, 07:57

Hello!

I'm working on a Poker Casino game, and I've originally architected my code around having 2 separate Java extensions.
1. A "CasinoExtension" attached at zone level (I have a single Zone representing the Poker game) which handles more generic things like connect, login, disconnect, friends status updates, management of HTTP connections to my backend API etc.
2. A "PokerExtension" attached at room level for each Room that represents an actual Poker table where poker is played. This one handles all the poker-specifics i.e. attaches request handlers for all poker operations (buy in, bet, fold, sit out etc.). But crucially I'm not actually storing any data in the PokerExtension class itself, it only registers handlers, nothing else.

The actual custom logic classes that I need (e.g. PokerTable, PokerPlayer) are attached as properties to native SFS objects (like Room or User). So when I need to do something on a particular table, I would pull that PokerTable instance from that Room via getProperty() and then do all the work there. Similarly with pulling a PokerPlayer from a User object.

Now I'm starting to think that I've overengineered this a bit and I could go with having a single PokerExtension attached at the Zone level to handle both generics and poker specifics, for the following reasons:
- the Zone itself represents the whole Poker game. If we'll ever have a Blackjack game, that will have its own separate Zone and will run a BlackjackExtension there, and I can find some other way to share common code between Poker and Blackjack extensions (like a common library, inheritance, git submodule etc.).
- I'm a bit worried that having say 1000 Rooms, each running its own Room-level PokerExtension puts unnecessary pressure on the JVM, as it has to instantiate all these extension objects that are all identical and do the same thing and don't store anything particular to this or that Room.
- the current two extensions where supposed to be loosly coupled if nor fully decoupled, but in fact they are coupled, because some of the generic things do need to reference a bit of poker-specifics. I've even ran into a problem with that (which we've discussed here in a separate older thread) because the two extensions are loaded in separate JVM Class Loaders, so if they need to use a common class, it won't appear to be the same class as viewed from different Class Loaders. So the solution to that was to place the .jar that contains both extensions in the __lib__ folder, to be loaded in the same, top-level class loader. But that seems a bit like a "hack".
- one advantage of having Room-level extensions is that you can update that Room-level extension more frequently on the fly, without restarting the server or disturbing the code that runs at Zone level. But we don't really care about that and having them both loaded through the __lib__ folder renders that useless anyway, I think.
- I'm trying to favor simplicity wherever possible and "dancing around" two extensions seems to need a rational explanation, which I can't find anymore.

So essentially my questions is this: Am I missing something here? Is there any better reason for having two extensions (zone-level and room-level) instead of a single one (zone-level) that does all the work from a single, centralized place? Is it somehow "good practice" to keep things separated between zone-level and room-level, instead of centralized at zone-level or it doesn't really matter?

Thank you!
Valentin
User avatar
Lapo
Site Admin
Posts: 23008
Joined: 21 Mar 2005, 09:50
Location: Italy

Re: Zone-level extension vs Room-level extension

Postby Lapo » 11 Nov 2022, 09:12

Hi,
both approaches are valid. The super-optimized way is to do everything in the Zone level extension to avoid extra overhead at the cost of a bit more coding.

These days servers are usually powerful enough that you don't need to care about this kind of optimizations, unless you're running in an environment that is tight on resources (e.g. a small vps) in which case you may still favor the Zone-only approach.
Other than that the Room+Zone extension approach is usually more convenient, from a development perspective.

Another factor in deciding between the two is the "coupling factor" that you have mentioned. If you have lots of interactions between Room Extensions and Zone Extensions you can evaluate two options:

1- deploy everything under extensions/__lib__/ to avoid class loading headaches (sacrificing Zone Ext hot redeploys)
2- move all code to the Zone Extension

These are the best practices so, essentially, you're already evaluating different best practices :)
The final choice depends on the complexity of your code and maybe evaluating how important it is to squeeze every bit of performance out of the JVM, which imho should not be top priority unless you're super tight on resources.

Hope it helps
Lapo
--
gotoAndPlay()
...addicted to flash games
Baiumka
Posts: 9
Joined: 04 Dec 2018, 09:57

Re: Zone-level extension vs Room-level extension

Postby Baiumka » 29 Nov 2022, 13:33

1- deploy everything under extensions/__lib__/ to avoid class loading headaches (sacrificing Zone Ext hot redeploys)

In that case init method in ZoneExt run twice. Is it normal?
User avatar
Lapo
Site Admin
Posts: 23008
Joined: 21 Mar 2005, 09:50
Location: Italy

Re: Zone-level extension vs Room-level extension

Postby Lapo » 01 Dec 2022, 07:51

No.
Why would it run twice? Initialization is invoked once regardless of the deploy position.

Cheers
Lapo

--

gotoAndPlay()

...addicted to flash games

Return to “SFS2X Questions”

Who is online

Users browsing this forum: No registered users and 70 guests