Skip to Content

archive

Monthly ArchivesMonthly Archives: December 2016

post

Realm Explorer vs Realm Engine

realmenginevs

As I’ve mentioned a few times recently we have a code base for our own proprietary multiplayer RPG / sandbox engine called Realm Engine.  We’ve created this as a generic server-side game engine but we’re using it exclusively for Realm Explorer right now.  Our server technology has evolved numerous times throughout the alpha period.  The server code used for the very first release was extremely primitive in comparison to our current code base.  The pre-cursor to Realm Engine was released several versions ago while the code was still tightly integrated for Realm Explorer.  Further refactoring helped us to fully realize the goal of creating Realm Engine as a unique standalone server technology that we could build our games against.  As of right now the current internal build of Realm Explorer is built entirely on Realm Engine.

Early on we had a goal (both philosophically and due to technical considerations) to make our server technology independent of Unity.  We use Unity3D for the client side (rendering, handling user input [keyboard and mouse input], playing sounds, playing music, etc.) but our server technology was developed to exist outside of Unity.  One of the reasons for this was that when we started working on Realm Explorer Unity’s 64bit support was hit or miss (and the Unity editor itself was 32 bit).  This meant that we were limited in how much total memory we could use.  The Marching Cubes algorithm we were using for the terrain would use a lot of memory and was difficult to try and handle situations where multiple players could be in completely different parts of the world.  Having 1 player with terrain loaded around him would already use of a lot of memory – having a dozen players each in different parts of the world all needing their surrounding terrain loaded was essentially impossible!

Don’t get me wrong – Unity is an incredible piece of technology but we knew that we would need a high performance and light weight solution for implementing the server code and all of the RPG/Sandbox rules for a truly huge world with support for a large number of simultaneous players.

The benefit of rolling our own server solution was that we could have complete control over every aspect of it.  We also make extensive use of dynamic data loading/unloading, multithreading, dynamic runtime script compilation, implementation of API endpoints for further third party integrations and support and several other big features. The downsides (aside from having to create such a program from scratch) included not being able to leverage some of Unity’s powerful features (in particular anything related to 3D geometry, physics, collisions and so on).  Over the past 2 weeks we’ve had a fairly major paradigm shift.  Let me elaborate.

Previously we had our game client done entirely in Unity and our server technology as a series of separate C# .NET projects making up the server application.  We had some common code libraries that both the client and server would share but otherwise these two programs were independent.  Since Realm Engine is pretty mature at this point the major goals we set out for it have been mostly accomplished.    The big change that’s recently come about has been that we now host Realm Engine inside of Unity on a separate thread from Unity.

You might be saying to yourself, “Didn’t you just tell us why you created Realm Explorer as a separate program to live outside of Unity???”.  Why yes, that’s correct.  We’re now at a point where Realm Engine is able to do its heavy lifting very efficiently and having worked with it so long we can clearly see where and how we can leverage a direct interface with the Unity engine to further improve several things.  Over the past few weeks I worked through all of the integration work so that we could spawn a dedicated server process inside of Unity.  The next step (which is almost done) will be to create a communication layer between the Unity engine and Realm Engine.  This way they can both run separately but marshal commands and information about objects between each engine.

Aside from being able to now get some useful information that we haven’t been able to have on the server before (such as collision between objects, performing accurate raycasts on the server side and so on) this also gives us a huge leg up on how we’re handling our dynamic infinite terrain and building construction.

Oh no it looks like we’re out of time for today.  We’ll get into the details of terrain generation, biomes, lakes(??), rivers(?!), caves and dungeons(?!?!), AI (!!!) and more in future posts as we work towards another alpha release (speaking of which, the current plan is to only provide new builds [when they are ready] to people who picked up the game during the brief alpha period – Realm Explorer won’t be posted for sale again until it’s ready!).  For now I’ll be continuing with finalizing the Realm Engine -> Unity integration and the engine-to-engine communication layer.

In my next post I’ll likely be taking a look at new building and house construction.  Maybe a new video for this?  That’s all for now!

post

100 Programmers or more?

rs

A question that I get fairly often is, “How many people are working on Realm Explorer?”.  Gabriel pointed out to me recently that when I respond to emails like this I usually come across sounding really formal and corporate.  The truth is our team is small.  How small?  Well, Gabriel and I are the only two programmers.  I created most of the game functionality, the majority of Realm Engine (our proprietary moddable multiplayer server engine), most of the game client features, the scripting / mod system and the majority of the networking code, etc.  Gabriel has done an incredible job creating virtually 100% of our UI (including making it skinnable / moddable), tons of user-interaction stuff (all of the special behaviors for drag and drop inventory, smooth transitions for chat messages, beautiful styling and so on).  Gabriel also does all of our web stuff (including RealmSource .NET account creation / account management, game key management, player sessions, password recovery email functionality and all of that good stuff).

We also work with a long-time associate of ours (who I’ve had the pleasure of meeting on several occasions now despite us living on completely different continents) ArmedBee who helps get us the artists we need to do specific projects — everything from 3D modelling, animation, concept art and more.  Without his help the in-game graphics would probably be a couple of 3D blocks moving around the screen (backed by our super powerful multiplayer RPG engine, of course).  ArmedBee has also helped with a lot of technical aspects of setting up art content and working through the workflow of setting up new visual features.

As of right now… that’s everyone!  We’ve had a few others come and go over the years contributing pieces here and there but the majority of artwork and code that we’re using right now has been the result of the continued efforts of the three of us.

Having said that there are a lot of people I would love to work with in the future (on the music side especially!  I’m a huge fan of great game music) but I firmly believe in making sure people get paid for their work.

That’s all for now.  Check back next week for some news on recent work on Realm Engine integration and other technology improvements that are letting us do more great stuff!