WesterosCraft Unreal

[Iwan]

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.

 

[Iwan]

Note: Quoted from @LucasMoran5

Interesting stuff! One question I do have is, which language will this largely be written in? To my understanding, UDK has its own scripting language, but you can also use C/C++. So I'd guess C++?

 

[Iwan]

Note: Quoted from @Hal9007

Yes, Unreal Engine 4 works primarily in C++, through which you can interface with most other languages. However, this isn't UDK (which is Unreal Engine 3), so UnrealScript has since been removed. In its place is a convenient system of 'blueprints', which is essentially a form of visual scripting that compiles directly to bytecode. For example, here is a blueprint which rotates an object on user keystrokes:

https://answers.unrealengine.com/storage/temp/4901-working_rotate_over_time.jpg

 

[Iwan]

Note: Quoted from @LucasMoran5

Ah ha! I've actually seen this visual scripting before, but never used it. I'd imagine common things such as handling camera rotation with keys or a mouse are part of a standard library?

 

[Iwan]

Note: Quoted from @Hal9007

Yep - the node library is fairly large; there's outlets for cameras, actors, events, lighting, time, etc., as well as all the standard logic (and, or, not, for, while, etc.). If what you need isn't there, you can write a new C++ class and set it up as a blueprint node. It's essentially a really quick way to pass parameters between C++ classes / methods.

Digging through the documentation can get pretty difficult, but it's the ideal way to implement game logic.

 

[Iwan]

Note: Quoted from @mikeprimm

While I love the idea of using Unreal Engine 4 - I've really enjoyed messing with it so far - I cannot help but point out that the amount of game logic, presentaiton content, and the like that we're talking about needing to reproduce (for this to be a migration, versus a new, start-from-scratch project) is rather huge. We're talking hundreds of thousands of lines of content, between vanilla game logic, the bukkit-style server administration content (security, access and action control, etc), very involved MCPatcher-derived presentation logic, world editing, map presentation, etc, etc. If we work a world migration pipeline, so that the UE4 world data is generated from the MC-based world data, it helps with some things (the need for in-game and out-of-game world content creation can be salvaged) but hurts with others (we're still stuck with the limitations of creating world content 'MC style', and essentially need to create much of the code logic for it twice - once for the 'creative' MC version, and once for the corresponding actor in UE4). If we don't do world migration, we're essentially doing the whole project from scratch - for better or worse - and we're essentially losing all our existing content and existing mods (both of our own authorship, and that of other folks), but we're gaining the option to do things unfettered by the limitations of an MC-based game.

My concern, with either scenario, is just how many person-months of full time development work we'd likely be looking at just to get to 'break even' (not so much with how pretty it would look, but more with existing client and server-based functionality and game logic). We're honestly in a position where it'd be quite hard to just move off of a Bukkit-based server to a purely Forge based server (even with the Sponge project), just due to the quantity of plugin/mod logic that we'd need to rebuild ourselves - and we're probably still going to need to do that to get beyond 1.7.10, since it doesn't appear that Cauldron (or the other Bukkit+Forge server solutions) are being carried forward beyond that.

In any case, while I think there is a lot of appeal to doing this, I just want to be clear that I'm 99% certain that those reasons cannot include the notion that it would take less time or less effort than the sticking-with-MC based alternatives - although the appeal of a fully top-to-bottom custom-to-our-needs-and-goals system certainly is there. In particular, a UE4 based game would certainly be stronger for things like PVP experience (for which MC is notoriously poor) and player/mob/environment graphics quality. Other elements, like much of the gameplay logic and such discussed in the MMO documents, would likely be a wash (once we get done re-creating the existing game logic inherited from things like WorldGuard, Essentials, and the like) - no particular reason to believe that a UE4 implementation would be more easily accomplished, since the associated logic and support isn't something that the UE engine offers specific advantages with implementing (unless its something easy enough to express using Blueprint).

 

[Iwan]

Note: Quoted from @Hal9007

I agree; given the uncertainty going forward, I left both graphics and man-hours out of the comparison. And while I have little doubt that UE4 won't break even with the current development - I'm far more interested in what mechanics Minecraft reasonably cannot offer. Dedicated RPG servers in Minecraft are as rampant as they are sporadic, and I often wonder how far one needs to go to "stand apart" from the masses. The builds achieve this to an extent, but aren't truly contributory to maintaining a stable playerbase when it comes down to the gameplay grind. It is for this same reason that I question the pursuit of Minecraft-esque logic in crossing over to a different platform.

I won't say much more on it; there's quite a bit to consider already. Even if we should decide against it, I will continue to extend on the UE4 platform, as it bears intriguing potential to future Minecraft endeavors and servers.

 

[Iwan]

Note: Quoted from @Thamus_Knoward

Hm. Realistically, Mike & Hal, what do we need in total. Can we get a detailed assessment of the workload that would await us to achieve a break even. Some sort of approximated quantification including numbers of people we need permission from, lines of code, MB filesize, approximated rates of conversion (100 lines Java to C++)? If we knew the exact extent of what we're in for we could better assess the situation, and perhaps invest time (or budget) into gaining the necessary resources/ manpower. So, that before we delve further MMO Dev, we can come to a definite conclusion on the platform we wish to use.

Perhaps, once we have evaluated these steps we could run a PR/ "Hiring campaign" directed to those coders out there that enjoy the challenge of transporting logic from one system to another to help us with this?

 

[Iwan]

Note: Quoted from @mikeprimm

We would need to discuss a few items relative to how we would want to target content creation on any UE4-based client implementaiton: its probably the biggest 'X factor' on any notion of how to define and size this beast. In particular, relative to (say) what would classically be referred to as 'level design'. Our MC legacy gives us a viewpoint on this subject which is quite distinct from what would be typical of a game production pipeline of the sort UE4 is most oriented around. In broad strokes, I see the following general approaches:

1) Classic UE4 style level design - the world and its content are created using UE4 tools (and possibly custom value add tools, such as (for example) a port of WorldPainter to generate UE4 level content), This all involves something very unlike our existing system, where the world is primarily defined by in-game activities. Upside is no limitations associated with the legacy MC design - the world doesn't need to be lots of blocks limited to a rectangular 1 meter grid for placement, objects can be developed as modules at whatever level you want (sections of landscape grids, full trees as objects, full buildings as objects - somewhat akin to what we wind up doing with WE templates), custom behaviors can be tied to objects on their own (akin to what MC allows with redstone, but without the fuss of building and hiding the redstone machines), etc. Downside is loss of all existing assets, and of the in-game and collaborative world creation process we currently enjoy. Skill development associated with the out-of-game asset development is also a concern.

2) Legacy MC-style level design, with development of sophisticated migration mechanisms to allow translation of the MC-based world data into something usable for UE4. This would be more than just a mesh translator - the content of the world is both passive (static unchanging landscapes and structures) and active (doors that open, furnaces and crafting tables that players use to build items, fires that burn folks, etc). We'd likely be talking about developing custom actors within UE4, and having the mapping/translating tools tailored towards mapping the blocks in MC to appropriate corresponding actors in UE4 (where the actors might be largish static meshes representing lots of inert content, or might be individual doors or furnaces or the like). World content always consists of a combination of presentation and behavior - we've previously focused on the notion of migration of presentation, but the defining characteristic of the MMO client/server setting would make behavior at least as relevant. This is the case I suggested above with, at some level, double development - its not COMPLETELY double, since the functionality of the creative-oriented block in the MC side doesn't need to necessarily be the same as the function on the UE4/MMO side - presentation demand are similar, but blocks that are passive in the MC side but active on the MMO side might not truly involve a full doubling of effort to build and support. In any case, the resulting MMO world content would necessarily still have many MC-like presentational and positional characteristics (otherwise, the act of visual design from within MC of the level would be compromised) - but could allow us to leverage existing asset investments (that is, the world we've already built and continue building) and existing world development methodology.

3) Classic UE4 style level design PLUS in-game UE4-based level design. This can also be described as 'building a whole new MC-like builder and MMO game'. For good examples of this, take a look at something like Space Engineers (

), Rust (

), EverQuest Next (

), Masterspace (

), Terrayn, and the like.

 

[Iwan]

Note: Quoted from @Hal9007

Thamus_Knoward
wrote:
Hm. Realistically, Mike & Hal, what do we need in total. Can we get a detailed assessment of the workload that would await us to achieve a break even. Some sort of approximated quantification including numbers of people we need permission from, lines of code, MB filesize, approximated rates of conversion (100 lines Java to C++)? If we knew the exact extent of what we're in for we could better assess the situation, and perhaps invest time (or budget) into gaining the necessary resources/ manpower. So, that before we delve further MMO Dev, we can come to a definite conclusion on the platform we wish to use.​

This is a difficult question to answer without having a significant amount of reference material to work off of, but I'll attempt to answer it from the top all the way down (this post is going to be really damn long). One of the larger factors associated with determining the amount of workload in Unreal Engine 4 is the community that exists behind it, and what we can derive from existing work (not unlike our current use of MCPatcher, WorldEdit, VoxelSniper, etc.). For this reason, I'm going to point to these outside opportunities as much as possible, and you can expect requests of permission from most all of them. I also want to note that lines of code and rates of conversion are heavily based on libraries that are available, so it's pretty hard to make guesses for them. Though you should probably just expect 100 lines of Java to be 100 lines in C++.

The first and foremost problem, as Mike points out, is the method of content creation employed in Unreal Engine 4, because that ultimately affects every other factor that gets implemented. Minecraft allows us to reference an existing model that we know is effective in terms of user collaboration and development, but the immediate difficulty encountered with Unreal Engine is that it's a game engine, and not something written entirely with voxel logic in mind. If we were to make a definitive decision on a content pipeline:

mikeprimm
wrote:
1) Classic UE4 style level design - the world and its content are created using UE4 tools (and possibly custom value add tools, such as (for example) a port of WorldPainter to generate UE4 level content), This all involves something very unlike our existing system, where the world is primarily defined by in-game activities.​

Unlikely. Not simply given the extent of current world development, this option would require a lot of rewriting of complex world generation tools which would almost certainly extend the development time unnecessarily. There's also the problem of Unreal's asset system - it allows for a much simpler editor workflow, but is isolated to just that: the Unreal editor. If we intend to have collaborative development of the RPG completely exclusive of the editor (which is the only scenario I can imagine - there's too much in-game content that can't be transferred directly to UE4 from Minecraft), then it is most likely in our best interest to leave out the UAsset system for anything more than the materials and basic block meshes that are fed to the client notwithstanding any additional RPG elements added by users. Level streaming based on UAssets is natively incorporated into Unreal Engine, but is heavily based on world volumes, which is a complex undertaking and easily not worth the time. Where this style of level design is viable (and opens up several possibilities which MC objectively does not) is in the creation of instances, where the separation of meshes and objects by UAssets might allow for more ambitious gameplay scenarios in smaller sections of the world.

mikeprimm
wrote:
2) Legacy MC-style level design, with development of sophisticated migration mechanisms to allow translation of the MC-based world data into something usable for UE4.​

Probably. This is much more akin to the modular system that would allow us freedom from Unreal editor and its own development sphere. Given that BrickGame (as mentioned in the OP) works under a similar but different logic, this would be the way to go in terms of reconstructing world data without losing any of our previous world data. There are two ways to handle the world data: parsing directly from the standard MC NBT format or having a data crawler translate sections of the world data to a new format that is more configurable for the RPG. Of these two, the latter is more reasonable, as it possibly prevents having to entirely reimplement something as complex as the connected textures mod, and also allows the "active blocks" (anvils, doors, etc...) to be handled separately. However, the tradeoff for this is almost undoubtedly a larger world size (which in itself becomes a problem when considering the transfer of packets from the server to the client). However, I do disagree on the notion of having passive blocks in MC that are active or modified in UE4 as a form of development, as it doesn't strike me as particularly efficient. Ideally, the world data should remain relatively 1:1 - make any changes and I expect we'd start facing conflict between voxel logic and "largish mesh" logic.

mikeprimm
wrote:
3) Classic UE4 style level design PLUS in-game UE4-based level design.​

Perhaps, but only the latter of the two. I've already mentioned the problems associated with UE4 level design for a large open world like this - as a default, Unreal Engine isn't readily equipped to handle massive worlds without some form of asset streaming based on preset load volumes. Traditional MMOs use this, to my knowledge, but were also created with streaming volumes to begin with, which is a tough act to follow. The latter point of UE4-based level design is what I see as the most reasonable pipeline for RPG development - work within the scope of the Unreal editor to develop an RPG-editing client through which a dedicated RPG team can populate the server with UActors.

With my current observations, this is the way to go, essentially rounding down to MC-style level design with in-game UE4-based level population. Though it should be clear that any form of MC-style level design should be isolated to the world data and be more or less separated from placement of UAssets - they natively save to vastly different formats and it probably isn't worth the effort attempting to force information of both types together (though I assume Minecraft doesn't attempt this either).

 

[Iwan]

Note: Quoted from @Hal9007 [cont.]

Returning to the topic of workload, BrickGame and its corresponding BrickGrid plugin are brilliant pieces of code and essentially solve the heavyweight problem of completely rewriting Unreal Engine's scene handler and rendering several million blocks on the user's screen in less than 30 milliseconds. To be honest, I believe it's the one thing that gives us a real shot at using Unreal Engine - without it I wouldn't have given the notion a second thought. The creator of the plugin is routinely available, has more experience with Unreal Engine than nearly anyone else in the community, and has already responded to my request to utilize the BrickGame framework. The amount of code in there already is pretty significant, and combined with its interaction with features already existing within UE4, it essentially makes up the core of Minecraft a.k.a. Minecraft in alpha 1.0.0. Obviously, this leaves nearly everything above to reimplement, but the important factor here is nearly. While I make no claims as to the ease of implementing features in Unreal Engine 4 over a different platform, our RPG is essentially Minecraft without some key features of MC development, including but not limited to redstone and actual modification of the MC-based world data (I'm aware of the planned RPG mines, but instances allow for separated logic). With this in mind, I'll break down some of the features that are missing from BrickGame:

Connected Textures: Difficult. Probably the most difficult thing to implement client-side during generation of the regions. To be honest, I haven't looked much into how connected textures works at the code level, but I assume it's on the order of several thousand lines of code, as it seems rather complex at the upper level. Honestly, it seems rather expensive to apply (checking each of the neighboring blocks around a CTM block). One particular way around this that I foresee is having the same tool that pushes MC world data to our desired format have a two-step process composed of identifying the mesh of the CTM block at a position and supplying the values associated with the current textures of each of its respective faces. This also seems like a rather ambitious undertaking, but it already seems to come into play with Mike's modified jmc-2-obj exporter (which I assume works off of Dynmap). However, this sacrifices world data at the sake of not rewriting CTM logic, perhaps on the order of five times bigger than the current region file data as a happy guess.

Water: Difficult. I didn't consider this one at first, but the behavior of water as an "active block" in Minecraft also appears rather complex. Again, if we use the same mesh identification and texture application as mentioned above, this might be relieved to an extent, but I might also mention that water takes up a good portion of the map, and it wouldn't really be space-efficient to mark each and every water block as adherent to CTM behavior. Perhaps only surface level blocks could be considered (having random wave textures anyhow).

HUD / User Interface: Easy. Certainly no harder than its counterpart implementation in Minecraft, this is an area where Unreal Engine 4 really excels. Well over a hundred blueprints exist for customizing the user HUD and interface, and a huge amount of work can get done relatively quickly. I might as well include the minimap as part of this - BrickGame does implement a Z-depth pass when initializing each of its regions, which can be used to send top-level block information directly to the client's minimap.

Weather: Easy. Despite being triggered server-side, the actual blueprint implementation of this would be, as expected, client-side. And several blueprints do exist for weather systems. I don't expect we'll have some of the same difficulty as experienced in Minecraft, with rain and snow being handled with the same Z-depth data as mentioned above - Unreal collision meshes are generated alongside the scene proxy, and UE4 also does exceptional handling of particle effects and physics.

Server Model: Difficult. Probably will be any way we attempt it. Socket programming isn't exactly rainbows and sunshine, but luckily we can cut back on a lot of the features of a traditional Minecraft server, namely the lack of immediate edits to the world data (given that "active blocks" remain in a separate category). The server still carries a lot of weight, however and the real killer is in handling the NPCs that move around the map. Server-side logic for NPCs tends to be as lightweight as possible, but lightweight doesn't mean short - there's a lot of work involved in generating nav meshes for NPCs and having them go on their merry way without getting stuck in a hole. Hopefully, the lack of full blown MC features will roll back server strain, if it can be helped. There are existing MMO plugins for Unreal Engine 4, but it's only a handful and most are proprietary for access to source. However, the head of Epic Games, Tim Sweeney, claims that the UE4 dev team is working on porting the Atlas MMO framework to UE4, so that's a hopeful.

NPCs: Moderate. This is in a client sense only. In the same way that we use Noppe's NPC mod, there are existing frameworks for NPCs direct from the UE4 community. Our purposes will likely be separated from these vanilla blueprints however, because they must also comply with the server's logic. But in terms of interfacing with the player's GUI and regular animations, there is a fair amount of existing content.

Security: Moderate. Typically, security is as large a part of server construction as anything else. An existing MMO plugin will grant us the benefit of security when transferring packets right off the bat, but with the expectation that we won't be so lucky, we'd have to take care of security on our own. This may mean a new client login system (which could potentially be a plus) and methods for encrypting / decrypting data, especially client info, over the server-client stream. We can't really expect to have the benefit of security simply through using our own server and client as opposed to MC's own, as security through obscurity rarely works.

WorldGuard: Easy. I don't really see how it could be otherwise, given a server that can do client-tracking and delta checks, which any MMO server should be doing anyway. Our map is a rather simple shape, and the client simply should not extend beyond a set of coordinates - this operation could probably be done by the client itself. Even without WorldGuard, I don't expect we need to include world generation logic, so the user will likely just fall off the map.

Essentials: Moderate. This hooks in with the server model and security mentioned above, and comprises of setting up what will presumably be a SQL database of permissions and abilities associated with each client and what they can or cannot do to another client. I expect the set of Essentials commands we'd be looking at would be rather different from the ones we see on the server beyond moderator and administrator control since the focus is on RPG and not development. A chat system would also presumably be included here - blueprints exist for this both in the form of standalones for clients and also packaged with all of the third-party MMO plugins.

Dynmap Support: Should be easy, though I don't really want to speak on Mike's behalf. I'm not sure how Dynmap communicates with the server. But if we truly use an MC-based level design, then the coordinate system on the Unreal client should be synonymous with that of the Minecraft world, and I'm fairly sure Dynmap could accept these coordinate updates from a server, should we write our own. In this way, Dynmap could still use display information from the MC dev server.

Combat: Difficult. I'm going to extend a little bit beyond "breaking even" here and mark this category as the one, central RPG feature that UE4 holds above Minecraft, as it may as well not exist in MC. Regardless, combat systems are difficult to implement as they are heavily animation-based. Blueprints exist for UE4 combat systems en masse, but as always, they must link in with the MMO plugin / server, and animations that involve multiple actors must be agreed upon by the server. Personally, I enjoy working with character animation, so this is something I'd be pretty eager to look into.

I should write a book or something... I know that isn't everything, but it's getting really late.

 

[Iwan]

Note: Quoted from @Thamus_Knoward

Thanks for that overview Hal! That was really helpful to get an idea!

I would like to clarify that it is completely out of the question to create the entire world from scratch as outlined in 1) of Mike's points. We really don't want to throw away the work, workforce and interest we have gained as an MC server with a highly-skilled and -motivated and tightly-knit community.

On the matter of CTM: I cannot speak in coder language, but as soon as a block is placed the texture on it remains static as it had been calculated by the CTM. So when we transition into the MMO, wouldn't it make sense to take the textures and animations as they are, and by that bypassing the need to recalculate them by CTM? The use of CTM only really applies to the building process anyways, as soon as that is finished, we would put a lock on the textures in the immutable world. Tiles, placeable "Blocks" (Entities), Spritesheets etc. developed for UE4 wouldn't really need CTM as far as I can tell. Please correct me if I am wrong here

As far as Essentials is concerend. Thats another feature that really only applies to running/maintaining a MC build-server. At least thats how I see it.

On the matter of Water, I don't really think we are using it as an active block anywhere in the world in actual functual builds, like where you'd push a button that opens flood gates and water would start flow through. Since nothing can be "driven" with water, builders have resorted to displaying static snapshots of contraptions etc. So I think it may be fair to ditch MC water entirely over whatever liquids UE4 offers. (Now I am phantasizing about exporting the wheels of watermills and windmills, rendering them into UE4 entities, and animating them in fixed places of the worlds to rotate merrily!!

)

On the matter of animating for Combat. I bet we would find a lot of people that would love to do animations for us. Iwan for one has always been interested in that and was dissapointed to find out that MC animations are more or less coded instead of the common animation formats. I am sure that many of our current builders as well as nobuilds visiting would be interest in working on combat animations etc.

 

[Iwan]

Note: Quoted from @Hal9007

Thamus_Knoward
wrote:
On the matter of CTM: I cannot speak in coder language, but as soon as a block is placed the texture on it remains static as it had been calculated by the CTM. So when we transition into the MMO, wouldn't it make sense to take the textures and animations as they are, and by that bypassing the need to recalculate them by CTM? The use of CTM only really applies to the building process anyways, as soon as that is finished, we would put a lock on the textures in the immutable world. Tiles, placeable "Blocks" (Entities), Spritesheets etc. developed for UE4 wouldn't really need CTM as far as I can tell. Please correct me if I am wrong here

If it's true that CTM gets solidified in world data, that simplifies things considerably - my initial thought was that CTM is determined client-side and on-the-fly when Minecraft does its texture pass. If every block can be predicted solely off of the world data (with the exception of active blocks), then it's a relatively simple matter to store the connected texture info in the UMeshComponent for each respective CTM block. This would make sense, as the standard NBT layout for the MCAnvil file contains a data array alongside the block array, which I assume carries direction, state, and hopefully CTM information. On the same note, it's also notable that lighting information is stored per-block in the MCA file (which is pretty stupid, but understandable when considering Minecraft's fast lighting system). The GZip compression alleviates this to an extent, but this is one of the things we might salvage in moving to our own format and could be taken into account when considering the new world data size - if the CTM truly works as above, then our worst-case scenario would be an equivalent disk space to the current MC data, if we decide to stick with the NBT format.

Thamus_Knoward
wrote:
On the matter of Water, I don't really think we are using it as an active block anywhere in the world in actual functual builds, like where you'd push a button that opens flood gates and water would start flow through. Since nothing can be "driven" with water, builders have resorted to displaying static snapshots of contraptions etc. So I think it may be fair to ditch MC water entirely over whatever liquids UE4 offers. (Now I am phantasizing about exporting the wheels of watermills and windmills, rendering them into UE4 entities, and animating them in fixed places of the worlds to rotate merrily!!

)
​

While I can't say for sure, I'm fairly certain we'd be stuck with using MC water meshes - there's too much logic associated with how Minecraft water works to translate to any Unreal-based particle fluid such as its flow and direction, and it probably wouldn't look that great on such a low-poly background. However, if we're set on not having any dynamic water sequences, then that would of course help.

As an update, I'm currently rewriting some of BrickGame's logic so that we could possibly start to see some actual mesh / texture generation from existing world data - I'll probably be sticking with NBT for now, as it suits most purposes quite well and there's no particular reason to navigate to a new one at the moment. Some of the major changes include changing the region size and updating the coordinate system; the BrickGrid plugin operates with chunks of 32 x 32 blocks as opposed to 16 x 16 as seen in MC. The rest of it is all general overwriting, namely the InitRegion method and replacing BrickGrid's Z-depth info with the heightmap data in the region file.

 

[Iwan]

Note: Quoted from @Hal9007

For those not able to follow along on Asana, the source code for WesterosCraftUnreal is now live at:
https://bitbucket.org/Hal9007/westeroscraftunreal/

You can keep up with the most recent updates there.

 

[Iwan]

Note: Quoted from @Hal9007

Addressed a few null pointers and memory leaks this weekend, and I'm glad to say that I have the first working prototype of the AnvilGen plugin! Here is a single-player world based off the WesterosCraft 1.7.10 instance being streamed into Unreal Engine 4:

Had to disable the block ID's for grass and ferns to make things a bit cleaner:

And just for fun, here's a bit of King's Landing:

Obviously, this is lacking textures, but it was a pretty relieving step to overcome. I'll be starting work on texture mapping and custom block models for the next few weeks.

 

[Iwan]

Note: Quoted from @mikeprimm

Hal9007 - I think you should take a look at this - https://www.unrealengine.com/blog/epic-launches-unreal-dev-grants

 

[Iwan]

Note: Quoted from @Hal9007

Cool stuff - that's as good an incentive as any to push forward toward a playable prototype, and it sounds like we'd really have to focus interest on aspects unique to our RPG goals to nab the described "wow" factor.

A $5,000 base grant is a killer deal, so I'll definitely keep an eye on this.


Some other brief updates:

The author of the "libmcmap" library I've been linking decided to re-license his material to LGPL, which means I can now ditch the GPL and transition over to the much friendlier BSD license (or close-source the project, if that somehow becomes desirable later on). Overall good news, as the UE4 EULA didn't play very nice with the GNU licenses to begin with.

Before moving on to textures, I'm really trying to get chunk-streaming up to speed - typical MC "far" render distance (about 15 chunks) gives me a fluid response, though anything beyond 20 chunks causes moderate amounts of hitching. I expect a few modifications can help with this on the AnvilGen side, such as initializing every region's header before starting the game (should save anywhere from 2 - 7 milliseconds on each chunk); most probably this will require a few modifications to the BrickGrid plugin itself. BrickGrid is fairly aggressive with the chunk loading; it strictly maintains the base chunk radius around the player, which can be pretty taxing on the CPU when the player moves very fast, so I might end up setting a deliberate delay timer on each loaded chunk to work around this issue.

 

[Iwan]

Note: Quoted from @Hal9007

Ok - I started work on texturing today. The texturing system is going to require a few heavy rewrites, so I've created this Google Spreadsheet (you can also find the link on Asana) to keep track of each texture that gets transferred over, and the overall progress.

As you can tell, it's pretty extensive, so I would greatly appreciate if any texture pack artists / anyone wants to chip in. I'll definitely need some feedback from the texture pack team in the end over what behavior should stick (pistons in their extended position, etc.) and what won't be necessary.

 

[Iwan]

Note: Quoted from @pizzainacup / @geeberry

What exactly do you need help with? Listing the textures?

 

[Iwan]

Note: Quoted from @Hal9007

pizzainacup
wrote:
What exactly do you need help with? Listing the textures?​

Yep, that and even comments here and there talking about the plans and usage for a particular block would be great.