Advice on server design

Hey guys,

I’m designing the backend for my app and had a couple of ideas that I wanted to talk you guys about.

Everything is going to be related to Java:

So the bare basics of programming would tell you that a class is a blueprint e.g. a Person class would describe a person. Nothing more, right?

Let’s think of a game more specifically RSPS (since we all love those) - The typical Player.java may contain some unrelated Player code such as a reference to a Socket or methods to send the user information.

  • Does this not violate the concept of what a player should be?

Stuff like Apollo and Scapeemulator do this. In fact, what is this Player.java class really suppose to be doing? https://github.com/apollo-rsps/apollo/blob/master/game/src/main/org/apollo/game/model/entity/Player.java

Seems like a lot going on for a class that is supposed to just model a Player.

Now what I think the correct approach would be is to have the player class actually define a player and nothing else e.g.

class Player { String name; String health; String runEnergy; }

Then have some other entity dealing with player updating, network calls etc. In regards to “how would we then send a player messages?” Maybe a map or a repo? Be creative :wink:

Going a little deeper into the core of a rsps, let’s talk about how some people implement networking (example).
When I was using Scapeemulator, I wanted to swap the networking library (that does the job a little better for what I wanted). I couldn’t, netty was everywhere making it impossible to do what I wanted.

What do you guys think about writing lightweight wrappers or strictly private modules? Maybe?

Hopefully, you guys could give a novice like me some advice on how I should be coding :slight_smile:

If you’re going to use a JVM language, why not give Kotlin a try? It has some pretty nice things (e.g.: coroutines, a means to cooperative scheduling) going for it.

At the end of the day, the design doesn’t matter that much - as long as it’s maintainable in the eyes of whoever needs to maintain it. In a managed runtime like the JVM though, you’ll want to be mindful of things like garbage collection and the latency/jitter it introduces.