Hards, the internal currency of Epiphany Games
Forward;
It’s been a while since I created a post about what Epiphany has been doing. The roller-coaster ride of game releases consolidating our efforts on development after the chaos of shipping a big game.
New horizons;
Now that it’s all said and done, Epiphany Studios ended up making some really useful stuff. And that stuff, we will share with other game developers, first in Sydney then in other places. The core what we have been working on was to address the need for a Steam like service for games (mostly the things that developers want to use in their games) that includes Friends, Achievements, Authentication, Messages, Internet Play Lobbies and other stuff.
So with this requirement Epiphany took Morgans side project right into the mainstreaming use a project called Birdcage on its game Frozen Hearth. This gave Epiphany the following without needing an other third party; DRM (We use Game Shield, but we hook it up differently), Registration of Accounts and that was it initially we needed it to do internet play, we wanted all the players together. So Epiphany released its game having DRM but a minimal integration and included registration in place for out internet play service. What was also interesting was the REST framework we were creating and what it could be. Then along came a really great game which Epiphany became a part of. This game was different from our usual hardcore games but we wanted to add the Epiphany spice to it, improved the Game Play interface and generally put the steroids into it.
What had we made a REST based persistence service with a Unity integration, this gave us community tools like Leagues, High scores and more importantly game data being saved to the cloud and a game turn execution server. So we now have community management, DRM, multi player, storage of generic game play objects and global game wide game turn execution (with an interface for custom rules that are linked in a database).
These systems we collectively call the Revnet service but it’s more than that. What it leads to is our next step in the development of persistent mass player data effectively large numbers of players in the one game. Future partnerships with other developers and publishers. Epiphany has always had a strong technical base, and chances are the products we produce will be designed to work with with our plethora of games. Last year we shipped a total of 9 games, this year we are shipping more. Some are big some are small but all will benefit from our new service.
Our next set of games will utilise all these tools to enhance their game play and I’m already planning the next big game. Frozen Hearth will benefit in the following ways, internet multi player, persistent user information and better control of patching.
The current project we are working, benefits by having a massively multi player service. Its game play is separated from user authentication but uses a token to perform actions for the player. Each of the objects can be separated and paired out into their own services via a message bus later for scaling (something like Mule ESB product; which we will leverage in the future).
The entire system is written in Python using a framework; however we made even more crazy stuff.
Message generation for API’s in integration is a tedious task to say the least. Our developers ended up creating a message generation program that makes the C# for Unity, C++ for Gamebryo and probably will make Unreal Script for UDK that wrapped up with our custom Json parser forms the engine side integration.
So how would it work in Unity, GameBryo and Unreal . Basically we supply a Plugin for Unity which deals with all the messy bits of HTTP, SSL, Json etc and returns Unity objects. In Gamebroy we do the same thing but its C++, in Unreal its probably going to be C++ with an U Script interface. And bam! You get game objects in the engine that can persist back to a server via HTTP. The other components are a Service C++ lobby that hooks into the rest of the framework to provide a battlenet like service, a Python Lobby server and a custom Python Gameplay service. These all however talk over the same interfaces but when it gets to network play we just facilitate the communication between a client and server or another client in the case of Frozen Hearth. The system is immediately scalable, durable, robust and flexible because of the way we did it. I think this will be very useful to anyone wanting to create games.
What’s next, well payment gateway support it took our friends at sit rep a while to do payment integration for in app purchasing we think it should take 10 seconds if it doesn’t well they don’t got time for that #$%^. Ill integrate the APP store, Google Play, Amazon, Pay Pal and Samsung.
If you want to know more about Revnet, contact Morgan Lean. It’s still in development but its growing all the time. We intend for it to be a low cost service and free to develop API. If you have a game which you think is amazing that needs some of the features, let us know we are here to help. This type of thing is too useful to not be shared.