IBM, startup launch massive gaming 'grid'
by Ken Finney · in General Discussion · 05/09/2002 (10:39 pm) · 15 replies
LOS ANGELES, California (Reuters) -- A start-up, Butterfly.net Inc., and computing giant IBM , have created a global network for online video games capable of supporting a million players or more that will be rented to major game publishers, the companies said Thursday.
Full Story
Butterfly.net home page
Full Story
Butterfly.net home page
About the author
#2
05/10/2002 (1:46 am)
I will suggest people not to rush into this thing right now. Probably should just wait a bit and see more proof that it works. It is not uncommon that network admin blocks most multicast packets, which is what this butterfly thing based on.
#3
I will share with you guys later what I think about it ok?
05/10/2002 (7:34 am)
Well I dont really know, but Im giving it a shot.I will share with you guys later what I think about it ok?
#4
I'm happy to be proved wrong.
Phil.
05/10/2002 (7:55 am)
Looks like another .com business idea. Pie in the sky and ultimately useless.I'm happy to be proved wrong.
Phil.
#5
So whats this butterfly net thingie?
Okie, so heres the deal, (as always you have to scrub off the hype to see what you actually have in your hands.)
( Before we start, I would like to point out this system will work for MMORPG and similar kind of games, but not fps, action games ok? good lets continue!)
As you probably know the soul of an MMOG is its server (without it theres no MMOG pure and simple.) since the server is the medium in which all users connect to each other, and save their status (in persistent worlds) in addition the server ussually also creates and controls bots (npcs), sets quests, etc.
Now, lets supose your MMOG server is down, well.. you are screwed, unless you have a server farm (which can be pretty expensive) to back you up, so what about if you could RENT a server farm, with your game on it? a server farm so big that could present you with stability for all your users and big enough to fit them all in a single world?
Well that is the basic idea, they are renting you a Multipurpose (huge) server farm!
Now, as you may guess running someone else code in your server is a bad idea(specially for something of this scale) the code may be corrupted, carry a trojan, it may crash etc. The solution would be to have a single server (farm) system that can be used by any kind of game and bingo! thats exactly what butterfly net is!
Ok, so what about the rules and the bots, servers have those right? In this case NO each client has to handle complex decision code so somehow each client also works partially as a server this way the server expends less time in making decissions and more time sending and receiving packets (which also means less lag)
(after all this is a grid based system and thats exactly how it works) Each client must have its own set of rules, bots, etc. so grid based clients become ,much more complex than ordinary clients. Since the server only sends and receives packages (and lets users in) so it doesnt have any other function, and those functions must be carried by the clients.
What butterfly net basically does is:
*Grabs and sends packages of information as predefined objects (things) to each connected user. (you can define what each packet is via scripting or coding)
*Saves and Loads info from a SQL server based farm in the net.
Thats it!
In the SDK you only get the code to create a client, which will in turn connect to the butterfly server.
Think of the butterfly server as a very big master server where everyone can connect to send and receive info to each other and in addition be able to save that info in a huge dbase (for persistent worlds!)
Of course, you only want to receive and send packets to YOUR game, instead of all games on the farm, so there is quite a bit of identification code to put on your code to do exactly that. (which I havent understood completely so I cant discuss it) They haven given this matter a lot of thought so dont worry, each packet is identified for each game. (and no I dont think it will be easy to hack into each game, security has also been taken care of)
So they offer you a 24/7 server (farm), the code to access it in a (2mb download!) sdk Free! which includes a small sample of how to connect to the server and send info!
Unfortunately (theres a catch) the SDK itself is free, but the use of the server for your game is NOT FREE a RENT must be payed each month and since it will be used for ps2, xbox,pc (read that as FF, EQ and even AC2) even PDAs and celphones games, Chances are it wont be particularly cheap.
I havent been able to contact butterfly for a price range, but the rule of thumb for costs is: "if they dont tell you the price right away you can be pretty sure there is a good reason for it." (Ouch!)
Perhaps we can convince the GG staff, to twist some arms to get us a discount to TGE users to use this system, or something. =)
Or maybe they charge for bandwidth and DBASE server space used, which will then be balanced by the users and fees you are getting in your game. In the beginning it wont be much, but if your game succeds then it will be a lot (but you will be making a lot from it too)unfortunately this last paragraph is just speculation and wishful thinking.
So thats the deal, it sounds great, but most probably is not cheap, havent tested the speed neither, although with IBM support it must be reasonably good.
As soon as I gather more info I will send it back to you.
May the torque be with you
05/10/2002 (9:13 am)
Ok.. here are some preliminary results on this butterfly net, this are very,very initial results , so please correct me if I im wrong (without using 4 letter expletitives if possible)So whats this butterfly net thingie?
Okie, so heres the deal, (as always you have to scrub off the hype to see what you actually have in your hands.)
( Before we start, I would like to point out this system will work for MMORPG and similar kind of games, but not fps, action games ok? good lets continue!)
As you probably know the soul of an MMOG is its server (without it theres no MMOG pure and simple.) since the server is the medium in which all users connect to each other, and save their status (in persistent worlds) in addition the server ussually also creates and controls bots (npcs), sets quests, etc.
Now, lets supose your MMOG server is down, well.. you are screwed, unless you have a server farm (which can be pretty expensive) to back you up, so what about if you could RENT a server farm, with your game on it? a server farm so big that could present you with stability for all your users and big enough to fit them all in a single world?
Well that is the basic idea, they are renting you a Multipurpose (huge) server farm!
Now, as you may guess running someone else code in your server is a bad idea(specially for something of this scale) the code may be corrupted, carry a trojan, it may crash etc. The solution would be to have a single server (farm) system that can be used by any kind of game and bingo! thats exactly what butterfly net is!
Ok, so what about the rules and the bots, servers have those right? In this case NO each client has to handle complex decision code so somehow each client also works partially as a server this way the server expends less time in making decissions and more time sending and receiving packets (which also means less lag)
(after all this is a grid based system and thats exactly how it works) Each client must have its own set of rules, bots, etc. so grid based clients become ,much more complex than ordinary clients. Since the server only sends and receives packages (and lets users in) so it doesnt have any other function, and those functions must be carried by the clients.
What butterfly net basically does is:
*Grabs and sends packages of information as predefined objects (things) to each connected user. (you can define what each packet is via scripting or coding)
*Saves and Loads info from a SQL server based farm in the net.
Thats it!
In the SDK you only get the code to create a client, which will in turn connect to the butterfly server.
Think of the butterfly server as a very big master server where everyone can connect to send and receive info to each other and in addition be able to save that info in a huge dbase (for persistent worlds!)
Of course, you only want to receive and send packets to YOUR game, instead of all games on the farm, so there is quite a bit of identification code to put on your code to do exactly that. (which I havent understood completely so I cant discuss it) They haven given this matter a lot of thought so dont worry, each packet is identified for each game. (and no I dont think it will be easy to hack into each game, security has also been taken care of)
So they offer you a 24/7 server (farm), the code to access it in a (2mb download!) sdk Free! which includes a small sample of how to connect to the server and send info!
Unfortunately (theres a catch) the SDK itself is free, but the use of the server for your game is NOT FREE a RENT must be payed each month and since it will be used for ps2, xbox,pc (read that as FF, EQ and even AC2) even PDAs and celphones games, Chances are it wont be particularly cheap.
I havent been able to contact butterfly for a price range, but the rule of thumb for costs is: "if they dont tell you the price right away you can be pretty sure there is a good reason for it." (Ouch!)
Perhaps we can convince the GG staff, to twist some arms to get us a discount to TGE users to use this system, or something. =)
Or maybe they charge for bandwidth and DBASE server space used, which will then be balanced by the users and fees you are getting in your game. In the beginning it wont be much, but if your game succeds then it will be a lot (but you will be making a lot from it too)unfortunately this last paragraph is just speculation and wishful thinking.
So thats the deal, it sounds great, but most probably is not cheap, havent tested the speed neither, although with IBM support it must be reasonably good.
As soon as I gather more info I will send it back to you.
May the torque be with you
#6
Actually, I see no reason why this wouldn't work for FPS or action games. Do you think their transport is too slow?
This is very, very wrong. The butterfly grid is based on (relatively) thin clients. All the rules, bots, npcs, scripts, whatever run on the servers, not the clients. The clients actually have very limited access to the game data.
The rest of your post is mostly based on most of this misunderstanding of what the server and clients jobs are so I won't go further. Basically, just download the SDK and read the docs. It's all pretty clear.
Yes, the cost will probably be high. But consider what you'll be getting in return. Mainly, you don't have to lease/buy servers, get enough bandwidth, maintain servers, write loadbalancing code, etc. That's a ton of stuff that I'd be very happy with someone else doing.
Some of the points that I really like are:
Updates on the fly: servers don't need to go down to do updates.
Python as the scripting language: It's a great language for this and glad to see more work being done with it.
So that's my take on the butterfly grid. I've downloaded the SDK and built and browsed through the win32 clients. Nice and simple.
One good point from an earlier post is that to combine it with Torque, you'd have to not use Torque net code. That's true and unfortunate. But it might be worth it for MAJOR projects. This isn't tech to use for small projects, it will be too expensive for that.
Drat, probably wrote too much again...
...ttfn
05/10/2002 (1:03 pm)
Here's my corrections(?) and views of the butterfly grid.Quote:
( Before we start, I would like to point out this system will work for MMORPG and similar kind of games, but not fps, action games ok? good lets continue!)
Actually, I see no reason why this wouldn't work for FPS or action games. Do you think their transport is too slow?
Quote:
Ok, so what about the rules and the bots, servers have those right? In this case NO each client has to handle complex decision code so somehow each client also works partially as a server this way the server expends less time in making decissions and more time sending and receiving packets (which also means less lag)
(after all this is a grid based system and thats exactly how it works) Each client must have its own set of rules, bots, etc. so grid based clients become ,much more complex than ordinary clients. Since the server only sends and receives packages (and lets users in) so it doesnt have any other function, and those functions must be carried by the clients.
This is very, very wrong. The butterfly grid is based on (relatively) thin clients. All the rules, bots, npcs, scripts, whatever run on the servers, not the clients. The clients actually have very limited access to the game data.
The rest of your post is mostly based on most of this misunderstanding of what the server and clients jobs are so I won't go further. Basically, just download the SDK and read the docs. It's all pretty clear.
Yes, the cost will probably be high. But consider what you'll be getting in return. Mainly, you don't have to lease/buy servers, get enough bandwidth, maintain servers, write loadbalancing code, etc. That's a ton of stuff that I'd be very happy with someone else doing.
Some of the points that I really like are:
Updates on the fly: servers don't need to go down to do updates.
Python as the scripting language: It's a great language for this and glad to see more work being done with it.
So that's my take on the butterfly grid. I've downloaded the SDK and built and browsed through the win32 clients. Nice and simple.
One good point from an earlier post is that to combine it with Torque, you'd have to not use Torque net code. That's true and unfortunate. But it might be worth it for MAJOR projects. This isn't tech to use for small projects, it will be too expensive for that.
Drat, probably wrote too much again...
...ttfn
#7
You see it makes sense to me to use a single multipurpose server (farm) for all systems and connect to it, but if you do have a server of your own how do you connect to it/upload it and make it work on the entire grid at the same time? it mentions it has a hot swap mechanism but I just dont see how you get it there.
btw. those features you mentioned are my favorite too.
=)
ps Do you know where I can find pricing info?
05/10/2002 (1:15 pm)
Oh.. I see well thanks for correcting me on that one, I did read the docs but since Im not a net expert (more likely the opposite) I got confused. You see it makes sense to me to use a single multipurpose server (farm) for all systems and connect to it, but if you do have a server of your own how do you connect to it/upload it and make it work on the entire grid at the same time? it mentions it has a hot swap mechanism but I just dont see how you get it there.
btw. those features you mentioned are my favorite too.
=)
ps Do you know where I can find pricing info?
#8
www.butterfly.net/developers/index.html
05/10/2002 (1:51 pm)
I dont know if you guys saw this part of their site so I am just posting it here to maybe clarify some more thingswww.butterfly.net/developers/index.html
#9
----------------------
Users connect to any machine in the grid (not sure if this is a static connection, or if it 'moves' through the grid as the avatar moves.. not quite clear on that)
Each machine in the grid runs a small SQL database.
When events come into the system, it looks up the game object in the database, then executes the script that goes with that object. (all objects have an object type, each type has an event-handler script)
Objects can only interact with other objects who's game IDs are the same (ie: part of the same game). So the database can have objects from many games in it, thus allowing each node to serve for multiple games seamlessly.
Whenever an object is updated, a message is sent to all active objects within range updating them with the new data. They also implement dead reckoning for network compression.
Grid boundaries are arbitrary - you define a set of planes in 3-space which act as the 'area' for the node. Then, you define regions of overlap between grid nodes (objects in these areas send messages to both nodes).
Arbitrary messages can be passed between objects. This includes text strings for chatting, or binary objects if you want to send other stuff.
The network protocol is UDP based, with support for reliable updates.
----------------------
Some thoughts:
- I'm curious what kind of speed it can achieve when doing SQL lookups on a 'typical' grid node? If I have a dense node of several hundred thousand objects, how quickly can it query for the ten or so objects in my area? Worse still: what if 10 games of this density were hosted on this node.. can it query a database of millions of objects to find the 10 'close' objects in my 'game' at real-time speed?
- How does it achieve load balance when the grid nodes are defined by the game designers? What if I made my entire MMOG using ONE grid cell.. would all 200,000 players hammer that poor server?
- MMORPG vs MMOFPS - It 'feels' like you could write an FPS with this system.. but it would depend on the speed of the SQL queries and the complexity of the Python scripts.. can these be done in real-time?
- Physics - I'm a bit curious how physics is implemented server-side. It feels like physics is achieved through passing "THING_HERE" messages continuously, thus continuously activating Python scrips, which continuously check for collisions, etc.. This sounds miserably slow..? They have an example of terrain collision which is nice, but doesn't describe the implementation in terms of node execution or message passing.. just some data structures.
.. after some more reading, it appears that each node also has a Daemon process (C/C++ code) which acts through a privelaged-account, and processes messages from all active objects in the node. This is probably where physics would occur.
--Bryan
05/13/2002 (7:39 am)
This thread got me curious, it seems to follow some of the research I was doing about two years ago. I downloaded the SDK and read through the docs.. It's a pretty neat system actually, really gets down to the meat of a MMOG.----------------------
Users connect to any machine in the grid (not sure if this is a static connection, or if it 'moves' through the grid as the avatar moves.. not quite clear on that)
Each machine in the grid runs a small SQL database.
When events come into the system, it looks up the game object in the database, then executes the script that goes with that object. (all objects have an object type, each type has an event-handler script)
Objects can only interact with other objects who's game IDs are the same (ie: part of the same game). So the database can have objects from many games in it, thus allowing each node to serve for multiple games seamlessly.
Whenever an object is updated, a message is sent to all active objects within range updating them with the new data. They also implement dead reckoning for network compression.
Grid boundaries are arbitrary - you define a set of planes in 3-space which act as the 'area' for the node. Then, you define regions of overlap between grid nodes (objects in these areas send messages to both nodes).
Arbitrary messages can be passed between objects. This includes text strings for chatting, or binary objects if you want to send other stuff.
The network protocol is UDP based, with support for reliable updates.
----------------------
Some thoughts:
- I'm curious what kind of speed it can achieve when doing SQL lookups on a 'typical' grid node? If I have a dense node of several hundred thousand objects, how quickly can it query for the ten or so objects in my area? Worse still: what if 10 games of this density were hosted on this node.. can it query a database of millions of objects to find the 10 'close' objects in my 'game' at real-time speed?
- How does it achieve load balance when the grid nodes are defined by the game designers? What if I made my entire MMOG using ONE grid cell.. would all 200,000 players hammer that poor server?
- MMORPG vs MMOFPS - It 'feels' like you could write an FPS with this system.. but it would depend on the speed of the SQL queries and the complexity of the Python scripts.. can these be done in real-time?
- Physics - I'm a bit curious how physics is implemented server-side. It feels like physics is achieved through passing "THING_HERE" messages continuously, thus continuously activating Python scrips, which continuously check for collisions, etc.. This sounds miserably slow..? They have an example of terrain collision which is nice, but doesn't describe the implementation in terms of node execution or message passing.. just some data structures.
.. after some more reading, it appears that each node also has a Daemon process (C/C++ code) which acts through a privelaged-account, and processes messages from all active objects in the node. This is probably where physics would occur.
--Bryan
#10
Great explanation on the system Bryan, and yes unfortunately the points you mentioned left some big question marks on the air about this system. It simply doesnt explain or mention if they are any boundaries/ limitations to a game on it, and as you have mentioned there has to be, otherwise the lag would be terrible for all games.
My guess is this is not an actually complete product, but more likely a project in beta (or maybe even alpha)phase, therefore they dont have the answers to those questions yet (or at least they have not tested their aproaches).
I havent even received any pricing information from them (which I asked a few days ago) which might mean they dont have any about it yet. They dont even mention how can you upload a (limited) server demo for testing/benchmarking purposes. (and without that, it becomes very difficult to code samples on it)
If you check on their webpage you will see they mention they will have a demo running on e3, they are no demos on site other than the small sample that comes with the sdk. (actually the site doesnt hold much info to be honest)
My guess is that this project is still a long way to go (maybe they are in a funding phase) before we can use it. (IF they decide to let everyone use it and not sell the exclusivity to major developers like sony or microsoft that is)
Well this is a real neat idea, but without any more info on how it works, or samples I dont see how we can use it, or learn to code on it.
Im glad you are interested on this one too Bryan. I hope we can gather more info about it.
May the torque be with you.
05/13/2002 (8:32 am)
Hi Bryan! I didnt knew you were here, Im German Cons I went to your Gameinstitute Terrain Rendering class =)Great explanation on the system Bryan, and yes unfortunately the points you mentioned left some big question marks on the air about this system. It simply doesnt explain or mention if they are any boundaries/ limitations to a game on it, and as you have mentioned there has to be, otherwise the lag would be terrible for all games.
My guess is this is not an actually complete product, but more likely a project in beta (or maybe even alpha)phase, therefore they dont have the answers to those questions yet (or at least they have not tested their aproaches).
I havent even received any pricing information from them (which I asked a few days ago) which might mean they dont have any about it yet. They dont even mention how can you upload a (limited) server demo for testing/benchmarking purposes. (and without that, it becomes very difficult to code samples on it)
If you check on their webpage you will see they mention they will have a demo running on e3, they are no demos on site other than the small sample that comes with the sdk. (actually the site doesnt hold much info to be honest)
My guess is that this project is still a long way to go (maybe they are in a funding phase) before we can use it. (IF they decide to let everyone use it and not sell the exclusivity to major developers like sony or microsoft that is)
Well this is a real neat idea, but without any more info on how it works, or samples I dont see how we can use it, or learn to code on it.
Im glad you are interested on this one too Bryan. I hope we can gather more info about it.
May the torque be with you.
#11
So there you have it, the official word, there is a chance you can upload your servers for testing purposes, pretty soon. Stay alert on that E3 both.
Let me see if I can get more info about this and pricing.
p.s. This may or may not cancel my prior comment, we will have to wait and see.
May the torque be with you
05/13/2002 (10:07 am)
Good news, a butterfly net member finally contacted me about using closed limited "test servers" and this is the answer Ive got:Quote:
German,
our plan is to that just post E3. we're pretty swamped right now.
cheers!
So there you have it, the official word, there is a chance you can upload your servers for testing purposes, pretty soon. Stay alert on that E3 both.
Let me see if I can get more info about this and pricing.
p.s. This may or may not cancel my prior comment, we will have to wait and see.
May the torque be with you
#12
This is THE answer Ive got from a butterfly.net member:
Yes, you may want to read that again, so in order save you the eye strain here it is:
Champagne gets opened in the distance
Ok, maybe is not time to open that champagne yet, but even knowing they are actually considering it is so cool, it brings small tears to my eyes! =)
If this turns out to be true, we will be so sorry for our dear TGE publishers namely the garagegames staff, (oh who we are kidding, we wont =)) but at least
we will sincerely hope they get a real nice indie discount or a shelf publisher for this sort of games. (oh dont worry, anyway we have that agreement in which
they make part of the monthly fees as well remember? that was nice thinking ahead!)
(Oh crap! this is the E3 Im going to truly miss not going the most!)
p.s.
Well since Im in a roll here, Im going to start tossing the tough technical questions I will tell you results asap IF I get them.
May the torque be with you.
05/13/2002 (11:37 am)
Ok, now I FINALLY got answered about pricing, this is not final but just in case you may want to put that champage to chill waiting for E3. (or crack it open if you feel like) This is THE answer Ive got from a butterfly.net member:
Quote:
That's gonna take a bit more work... we've been focused on product, not pricing, but will try to come up w/ something soon.
most likely we'll charge publishers, make it free to developers and gamers.
Yes, you may want to read that again, so in order save you the eye strain here it is:
Quote:
most likely we'll charge publishers, make it FREE to developers and gamers.
Champagne gets opened in the distance
Ok, maybe is not time to open that champagne yet, but even knowing they are actually considering it is so cool, it brings small tears to my eyes! =)
If this turns out to be true, we will be so sorry for our dear TGE publishers namely the garagegames staff, (oh who we are kidding, we wont =)) but at least
we will sincerely hope they get a real nice indie discount or a shelf publisher for this sort of games. (oh dont worry, anyway we have that agreement in which
they make part of the monthly fees as well remember? that was nice thinking ahead!)
(Oh crap! this is the E3 Im going to truly miss not going the most!)
p.s.
Well since Im in a roll here, Im going to start tossing the tough technical questions I will tell you results asap IF I get them.
May the torque be with you.
#13
:)
05/13/2002 (9:30 pm)
Although I'm just a gaming hobbyist, from what I have read about developer/publisher relationships "SCREW THE PUBLISHERS ROYALLY".:)
#14
05/14/2002 (1:02 am)
I just wanted to play single player *sniff* *sniff*
#15
That includes if you just want to use it for learning purposes.
On the bright side, is almost the same prize as a dedicated server, except is made for gaming.
May the torque be with you...
05/15/2002 (2:25 pm)
Well.. Is official , the price for using the grid is $395.00 per month, per developer. That includes if you just want to use it for learning purposes.
On the bright side, is almost the same prize as a dedicated server, except is made for gaming.
May the torque be with you...
Associate Ken Finney
Tubetti World
To use their system you'll need to use their SDK, and when using their SDK with Torque, you'll need to throw out - or otherwise just not use - most of Torque's net-code.