What's the most efficient way to store map data that I don't need to visualize?

I'm building a submarine game in which the player never sees the exterior of his vehicle, not entirely unlike the silent hunter games on maximum realism. For the purposes of gameplay I need to track the submarine's position in the world, the position of any nearby enemies, and the height of the seabed/terrain for collision purposes.

However, none of this needs to be visualized- terrain is only important as a binary (you hit it, or you don't), and all combat is done programmatically based on the enemy's stated position, velocity, and bearing.

One way I could do this would be to give the player and enemies literal sphere meshes and move them around, but that feels somewhat hacky- is there a reasonably simple way I could keep the entire world in data? One idea that occurred to me was storing terrain blocks in a three-dimensional array, but that would be enormous and a lot of the terrain would just be water.

 

Whats wrong about using GameObjects to hold entities positions? There is a distinction between Mesh components and Transforms. Attach sphere colliders to get proper collision detection (either via OnCollisionEnter, OnTriggerEnter or Physics casts) on game objects without MeshFilter or MeshRenderer.

 

The main reason I was leaning away from that was because creating gameobjects for something that could be done purely in data felt like a waste, but I do really like that idea. I know unity can get weird when objects get too far from the origin (and thus, calculations involving the transform get huge), assuming I was doing this with a fairly large world, do you have any idea how far I could get before I'd want to worry?

 

But for what I understand of your game, you will need lot of things from GameObject, transform and colliders (unless you are willing to write a lot of code that is already done and tested in Unity). Namely: translates, parenting, quaternion rotation, World <-> Object space transformation... The list goes on. The only thing that you will not be using are meshes, but this is only the visible part of objects.

Never had any issue with large distances (except visual artifacts from ZBuffer precision) and I'm not aware that large distances cause performance hits of any kind.

 

I probably don't have any reason to worry, then.

I did some quick checking just now, and it looks like physics take the biggest hit at distance, due to the loss of floating point accuracy- some projects were reporting shaking and stuttering past 1,000 units from origin, and lots of guys had trouble when they got past 5,000. It's easily solved by stitching scenes together, though, and not really an issue at all if I'm only using collision volumes that don't have physics.

 

Two words. "Space Kraken". Google it.