MKelm / mct

"Mass Control Tycoon" a GPL game for Windows, Mac and Linux
Other
5 stars 1 forks source link

Planet grid, areas and layers #37

Open MKelm opened 10 years ago

MKelm commented 10 years ago

The idea is not a new one, I had it some days ago ... I call it planet grid, areas and layers ....

The planet grid should be an important coordinate system for the planet. Here is a 3D planet grid but the game has a 2D planet, so it gets a 2D grid with a mask by the planet radius. The grid nodes have a specific distance to each other, and border nodes must have the half of this distance value to the border to be visible.

The planet view is very simplified view, because it ignores that planets are spheres. We have the area of a circle with a grid. And the player can put his factories / offices onto it. And the planet grid should contain nodes for distributors and other related objects the player can use in his planet business process.

Ah I have it, we can add an object for every game function, like an investment center for the investment functions, and a mafia / politics center and so on. And if the player has the focus on a specific planet he can press a hot key to navigate / zoom (more) in to the related object.

So a combination of the planets and planet view is useful to use the zoom function described for the plantes view in both views and to display more planets if the zoom level is higher, and to display more planet details if the zoom level is lower. That needs some more display logic indeed and the texture resolutions for a planet must be far higher than currently. And trade/extension connections have to get a space (connection) outpost to handle trade/extension ship traffice or something like that there. And another idea, maybe the player can use mercenaries for transports from space outposts ...

The grid nodes should get an additional information, about a grid area type with a specific radius, and each area type has another texture. So we can create planet maps/grids out of definition files with area information. It might reduce the effort to design area textures than a whole planet ... we need one set of area greyscale images and color overlay images for each planet only ... The area type should have an impact on the game mechanics ... like water is a non-build area ... and the planets can have different sizes ... but it needs a planet editor/builder tool to create json files with such a high amount of data, e.g. if a planet have 500 grid nodes or more ...

... so we can have object related data and area type related data for each grid node yet. Aaaand, we have layers, one, two, three, ore more, I do not know, but each layer needs more grid node data related to the layer.

Layers are like the Sim City data layers we can use a type of color map with color levels for each area/grid node and can replace the planet color layer images with different data layer color layer images depending on data values and each layer has another data source.

So layers can have data like in Sim City e.g. crime, so it is more like a Sim Earth in relation to this feature ... the layers visualize e.g. the effect of different problems for the own business on a planet more or less high in different zones. The different data / layers types can have different effects on the market, if they are higher or lower ...

Open for comments ....

I put it on the alpha1 milestone, but not all features of it can be implemented there, so I will to open a new issue for further implementations after the alpha1 milestone.

MKelm commented 10 years ago

Aims for alpha1:

*the grid density in a view without zoom should be less than in a later zoomable version of the planet view, related to the visibility and click-ability of objects

The first aims will make it possible to implement more basic features of the concept.

Alpha 2 can contain the first version of the area map layer and alpha 3 first data layers.

MKelm commented 10 years ago

I have added the first version of the planet grid, more about it here https://github.com/mctteam/mct/issues/18

The planet grid has two scale factors the first scale factor is a parameter of the planet class to calculate the grid units by using a predefined units amount to get a fixed density of grid nodes, the second scale factor is in the display logic which is 95% of the planet scale factor.

So the outer grid nodes has enough space to the border on every planet independent from the planet size, the planet needs another type of planet grid, which will have a min / max radius, to set an orbit ring to place space infrastructure objects (products)

MKelm commented 10 years ago

The border exists no longer, because the current planet image is just a simple background image of the planet grid, so the background can not be larger than the grid. I will add a better solution if planets will get map elements.

The game contains two grids now, in a new space scene with a space and planet element. A space grid and the planet grid. And it is possible to set DisplayObjects of an element layout inside a new layout part of another element. The planet layout is visually linked in the space layout now.

To make positioning of space grid elements (planets) easier, DisplayObjects in layouts have a center option now, and single graphic display objects too. E.g. the planet center point will be on a space grid point, but the planet can still has it's own grid points with all related layout features.

Another feature is to zoom the space grid/element, that makes it possible to view planets in detail, and the space have a move interaction on mouse down, which moves all contents (planets) too.