- Joined
- Jun 1, 2018
- Messages
- 105
- Reaction score
- 40
"MyCoke, previously known as Coke Music or Coke Studios, was an MMO chat game utilized in the marketing of the Coca-Cola brand. Made by Studiocom using core technology from the Sulake Corporation, famous for a similar title - Habbo Hotel. Later developing it's own engine, called Galapagos, the service launched Version 2 of the game in late 2004. On December 6, 2007, MyCoke was shut down..." - MyCoke Wiki
Today I am releasing all the Coke Studios related files that are in my possession.
I worked on reverse engineering the original Coke Studios client and trying to come up with a proper emulation of it for a few months and ended up recovering many lost files, organizing files/data that were found scattered across the internet, and also kicked up quite a bit of knowledge regarding the game that I at least never saw discussed or released anywhere else.
I've spent quite a bit of time organizing things and documenting tid-bits that may be relevant to those seeking to emulate or recreate the game in its entirety and some of this has already been posted in another community dedicated to the game. I'll share some of these details below before finally linking to my archive.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The original Coke Studios (v1) was heavily worked on by Sulake and from what has been gathered across the internet, was most likely using Sulakes FUSE protocol and a similar design architecture to Habbo Hotel. Upon the release of the revised client (v2+), the game developers worked out an entirely revamped design for the client-server architecture (Galapagos).
This new client-server architecture was probably "cutting-edge" for its time and consisted of a front-end published in Director, a Java back-end, and multiple databases. Effectively the front end (visual aspect) was still created via Director, however, one of the cast files contained a cast member that was actually a Flash file (SWF). Inside of this Flash file is in fact, most of the clients source code.
See the developers decided to design a system that relied on using XML-RPC, RTMP, and ActionScript Messaging Format (AMF) for the networking related aspects. To utilize Remote Procedural Calls in Flash the developers used a technology called Flash Remoting. Essentially the client would prepare data and call a client-side stub, this stub would serialize the data and send it to a intermediary piece of software called the Flash Remoting Gateway. This Flash Gateway would de-serialize the data and pass it on to the server-side application which would then call a server-side stub, perform some action, and serialize a response which is then sent back to the Flash Gateway and back on to the client. Essentially with this design many things are stateless and the client relied on using caching/cookies or state would be sent in each packet.
If you are familiar with distributed systems and remote procedural calls, at this point you may have realized the implications that this design choice carries with it. Essentially since we have the source code from this SWF (thank you JPEXS) we have a copy of all the client-side stubs. Which means that you can more or less infer what the server was doing (not everything...).
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This is a very condensed version of things and I omitted tons of detail while simplifying concepts that you can easily write entire books on. Which is to say that this is not the entire picture but plenty to go off of and definitely a better starting point than I had when I began this journey.
I won't bore you any longer, here is a screenshot of the archive's layout and also the download link.
https://mega.nz/file/euQQSapQ#Lw1qBqLrftyIpzdnDC2nFMuDdOXkqq12A5Fyc8PtFCg
I do not take credit for all of the files in this archive, thanks.
Today I am releasing all the Coke Studios related files that are in my possession.
I worked on reverse engineering the original Coke Studios client and trying to come up with a proper emulation of it for a few months and ended up recovering many lost files, organizing files/data that were found scattered across the internet, and also kicked up quite a bit of knowledge regarding the game that I at least never saw discussed or released anywhere else.
I've spent quite a bit of time organizing things and documenting tid-bits that may be relevant to those seeking to emulate or recreate the game in its entirety and some of this has already been posted in another community dedicated to the game. I'll share some of these details below before finally linking to my archive.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The original Coke Studios (v1) was heavily worked on by Sulake and from what has been gathered across the internet, was most likely using Sulakes FUSE protocol and a similar design architecture to Habbo Hotel. Upon the release of the revised client (v2+), the game developers worked out an entirely revamped design for the client-server architecture (Galapagos).
This new client-server architecture was probably "cutting-edge" for its time and consisted of a front-end published in Director, a Java back-end, and multiple databases. Effectively the front end (visual aspect) was still created via Director, however, one of the cast files contained a cast member that was actually a Flash file (SWF). Inside of this Flash file is in fact, most of the clients source code.
See the developers decided to design a system that relied on using XML-RPC, RTMP, and ActionScript Messaging Format (AMF) for the networking related aspects. To utilize Remote Procedural Calls in Flash the developers used a technology called Flash Remoting. Essentially the client would prepare data and call a client-side stub, this stub would serialize the data and send it to a intermediary piece of software called the Flash Remoting Gateway. This Flash Gateway would de-serialize the data and pass it on to the server-side application which would then call a server-side stub, perform some action, and serialize a response which is then sent back to the Flash Gateway and back on to the client. Essentially with this design many things are stateless and the client relied on using caching/cookies or state would be sent in each packet.
If you are familiar with distributed systems and remote procedural calls, at this point you may have realized the implications that this design choice carries with it. Essentially since we have the source code from this SWF (thank you JPEXS) we have a copy of all the client-side stubs. Which means that you can more or less infer what the server was doing (not everything...).
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This is a very condensed version of things and I omitted tons of detail while simplifying concepts that you can easily write entire books on. Which is to say that this is not the entire picture but plenty to go off of and definitely a better starting point than I had when I began this journey.
I won't bore you any longer, here is a screenshot of the archive's layout and also the download link.
https://mega.nz/file/euQQSapQ#Lw1qBqLrftyIpzdnDC2nFMuDdOXkqq12A5Fyc8PtFCg
I do not take credit for all of the files in this archive, thanks.
