Kickstarter for this is live...
And wow... this seems ridiculously ambitious. I so want an MMO like this to exist, but how can a small team pull this off? And for only $900k?
I'm tentatively in for $50 early bird tier - but I might still pull out if I come to my senses.
I really think they should start trimming down features now to make this even possible to do.
Not every sandbox MMO/RPG has to be harsh. I've much preferred MMO's like Wurm Online and Mortal Online and Xsyon with PvP, but that doesn't mean I don't want Minecraft or a more accessible/friendlier sandbox to exist. I just don't want them coming to my MMO and bitching like children. Live and let live should be the standard we strive for. We're all differnet and should respect that.One thing I don't like about it so far is that SJW is strong within' the community. And there are a lot of carebear role players. If they want the game to really suceed, there must be some risk behind everything, otherwise it would be boring.
Cautiously optimistic, just as you are.
Did we all learn nothing from Scam Shitizen?
I followed this project and had some hopes for it. They are not aiming for the skies like Star Shitizen does, but still they try to milk their playerbase by just showing some models/pretty graphics from time to time.
"We legitimately spent more time on reworking the engine than working on the game, and I wish we had just made one from scratch in the first place. Here's high hopes for that with Tera 2!"
SpatialOS, self-stated "fabric of the game", is dropped due to "financial viability".
When talking about an MMORPG - or as we like to call games like Chronicles of Elyria, a Multiplayer Evolving Online World (Meow!) - there’s nothing more foundational than the back-end server. The back-end server is responsible for managing the entire state of the game, performing all the necessary computations for systems like AI, physics, pathfinding, and combat, and for receiving and processing all the input for, in the case of CoE, hundreds of thousands of connected clients. In January of 2017 we began the long process of taking what was mostly an offline, single-player game – designed primarily to validate user experience and gameplay feel – and turn it into a MEOW (what can I say, the Internet loves cats).
The process of building a scalable, reliable back-end server with all the gameplay mechanics for a game like Chronicles of Elyria can be divided up into two primary components. There’s the platform, necessary for providing infrastructure such as entity and state management, fault tolerance, load balancing, and a method of cross-process communication, and then there are the services or workers that are responsible for performing all the actual gameplay logic and processing the user input of all the clients.
Shortly after we announced development of Chronicles of Elyria we started looking around for ways to solve the typical problems associated with building a large, distributed simulation. In short, we were looking for ways to speed up development of the platform. As part of our research we got in contact with Improbable and as a first effort at bringing our game online, we began integrating SpatialOS in January of 2017. As a test, we built our own PhysX simulation in SpatialOS which, when integrated with our Unreal Engine 4 (UE4) client, allowed us to move around the world using our own custom physics engine in a way that provided all the benefits SpatialOS has to offer.
But, then we started encountering some issues. First, while SpatialOS provided load-balancing and fault tolerance for all our spatial workers, there were still many workers that were not spatial in nature. Workers such as our authentication and login server, our AI system, and our Procedural Story Engine. For these, we still needed our own load balancer, fault-tolerance, and cross-process communication. So, we began researching different technologies that, while not a single solution, would provide the scalability, reliability, storage, and communication benefits normally provided by SpatialOS.
Second, we started to have some concerns about the financial viability of SpatialOS for our needs. Whenever you use SpatialOS you're also signing up to have your game hosted by Improbable. That has the benefit of lowering operations costs, but has the drawback of passing all the hosting fees they pay to their cloud partner onto us. It also means we don't have the ability to choose a hosting partner - whether cloud, bare metal, or dedicated servers that meet our performance needs. And CoE has some very specific needs! In specific, our use of Offline Player Characters (OPCs), the extremely large size of our world, the vast number of entities in the world, and the way we divide our game server up into dozens of different worker types meant that SpatialOS was particularly expensive for our use-cases. Our philosophy has always been about keeping our hosting fees low so we could pass those savings onto you. With SpatialOS, our hosting fees would have been more expensive, which would have forced us to increase our prices - something we didn’t want to do.
Of course, we brought our concerns to Improbable, and over the last eight months they’ve done a fantastic job working with us to try and bring the price down. Unfortunately, it remains an expensive solution for us. To make sure we were prepared, we began looking for alternative technology that could fill any gaps left behind if we were unable to use SpatialOS for any reason.
As we had already started leveraging Docker Swarm, a Container technology for load balancing and fault tolerance of our non-spatial services, we knew we could transition to a full Docker stack if necessary for our spatial services as well. When we realized we were going to need to communicate between our spatial services and non-spatial services, we integrated RabbitMQ into our back-end, a super fast routing and message protocol used to serve 10's of millions of requests by banks and other high-traffic websites across the internet each day. And because we needed persistent storage for all our non-spatial data, we integrated PostgreSQL into our backend. Fortunately, PostgreSQL supports SQL, NoSQL, and even spatial queries, enabling it to act as a backend and persistent storage for both our spatial and non-spatial data.
As you can see, our non-spatial services required a large part of 2017 to be spent getting our core stack set up and creating the necessary components to have our own, proprietary platform. And because we were concerned about how things would end up with SpatialOS, we continued to make progress on these areas within the Soulborn Engine throughout 2017. In fact, we went to PAX West this year and showed off our jousting demo. This was the first time we'd taken a multiplayer demo to PAX since our combat demo back in 2016, but unknown to many, the Joust Demo was running on a locally deployed version of the Soulborn Engine. This means that everyone who played the jousting demo at PAX West has already played on our new server stack.
And finally, in December 2017, we released Version 0.1.0 of Chronicles of Elyria to our “Friends and Family”. This was the first time offsite users were able to play Chronicles of Elyria. Again, the milestone was completed using an entirely Soulborn-based game engine. So, what does this all mean in a nutshell? It means that in 2017 we began by using SpatialOS, and ended with something that, while not a single solution, does everything SpatialOS did - ultimately providing us all the same functionality as SpatialOS, while allowing us to keep our operating costs low and providing us more control over our server performance. With the transition complete, we’re now ready to move forward with more core gameplay mechanics in 2018.
Quotes from Caspian on discord
We use Docker. Our initial implementation was with Docker Swarm, but we're likely moving to Kubernetes.
I'd considered the Mesos platform as well. DC/OS has some nice features, but there seems to be more complexity than we need.
Kubernetes is, so far, the right balance between Swarm and DC/OS.
We're also doing R&D on various programming languages for our service mesh.
There's a couple service mesh implementations out there that utilize a sidecar implementation. We're experimenting to see if that'll be efficient enough for us, but I don't think it will. So we're looking to integrate some of the sidecar features into our service hosts so we can get the same functionality: discoverability, short circuiting, g/b deployments, etc. without the performance cost of a proxy server.
The two main ones right now are the Linkerd proxy (Rust) and Envoy (C++). I've been experimenting with both.
Our first implementation used RabbitMQ as a pub/sub messaging protocol. We're experimenting with alternatives right now.
Heh. Ok. I'm done talking tech. Don't want to alienate people. The TL;DR is: we're experimenting with other programming languages and environments for our gameplay mechanics and platform in order to create a more efficient, scalable world and platform. Things are coming along slowly on that front, but will pick up shortly.
We're doing investigation into using C++, C#, or Rust now for our platform. We were previously using NodeJS, but the process overhead and large memory footprint of NodeJS made it unsuitable for the large scale world we're creating.
There's pros and cons to all three languages. C++ is fast but takes longer to develop in. It's also prone to mistakes. Something like 70% of all security hotfixes at Microsoft were due to buffer overrun or pointer mismanagement. However, we use UE4 for our client, so having our platform also built entirely in C++ would allow us to minimize domain knowledge.
C# is fast enough now. But it does have a slightly higher memory footprint than native languages, and even in server GC mode, can still create unexpected hiccups in execution doing garbage collection. But everyone on the team can develop in C# pretty quickly, and as about 50% of all games being developed now are in C#, it's really easy to find new people. But, it's harder to interop with UE4 and we just aren't certain yet whether the memory and GC will be a problem.
Rust has the performance benefits of C++, without the instability or security issues. It can be used with both C++ and C# with a 'C' extern library, but it requires a bit of overhead to do that. Rust is arguably the language of the future, game development in general, but it's the language the team is the least familiar with, so it comes with a learning curve.
At the end of the day, we know we need to port our infrastructure to a new language and platform to reach the scalability we want, but it's a tradeoff between performance, security, staffing, and time-to-market.