WesterosCraft Unreal

Iwan

Iwan

Boldtown
Note: Quoted from @Hal9007

Was following development of that closely; we're unfortunately stuck with 4.5.1 and below, because Epic removed material ambient occlusion from the deferred shader in all later versions (basically, the dependency of the CPU solution which makes the corner of adjacent blocks and the insides of caves darker). We won't be able to move to later versions unless they decide to bring it back or a manual workaround is found. Not to say HTML5 is completely out of range, but this probably won't reach any packaged versions of WCU. Consoles / mobile are still a possibility, if those are target platforms of interest.

WCU compiles fine with UE 4.7+, however, so I might try packaging it without occlusion for HTML5, just to see what running Minecraft in-browser is like.
183_16.png
 
  • Like
Reactions: W1ck3dWolf
Iwan

Iwan

Boldtown
Note: Quoted from @Hal9007

Added a few basic, non-CTM textures from the WesterosCraft RP and worked on a graphical overhaul of the player environment. I also went ahead and ported the third-person framework, so that any work on server-client replication can be done alongside the texturing work.

Nil51je.png


gm5159F.png


RhqDjz6.png


Kinda hard to stop running around and actually work on the code.
183_16.png
 
  • Like
Reactions: W1ck3dWolf
Iwan

Iwan

Boldtown
Note: Quoted from @Hal9007

Even refunded me $30 too - this is a huge statement toward developers and the industry in general.


Got blueprint replication working last night; here's me simulating two clients and a listen server:

f35GORQ.png


The replication is more straightforward than I imagined, though it looks like chunk streaming will have to be handled apart from the UE4 built-in replication. In the end, we'll probably be looking at two different servers: the Unreal Engine dedicated client and NPC tracking server and a separate server to handle chunk requests.
 
  • Like
Reactions: W1ck3dWolf
Iwan

Iwan

Boldtown
Note: Quoted from @Hal9007

Cool - if you're interested in running the WCU client as it stands (and have a 64-bit system), you can do the following:

1) Install Visual Studio Community 2013 or XCode if you're on Mac, as UE4 depends on it to build the game.
2) Go here and download the repo (it's only ~32 MB zipped).
3) Extract it to your 'Unreal Projects' folder - usually in your documents. If you don't have one, make one with that name.
4) Double click the UE4 logo in the extracted folder (WesterosCraft.uproject).
5) Click 'Yes' when/if it informs you of the missing DLL's and wait for it to build.
6) When Unreal Engine opens, wait for it to discover the game assets then click 'Play' at the top.

Should run fine if you're on a 64-bit OS, though I admittedly haven't tried it on Mac or Linux. If the performance isn't that great, click 'Settings' at the top, go down to 'Engine Scalability Settings', and set 'Shadows' to low. Coders can, of course, directly clone the repo to pull down the latest commits.
 
  • Like
Reactions: W1ck3dWolf
Iwan

Iwan

Boldtown
Note: Quoted from @Thamus_Knoward

I've just downloaded the Engine since its free now, and I will make sure to clone the repo sometime this week! After Winterfell has started I should be able to help work out the texture stuff you asked for previously!
 
  • Like
Reactions: W1ck3dWolf
Iwan

Iwan

Boldtown
Note: Quoted from @Hal9007

Found this interesting blog post by the guy who wrote the BrickGrid plugin, which details the process he went through in setting up a voxel world. It's quite informing about how it works, and I recommend it to any coders.

I'm starting to actually work on the netcode that can power this - it's undoubtedly the hardest thing involved in optimizing an MMO. The architecture I'm looking at is fairly standard - the client communicates with a PHP web server, which pushes back to both the Unreal dedicated server and a MySQL database. At the moment, I'm working on a system for client authorization, with logging and permissions registered through an external launcher which keeps the client files up-to-date. I'm moving toward a custom Qt-based user interface for this, which I hope will be useful for us in both Unreal Engine and Minecraft.

AymNlVu.png


It's pretty sparse at the moment, but it's mostly proof-of-concept and there's a lot of room to tweak it. In the end, it will hopefully be a means of authorizing the client before they join the server. It compares the checksum of the client's files against what we intend, and subsequently contacts the web server with information about allowing that client access to the server.

Similarly, I started playing around with the in-game user interface options - below is a loading screen which should play while BrickGrid is initializing the first batch of chunks immediately surrounding the client. I thought it would be cool to match the theme I went after in the launcher. UMG (Unreal's user interface system) is pretty neat, and should be easy enough for any texture artists to use.

gx9n2cL.png


Lastly, with RTX coming up in less than 150 days, I've been working on a combat system that we can actually demonstrate regardless of setting. I pulled down some motion-captured animations for sword-and-shield combat. Here's a small scenario with myself and three other scripted AI's. As you can see, I'm aiming for an intelligent strafing system that keeps the user focused forward and separates our combat from typical MMORPG point-and-click combat.

8Cus3Up.png


I'll try to post a video on that further down the line, when it's a little more sophisticated.
 
  • Like
Reactions: W1ck3dWolf
Iwan

Iwan

Boldtown
Note: Quoted from @mikeprimm

Hal - have you had a chance to take a peek at the new 'open world' stuff, in 4.7? I know you're current code has some issues with the lighting changes on newer stuff, but I was wondering if this was going to wind up being important for anything done here. Specifically, I know the multiplayer stuff has some issues with extended worlds - not sure if what you've been messing with is handling that, and whether the 'open world' stuff is relevant to dealing with that.
 
  • Like
Reactions: W1ck3dWolf
Iwan

Iwan

Boldtown
Note: Quoted from @Hal9007

Quite relevant, actually.
183_16.png
It demonstrates a lot of the new 'open-world' features of version 4.7+ for the engine; unfortunately, it appears to be severely bugged on my branch of the engine, so I'll have to update to UE4.8 before I check that out.


mikeprimm
wrote:
Hal - have you had a chance to take a peek at the new 'open world' stuff, in 4.7? I know you're current code has some issues with the lighting changes on newer stuff, but I was wondering if this was going to wind up being important for anything done here. Specifically, I know the multiplayer stuff has some issues with extended worlds - not sure if what you've been messing with is handling that, and whether the 'open world' stuff is relevant to dealing with that.​

Lighting shouldn't be too much of a concern - ambient occlusion has been the primary issue with BrickGrid, though one of the newer features of the engine is Distance Field Ambient Occlusion, which is a very good dynamic implementation (on that same note, I really want to merge in Distance Field Soft Shadows).

Map size is one of the issues I'm more concerned about. Epic hasn't been altogether transparent about the capabilities of their own networking system. The map in the videos I linked above is about 16 x 16 km. From what I've collected, the suggested maximum map size is 2,000,000 x 2,000,000 Unreal units; in direct conversion to our units, that's 20 x 20 km, or about a third of our map. However, as you may know, the real issue has to do with floating point precision at those sizes - the PhysX collision system starts to get wonky when you go beyond that. So really, it depends on what kind of precision we want - we can, of course, redefine each Unreal unit as 10 cm instead of just 1 cm, which would be a tenth of the precision (but we'd end up with a working space of 200 x 200 km, which is more than enough).

Unreal already has a solution for singleplayer, something called world "rebasing"; basically, every so often, the engine resets the players coordinates and adds them to a vector offset that it stores in memory, allowing you to tile the world map to infinity. This presents obvious problems for multiplayer, so I'm hoping we can just get away with reduced precision. I don't expect we'd need as much for something the likes of Minecraft, but I can't be sure of what effects it might have down the line.


I'm still working with client authorization at this point - struggling quite a bit with the PHP -> MySQL interaction, which is something I'm mostly learning on the fly. I've set up a web domain which communicates with all of the Unreal-related files (both the launcher and client) at http://westeroscraft.x10host.com; client login through the launcher should hopefully be up at least before this summer.

I'm making a few more advances on the combat front; finally figured out how to do proper blendspaces and bone-separated animations. Here's my current work-in-progress. There's only one swing animation at the moment, but I have well over 30 in stock:

 
  • Like
Reactions: W1ck3dWolf
Iwan

Iwan

Boldtown
Note: Quoted from @Thamus_Knoward

Just bumping this up because I've started to get into understanding the UE editor.

What would you like me to focus on here Hal? Texture stuff? Items? Meshes? Models? Getting everyone together on the story team?

Let's open up our communication here!
 
  • Like
Reactions: W1ck3dWolf
Iwan

Iwan

Boldtown
Note: Quoted from @Hal9007

Took a little time to get around to this, but here are my thoughts:

For now, I'd like to focus on things we can execute with confidence - WesterosCraftUnreal can read and recreate Minecraft world data, but the way we handle custom blocks, CTM, and textures are currently 'uncertain' and will be based on how much data we can transfer directly from Minecraft (apparently 1.8 has custom block data specified in-line, which would be very useful for us). But for now, I would avoid that whole side of it simply because we don't have a workflow for it yet.

Instead, I'd rather we spend time on what Unreal does best, which is gameplay. There are a million different ideas specified in our game design doc, and that's something we can begin to explore step-by-step, at a rate faster than we could ever do through MC plugins alone. These gameplay concepts, for the most part, don't specifically relate to Minecraft in any way, and we can prototype them outside of a voxel world to see how they function, and moreover, how to balance them for a rounded experience. Ultimately, this is where the most people can jump in, because it doesn't require any prior knowledge about Minecraft internals, networking, and graphics programming.

As such, here's what I'd recommend, in this order:


  • Read through the design document, mark off concepts which are decoupled from Minecraft and can be prototyped in a standalone environment.
  • Of those, isolate only ones that have been sufficiently developed.
  • Prioritize these concepts in order of their importance to the RPG schema.
  • Determine what resources we need for prototyping that concept (UI designs, frameworks, etc.).
  • Delegate these 'prototypes' accordingly to whomever is available or willing
  • Do thorough QA / balance tests on each concept following development (can ship test executables to literally anyone willing to give feedback).
  • Maintain one project to merge in things we find successful and try and combine them effectively.

The design doc is very long, and I understand you have the most complete grasp on it. If we can knock out the first three bullet points, we may be able to approach Unreal Engine with something useful to our efforts.
 
  • Like
Reactions: W1ck3dWolf
Iwan

Iwan

Boldtown
Note: Quoted from @Hal9007

It's all good - there's a lot of underlying things to get out of the way anyhow. I've mostly been running platform tests to get the base voxel project functioning correctly on OSX and Linux machines, with fairly good results so far. I've also begun dividing the project preemptively into a lot of isolated test blocks, where I've been trying a variety of different things: secure peer-to-peer chat, world instances, accurate day/night cycles and so on. I think it'll be really useful to maintain this schema for approaching topics on the design doc.

I know there's been a lot of ground to cover, so maybe we could meet up with Kraken and discuss it sometime soon?
 
  • Like
Reactions: W1ck3dWolf
Thamus_Knoward

Thamus_Knoward

Shadowbinder
I'm super super sorry for neglecting all of this for so long :(

Life has had a firm grip on me the past 4 years. I will add this list to my weekly todo list! Could you send me the link to your trello again? I'll do it in there!

  • Read through the design document, mark off concepts which are decoupled from Minecraft and can be prototyped in a standalone environment.
  • Of those, isolate only ones that have been sufficiently developed.
  • Prioritize these concepts in order of their importance to the RPG schema.
  • Determine what resources we need for prototyping that concept (UI designs, frameworks, etc.).
  • Delegate these 'prototypes' accordingly to whomever is available or willing
  • Do thorough QA / balance tests on each concept following development (can ship test executables to literally anyone willing to give feedback).
  • Maintain one project to merge in things we find successful and try and combine them effectively.
Click to expand...
 
  • Like
Reactions: W1ck3dWolf
Hal9007

Hal9007

Street Preacher
Guest
No worries - glad to see you back around Thamus, and also glad to see that the team found some new footing.

Here's the link to the Trello. You should still have access to modify it, though I personally haven't posted updates to this board in quite a while: https://trello.com/b/ql291HEk/westeroscraft-mmo-development

And again, I really want to stress to the design team that I created this checklist specifically without mentioning a specific technology. It is in no way whatsoever tied to the UE efforts - the point being that if we do the above effectively, it really doesn't matter how we approach the development process in the future, it will still be a tremendous help down the line, and help break things into smaller pieces for making those types of decisions later on. I'd suggest forgetting that we're working with Minecraft at all, and focusing on things that you'd really like to see out of the almanac.

In short, worry about the what, not the how, because us developers can't decide how to do something until we know what we're doing.
 
  • Like
Reactions: Emoticone11, W1ck3dWolf and Iwan
W1ck3dWolf

W1ck3dWolf

Messenger
Guest
I’ve begun hiring for my Story Team - once I get the MMO team in place it would be nice if we could get a simpler explanation as to what it’s looking like on the coding end of things so we have a better sense of direction when developing and adding new/existing aspects to the MMO.
 
Thamus_Knoward

Thamus_Knoward

Shadowbinder
@Hal9007 I've gone through the Almanach and have selected a few items that I think are mature enough to be prototyped in UE. I put them in the Game Design Product Backlog column in this board: https://trello.com/b/ql291HEk/westeroscraft-mmo-development

Let's implement a rough prototype and then have the community give us feedback? I suppose they would be the primary stakeholders? Maybe we should also post stuff to itch.io to get feedback there?
 
  • Like
  • Love
Reactions: Iwan and AerioOndos
You must log in or register to reply here.
Top Bottom