Hi
I was wondering if there’s a specific pattern to look for, when implementing client-server based games. I’m getting to a point where I’m wondering if my implmentation of client commands could be done in a better way - right now I simply add new command every time I need it to - but I could see that escalating. And I thought perhaps the commands could be grouped somehow and maybe there’s a good pattern for it.
Perhaps all interactions in the game that controls the players ship could be wrapped in some sort of ‘ActionCommand’, whenever I edit the map I’d wrap them in some form of ‘MapCommand’, if I do some squad/clan management from the client, I could wrap/group those into a ‘SquadCommand’…
I google my way to https://www.javaworld.com/article/2077569/core-java/java-tip-68--learn-how-to-implement-the-command-pattern-in-java.html?page=2 and wanted to get some jME community input in this regard - what are your prefered method, pros and cons etc.
Kind regards
My number one goal is re-useability so I don’t have to write it again, so in that sense, similarity encourages implementations and boilerplate encourages extensions of classes.
Rule #1 really for me is that a method should do only one thing, and a class only one job. Factories and generators are useful for creating multiples of the same thing… I think a lot of this comes with experience. When I look at Paul’s code, who has at least a decade on me, I can see his paths are well trodden through his remarks in his code.
Just try to build components and not get stuck in spaghetti hell. It’s a daily struggle; hence I spent a good 60-70% in thought and the rest in practicality.
If you mean a true command pattern where the command also holds the logic… then you can get in trouble in a client-server game because the client and server code must match in lock-step. Also the client will have the code even if it’s not using it… which may not be desirable.
The command pattern can be useful in certain cases where you must do certain things before and after every command and/or you want to be able to replay them, etc… Editors, transactional storage, etc. are all good places for the command pattern.
In the case of a client-server network API, command patterns lose some programming convenience. Rather than just calling account.login(…) you end up creating an object, passing that object to some method… for no real benefit. As a designer/developer, instead of just adding a method to an interface and an impl (as with SpiderMonkey’s basic RMI support), you end up having to create a whole new class.
Also, sometimes it’s nice if the things the client can call on the server are actually defined by the server. Maybe this server has different features or game objects that have different ‘methods/actions’ that can be performed. In that case you will need a completely different setup anyway. (I usually go with something where I pass a command ID or string along with a set of parameters… then the server looks up the command/function to run for that ID.)
…and the method you call with that action ID + parameters would likely be through RMI with an impl+interface.
(These days I so rarely create custom Messages.)
1 Like