The Big Questions...

edited November 2014 in Modding and Coding
There are a few broad suggestions I wanted to bring up not because I particularly want to see them in the game (though some have exciting potential), but because I expect that they will be frequently asked, and I'd like to know how reasonable these suggestions are, or indeed if they've already been implemented (or, for that matter, formally rejected). They are:

-All the background stuff. Is the engine multithreaded? x64 compatible? Mac/linux ready? These sorts of questions are likely to come up again and again, what's the official word?

-Physics in environments. If you dig a rock free from the ground around it, will the rock fall? Will even a single pillar of earth be sufficient to support it? I assume we will sacrifice accuracy for function at some point, but what point? I do not personally mind if floating islands are possible; nonetheless, if you cut down a tree, it should fall over.

-Dynamic Fluids. This shades into the previous heading. Is rain, flooding, and lava possible? Snow and ice?

-The Dreaded Multiplayer. I expect that multiplayer is not a priority. Nonetheless, is multiplayer even a remote possibility, or does the engine preclude it?

-Modding. Clearly this is a priority, but how much will be moddable easily? That is to say, what sort of tools will be provided for designing structures, chopping up the world, or tweaking the generator?

I should add, I apologize if some of this has been covered elsewhere; a link to the most relevant information would be appreciated if that's the case. Thank you.

Comments

  • edited November 2014
    EDIT: confirmed that VQ requires 64-bit CPU

    I can answer some of these, @PTTG.

    Background stuff: I don't know about multithreading, but VQ does require a 64-bit processor. Initially VQ will be just Windows, but either Gavan will port to MacOS/Linux or he'll make it easy. No Windows-specific libraries so far, so porting shouldn't be difficult.

    Physics: definitely reasonable, I don't know if Gavan plans to implement them. We've talked about them a little bit in this forum post.

    Dynamic fluids: Gavan already supports fluid dynamics for water. Flooding/lava should be possible. He's put out some images of the "winterized" VQ engine (check the very bottom of the gallery. Has not yet discussed rain.

    Dreaded multiplayer: turn-based synchronous multiplayer is a definite yes. Real-time is up to modders, as well as asynchronous.

    Modding: Gavan will provide some of the simple voxel addition/subtraction tools that he's been demonstrating with the source. A lot of the items and visual effects (terrain colors, etc) will be easily modified in JSON files, and the source is of course open for really deep tinkering. He said that he's going to write the source intelligently so classes can easily be modified/swapped out.

    Hope this helps! I'll make a note of the x64 and multithreading parts and ask Gavan if he doesn't respond directly.
  • edited November 2014
    PTTG said:


    -All the background stuff. Is the engine multithreaded? x64 compatible? Mac/linux ready? These sorts of questions are likely to come up again and again, what's the official word?

    x64 is required. This was an easy choice for me to make. 32 bit systems are increasingly rare these days (although still surprisingly abundant, although primarily in the mobile world at this point). I did not want to go through the trouble of supporting 32 bit builds, and although it is in the future, IIRC OSX requires a 64 bit build. VQ mem usage is still pretty low, but nonetheless I'd like to be able to natively extend a memory space larger than 4 gigabytes. It was originally ported from a Mac, so I can say from experience the port is fairly trivial - nonetheless ports are up to the community until I get a solid working product on Windows. Uses all cross platform libraries, including for multithreading. Initially multithreading was supported but I've since stopped using it as most work has been moved to the GPU or is limited by the single-threaded nature of OpenGL calls.
    PTTG said:


    -Physics in environments. If you dig a rock free from the ground around it, will the rock fall? Will even a single pillar of earth be sufficient to support it? I assume we will sacrifice accuracy for function at some point, but what point? I do not personally mind if floating islands are possible; nonetheless, if you cut down a tree, it should fall over.

    Initially no physics. However, in the actual game mode, you are not explicitly destroying voxels, but rather higher-level objects. So, lets say you are chopping down a tree - the tree has some property like X percent chopped down / destroyed. After it hits that threshold, it falls over (maybe just rotated 90 degrees to ground level, who knows). Similarly, if you are bashing down a door, once it hits that damage threshold, it just shatters completely or disappears, letting you walk through.
    PTTG said:


    -Dynamic Fluids. This shades into the previous heading. Is rain, flooding, and lava possible? Snow and ice?

    Yes, at the macro level mostly (beyond trivial screenspace particle fx). Macro chunks are currently 8x8x4 meters large, meaning you can reroute rivers and stuff easily. Going much smaller than this is not entirely realistic from a computation and memory standpoint, unless you do really simple/fake fluid dynamics like Minecraft. Snow, ice, and lava will exist.
    PTTG said:


    -The Dreaded Multiplayer. I expect that multiplayer is not a priority. Nonetheless, is multiplayer even a remote possibility, or does the engine preclude it?

    Multiplayer is on the back of the queue - if everything else is working moderately well, it will be implemented. Otherwise, its up to modders. Only synchronous multiplayer (turn-based) - realtime is something definitely left up to modders.
    PTTG said:


    -Modding. Clearly this is a priority, but how much will be moddable easily? That is to say, what sort of tools will be provided for designing structures, chopping up the world, or tweaking the generator?

    Its a programmer-oriented engine (as opposed to a designer-oriented engine). All things are accessible in the code, and if people want to build simplified front ends for designers, they are welcome to. That said, I am putting in many basic things into sandbox mode, mostly for testing purposes, including placing and removing structures or arbitrary geometry. A full on material editor already exists but might be phased out, see here (it runs externally in a browser and links to the client via websocket):


Sign In or Register to comment.