Majestic Nights is about to be submitted to Switch. As a game we feel strongly about this title we hope our Switch port will bring new players to this title and they can find as much enjoyment as other players on the PC platform.
We will use to proceeds from the Switch release to really plan what we are doing with Majestic. Majestic Nights, if you haven’t played it is what we call a strange and wonderful gem. This game had a very bumpy launch, but has a core to it which is like no other game. We want to make the remaining chapters, and are thinking carefully about which engine we use, either its existing engine or the Chaos Engine.
Last year was very difficult for us, for a variety of reasons. As the CEO, I was also building a whole new piece of technology and we were doing a large amount of development on our Reclaimer title (more about that later).
Chaos Engine is our proprietary code framework for turn based games, but has many components useful in other genre titles. The Chaos Engine was built to satisfy 3 criteria: Fast Prototyping, Efficient Production, and Easy Maintenance. Focusing on these core principles has allowed us to create a codebase that is modular and easy to modify, allowing for reuse of existing code in new projects quickly and easily.
Because the Chaos Engine relies heavily on complex data to drive gameplay, the Chaos Forge tool was created. This tool provides several important functions, including Asset creation, Gameplay programming, Build packaging, and more. Chaos Forge is where most of a Chaos Engine title is made, here, designers can create items, build maps, tweak character stats, edit abilities, and work on any other game data. Levels produced within Chaos Forge can utilize nested Prefabs, enabling level designers to create and use a library of reusable level parts created from sets of assets. This tool significantly reduces game development time, making it possible to produce several hours of game play in only weeks, rather than months.
Assets and Data produced for Chaos Engine is packaged into files called ‘Bundles’. Using this system, it’s possible to replace or extend assets and data, allowing for almost complete modification of a games assets. Our objective with this system is to provide for and nurture a healthy modding community around our Chaos Engine titles. In the hands of our users, we hope to see a wide range of community made content produced, including mods, fan made characters, new campaigns, and many more.
The Chaos Engine will see its first release soon, as one of several Chaos Engine powered titles that have been in development. We are also investigating the possibility of applying this technology to our existing title, Majestic Nights.
In 2016 Epiphany Games began several porting projects. After a successful port and upgrade of Tiny Troopers Joint Ops for PlayStation 4 (Unity), We began a project to port the PC Indie hit game: Anodyne, published by our good friends at Nnooo.
Anodyne was a complex project to port, as it was built using Adobe Flash, an engine not supported natively on Xbox One and PS4. To achieve this port, we used the Autodesk flash renderer Scaleform. The results of this work culminated in a set of PS4 and Xbox One code that can be used in porting of other flash based products.
This is the Recycling game we did for Planet Ark. This is a great example of a smaller game done in Unity and made completely cross platform. The leaderboard is running on our Birdcage services. The application is hosted on Amazon.
The inhaler wheezed like a dying horse as Ginzsby entered the crowded emergency ward. Freaks, creeps mutants and scum were lined up; waiting to be triaged or bleeding out. The riot had ended with the BG Company agreeing to treat all members of the block ward for free. Berkley Genomics was the biggest heath and genetics corporation in the solar system. They appeared as white knights but underneath, they were sharks taking what they could.
Jeffersons plague was nothing more than a predicted reaction from humans from earth, to the permanent settlement on New Mars. A debilitating disease that wasted the infected and eventually killed them.
The BG Company announced a cure about five days ago, already out of supplies, time and patience the blockers (dwellers of the blocks) had decided to take the cure, that’s where we came in; the Red Dragons. We held positions between the riot and the clinics on levels 310 to 298, a big territory held by a score more gangs. Armed with mono swords, heavy SMGs and occasional RPG we were more than a match for most gangs. Secure in our positions we went around the “job” of extorting, terrorising and running the show until they came and turned most of us into charcoal. Hailing from old Earth, hired goons with hired haircuts; speaking a variety of arcane and forgotten languages like Swedish, German and French none of them speaking Martian street chat.
Armed with lethal weapons like plasma flame throwers, micro missiles, robot wolves and drones. They cut a swath through us all the way to that clinic warehouse. Then those creeps began launching missiles and grenades as if they were children with fireworks for the first 4th of July. The promptly destroyed the supply of Jefferson’s cure, burning the warehouses to the ground.
Like ghosts those black clad mercenaries methodically moved through our turf. Fighting was fierce, we won some they won more; and in the end they got what they came for. That’s why I’m here in the hospital, with my finger in this guy’s belly wound. “Now Hanz, tell me what the fuck you were doing”
It was August 2013, it was raining and I was wearing sunglasses. In a flash I had the vision of an Isometric RPG like game set in the 80’s with all the trimmings. How could I do such a game on a small budget but where we were going we didn’t need roads!
Majestic Nights came about in its early concept the team latched onto it like Indiana Jones snatching a priceless relic. We had come off a big multi-year project, Frozen Hearth, and due to mixed reviews and numerous perfect storm events we didn’t want to enter into the fray with something so massive quite so soon. One year and one month on, Majestic Nights is ready for preview, though as we say: it’s all in the reflexes.
Stick around and I’ll tell you why we did it, what we learned and where we hope it will go. First thing we wanted to do was learn to really tell stories well in games. We had a huge amount of narrative for Frozen Hearth that we didn’t get into that game. Secondly, we wanted to do a smaller project that would serve as a break for a bit for the team. And finally, when you have an idea that ‘feels’ right, and test it and turns out to be good: follow it.
Majestic Nights springs from my love of finding and researching secret information, and this game exposes those secrets in a fun way. And after all, why do us Indies get into something so challenging as making games?
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.
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.
We now have a website specifically for Frozen Hearth, up at www.FrozenHearth.com. This website will host a trailer for the game and includes a contact form. The games looking fantastic, a massive upgrade over the last two months. I can’t believe how much of a difference there is in the game play and visual effects. The core features of the game are working better than ever, which includes Co-Operative campaign for two players. Several modes of play for multi-player, one of our favorites the office is King of Hill a close second by Crucible. Crucible you basically get to fight across the map, capturing towers as you go (after you destroy them) and then you place your own tower there.
This Friday we had some more games, and we now have a handful more multi-player maps. Our lead level designer Ciarán created a really nice One Vs One map based on his home town in Ireland.
From time to time, I would like to share with the community my general thoughts anecdotes and observations. Finding the Fun is a short article about that, it describes where in a games life cycle the creation of the game becomes more than the sum of its parts. Like any creative project, at some point a game becomes an organism with a life all its own, and around this point observing developing behaviourisms from seemingly simple code is one of the most interesting moments in a project. For me this has now happened twice on the Frozen Hearth project. The first time was when I observed one of our developers and Boon, the developer/game designer on Runic Rumble conferring on tactics with another of our developers. While they were doing that, I was updating Hydra and the game and checking out the actual changes to scripts and realised that Sam had nerfed my latest exploit (And why exactly were you in MY Hydra, messing with MY balancing…! – Sam). The fun had been found in the game, and it was found during one of our Friday night testing sessions…
… We were playing for about four hours that night and ironing out what we call ‘de-sync’ errors, however the game was at a point where we could legitimately compete against each other and the stakes had apparently become high between the combatants. This was the point when I knew the game had become more than just the fragments of code and textures running through the computer, it had become Fun. We kept working till around 2am, playing and battling, using Spells and Squads, Abilities and Buildings, and if a ‘de-sync’ occurred we looked for the offending section and fixed it. The game was a Game, and resembled the game that we had set out to make – it had come to life and it was brutal. It’s going to be interesting comparing the game we ship to that game back on that day which seemed rough around the edges and all-too deadly and relatively unbalanced. It keeps getting better as we go, but I will enjoy looking over the changes that has occurred since then.
The next time I was surprised was only last week, when we completed part one of our current AI sprint. Watching our AI fight against itself and see one lose and one win was a great moment. They groped around the map like primitive children, taunting each other and getting into fights with only the most rudimentary commands at their disposal. The two teams-of-two had no concept of casting spells, but they formed their squad groups, marched off to capture points, and got in each other’s way.
AI’s are strange beasts, and coding them is a big task. However, once you get something working, regardless of how primitive, you know that you can get there by taking one step at a time. We focused first on Multiplayer and the AI that supports the player’s units; the inherent behaviours that all units require. Next, we focused on making the path-finding good. Finally, we are focusing on the brains of the beast and like Frankenstein’s monster it’s primitive, strong and scary – and it’s going to hurt people in its quest for survival. The emerging behaviours was deeply interesting, and a few of us gathered around to simply watch the AI in its various guises stagger around the map; a tug of war existed between the two sides as they vied for control of points. At one point, one side was losing, and decided to ‘rage quit’ for a while as Sam put it.
This moment of the computer player of the game moving around on its own with limited knowledge was another moment where we knew we had found the fun in the game.
As Epiphany Games wants to give players an experience in a variety of platforms; one world but many ways of interacting with it, I thought I would take the time to make some points about tools that can assist our vision and bring that experience to multiple platforms. I’ll also talk about how those tools help our projects which are not in the same setting; some of which are revenue sources for our company.
Our goal of cross-platform games requires us to have a higher level of understanding and deeper level of integration than many other companies. We have pushed out many games this year and last year on iPhone and Android; before that we were developing engine technology to enhance our ability to make the games we wanted to make. Early on, we found that to enable a certain level of cross platform development C++ was the language that gave us the most bang for our buck. We have a strong team, well versed in C++ from Frozen Hearth and GameBryo development. Frozen Hearth uses a combination of C++, C#, and LUA script. Our mobile title ‘Runic Rumble’ uses C# almost exclusively because of the engine choice; I would have liked to have the development in C++, but the project was too far along and we decided to stick with C# on Unity.
At Epiphany we also develop many mobile games for companies in Australia and Japan, and on these projects we tend to use C++ to get the project done in a tight deadline. This month we developed three games in two weeks to an Alpha stage using a very small mobile team. These games functioned on both iPhones and Android phones and were skinned with different themes for different levels. Using an objective-C wrapper or a Java Wrapper on the different platforms allowed us to release the games at the same time on the different platforms. When we partnered with Flat Earth Games, and we are using the same cross platform techniques in this development and I think it will help us a great deal. The project is really cool and we are making some great progress, and I think our approach is going to help Flat Earth Games and ourselves get the game out to a variety of platforms and market places. The next step for us is to take some of our free games and our paid Android games to the various market places; we use is a company called Codengo to deal with the plethora of mobile stores. For the App Store we must still submit ourselves.
One of the hardest and most time consuming components of mobile development is submitting your game to a store for review and then tracking the results across stores and sectors, there are many stores that game developers never even think of like the Samsung store. Codengo is a new distribution service that puts the mobile submission and tracking of games in the hands of the developer, for a small fee and no percentage of the games revenue Codengo will submit your game to over ten stores, Google Play, Samsung and others. The service can track the results consolidate the marketing material and within a few clicks your game is submitted across the world to a variety of market places. Codengo isn’t free; however the benefits of a one-service submission will be attractive to cross platform developers who distribute in multiple markets.
By using this cross-platform approach we hope to service our customers on both platforms, in a variety of market places, and enable them to experience our games in a variety of ways. I really think this cross-platform approach services our customers better because we can give them a variety of experiences on multiple platforms. It’s imperative that all Australian Game developers look at how they are dealing with multiple platforms because the need is never going to disappear.