Jump to content

Mathig

Member
  • Content Count

    6
  • Joined

  • Last visited

  1. Just look at EvE online; that game is full of pirates. When you destroy a ship, self-destructed or otherwise, it leaves a wreck with some (not all) modules that were on the ship. Some of the cargo also survives in the wreck. That's plenty of reason to pirate, and in EvE people will even attack in "protected space" that has an infinite police response. You can make this mechanic balanced quite easily out of basic elements that should be in your game anyway. 1: Force ships to require power generation. (I think this is a pretty common mechanic in space, and it doesn't make physical sense not to have it...) 2: Require power generation to have cooling.(Which must be outside the ship... yay thermodynamics!) 3: Destroying too much cooling will cause the power generator to slowly overheat based on power usage. Once it overheats it will shut down. 4: If your power generator is still online, you can activate the self destruct sequence. This requires you save up a certain amount of charge(per tank) to discharge into your fuel tanks.5: Additional timer, because self destruct timers are awesome. 6: When ready, a powerful arc surges through the oxygen/hydrogen(or whatever) fuel walls causing both the source and ignition for explosions centered at fuel tanks. 7: This can be canceled at any terminal/cockpit. 8: Shooting at a fuel canister has the same effect as overloading power, causing an explosion. So, Pirates can either destroy your power generators, your coolant panels, or they merely risk your fuel canisters blowing up. Even that doesn't guaruntee the valuable loot is lost. And they have until you save up power and wait for the count-down, which will be really hard if you're power is being shunted to shields or engines or guns instead. It also means that in the design of a ship, you must plan for that feature. However, if you put fuel canisters next to your cargo, or cockpit, then you also risk the enemy blowing them up prematurely. Thoughts?
  2. This is exactly what I was looking for, thanks. So, just to be clear, the only thing that worries me is whether or not the terrain shown at the beginning and end of this video is actually voxel based or something else. Now, I agree that the terrain shown in the middle absolutely is Voxel-based. However, I'm not convinced the two are the same. I'm also a little confused why the higher mesh detail isn't centered around the camera for that part of the video, but I imagine it would be almost as hard to program a fake mesh enhancement that convincing as a real one, so... @Wesbruce your example is poor, because it is very obviously voxel based. Note the texture is almost the same flat tone for everything. It's not displayed as cubes, but the data is obviously stored as cubes. What keeps tripping me up is those small indents on the ground and the lack of obvious tiling which you should see unless they are messing with the textures. Also, why the tower at 10 seconds is floating on the right. However, after staring at the terrain I can kinda sorta see tiling textures that are maybe randomly rotated or cropped (off of a larger single texture), perhaps based on a seed derived from it's coordinates? Perhaps small variations in height are actually non-existent and are really just baked on as part of the texture? Yeah, now I'm starting to see it. I guess I didn't understand that dual contouring was basically averaging terrain meshes over local space. I thought it was storing shapes as meta data. That explains a lot of why the spherical tool doesn't seem to "work" as intended, or behaves rather unpredictably. I have a very hard time believing that those voxels are 100 cm though. They look much more like 25 cm. Anyway, that doesn't matter either way. Thanks @Wesbruce for the pdf. While I probably didn't read it closely enough to fully understand it, it did help.
  3. As far as I know, voxel technology means saving meta-data to a grid of a certain mesh. In Minecraft that meta data is a block type which indicates which block it is, grass, dirt, what-have you. On top of the meta-data mesh, you need to generate a surface to attach textures to. Minecraft does this by generating planar faces in between the block and any transparent blocks. Dual Contouring, to my understanding, generates a surface based purely on that mesh. In their video here at 1:47, that is clearly voxel based. At 1 second, however, I'd argue the terrain isn't. I'll just assume the rocks are effectively elements and were custom designed. The terrain, especially towards the bottom right, however, does not look like it is flat except for the occasional 20cm change over a distance of 20cm. The terrain towards the middle-left isn't what I'm worried about, since I can't see it clearly. It's the bottom right that concerns me.
  4. Do you mean this? If so, then no, it does not answer my questions regarding voxel mesh size. If anything, those videos in specific imply something quite dishonest going on behalf of Novaquark, but as I've said, I thought to give them the benefit of the doubt. Specifically, this video seems to be an unmistakable example of non-voxel based terrain masqueraded as voxel based terrain generation. Would you like me to explain why that terrain isn't voxel based, why non-voxel based terrain is a terrible design decision(for Dual Universe), or what dark scheme I think Novaquark could be up to? It's obvious that either I'm missing some major feature of development, or NovaQuark isn't being honest with development, and that concerns me.
  5. So, I wrote this long comment, but it didn't bode well for Novaquark. So, I'm giving them the benefit of the doubt. What is the lowest mesh size for the voxel terrain. (If you aren't a dev, please link some form of source) I'm also curious why the smallest mesh size ever used is on the order of 100 mm, but the terrain looks to be on the order of 1 mm or even smaller.
  6. Firstly, do you have any confirmation whether or not scripts will run locally on the users PC? This is a massively important feature, as it determines whether or not the game could be feasible to begin with. I have put thought into a number of systems, any one of which, would brutally murder a server. One is an accidentally bugged code which features an infinite loop that runs a bunch of intensive commands. If these ran on a server, you could on-demand crash local nodes. Another is an cleverly constructed code designed to replicate itself. That is, teach a robot to mine resources, develop them into another robot, and copy it's data morphed for cooperative play for that other robot. In other words, a literal hive mind that, once started, will reproduce exponentially. While you're building your hive mind, you could incorporate machine learning to spontaneously adapt and develop new code automatically to improve the hive-mind's function. Granted no one has done this in real life yet, but it is still possible someone could reach the singularity in-game and no one can know what will happen next. (Although perhaps the developers of Dual Universe would be more than happy to facilitate that development) IFF code ran on local computers, this sort of game play would merely crash the users PC, and not the server as a whole. Of course, there are also a number of things that can be done to limit the above from ever becoming an issue at all. For example, if you made it local to a certain distance ®, you'd prevent players from using more than r^3 DPU's which could potentially have their own limits on computational power. If you made it local to the player with some upper threshold of active DPU's or DPU operations per second, then you could prevent players from expanding too much by slowing down their operations (like EvE's time dilation). There are also a number of things that could be done that would eliminate various methods of play (in my opinion, less desirable), for example preventing AI from creating or activating other AI. Of course, if you let players crash their own PC, now you've opened the door to effectively installing a virus via your game, by allowing players to sell code that potentially damages the buyers PC. Which might now have legal ramifications for the developers, since it might be unreasonable to expect a reasonable video-game to burn out your recommended spec meeting hardware. I'm still quite the skeptic, though, so it'd be really nice if the devs have already thought of this stuff before I have.
×
×
  • Create New...