Hello. I hope I got this topic in the right section. I have a question about Unity3D.

I've made this scenery that has several prefabs (stars) generated automatically that basically represent a solar system in the galactic map. My noob question is, how can I associate to each of these objects a random number of planets that show up in the UI when I click them. I was thinking about using text files with the names of the systems/planets, but from this on I am stuck. Should I use a database where the game will store planets/ships/other objects and update them as the game progresses? What would be the best approach for this problem? Any help would be appreciated.

The reason I'm asking is because the RTS/4X Unity tutorials aren't really that many and don't cover some of the more advanced stuff, so I was hoping I'd get an idea here. I've attached an image of what I'm hoping to achieve.

So I have some stars displayed, and now I need each of them to contain several planets and other things, like fleets, structures etc. My problem is, I don't have many ideas how to do this, since I'm new to game development and programming in C#. Again, any idea would be helpful.

[attachment=31147:Planets.png]

Thanks in advance!

So, one way to do this, is to seed the random number generator when you click, with some deterministic value. For example, you could do a hash of the name of the planetary system.

Then when the user clicks, it could be something like:

GeneratePlanets(seedvalue)
{
  Random.seed = seedvalue;
  var numPlanets = Random.Range(MinPlanets, MaxPlanets);

  for(var i = 0; i < numPlanets; ++i)
  {
      //instantiate a planet, use Random again to determine its values
  }

}

That should give you the same planets as long as the seed was the same (and no one else is doing anything with random on another thread.

EDIT: PS. Unity has a built in hash function StringToHash

If you are going to re-invent the wheel, and it may need re-inventing, first look at a wheel.

I have been procedurally generating galaxies since the 80's, and so have a lot of other people.

Start by reading up on the subject, there are a hell of a lot of sites which cover it.

Start with pages like this.

http://blog.rabidgremlin.com/2015/01/14/procedural-content-generation-creating-a-universe/

Then move on to pages like this.

http://stainlessbeer.weebly.com/planets-1-mercators.html

When you start to understand them. you can then dive in and re-invent the wheel.

I like hexagons myself. You would have to modify the roads to accommodate hexagonal wheels, but they have a lot of advantages over standard designs.

Wow, thank you both so much! It's more than I had in mind.

I'll make good use of this info.

If you look at the algorithms for most random name generators, typically the way they work is through some sort of schematic or pattern semantic.

Observe...

The Milky Way

The Semantic here is

The [Aspect] [Word]

You have a dictionary for a whole category of different words for each item. Aspect will be things that describes the galaxy, or reasons the galaxy was named. Word is simply something to throw in that feels appropriate. I don't know how you would categorize "way".

The Lyana Spial

The Spindel Galaxy

[Three Random Chars] [Random 16bit Hex]

HIP 0bb4

[Name] [Number]

Kepler 1882

As for displaying information. You can hold all relevant information in structures.

Thank you for your help.

Right now I'm considering using SQLite to store all the data the main game will have. There's going to be a lot of data in the game besides planets, so I believe this would be the best approach.

I hope I'm not wrong.

Thank you all again. This was all very helpful.

SQL lite is taking a sledge hammer, gluing it to a nuclear war head, and dropping it on an ant mound to cut paper. In case you don't know what I just said, you're over complicating a simple problem. You can just use a simpler option and edit it with a text pad.

If you get your design correct, you only need to store changes that are created by game play.

Say you want to display a star map of the local area. You define a function that determines if a star exists at a location. This function creates a random number seed from the location and uses this to generate a random number.

If it's bigger than X, a star exists.

This will never change because the seed is calculated from a position.

So instead of having to search through a database looking for all stars within a given range of (x,y,z), building a list of results, parsing them..........

You just do a quick and simple check on the locations you need to.

Databases are evil when it comes to these types of games.

Just think about how much data you would need to store.

A billion stars in the universe (small universe....) 1 billion bytes just for star type. Then names, spectral parameters, planets, towns, cities, people.........

Are you planning to ship this game with a quantum file storage device ? Of course not. So stop thinking about storing information you don't need to and start thinking procedurally.

SQL lite is taking a sledge hammer, gluing it to a nuclear war head, and dropping it on an ant mound to cut paper. In case you don't know what I just said, you're over complicating a simple problem.

Databases are evil when it comes to these types of games.

Well, this is my first "big" Unity experiment/project. I'm rather new at this, so thanks for pointing this out. I'll make sure to stay away from the evil databases.

I'll look into procedural generation and PlayerPrefs instead.

SQL databases are not bad, they just operate under different assumptions and serve a different purpose than games. Many games use databases for certain things.

SQL-based databases are usually based on queries and are generally built so they search for data spread across multiple sets of data, and frequently will jump out to disk. The queries take time to run, on the order of 10ms, 50ms, or sometimes longer. They can be viewed by many different tools.

Information like player account information and login details that are rarely accessed are great for these databases. The game can look at the details using SQL calls, the web site can look at the details, the billing and accounting system can look at the details.

For reasons that should be clear, since an SQL database query can take multiple graphics frames to run, these requests should be run in the background while the data is fetched.

Long-running persistent games (like MMORPGs) store quite a lot of the persistent data in SQL databases. It is loaded from the database into the game world when you log in, and whenever you pass a checkpoint or key event the data gets written. The data is not used moment-to-moment, more like a save file.

Game data used in the game is generally implemented as data sets in code that can be looked up on the order of nanoseconds as collection containers, game objects, or other arrays and pointers and whatnot. This data is held in main memory and directly accessed.