Note: Quoted from @Hal9007
I understand more than a few of you may be interested in knowing what progress is being made toward Unreal Engine 4, and whether it stands as a potential platform for future RPG development or not. I've been focusing heavily on this topic over the last few weeks, and I've begun collecting information to assist in making a decision. The first section is directed toward staff, and the last bit toward coders.
To be clear, the outright reason for using Unreal Engine as a platform does not involve graphics, but rather the ease of implementing a variety of MMORPG elements using a toolset that is directed toward that goal. I doubt that any gains would be made graphically if we intend to target performance similar to that seen in Minecraft. With that said, here are a few general pros and cons (as requested) on the matter:
Pros:
= Less conformity to an existing server-client model, more ground-up writing to our own needs.
= Unreal Engine is open-source (after purchase), allowing for modification of the toolset itself.
= An implementation of our own client tracking system, separated from MC servers.
= Utilization of several existing RPG blueprints made by the UE4 community.
= Separation of the RPG and development clients; less clutter between server and client.
= Access to large amounts of disk memory on the client side; less server strain.
= Ability to decide how data gets passed and prevent packet manipulation.
= Access to physics and creative art design for instances (collapsing structures, etc...)
= Potential to ship to different platforms (consoles and mobile, though not likely).
Cons:
= Reinstating whatever game logic we intended to utilize from vanilla Minecraft / mods.
=Unreal Engine 4 is proprietary, costing $19 per access to source (coders, basically).
= Rewriting some of the code that has already been written toward the RPG.
= Potential subservience to MC's legal measures, depending on how world data is used.
= Unreal Engine does not have direct models for MMO's, only third-party plugins.
= Separation of the RPG and development clients; world changes are pushed slower.
= Depending on future UE4 development, support for Linux is in a grey area.
= Animations must be created and laid down for new entities and features.
= A new set/type of world data will likely need to get created specifically for the RPG.
The obvious obstacle up front is in creating the world itself within Unreal Engine 4. For a while, I was stumped on this front (with a few of my own attempts), until I found an interesting project called BrickGame. I was pretty fascinated by how closely the source interacted and overrode Unreal Engine, so I got in contact with the creator, Andrew Scheidecker, and was even more surprised to find out he was the lead graphical programmer for Unreal Engine 3 (before leaving the company). Here's an example of his BrickGrid plugin at work:
If you're not a coder, there's not much point in reading beyond this point, but I'll go more in-depth about a potential server-client model.
After conversing with Andrew over the Unreal forums for a bit, I've started to grasp how world data is handled and optimized at render time. There are a only a few sections of his plugin that would actually need to be overridden, primarily the world generation. At the moment, regions are initialized based on a noise pattern, and mesh optimization is only done with the standard cube model in mind. Because the relationship between client and server is more pertinent to our potential use than the current 'single-player' BrickGame model, I queried Andrew with my own server-client model, and he offered me a few pointers on how the plugin would integrate. Here I've drafted a general model of the flow of logic that occurs between each tick on the server-side and on the client-side:
These ticks are entirely asynchronous, though I've drawn the transfer of packets across to demonstrate where the respective packets would be utilized on either side of the model. Many of the things currently being done on the server side were previously done on the client side within the base BrickGrid plugin, and the current model isn't too far off from Minecraft's own. A large part of the optimization done here is in pushing huge amounts of hashed chunk data onto the client in the form of dynamic disk memory, which subsequently allows the client to query this cache and reduce packet transfer from the server.
That's about it for now, though I'll elaborate where I have to.
I understand more than a few of you may be interested in knowing what progress is being made toward Unreal Engine 4, and whether it stands as a potential platform for future RPG development or not. I've been focusing heavily on this topic over the last few weeks, and I've begun collecting information to assist in making a decision. The first section is directed toward staff, and the last bit toward coders.
To be clear, the outright reason for using Unreal Engine as a platform does not involve graphics, but rather the ease of implementing a variety of MMORPG elements using a toolset that is directed toward that goal. I doubt that any gains would be made graphically if we intend to target performance similar to that seen in Minecraft. With that said, here are a few general pros and cons (as requested) on the matter:
Pros:
= Less conformity to an existing server-client model, more ground-up writing to our own needs.
= Unreal Engine is open-source (after purchase), allowing for modification of the toolset itself.
= An implementation of our own client tracking system, separated from MC servers.
= Utilization of several existing RPG blueprints made by the UE4 community.
= Separation of the RPG and development clients; less clutter between server and client.
= Access to large amounts of disk memory on the client side; less server strain.
= Ability to decide how data gets passed and prevent packet manipulation.
= Access to physics and creative art design for instances (collapsing structures, etc...)
= Potential to ship to different platforms (consoles and mobile, though not likely).
Cons:
= Reinstating whatever game logic we intended to utilize from vanilla Minecraft / mods.
=
= Rewriting some of the code that has already been written toward the RPG.
= Potential subservience to MC's legal measures, depending on how world data is used.
= Unreal Engine does not have direct models for MMO's, only third-party plugins.
= Separation of the RPG and development clients; world changes are pushed slower.
= Depending on future UE4 development, support for Linux is in a grey area.
= Animations must be created and laid down for new entities and features.
= A new set/type of world data will likely need to get created specifically for the RPG.
The obvious obstacle up front is in creating the world itself within Unreal Engine 4. For a while, I was stumped on this front (with a few of my own attempts), until I found an interesting project called BrickGame. I was pretty fascinated by how closely the source interacted and overrode Unreal Engine, so I got in contact with the creator, Andrew Scheidecker, and was even more surprised to find out he was the lead graphical programmer for Unreal Engine 3 (before leaving the company). Here's an example of his BrickGrid plugin at work:
If you're not a coder, there's not much point in reading beyond this point, but I'll go more in-depth about a potential server-client model.
After conversing with Andrew over the Unreal forums for a bit, I've started to grasp how world data is handled and optimized at render time. There are a only a few sections of his plugin that would actually need to be overridden, primarily the world generation. At the moment, regions are initialized based on a noise pattern, and mesh optimization is only done with the standard cube model in mind. Because the relationship between client and server is more pertinent to our potential use than the current 'single-player' BrickGame model, I queried Andrew with my own server-client model, and he offered me a few pointers on how the plugin would integrate. Here I've drafted a general model of the flow of logic that occurs between each tick on the server-side and on the client-side:

These ticks are entirely asynchronous, though I've drawn the transfer of packets across to demonstrate where the respective packets would be utilized on either side of the model. Many of the things currently being done on the server side were previously done on the client side within the base BrickGrid plugin, and the current model isn't too far off from Minecraft's own. A large part of the optimization done here is in pushing huge amounts of hashed chunk data onto the client in the form of dynamic disk memory, which subsequently allows the client to query this cache and reduce packet transfer from the server.
That's about it for now, though I'll elaborate where I have to.

Last edited: