MapleScala

[Shmoconut]

Personally I think it is a good thing to split up the servers and the clients, because in this way it would be impossible for the client to affect the server.
So it really just is a piece of fault tolerance.

Though this is also how the Akka documentation advised on how to use the TCP system so I sticked with it.

So basically the server Actors will try to restart when something occurred they could not recover from while the client Actors will simply be killed to prevent anything from escalating.

I wanted to write a MapleStory server in Erlang but never got around to it, so I'm looking forward to seeing your progress because it is naturally going to be architecturally similar. Making each client an actor seems like the right thing to do. With that said, here are some considerations:

Don't really get what you mean by client affecting the server, but the main benefit I see in making each client an actor is to have the power to persist client state even if a server fails. You can look into making each client supervise its server actor, so if a server fails then the character data can be persisted and the client session can be automatically migrated to a functioning server. Akka has some cool health checking functionality, but I don't know if it's possible to have a many-to-one supervision scheme, or if it's even necessary - maybe there's a simpler way. I'm not overly familiar with Akka.

Also I looked through your code a little bit (I like it when things are on Github) and it seems like you never keep characters in memory? Every time a user gets its character it re-constructs one from the database. If I'm not wrong, then perhaps you should look into changing that.
It seems like you have two actors per player (one as the Client, one unnamed representing the raw tcp connection between player and server), but I guess that doesn't really matter.

Like others have said, you really should use pattern matching on Options and similar things instead of for loops though, it's more readable and is considered good practice.

Have you thought about how you are going to implement cross-server messages? Right now I don't think you keep track of all clients in the server, so you should probably think about how you would implement a super megaphone (or buddy/guild chat, etc) because that's probably a design decision that needs to be made early on.
It seems like this is where there is added complexity by making each client its actor.

 

[Minike]

Don't really get what you mean by client affecting the server

Actually, you said exactly what I ment;

but the main benefit I see in making each client an actor is to have the power to persist client state even if a server fails.

Also I looked through your code a little bit (I like it when things are on Github) and it seems like you never keep characters in memory? Every time a user gets its character it re-constructs one from the database. If I'm not wrong, then perhaps you should look into changing that.

Yeah, I havent had any need yet in for persisting the character in the memory, but I will probably story it within the Client after it migrated away from the loginserver

It seems like you have two actors per player (one as the Client, one unnamed representing the raw tcp connection between player and server), but I guess that doesn't really matter.

As far as I am aware I only wrap the Client (which directly is the TCP actor) in a RoundRobinPool, which the documentation suggested for the fault tolerance.

Like others have said, you really should use pattern matching on Options and similar things instead of for loops though, it's more readable and is considered good practice.

I actually use for loops when I have no need for the None case and already checked the None case in previous code. So it is only for unwrapping the value and ensure it could never be None (as alternative to just using .get). Adding a None case would be redundant in my opinion.

Have you thought about how you are going to implement cross-server messages? Right now I don't think you keep track of all clients in the server, so you should probably think about how you would implement a super megaphone (or buddy/guild chat, etc) because that's probably a design decision that needs to be made early on.
It seems like this is where there is added complexity by making each client its actor.

Basically the same story as with the characters, I tend to write code only when I actually need it even though I already thought out the process in the first place (it is not like I am writing everything blindly). I will probably store all clients per server instance and have the client message the server, which in turn messages all clients.

The nice thing about this Actor system is that you could make relative large changes to the system as a whole with only minor changes in code.

 

[aaronweiss]

Sure, but you are being extremely condescending and hardly constructive.

Am I being condescending? Sure. I think it's plenty constructive though. I gave him examples of things that could be done better, and I told him specific tools for him to research to write better code in Scala.

The guy said he didn't know how to use fold. Show him how to use fold then. You're right, he won't know how to do fold with pure theory. It takes usage to actually learn it. The thing is you're basically doing the same thing as people going to /f427/ and posting on the release threads that they didn't write their code right.

I don't think it's my job to write tutorials for Scala on this forum. There's plenty of guides that go into detail about how to use higher-order functions. It's a short web search away. If he can't learn how to search the web properly, there's not much I can really do for him.

 

[Snakeday]

aaronweiss: Yes there were some constructive points but overall your comments were rather toxic. For example you have yet failed to mention that not all scala users/advocates actually favor a highly functional style, Scala is a multi-paradigm programming language. Feel free to treat it as such.

retep998: You are making the common mistake of misclassifieing something as premature optimization. If I have a given problem and can choose between two algorithms of which I know that one is faster and both are equally readable I should always choose the faster one. Kevlin Henney talks about this here:

You must be registered to see links

I personally find it's a very good talk on the topic.

That said I'm a huge fan of writing code to get things done and not being afraid to revise the code later when I learn newer things about the language/libraries/frameworks. I'm also excite about a pserver project in scala. Try to go on and do not get distracted by the toxicity.

 

[retep998]

retep998: You are making the common mistake of misclassifieing something as premature optimization. If I have a given problem and can choose between two algorithms of which I know that one is faster and both are equally readable I should always choose the faster one. Kevlin Henney talks about this here:

You must be registered to see links

I personally find it's a very good talk on the topic.

OP was expressing uncertainty regarding the performance of fancy iterator stuff, like filter and foreach, compared to handwritten loops. Since that difference alone is not an algorithmic difference, and I know from personal experience that iterators can be implemented very efficiently (see Rust), I therefore classified it under premature optimization. Now if OP did benchmark the various techniques and get some numbers to demonstrate that iterators are significantly slower than the equivalent handwritten loop, then that optimization would no longer be premature.

EDIT: Whoops. Didn't realize this was a different person. Fixed.

 

[Hilia]

You were expressing uncertainty regarding the performance of fancy iterator stuff, like filter and foreach, compared to handwritten loops. Since that difference alone is not an algorithmic difference, and I know from personal experience that iterators can be implemented very efficiently (see Rust), I therefore classified it under premature optimization. Now if you did benchmark the various techniques and get some numbers to demonstrate that iterators are significantly slower than the equivalent handwritten loop, then that optimization would no longer be premature.

I have actually tested this in C# some time ago ( i can't talk about scala) where i looped though almost all types in the assembly at start up and in that case LINQ was slower, by 25% now uh.. 25% is that much? , uhm not really since i am talking about mili seconds( i don't have the code any more or the exact time but the impact was so low that i desided to go for LINQ since i found it more readable) and so i agree that it is premature optimizing (atleast in the case of C#)

 

[ALotOfPosts]

You were expressing uncertainty regarding the performance of fancy iterator stuff, like filter and foreach, compared to handwritten loops. Since that difference alone is not an algorithmic difference, and I know from personal experience that iterators can be implemented very efficiently (see Rust), I therefore classified it under premature optimization. Now if you did benchmark the various techniques and get some numbers to demonstrate that iterators are significantly slower than the equivalent handwritten loop, then that optimization would no longer be premature.

You quoted the wrong person? Nothing in his post is about filter and foreach

 

[retep998]

You quoted the wrong person? Nothing in his post is about filter and foreach

Erk, you're right. Fixed my post.

 

[oxysoft]

ITT: op who doesn't know anything about scala starts writing a game server meanwhile other ppl argue over stuff no one cares abt

 

[aaronweiss]

aaronweiss: Yes there were some constructive points but overall your comments were rather toxic. For example you have yet failed to mention that not all scala users/advocates actually favor a highly functional style, Scala is a multi-paradigm programming language. Feel free to treat it as such.

It's a multi-paradigm language because it more-or-less has to be to have Java interop. There are few Scala programmers who don't use functional idioms, and for the most part, those people are basically just writing Java. There's little point to using a different language if you're not going to take advantage of the features it gives you.

 

[oxysoft]

Scala is a multi-paradigm programming language. Feel free to treat it as such.

this is the dumbest thing I've read all week, good job

retep998: You are making the common mistake of misclassifieing something as premature optimization. If I have a given problem and can choose between two algorithms of which I know that one is faster and both are equally readable I should always choose the faster one

except when the difference is Ducking insignificant and/or it hinders readability significantly

[...] comments were rather toxic [...]
[...] by the toxicity [...]

it's like you came straight from tumblr, you Ducking waste of oxygen