About a prototype 'like EVE Online'

Okay, let me first state something, I'm talking about something absurdly simple and in the sense of asking for everyone's help in 'directions' - as I'm a newbie and I study C# and I'm trying to develop a very simple prototype of a 'point and click space' (This is where the Navigation UI comes in).

Here I want to talk about two aspects of the game Eve that caught my attention - the navigation system and 'scalar quantities' (I use google translator, I don't know if this is the correct term).

My prototype - and I ask the more experienced for guidance on this:

A sphere with 50 units x a small box with 0.01 of a unit. As my idea, as in Eve is to 'simulate', to create a 'fake' idea about magnitudes, as I want to avoid any problems with a real 'huge world' - I would like suggestions regarding 'code that holds' (if necessary) a simple movement on any axis, however, preventing possible 'shakes' of the object (as I suppose 0.01 is a very small scale).

Another direction would be about textures, here treated with objects with only 0.01 of a unit - a certain level of detail is possible in this texture/map/material.

Another aspect would be or deal with the camera - what they suggest about - there are ways of 'simulating' (creating a sensation) or giving the camera some property that would help this general idea of greatness, either by code or something already native to the 'main camera' and Cinemachine?

I hope the questions don't seem strange, obviously I have no intention of recreating a game even like Eve, nor would I be able to, but just studying scale and movement, things that would fit better in my prototype using some principles used in Eve Online.

Thanks

 

This isn't really a Game Design question. (Edit: on a re-read, maybe this one is?) Same deal with your last thread about "scalar quantities", which should have been in the Scripting section.

That aside, my suggestion is to just try making something and see what happens. For early projects it's perfectly fine to identify and solve problems when you run into them rather than trying to avoid them in the first place. I don't know how to answer your questions in any practical way because they're vague and have little context. What do the two boxes represent? What kind of interactions will they have? To get useful answers you're going to need to ask specific questions, and you can't do that until you have specifics to ask about.

My main piece of advice is to figure out very early on what a "standard unit" represents in your game. By default Unity's physics settings (eg: gravity) are set such that a standard unit = 1 meter, and that makes perfect sense if your game is played at a human scale. But if your game is being played at a planetary scale then it doesn't make much sense at all, because every number you use will have a bunch of trailing zeros. I don't know what would be a better standard unit to suggest, as you haven't said what your boxes represent.

 

I'm also confused as to what would be the best place to post about this. Before posting, including and via private message, I asked one of the moderators which place would be most appropriate. He responded right away, which was really cool, suggesting this place.

I will try to be clearer:

let's say the 'player' object (anything I click on, like in Stellaris games for example) is a small box. I click on it towards a sphere (planet).

There are things to consider here, my idea is something a little more 'real' in terms of sizes, proportionalities. A relatively large planet (a sphere) and the player (any selectable object in the scene) a small square.

So, I asked for help for not knowing many aspects of the engine and of C# itself. For example, what would be the best way to solve the 'equation' - I'll call it that - scale (a big planet x a small player, proportionally) without overloading the engine? (this problem is common in open world games where there are very large worlds). Another thing would be the 'movement', as I thought of reducing the general scale of what is seen on screen (planet and player - sphere and box - object to be approached and player to be approached to the object). Here I want to digress about the 'how to keep the movement - whatever, from the little box, smooth? 'What its the best pratice about it in this context?'.

 

Right, realistic sizes at planetary scales are likely to be problematic, for two reasons:

1. In reference to your previous thread, there's a good chance that you'll need far more than 7 significant figures for your numbers to work out if you do things the "standard" ways, ie: direct physics simulation on each body. However, it sounds like you're using point-and-click movement, in which case you can pre-calculate paths and destination times when movement commands are given (or need to be re-evaluated) and then interpolate along the path. That way even if individual steps are too small to be picked up the objects will still move along their paths. Movement does not happen quickly in space, so pre-calculating paths is probably fine.

2. Just as significant a concern is that anything "real" is likely to take aaaages. Travelling from Earth to the closest star at the speed of light will take years, and I don't suppose you want a game to take that long. So there's also a good chance that your design will need to consider some form of time compression as well.

The other thing to consider is physics. The mass (and possibly size) difference between, say, a space ship and a planet is going to be too great for the built-in physics system to handle effectively, and this isn't really the use case it was designed for anyway. So you're probably going to have to write your own physics.

 

Perfect. You understand everything what i want. I dont have experience, but I assume - about movement (mere presumption of mine) that I can also work with 'half terms' on the calculated velocity between objects. Of course, I don't want anything 'realistic' (nor could I, I think, talk about interplanetary travel). About the 'seven digits', from what I've been reading, Unity accepts this limit of 7 digits - of course, I would have to test it myself.

Today I ran into another problem, I only find navigation by 'navMesh' (tutorials) on the web, I didn't find any in the three-dimensional space. I resorted to Unity's ducommentation, but it also only talks about navmesh.

I didn't find it in Unity's 'learn' either (I'm currently doing one on the 'visual script' - I'm in love with that, finally learning some logic).

Thanks - really help me a lot. I was a little disheartened as the day went on, after not finding anything more 'directed' on the web and not understanding what little I found - but you encouraged me again. (im using google translate*)

 

The "7 digits" is a very loose rule of thumb. See my response in your other thread, and the links I put in there, for more information.

I've got no idea, because I don't think that translated particularly effectively.

Trajectories between travelling bodies in space are quite complicated because they all interfere with each other.

 

While a NavMesh is a pathfinding tool it solves fundamentally different problems than those encountered in space.

I typed out a rather geeky explanation, but I don't want to over complicate things so I deleted it. Basically, a NavMesh is for use cases such as walking around a building or a street - how do I get from A to B without colliding with anything. That's not a problem you have to solve often when traveling in space, because the distance between bodies is usually huge.

What kind of navigation problems do you actually have to solve?

 

Unity dont have a volume NavMesh... but we have a oclusion system to use like.

 

Hey, I dont wanna be mean or anything, but I think the kind of problems you're trying to tackle ar a bit too advanced if you're learning the basics of programming.

I'm not saying you should throw the idea and do something completely different, but how about you try to sidestep the problems creatively? For example, can you make a proof of concept of your game idea without giant planets? Could you make it 2D to simplify the navigation?

 

Why would you need a volume navmesh? If this game is in space what do you need to navigate around?

Gravity is likely to be a far more significant concern.

 

Because we have 3 axis and i desire mov in 3 axis?

https://docs.unity3d.com/Manual/class-NavMesh-ModifierVolume.html

But, we have it: https://github.com/Unity-Technologies/UnityOctree

(but, like EVE, i ll not alowed to land in planets, etc...far from it... this is really complicate. What i think is just a aproximation in a body, planet, moons, asteroids....nothing more complicate).

Anyway, Infinite Lagrange use this system XZ axis, only and work well, i can think about.

 

I agree with you, for sure. But why one axis - Y - is the HUGE problem if we have a nav system in 2 axis - XZ?

Just to clarify - i ll not do nothing 'huge', i ll simulate it - will be a FAKE huge (i ll drop the overall scale to avoid problems).

 

You do not need a pathfinding system just to move an object.

A navmesh's job isn't to move an object. It is to find a path from one place to another around any obstructions. In space there are almost no obstructions.

 

I read some articles about scaling in Unity, problems that big worlds encounter in all engines. So - watching some games - I realized that the general scale was 'downsized' to suppress any bugs or limitations of these engines. The 'huge' - maybe I should have mentioned this better (unfortunately I'm using google translate and I'm also here to 'rearrange ideas with experienced people' - you). My 'huge' will be something like a 'fake new'. My huge will be, for example, for a planet 60 units. I will focus on the 'minimum' but my concern is finding or encountering 'jitter' (is that the name?) in relatively small objects (0.01 of a unit). Another would be texture, light/shadow.

 

In 3 axis, yes, i need Its a nice idea, no? Maybe hard to implement in Unity, but nice

 

I was thinking something, you is right, in really i dont need a vol.nav. Eve avoid it to big objects, but they have a system, actually, to avoid small objects. In another way, games like Infinite Lagrange, Battlestar Galactica Deadlock, for exemple, work only with approximations in a 2d plane, the 3d sensation is made by the camera that can orbit objects. That would, of course, make things infinitely simpler. Still, Battlestar Galactica allows for height adjustments (Y) - as if each object carries or takes with it two navigation planes for control.

 

Could be getting lost in translation. I don't understand what the nice idea is.

But I agree with JoNax97. You're talking about still learning C# but you're trying to tackle intermediate and advanced problems without even knowing whether or not they matter.
You really need to start by building some really simple bits and learning from it.

As a suggestiob, start by putting your small and large objects in a scene with the sizes you want and write a script to get one to orbit the other (without any parenting tricks). Just sehow it goes.

 

https://gamedevelopment.tutsplus.com/series/understanding-steering-behaviors--gamedev-12732
Read this. Perhaps in your case, steering algorithm will suffice instead of full A* pathfinding. "Seek" the set target in 3d + some kind of avoidance