DEV

Understanding Fractured Veil

We’ve been working on Fractured Veil (FRV) for almost 2 years now. We started with some rather wacky ideas about what kind of game we were going to make and have made a lot of progress over time. But lets start these tech posts with some details on the engine we chose:

We’re using the Unreal engine, version 4.14 currently (though we were developing under 4.12 until Thanksgiving of 2016) and we’re currently only targeting the PC. Consoles might be in the future, but we’re more likely to ride the PC Master Race train for the coming future. Our mobile/second screen story is horrifically under-developed, but that’s okay. We all have enough crappy phone games to get us through our time in line, in the bathroom/shower, etc…we’ve spent a fair amount of time on the website and will lean on that for inventory tetris, chat, etc for mobile out-of-game use.

Why Unreal over Unity? We chose Unreal because we thought we could make a prettier game that reacts better to user input than on Unity, which we could have made a game faster across more platforms but less refined. We’ve spent probably more time on foliage (this is set in hawai’i) than is strictly speaking wise and we want it to look really nice, and we feel that Unreal does pretty better than Unity. We think a game that is pretty with some really scary people (humans and NPCs) is more engaging than a brown world with brown baddies that bleed ochre onto the brown leaves brownly.

Please note, brownatics, we don’t hate brown. We have some brown bark, dirt, pants, eyes, etc… heck, I have brown eyes. Some of our best friends are brown. This paragraph is going in a weird (brown) direction now so I’ll stop…. brown.

Ours is a multiplayer online world, and that means messing with any engine to deal with the round trips to the server and then keeping what happens on the server happening very quickly. Unreal has a history of being a great client but out of the box trusts the user client too much for a proper MMO. Fighting RT times and maintaining server/client state is something we’ve spent a lot of time on, but that would be true no matter what engine we chose. In our bizarro dream world where we have gobs of filthy cash and an Abrash cloning machine, we would spin up a team to do our own backend engine or sometime equally nutty, but that’s not who we are yet…

Unreal’s mobile capabilities are developing decently, so when we do get off our asses on mobile, the engine will probably be more usable than it was 2 years ago when we started this adventure, at that time Unreal on Mobile was like trying to put toothpaste back in the tube.

Some insight into the machines we’re using: San (who is our lead gerfingerpokerer on the confusers) ended up buying a pretty absurd dual cpu, 36 core (72 ht) machine to do code/build on, and we have a few high cpu machines on the cloud that we also distribute our builds to (We do automatic builds overnight and on demand). As compile times grew, we needed more powah..on the backend we’re mostly using various machines/services on Google’s cloud offering (We came from Google and understand it and it’s capabilities)

More about the tech as we think to write about it!