|
Scala for MMOs!
Hi,
Almost one year after my first post; I come back again to this subject.
This time this is not an exploratory discussion but it is for a real project in my new job position.
So my company is involved in the creation of a massively multiplayer online game; and we're heavily considering using Scala to build it - notably using the Actor library.
We will use Scala on the server side and need to have some shared code (game logic code) between the client and the server.
So, here are my questions:
A) For the client; I need to integrate a JVM on top of a C++ runtime; considering that it could be used on next gen consoles (xbox 360, ps3, etc..) it needs to be quite fast, memory efficient, realtime and free if possible.
Does one has any recommendation?
B) Could I have any problem using two differents VMs on the client and the server respectively (I know portability is a selling point of the jvm; but I prefer to have feedback fromn real experience).
C) What libraries would you consider for the database, logs, etc..?
D) Does the actor library scales well with the number of nodes?
Would it be stupid to try to create some remote processes on the clients; is there some internals in the library that would suffer from having, say, hundreds of thousands nodes?
If you think of other points; please feel free to mention them.
Stephane.
|
|
Re: Scala for MMOs!
On 1/7/08, Stephane Le Dorze <stephane.ledorze@...> wrote:
Hi,
Almost one year after my first post; I come back again to this subject.
This time this is not an exploratory discussion but it is for a real project in my new job position.
So my company is involved in the creation of a massively multiplayer online game; and we're heavily considering using Scala to build it - notably using the Actor library.
We will use Scala on the server side and need to have some shared code (game logic code) between the client and the server.
So, here are my questions:
A) For the client; I need to integrate a JVM on top of a C++ runtime; considering that it could be used on next gen consoles (xbox 360, ps3, etc..) it needs to be quite fast, memory efficient, realtime and free if possible.
Does one has any recommendation?
B) Could I have any problem using two differents VMs on the client and the server respectively (I know portability is a selling point of the jvm; but I prefer to have feedback fromn real experience).
C) What libraries would you consider for the database, logs, etc..?
D) Does the actor library scales well with the number of nodes?
Would it be stupid to try to create some remote processes on the clients; is there some internals in the library that would suffer from having, say, hundreds of thousands nodes?
If you think of other points; please feel free to mention them.
Stephane.
Quite a task indeed.
Please drop some progress-mails along the way. :)
Cheers,
Viktor
--
_____________________________________
/ \
/lift/ committer (www.liftweb.net)
SGS member (Scala Group Sweden)
SEJUG member (Swedish Java User Group)
\_____________________________________/
|
|
Re: Scala for MMOs!
Stephane,
On Jan 7, 2008, at 2:43 AM, Stephane Le Dorze wrote: Hi,
Almost one year after my first post; I come back again to this subject.
This time this is not an exploratory discussion but it is for a real project in my new job position.
Cool!
So my company is involved in the creation of a massively multiplayer online game; and we're heavily considering using Scala to build it - notably using the Actor library.
We will use Scala on the server side and need to have some shared code (game logic code) between the client and the server.
So, here are my questions:
A) For the client; I need to integrate a JVM on top of a C++ runtime; considering that it could be used on next gen consoles (xbox 360, ps3, etc..) it needs to be quite fast, memory efficient, realtime and free if possible.
Does one has any recommendation?
gcj is one option... compile the byte-code down to native code.
B) Could I have any problem using two differents VMs on the client and the server respectively (I know portability is a selling point of the jvm; but I prefer to have feedback fromn real experience).
Serialization is the biggest one that comes to mind. Although, I'd do client <-> server communications using RabbitMQ.
C) What libraries would you consider for the database, logs, etc..?
See the next answer.
D) Does the actor library scales well with the number of nodes?
Yes, until you reach the maximum size of RAM, and then you're hosed... unless...
I've been doing a fair amount of work in this area recently. The lift team with working with the folks at Terracotta and Philipp Haller to use Terracotta to distribute Actors across JVMs. The side benefit will be that actor state will be persisted. So, in theory (and once we get a demo put together, we're going to test the theory against reality on 50 EC2 instances), you've got a very scalable mesh network of Actors on the server side.
Combine this with AMQP/RabbitMQ support for distributing messages between clients and the Actor pool on the server and you've got a really amazing way to built a highly scalable network application.
I am currently working on a project that will take advantage of this architecture. More on that in a few weeks.
Would it be stupid to try to create some remote processes on the clients; is there some internals in the library that would suffer from having, say, hundreds of thousands nodes?
No. As far as I can tell, the Actor library performance in O(n) where n is the number of messages in the Actor's mail box. This is the same as Erlang's Actors.
Thanks,
David
PS -- I much of the project that I'm working on will be open source and you'll be able to see the actual implementation.
If you think of other points; please feel free to mention them.
Stephane.
|
|
Re: Scala for MMOs!
Hi David! Last Time I heard of gcj it wasn t completly successfull.. In addition I will need to be able to update the client game logic without reshipping a complete exe ou dll for several *good* reasons.. :) So we'll still need a JVM on board.
Nice to have some feedback from your experience; even if our constraints are a bit different; they are similar in a lot of aspects. I am particularly interested in your work with terracota; we need to start quickly but are taking some time to evaluate such possibilities; so it would be nice to have more technical and licence informations + some release dates ((ASAP)) :)
Thanks! Stephane On Jan 7, 2008 5:18 PM, David Pollak < dpp@...> wrote:
Stephane,
On Jan 7, 2008, at 2:43 AM, Stephane Le Dorze wrote: Hi,
Almost one year after my first post; I come back again to this subject.
This time this is not an exploratory discussion but it is for a real project in my new job position.
Cool!
So my company is involved in the creation of a massively multiplayer online game; and we're heavily considering using Scala to build it - notably using the Actor library.
We will use Scala on the server side and need to have some shared code (game logic code) between the client and the server.
So, here are my questions:
A) For the client; I need to integrate a JVM on top of a C++ runtime; considering that it could be used on next gen consoles (xbox 360, ps3, etc..) it needs to be quite fast, memory efficient, realtime and free if possible.
Does one has any recommendation?
gcj is one option... compile the byte-code down to native code.
B) Could I have any problem using two differents VMs on the client and the server respectively (I know portability is a selling point of the jvm; but I prefer to have feedback fromn real experience).
Serialization is the biggest one that comes to mind. Although, I'd do client <-> server communications using RabbitMQ.
C) What libraries would you consider for the database, logs, etc..?
See the next answer.
D) Does the actor library scales well with the number of nodes?
Yes, until you reach the maximum size of RAM, and then you're hosed... unless...
I've been doing a fair amount of work in this area recently. The lift team with working with the folks at Terracotta and Philipp Haller to use Terracotta to distribute Actors across JVMs. The side benefit will be that actor state will be persisted. So, in theory (and once we get a demo put together, we're going to test the theory against reality on 50 EC2 instances), you've got a very scalable mesh network of Actors on the server side.
Combine this with AMQP/RabbitMQ support for distributing messages between clients and the Actor pool on the server and you've got a really amazing way to built a highly scalable network application.
I am currently working on a project that will take advantage of this architecture. More on that in a few weeks.
Would it be stupid to try to create some remote processes on the clients; is there some internals in the library that would suffer from having, say, hundreds of thousands nodes?
No. As far as I can tell, the Actor library performance in O(n) where n is the number of messages in the Actor's mail box. This is the same as Erlang's Actors.
Thanks,
David
PS -- I much of the project that I'm working on will be open source and you'll be able to see the actual implementation.
If you think of other points; please feel free to mention them.
Stephane.
|
|
Re: Scala for MMOs!
Some parts of this message have been removed.
Learn more about Nabble's security policy.
On 1/7/08, Stephane Le Dorze <stephane.ledorze@...> wrote:
Hi David!
Last Time I heard of gcj it wasn t completly successfull..
In addition I will need to be able to update the client game logic without reshipping a complete exe ou dll for several *good* reasons.. :)
So we'll still need a JVM on board.
No worries.
Nice to have some feedback from your experience; even if our constraints are a bit different; they are similar in a lot of aspects.
I am particularly interested in your work with terracota; we need to start quickly but are taking some time to evaluate such possibilities; so it would be nice to have more technical and licence informations + some release dates ((ASAP)) :)
We're working with the excellent folks @ Terracotta and the folks at LAMP right now to get a solution. I'll be meeting with Philipp Haller this week and I'm hoping that we'll have something to demonstrate in the next 10 days.
If you hang out on the lift list, we'll be making announcements there.
Thanks,
David
PS -- Where are you located?
Thanks!
Stephane
On Jan 7, 2008 5:18 PM, David Pollak < dpp@...> wrote:
Stephane,
On Jan 7, 2008, at 2:43 AM, Stephane Le Dorze wrote: Hi,
Almost one year after my first post; I come back again to this subject.
This time this is not an exploratory discussion but it is for a real project in my new job position.
Cool!
So my company is involved in the creation of a massively multiplayer online game; and we're heavily considering using Scala to build it - notably using the Actor library.
We will use Scala on the server side and need to have some shared code (game logic code) between the client and the server.
So, here are my questions:
A) For the client; I need to integrate a JVM on top of a C++ runtime; considering that it could be used on next gen consoles (xbox 360, ps3, etc..) it needs to be quite fast, memory efficient, realtime and free if possible.
Does one has any recommendation?
gcj is one option... compile the byte-code down to native code.
B) Could I have any problem using two differents VMs on the client and the server respectively (I know portability is a selling point of the jvm; but I prefer to have feedback fromn real experience).
Serialization is the biggest one that comes to mind. Although, I'd do client <-> server communications using RabbitMQ.
C) What libraries would you consider for the database, logs, etc..?
See the next answer.
D) Does the actor library scales well with the number of nodes?
Yes, until you reach the maximum size of RAM, and then you're hosed... unless...
I've been doing a fair amount of work in this area recently. The lift team with working with the folks at Terracotta and Philipp Haller to use Terracotta to distribute Actors across JVMs. The side benefit will be that actor state will be persisted. So, in theory (and once we get a demo put together, we're going to test the theory against reality on 50 EC2 instances), you've got a very scalable mesh network of Actors on the server side.
Combine this with AMQP/RabbitMQ support for distributing messages between clients and the Actor pool on the server and you've got a really amazing way to built a highly scalable network application.
I am currently working on a project that will take advantage of this architecture. More on that in a few weeks.
Would it be stupid to try to create some remote processes on the clients; is there some internals in the library that would suffer from having, say, hundreds of thousands nodes?
No. As far as I can tell, the Actor library performance in O(n) where n is the number of messages in the Actor's mail box. This is the same as Erlang's Actors.
Thanks,
David
PS -- I much of the project that I'm working on will be open source and you'll be able to see the actual implementation.
If you think of other points; please feel free to mention them.
Stephane.
-- lift, the secure, simple, powerful web framework http://liftweb.netCollaborative Task Management
http://much4.us
|
|
Re: Scala for MMOs!
Nice to hear! We have a lot of (game) design challenges to adress and need to make progress with our code base in the meantime.
How hard would it be to migrate from our currently developped actor based solution to what you' re expecting to build? Stephane On Jan 7, 2008 10:27 PM, David Pollak < feeder.of.the.bears@...> wrote:
On 1/7/08, Stephane Le Dorze <stephane.ledorze@...> wrote:
Hi David!
Last Time I heard of gcj it wasn t completly successfull..
In addition I will need to be able to update the client game logic without reshipping a complete exe ou dll for several *good* reasons.. :)
So we'll still need a JVM on board.
No worries.
Nice to have some feedback from your experience; even if our constraints are a bit different; they are similar in a lot of aspects.
I am particularly interested in your work with terracota; we need to start quickly but are taking some time to evaluate such possibilities; so it would be nice to have more technical and licence informations + some release dates ((ASAP)) :)
We're working with the excellent folks @ Terracotta and the folks at LAMP right now to get a solution. I'll be meeting with Philipp Haller this week and I'm hoping that we'll have something to demonstrate in the next 10 days.
If you hang out on the lift list, we'll be making announcements there.
Thanks,
David
PS -- Where are you located?
Thanks!
Stephane
On Jan 7, 2008 5:18 PM, David Pollak < dpp@...> wrote:
Stephane,
On Jan 7, 2008, at 2:43 AM, Stephane Le Dorze wrote: Hi,
Almost one year after my first post; I come back again to this subject.
This time this is not an exploratory discussion but it is for a real project in my new job position.
Cool!
So my company is involved in the creation of a massively multiplayer online game; and we're heavily considering using Scala to build it - notably using the Actor library.
We will use Scala on the server side and need to have some shared code (game logic code) between the client and the server.
So, here are my questions:
A) For the client; I need to integrate a JVM on top of a C++ runtime; considering that it could be used on next gen consoles (xbox 360, ps3, etc..) it needs to be quite fast, memory efficient, realtime and free if possible.
Does one has any recommendation?
gcj is one option... compile the byte-code down to native code.
B) Could I have any problem using two differents VMs on the client and the server respectively (I know portability is a selling point of the jvm; but I prefer to have feedback fromn real experience).
Serialization is the biggest one that comes to mind. Although, I'd do client <-> server communications using RabbitMQ.
C) What libraries would you consider for the database, logs, etc..?
See the next answer.
D) Does the actor library scales well with the number of nodes?
Yes, until you reach the maximum size of RAM, and then you're hosed... unless...
I've been doing a fair amount of work in this area recently. The lift team with working with the folks at Terracotta and Philipp Haller to use Terracotta to distribute Actors across JVMs. The side benefit will be that actor state will be persisted. So, in theory (and once we get a demo put together, we're going to test the theory against reality on 50 EC2 instances), you've got a very scalable mesh network of Actors on the server side.
Combine this with AMQP/RabbitMQ support for distributing messages between clients and the Actor pool on the server and you've got a really amazing way to built a highly scalable network application.
I am currently working on a project that will take advantage of this architecture. More on that in a few weeks.
Would it be stupid to try to create some remote processes on the clients; is there some internals in the library that would suffer from having, say, hundreds of thousands nodes?
No. As far as I can tell, the Actor library performance in O(n) where n is the number of messages in the Actor's mail box. This is the same as Erlang's Actors.
Thanks,
David
PS -- I much of the project that I'm working on will be open source and you'll be able to see the actual implementation.
If you think of other points; please feel free to mention them.
Stephane.
--
lift, the secure, simple, powerful web framework http://liftweb.net
Collaborative Task Management
http://much4.us
|
|
Re: Scala for MMOs!
On Jan 8, 2008, at 3:37 AM, Stephane Le Dorze wrote: Nice to hear!
We have a lot of (game) design challenges to adress and need to make progress with our code base in the meantime.
How hard would it be to migrate from our currently developped actor based solution to what you' re expecting to build?
If it works as expected, there will be no code changes at all. All the actors will appear as first class objects in a giant mesh of JVMs managed by Terracotta.
The advantages are: - Code on the developers' machines is identical to code on production - Scalability by adding machines
As with anything, there may be some issues: - Sending messages to Actors in other JVMs is more expensive than calling an Actor in the same JVM and if you want to know where an Actor lives, you'll have to write code that makes the Actor aware of where they are. This also discourages lots of back and forth conversation (like you may have seen in Java objects that became remoted via RMI... a method call per property rather than a "give me all your properties" call.) - Balancing your Actors across JVMs will be necessary so that you don't have 2 or 3 machines out of a cluster of 50 that are doing most of the work
Thanks,
David
Stephane
On Jan 7, 2008 10:27 PM, David Pollak < feeder.of.the.bears@...> wrote:
On 1/7/08, Stephane Le Dorze <stephane.ledorze@...> wrote: Hi David!
Last Time I heard of gcj it wasn t completly successfull..
In addition I will need to be able to update the client game logic without reshipping a complete exe ou dll for several *good* reasons.. :)
So we'll still need a JVM on board.
No worries.
Nice to have some feedback from your experience; even if our constraints are a bit different; they are similar in a lot of aspects.
I am particularly interested in your work with terracota; we need to start quickly but are taking some time to evaluate such possibilities; so it would be nice to have more technical and licence informations + some release dates ((ASAP)) :)
We're working with the excellent folks @ Terracotta and the folks at LAMP right now to get a solution. I'll be meeting with Philipp Haller this week and I'm hoping that we'll have something to demonstrate in the next 10 days.
If you hang out on the lift list, we'll be making announcements there.
Thanks,
David
PS -- Where are you located?
Thanks!
Stephane
On Jan 7, 2008 5:18 PM, David Pollak < dpp@...> wrote: Stephane,
On Jan 7, 2008, at 2:43 AM, Stephane Le Dorze wrote: Hi,
Almost one year after my first post; I come back again to this subject.
This time this is not an exploratory discussion but it is for a real project in my new job position.
Cool!
So my company is involved in the creation of a massively multiplayer online game; and we're heavily considering using Scala to build it - notably using the Actor library.
We will use Scala on the server side and need to have some shared code (game logic code) between the client and the server.
So, here are my questions:
A) For the client; I need to integrate a JVM on top of a C++ runtime; considering that it could be used on next gen consoles (xbox 360, ps3, etc..) it needs to be quite fast, memory efficient, realtime and free if possible.
Does one has any recommendation?
gcj is one option... compile the byte-code down to native code.
B) Could I have any problem using two differents VMs on the client and the server respectively (I know portability is a selling point of the jvm; but I prefer to have feedback fromn real experience).
Serialization is the biggest one that comes to mind. Although, I'd do client <-> server communications using RabbitMQ.
C) What libraries would you consider for the database, logs, etc..?
See the next answer.
D) Does the actor library scales well with the number of nodes?
Yes, until you reach the maximum size of RAM, and then you're hosed... unless...
I've been doing a fair amount of work in this area recently. The lift team with working with the folks at Terracotta and Philipp Haller to use Terracotta to distribute Actors across JVMs. The side benefit will be that actor state will be persisted. So, in theory (and once we get a demo put together, we're going to test the theory against reality on 50 EC2 instances), you've got a very scalable mesh network of Actors on the server side.
Combine this with AMQP/RabbitMQ support for distributing messages between clients and the Actor pool on the server and you've got a really amazing way to built a highly scalable network application.
I am currently working on a project that will take advantage of this architecture. More on that in a few weeks.
Would it be stupid to try to create some remote processes on the clients; is there some internals in the library that would suffer from having, say, hundreds of thousands nodes?
No. As far as I can tell, the Actor library performance in O(n) where n is the number of messages in the Actor's mail box. This is the same as Erlang's Actors.
Thanks,
David
PS -- I much of the project that I'm working on will be open source and you'll be able to see the actual implementation.
If you think of other points; please feel free to mention them.
Stephane.
--
lift, the secure, simple, powerful web framework http://liftweb.net
Collaborative Task Management http://much4.us
|
|
Re: Scala for MMOs!
Simply wonderful! I got a basic beginner question now (Back to reality): When I try to send messages between two actors; it works well BUT when I create two actor services, run both of them on the same machine; and try to send messages between them (using
RemoteActor.select to locate them). I got this error. Error: scala.actors.remote.NetKernel@1aa57fb: caught java.lang.ClassNotFoundException: Supervisor/supervisor$Registered I got a serializable error when I try to send a class instance; this is partially fixed when I add the serializable annotation; I get the same error as above.
It works if I send a basic type; an Int for instance.
What is the status about sending remote messages? (What did I missed) Thanks! Stephane. On Jan 8, 2008 3:52 PM, David Pollak < dpp@...> wrote:
On Jan 8, 2008, at 3:37 AM, Stephane Le Dorze wrote: Nice to hear!
We have a lot of (game) design challenges to adress and need to make progress with our code base in the meantime.
How hard would it be to migrate from our currently developped actor based solution to what you' re expecting to build?
If it works as expected, there will be no code changes at all. All the actors will appear as first class objects in a giant mesh of JVMs managed by Terracotta.
The advantages are: - Code on the developers' machines is identical to code on production - Scalability by adding machines
As with anything, there may be some issues:
- Sending messages to Actors in other JVMs is more expensive than calling an Actor in the same JVM and if you want to know where an Actor lives, you'll have to write code that makes the Actor aware of where they are. This also discourages lots of back and forth conversation (like you may have seen in Java objects that became remoted via RMI... a method call per property rather than a "give me all your properties" call.)
- Balancing your Actors across JVMs will be necessary so that you don't have 2 or 3 machines out of a cluster of 50 that are doing most of the work
Thanks,
David
Stephane
On Jan 7, 2008 10:27 PM, David Pollak < feeder.of.the.bears@...> wrote:
On 1/7/08, Stephane Le Dorze <stephane.ledorze@...> wrote:
Hi David!
Last Time I heard of gcj it wasn t completly successfull..
In addition I will need to be able to update the client game logic without reshipping a complete exe ou dll for several *good* reasons.. :)
So we'll still need a JVM on board.
No worries.
Nice to have some feedback from your experience; even if our constraints are a bit different; they are similar in a lot of aspects.
I am particularly interested in your work with terracota; we need to start quickly but are taking some time to evaluate such possibilities; so it would be nice to have more technical and licence informations + some release dates ((ASAP)) :)
We're working with the excellent folks @ Terracotta and the folks at LAMP right now to get a solution. I'll be meeting with Philipp Haller this week and I'm hoping that we'll have something to demonstrate in the next 10 days.
If you hang out on the lift list, we'll be making announcements there.
Thanks,
David
PS -- Where are you located?
Thanks!
Stephane
On Jan 7, 2008 5:18 PM, David Pollak < dpp@...> wrote:
Stephane,
On Jan 7, 2008, at 2:43 AM, Stephane Le Dorze wrote: Hi,
Almost one year after my first post; I come back again to this subject.
This time this is not an exploratory discussion but it is for a real project in my new job position.
Cool!
So my company is involved in the creation of a massively multiplayer online game; and we're heavily considering using Scala to build it - notably using the Actor library.
We will use Scala on the server side and need to have some shared code (game logic code) between the client and the server.
So, here are my questions:
A) For the client; I need to integrate a JVM on top of a C++ runtime; considering that it could be used on next gen consoles (xbox 360, ps3, etc..) it needs to be quite fast, memory efficient, realtime and free if possible.
Does one has any recommendation?
gcj is one option... compile the byte-code down to native code.
B) Could I have any problem using two differents VMs on the client and the server respectively (I know portability is a selling point of the jvm; but I prefer to have feedback fromn real experience).
Serialization is the biggest one that comes to mind. Although, I'd do client <-> server communications using RabbitMQ.
C) What libraries would you consider for the database, logs, etc..?
See the next answer.
D) Does the actor library scales well with the number of nodes?
Yes, until you reach the maximum size of RAM, and then you're hosed... unless...
I've been doing a fair amount of work in this area recently. The lift team with working with the folks at Terracotta and Philipp Haller to use Terracotta to distribute Actors across JVMs. The side benefit will be that actor state will be persisted. So, in theory (and once we get a demo put together, we're going to test the theory against reality on 50 EC2 instances), you've got a very scalable mesh network of Actors on the server side.
Combine this with AMQP/RabbitMQ support for distributing messages between clients and the Actor pool on the server and you've got a really amazing way to built a highly scalable network application.
I am currently working on a project that will take advantage of this architecture. More on that in a few weeks.
Would it be stupid to try to create some remote processes on the clients; is there some internals in the library that would suffer from having, say, hundreds of thousands nodes?
No. As far as I can tell, the Actor library performance in O(n) where n is the number of messages in the Actor's mail box. This is the same as Erlang's Actors.
Thanks,
David
PS -- I much of the project that I'm working on will be open source and you'll be able to see the actual implementation.
If you think of other points; please feel free to mention them.
Stephane.
--
lift, the secure, simple, powerful web framework
http://liftweb.net
Collaborative Task Management http://much4.us
|
|
Re: Scala for MMOs!
Remote Actors are pretty much broken.
You might take a look at what SteveJ did with RabbitMQ and Scala Actors in lift. It's a nice way to do message passing between remote Actors, but you don't get the !? or !! stuff, just the raw ! "send a message".
On Jan 8, 2008, at 7:57 AM, Stephane Le Dorze wrote: Simply wonderful!
I got a basic beginner question now (Back to reality):
When I try to send messages between two actors; it works well BUT when I create two actor services, run both of them on the same machine; and try to send messages between them (using RemoteActor.select to locate them).
I got this error.
Error: scala.actors.remote.NetKernel@1aa57fb: caught java.lang.ClassNotFoundException: Supervisor/supervisor$Registered
I got a serializable error when I try to send a class instance; this is partially fixed when I add the serializable annotation; I get the same error as above.
It works if I send a basic type; an Int for instance.
What is the status about sending remote messages? (What did I missed)
Thanks!
Stephane.
On Jan 8, 2008 3:52 PM, David Pollak < dpp@...> wrote: On Jan 8, 2008, at 3:37 AM, Stephane Le Dorze wrote: Nice to hear!
We have a lot of (game) design challenges to adress and need to make progress with our code base in the meantime.
How hard would it be to migrate from our currently developped actor based solution to what you' re expecting to build?
If it works as expected, there will be no code changes at all. All the actors will appear as first class objects in a giant mesh of JVMs managed by Terracotta.
The advantages are: - Code on the developers' machines is identical to code on production - Scalability by adding machines
As with anything, there may be some issues: - Sending messages to Actors in other JVMs is more expensive than calling an Actor in the same JVM and if you want to know where an Actor lives, you'll have to write code that makes the Actor aware of where they are. This also discourages lots of back and forth conversation (like you may have seen in Java objects that became remoted via RMI... a method call per property rather than a "give me all your properties" call.) - Balancing your Actors across JVMs will be necessary so that you don't have 2 or 3 machines out of a cluster of 50 that are doing most of the work
Thanks,
David
Stephane
On Jan 7, 2008 10:27 PM, David Pollak < feeder.of.the.bears@...> wrote:
On 1/7/08, Stephane Le Dorze <stephane.ledorze@...> wrote: Hi David!
Last Time I heard of gcj it wasn t completly successfull..
In addition I will need to be able to update the client game logic without reshipping a complete exe ou dll for several *good* reasons.. :)
So we'll still need a JVM on board.
No worries.
Nice to have some feedback from your experience; even if our constraints are a bit different; they are similar in a lot of aspects.
I am particularly interested in your work with terracota; we need to start quickly but are taking some time to evaluate such possibilities; so it would be nice to have more technical and licence informations + some release dates ((ASAP)) :)
We're working with the excellent folks @ Terracotta and the folks at LAMP right now to get a solution. I'll be meeting with Philipp Haller this week and I'm hoping that we'll have something to demonstrate in the next 10 days.
If you hang out on the lift list, we'll be making announcements there.
Thanks,
David
PS -- Where are you located?
Thanks!
Stephane
On Jan 7, 2008 5:18 PM, David Pollak < dpp@...> wrote: Stephane,
On Jan 7, 2008, at 2:43 AM, Stephane Le Dorze wrote: Hi,
Almost one year after my first post; I come back again to this subject.
This time this is not an exploratory discussion but it is for a real project in my new job position.
Cool!
So my company is involved in the creation of a massively multiplayer online game; and we're heavily considering using Scala to build it - notably using the Actor library.
We will use Scala on the server side and need to have some shared code (game logic code) between the client and the server.
So, here are my questions:
A) For the client; I need to integrate a JVM on top of a C++ runtime; considering that it could be used on next gen consoles (xbox 360, ps3, etc..) it needs to be quite fast, memory efficient, realtime and free if possible.
Does one has any recommendation?
gcj is one option... compile the byte-code down to native code.
B) Could I have any problem using two differents VMs on the client and the server respectively (I know portability is a selling point of the jvm; but I prefer to have feedback fromn real experience).
Serialization is the biggest one that comes to mind. Although, I'd do client <-> server communications using RabbitMQ.
C) What libraries would you consider for the database, logs, etc..?
See the next answer.
D) Does the actor library scales well with the number of nodes?
Yes, until you reach the maximum size of RAM, and then you're hosed... unless...
I've been doing a fair amount of work in this area recently. The lift team with working with the folks at Terracotta and Philipp Haller to use Terracotta to distribute Actors across JVMs. The side benefit will be that actor state will be persisted. So, in theory (and once we get a demo put together, we're going to test the theory against reality on 50 EC2 instances), you've got a very scalable mesh network of Actors on the server side.
Combine this with AMQP/RabbitMQ support for distributing messages between clients and the Actor pool on the server and you've got a really amazing way to built a highly scalable network application.
I am currently working on a project that will take advantage of this architecture. More on that in a few weeks.
Would it be stupid to try to create some remote processes on the clients; is there some internals in the library that would suffer from having, say, hundreds of thousands nodes?
No. As far as I can tell, the Actor library performance in O(n) where n is the number of messages in the Actor's mail box. This is the same as Erlang's Actors.
Thanks,
David
PS -- I much of the project that I'm working on will be open source and you'll be able to see the actual implementation.
If you think of other points; please feel free to mention them.
Stephane.
--
lift, the secure, simple, powerful web framework http://liftweb.net
Collaborative Task Management http://much4.us
|
|
Re: Scala for MMOs!
Damn; '!?' is a very important feature.. It seems the problem is with the introspection; I wonder how hard it would be to fix or if there are other problems (??) Is the fact that the remote message passing is broken that lead to the use of RabbitMQ or is there other benefits?
Stephane On Jan 8, 2008 5:30 PM, David Pollak < dpp@...> wrote:
Remote Actors are pretty much broken.
You might take a look at what SteveJ did with RabbitMQ and Scala Actors in lift. It's a nice way to do message passing between remote Actors, but you don't get the !? or !! stuff, just the raw ! "send a message".
On Jan 8, 2008, at 7:57 AM, Stephane Le Dorze wrote: Simply wonderful!
I got a basic beginner question now (Back to reality):
When I try to send messages between two actors; it works well BUT when I create two actor services, run both of them on the same machine; and try to send messages between them (using RemoteActor.select to locate them).
I got this error.
Error: scala.actors.remote.NetKernel@1aa57fb: caught java.lang.ClassNotFoundException: Supervisor/supervisor$Registered
I got a serializable error when I try to send a class instance; this is partially fixed when I add the serializable annotation; I get the same error as above.
It works if I send a basic type; an Int for instance.
What is the status about sending remote messages? (What did I missed)
Thanks!
Stephane.
On Jan 8, 2008 3:52 PM, David Pollak <
dpp@...> wrote:
On Jan 8, 2008, at 3:37 AM, Stephane Le Dorze wrote: Nice to hear!
We have a lot of (game) design challenges to adress and need to make progress with our code base in the meantime.
How hard would it be to migrate from our currently developped actor based solution to what you' re expecting to build?
If it works as expected, there will be no code changes at all. All the actors will appear as first class objects in a giant mesh of JVMs managed by Terracotta.
The advantages are: - Code on the developers' machines is identical to code on production - Scalability by adding machines
As with anything, there may be some issues:
- Sending messages to Actors in other JVMs is more expensive than calling an Actor in the same JVM and if you want to know where an Actor lives, you'll have to write code that makes the Actor aware of where they are. This also discourages lots of back and forth conversation (like you may have seen in Java objects that became remoted via RMI... a method call per property rather than a "give me all your properties" call.)
- Balancing your Actors across JVMs will be necessary so that you don't have 2 or 3 machines out of a cluster of 50 that are doing most of the work
Thanks,
David
Stephane
On Jan 7, 2008 10:27 PM, David Pollak < feeder.of.the.bears@...> wrote:
On 1/7/08, Stephane Le Dorze <stephane.ledorze@...> wrote:
Hi David!
Last Time I heard of gcj it wasn t completly successfull..
In addition I will need to be able to update the client game logic without reshipping a complete exe ou dll for several *good* reasons.. :)
So we'll still need a JVM on board.
No worries.
Nice to have some feedback from your experience; even if our constraints are a bit different; they are similar in a lot of aspects.
I am particularly interested in your work with terracota; we need to start quickly but are taking some time to evaluate such possibilities; so it would be nice to have more technical and licence informations + some release dates ((ASAP)) :)
We're working with the excellent folks @ Terracotta and the folks at LAMP right now to get a solution. I'll be meeting with Philipp Haller this week and I'm hoping that we'll have something to demonstrate in the next 10 days.
If you hang out on the lift list, we'll be making announcements there.
Thanks,
David
PS -- Where are you located?
Thanks!
Stephane
On Jan 7, 2008 5:18 PM, David Pollak < dpp@...> wrote:
Stephane,
On Jan 7, 2008, at 2:43 AM, Stephane Le Dorze wrote: Hi,
Almost one year after my first post; I come back again to this subject.
This time this is not an exploratory discussion but it is for a real project in my new job position.
Cool!
So my company is involved in the creation of a massively multiplayer online game; and we're heavily considering using Scala to build it - notably using the Actor library.
We will use Scala on the server side and need to have some shared code (game logic code) between the client and the server.
So, here are my questions:
A) For the client; I need to integrate a JVM on top of a C++ runtime; considering that it could be used on next gen consoles (xbox 360, ps3, etc..) it needs to be quite fast, memory efficient, realtime and free if possible.
Does one has any recommendation?
gcj is one option... compile the byte-code down to native code.
B) Could I have any problem using two differents VMs on the client and the server respectively (I know portability is a selling point of the jvm; but I prefer to have feedback fromn real experience).
Serialization is the biggest one that comes to mind. Although, I'd do client <-> server communications using RabbitMQ.
C) What libraries would you consider for the database, logs, etc..?
See the next answer.
D) Does the actor library scales well with the number of nodes?
Yes, until you reach the maximum size of RAM, and then you're hosed... unless...
I've been doing a fair amount of work in this area recently. The lift team with working with the folks at Terracotta and Philipp Haller to use Terracotta to distribute Actors across JVMs. The side benefit will be that actor state will be persisted. So, in theory (and once we get a demo put together, we're going to test the theory against reality on 50 EC2 instances), you've got a very scalable mesh network of Actors on the server side.
Combine this with AMQP/RabbitMQ support for distributing messages between clients and the Actor pool on the server and you've got a really amazing way to built a highly scalable network application.
I am currently working on a project that will take advantage of this architecture. More on that in a few weeks.
Would it be stupid to try to create some remote processes on the clients; is there some internals in the library that would suffer from having, say, hundreds of thousands nodes?
No. As far as I can tell, the Actor library performance in O(n) where n is the number of messages in the Actor's mail box. This is the same as Erlang's Actors.
Thanks,
David
PS -- I much of the project that I'm working on will be open source and you'll be able to see the actual implementation.
If you think of other points; please feel free to mention them.
Stephane.
--
lift, the secure, simple, powerful web framework
http://liftweb.net
Collaborative Task Management http://much4.us
|
|
Re: Scala for MMOs!
|
|
Re: Scala for MMOs!
Paul J. LaCrosse <pjlacrosse@...> writes:
Berkeley DB Java Edition (JE) is another possible choice. Disclosure: I'm on JE
development team. JE is a non-relational embedded transactional store for plain
Java objects.
http://www.oracle.com/technology/documentation/berkeley-db/je/index.htmlBut my primary interest on this list is to learn Scala, not to promote JE. I'd
really like to "scalify" the JE object persistence API (Direct Persistence
Layer) as I believe there are some really great opportunities for using Scala to
define "native" queries using functional syntax. But learning Scala is my first
step! ;-)
Of course, like any Java library JE is usable in Scala now. The persistence
annotations used in JE work fine in Scala. I posted a small example using JE in
Scala here:
http://forums.oracle.com/forums/thread.jspa?messageID=2243263Later, as I start to scalify the JE interfaces I'll post my ideas to this list
for comments, and I will greatly appreciate any feedback.
--mark
|
|
Re: [scala] Scala for MMOs!
Stephane Le Dorze schrieb:
> [...]
> C) What libraries would you consider for the database, logs, etc..?
I would consider using Project Darkstar( http://projectdarkstar.com/) for
the game server.
Max
|
|
Re: Scala for MMOs!
Some parts of this message have been removed.
Learn more about Nabble's security policy.
On 1/8/08, Stephane Le Dorze <stephane.ledorze@...> wrote:
Damn; '!?' is a very important feature..
It seems the problem is with the introspection; I wonder how hard it would be to fix or if there are other problems (??)
Is the fact that the remote message passing is broken that lead to the use of RabbitMQ or is there other benefits?
The RabbitMQ and more recently XMPP support in lift have nothing to do with lift's use of Actors as part of Comet support. The messaging has more to do with the fact that most web apps communicate with the outside world. That could be RDBMS support, OpenID support, or generic messaging support. Having all of those things in an increasingly uniform set of APIs within lift is one of our goals (not baked in to the exclusion of other things, but easily accessible to developers who need particular functionality.)
lift's scaling will be based on Terracotta and not RabbitMQ-based IPC. Terracotta breaks down the barriers between homogeneous apps running in separate JVMs. RabbitMQ and XMPP are about communication with external systems running different software.
Thanks,
David
Stephane
On Jan 8, 2008 5:30 PM, David Pollak <dpp@...
> wrote:
Remote Actors are pretty much broken.
You might take a look at what SteveJ did with RabbitMQ and Scala Actors in lift. It's a nice way to do message passing between remote Actors, but you don't get the !? or !! stuff, just the raw ! "send a message".
On Jan 8, 2008, at 7:57 AM, Stephane Le Dorze wrote: Simply wonderful!
I got a basic beginner question now (Back to reality):
When I try to send messages between two actors; it works well BUT when I create two actor services, run both of them on the same machine; and try to send messages between them (using RemoteActor.select to locate them).
I got this error.
Error: scala.actors.remote.NetKernel@1aa57fb: caught java.lang.ClassNotFoundException: Supervisor/supervisor$Registered
I got a serializable error when I try to send a class instance; this is partially fixed when I add the serializable annotation; I get the same error as above.
It works if I send a basic type; an Int for instance.
What is the status about sending remote messages? (What did I missed)
Thanks!
Stephane.
On Jan 8, 2008 3:52 PM, David Pollak <
dpp@...> wrote:
On Jan 8, 2008, at 3:37 AM, Stephane Le Dorze wrote: Nice to hear!
We have a lot of (game) design challenges to adress and need to make progress with our code base in the meantime.
How hard would it be to migrate from our currently developped actor based solution to what you' re expecting to build?
If it works as expected, there will be no code changes at all. All the actors will appear as first class objects in a giant mesh of JVMs managed by Terracotta.
The advantages are: - Code on the developers' machines is identical to code on production - Scalability by adding machines
As with anything, there may be some issues:
- Sending messages to Actors in other JVMs is more expensive than calling an Actor in the same JVM and if you want to know where an Actor lives, you'll have to write code that makes the Actor aware of where they are. This also discourages lots of back and forth conversation (like you may have seen in Java objects that became remoted via RMI... a method call per property rather than a "give me all your properties" call.)
- Balancing your Actors across JVMs will be necessary so that you don't have 2 or 3 machines out of a cluster of 50 that are doing most of the work
Thanks,
David
Stephane
On Jan 7, 2008 10:27 PM, David Pollak < feeder.of.the.bears@...> wrote:
On 1/7/08, Stephane Le Dorze <stephane.ledorze@...> wrote:
Hi David!
Last Time I heard of gcj it wasn t completly successfull..
In addition I will need to be able to update the client game logic without reshipping a complete exe ou dll for several *good* reasons.. :)
So we'll still need a JVM on board.
No worries.
Nice to have some feedback from your experience; even if our constraints are a bit different; they are similar in a lot of aspects.
I am particularly interested in your work with terracota; we need to start quickly but are taking some time to evaluate such possibilities; so it would be nice to have more technical and licence informations + some release dates ((ASAP)) :)
We're working with the excellent folks @ Terracotta and the folks at LAMP right now to get a solution. I'll be meeting with Philipp Haller this week and I'm hoping that we'll have something to demonstrate in the next 10 days.
If you hang out on the lift list, we'll be making announcements there.
Thanks,
David
PS -- Where are you located?
Thanks!
Stephane
On Jan 7, 2008 5:18 PM, David Pollak < dpp@...> wrote:
Stephane,
On Jan 7, 2008, at 2:43 AM, Stephane Le Dorze wrote: Hi,
Almost one year after my first post; I come back again to this subject.
This time this is not an exploratory discussion but it is for a real project in my new job position.
Cool!
So my company is involved in the creation of a massively multiplayer online game; and we're heavily considering using Scala to build it - notably using the Actor library.
We will use Scala on the server side and need to have some shared code (game logic code) between the client and the server.
So, here are my questions:
A) For the client; I need to integrate a JVM on top of a C++ runtime; considering that it could be used on next gen consoles (xbox 360, ps3, etc..) it needs to be quite fast, memory efficient, realtime and free if possible.
Does one has any recommendation?
gcj is one option... compile the byte-code down to native code.
B) Could I have any problem using two differents VMs on the client and the server respectively (I know portability is a selling point of the jvm; but I prefer to have feedback fromn real experience).
Serialization is the biggest one that comes to mind. Although, I'd do client <-> server communications using RabbitMQ.
C) What libraries would you consider for the database, logs, etc..?
See the next answer.
D) Does the actor library scales well with the number of nodes?
Yes, until you reach the maximum size of RAM, and then you're hosed... unless...
I've been doing a fair amount of work in this area recently. The lift team with working with the folks at Terracotta and Philipp Haller to use Terracotta to distribute Actors across JVMs. The side benefit will be that actor state will be persisted. So, in theory (and once we get a demo put together, we're going to test the theory against reality on 50 EC2 instances), you've got a very scalable mesh network of Actors on the server side.
Combine this with AMQP/RabbitMQ support for distributing messages between clients and the Actor pool on the server and you've got a really amazing way to built a highly scalable network application.
I am currently working on a project that will take advantage of this architecture. More on that in a few weeks.
Would it be stupid to try to create some remote processes on the clients; is there some internals in the library that would suffer from having, say, hundreds of thousands nodes?
No. As far as I can tell, the Actor library performance in O(n) where n is the number of messages in the Actor's mail box. This is the same as Erlang's Actors.
Thanks,
David
PS -- I much of the project that I'm working on will be open source and you'll be able to see the actual implementation.
If you think of other points; please feel free to mention them.
Stephane.
--
lift, the secure, simple, powerful web framework
http://liftweb.net
Collaborative Task Management http://much4.us
-- lift, the secure, simple, powerful web framework http://liftweb.netCollaborative Task Management http://much4.us
|
|
Re: Scala for MMOs!
Salut Stephane.
> A) For the client; I need to integrate a JVM on top of a C++ runtime;
> considering that it could be used on next gen consoles (xbox 360, ps3,
> etc..) it needs to be quite fast, memory efficient, realtime and free if
> possible.
> Does one has any recommendation?
I don't know it that's a sensible idea, but you may want to have a look
at what can be done with VMs that transform a JVM-bytecode program into
a C++ program and its VM runtime. This can then be compiled to native
code as a single all-in-one application.
I once had a course by prof. Vitek on OVM, an open VM that does exactly
that. Boeing uses it to run the flight control system of a tiny
unmanned air vehicle. The use case for OVM defines its design goals:
real-time, fast and memory efficient (they also worked on
extensibility).
They could do some pretty neat things with OVM, for example they run a
program in interpreted mode until it reaches a fix-point (i.e. it
finishes its initialisation). Then, they generate the program, program
state and VM runtime from that point and compile it to native code.
http://www.cs.purdue.edu/homes/jv/soft/ovmNow, maybe OVM wouldn't fit your bill exactly: it doesn't seem very
well maintained right now (but you may try to contact Jan Vitek and ask
him what the exact status is). And I don't know how well it would
integrate with Scala.
But it may be worth looking into that direction.
Cheers,
Gilles.
|
|
Re: [scala] Re: Scala for MMOs!
Interesting approach, But such beast looks poorly supported and remain a very risky bet. Thanks for the link anyway! Stephane. On Jan 9, 2008 2:37 PM, Gilles Dubochet < gilles.dubochet@...> wrote: Salut Stephane.
> A) For the client; I need to integrate a JVM on top of a C++ runtime;
> considering that it could be used on next gen consoles (xbox 360, ps3,
> etc..) it needs to be quite fast, memory efficient, realtime and free if
> possible.
> Does one has any recommendation?
I don't know it that's a sensible idea, but you may want to have a look
at what can be done with VMs that transform a JVM-bytecode program into
a C++ program and its VM runtime. This can then be compiled to native
code as a single all-in-one application.
I once had a course by prof. Vitek on OVM, an open VM that does exactly
that. Boeing uses it to run the flight control system of a tiny
unmanned air vehicle. The use case for OVM defines its design goals:
real-time, fast and memory efficient (they also worked on
extensibility).
They could do some pretty neat things with OVM, for example they run a
program in interpreted mode until it reaches a fix-point (i.e
. it
finishes its initialisation). Then, they generate the program, program
state and VM runtime from that point and compile it to native code.
http://www.cs.purdue.edu/homes/jv/soft/ovm
Now, maybe OVM wouldn't fit your bill exactly: it doesn't seem very
well maintained right now (but you may try to contact Jan Vitek and ask
him what the exact status is). And I don't know how well it would
integrate with Scala.
But it may be worth looking into that direction.
Cheers,
Gilles.
|
