Multiple map locations

[vogonistic]

With the grand exception of Dwarf Fortress that has z-levels, most tile based games only have a single map and location.

I suggest we decouple the tiles and map data from our World object so that we can have multiple locations.

All locations would run their simulations all the time, but we only show one. It will allow our brave and probably soon to be dead (space-dysentery?) crew to embark on mining, trading and other missions. We can add a new map locations and allow the user to switch between the different locations at will. We could even use it to add more z-levels to the astroids, in case we want to go the direction of space dwarfs.

I feel that it brings something new to this genre and I'd love to figure out what we could do with it.

What do you guys think?

[fre-ber]

Sounds like a good idea to me. In my project I have no World class, instead my GameController singleton has a SiteManager that can keep track of several Site objects and I guess that the Site class is more or less equivalent to the World class here.

[koosemose]

I suppose the question is, "What does it add to gameplay?" Obviously we don't want to just add multiple maps solely because it's different, it needs to add something to gameplay.

Just a few thoughts to discuss to get things going: I assume we don't just want multiple "space" maps as that would be little more than an alternative way to achieve a bigger map, and doesn't really add all that much. Being able to go down to the planet is an obvious option, but then we need to answer the question of why the character's aren't settling the planet (if they can I think it would change the game from a "Space Base Building Game" to "Like Rimworld, but you can have a space station too"). One potential solution is that the planet is hostile in some way (perhaps eventually the game could even have different types of hostile planets, or even no planet, or rather no planet they can go down to, such as a Gas Giant, for greater difficulty), which would also allow us to not have quite as involved planet generation as something like Rimworld, since, presumably, a planet hostile to human life is likely to be hostile to all life and therefore not have as much variation.

An asteroid belt could be somewhat interesting, thought it would, to a degree, just be space but with more rocks. Obviously we wouldn't want a realistic asteroid belt, as that would just be empty space but with one rock in it.

I'm not sure what other sorts of locations would be reasonably different from empty space, perhaps other planets or moons in the system. If we can come up with a reasonable variety of location types we could even have an "Exploration Tree", either done like research typically is in this sort of game (except rather than sitting at a workstation, the go to a ship that leaves the map for a time period and comes back when they're done working, and eventually succeed in discovering a new location. Or it could be done interactively, where you have to do certain things at a given location to gain access to other locations that branch from there. So you start with just access to the station, build a landing craft that get's you access to the planet, or build a scout that can get you to that planets moon (or perhaps each is an upgrade of the same shuttle. Then you build, for example, a refueling station, and you can get to the next planet, or anomaly or whatever. And so on. You could potentially even combine them, so you have to build the prerequisite, then the character spends some time off map "exploring" before discovering the next one.

To keep it interesting you could make the tree semirandom (procedural rather than just picking each node of the tree from all options at random). If we have different types of planets available, the starting planet could be either random or chosen from a list (at players option or according to a scenario) since it would be feasible if a space station were being built as a hub for a mining operation or whatever, they would know and somewhat control what kind of planet it was). I think a procedural exploration tree would be a really good use of multiple maps if we can create enough different options for the nodes, and keep things fresh so every playthrough isn't just the same progression just with a different coat of paint.

[fre-ber]

I think that it would be cool to be able to set up multiple space stations in different locations around the solar system - different planets will have different types of resources and rather than shipping the raw ores back to the main base, you build a local refineries and just ship the enriched materials or even finished goods.

[Sommerbo]

Very early on Quill mentioned that each "world" could be used as a different z-level. I think that is a great idea.

[vogonistic]

@koosemose I feel like you convinced yourself why in your post.

To me, it provides gameplay options.

• In a campaign mode, we could show animated scenes from before or other locations.
• We can create traveling spaceships
• We can make multi level buildings
• We can have planet landings
• We can raid other bases
• Travel could be based on sending our stuff to someone else for trading

The way I see it, there are a lot of things that we could do, but if we don't do something like this, then all the resources, pirates, asteroids and events will have to happen on the map where we are.

[GamerInspired]

I feel like having multiple maps (having the option at least) allows far greater opportunities for this game. As @vogonistic mentioned, so I would think that this would be worth doing.

[WardBenjamin]

As far as the game design and story, you might want to move to #431, and to keep implementation discussion here. Sounds great, guys!

[koosemose]

I want so much looking for convincing, as asking questions I think we need to consider. Much of my thoughts on the matter hinges on us being able to come up with a reasonable amount of distinct and interesting locations outside of just different planet types and multiple space stations, and I don't presently have any idea what most of those locations would be. Or if even that many carried locations would be desirable as it might pull away from the concept of base building.

[Sommerbo]

I like multiple map locations for Z-levels, I don't see the need for multiple other locations except way in the future. If we resolve z-levels then new locations could easily be added by modders. Of course some stuff must be exposed to LUA and maybe some worldsettings.

[Grenkin1988]

Such a tasty task to those who like challenges :-)

[vogonistic]

I added an item to feathub for people to vote on this: http://feathub.com/TeamPorcupine/ProjectPorcupine/+13

[alexanderfast]

I added a similar one. Maybe the should be combined. Or specialized. You seem to focus on z levels. I talk about taking your base to a new map.

[vogonistic]

@Mizipzor I'm not really focused on z-levels. I just want the decoupling of World and Map so we can have multiple maps in the same game and z-levels is just a convenient example.

If there is a difference between ours, it's that I want the multiple maps to be both active and simulated at the same time, while yours seems to be one at a time.

[alexanderfast]

Well put. I like that. :)

[fre-ber]

I still think that "World" is not the right word for the "One True Thing That Holds Everything Together (tm)". A World is, in my mind, too closely related to a planet and keeping that name would make it awkward to add multiple planets in addition to Z-levels.

So instead of breaking the Map out of World I recommend a structure like a SiteManager managing Site objects. Alternatively LocationManager and Location respectively. Site/Location would hold the map, the workers, the job queue, etc. The SiteManager/LocationManager would then hold one or more Site/Location objects.

Taking it one step further, the object that I think could be that "One True Thing That Holds Everything Together (tm)" is the GameController, and that could hold a, possibly static, reference to the SiteManager/LocationManager for easy access.

[fre-ber]

Is anyone working on this or have we not yet decided if we want it? Should I have a go at implementing it?

I was thinking of adding classes SiteManager, Site and Level. The WorldController would hold a reference to a SiteManager object and the SiteManager would keep track of a collection of Site objects and a property "CurrentSite". Each Site object would contain the job queue and a collection of Level objects. Each Level object would hold a map and all things needed for a single Z-level of a site.

The first step of development would make the WorldController have properties that act as shorthand for getting at things in the first level of the current site so that this first round doesn't break everything.

[alexanderfast]

Label has been added, removing text tag.

[donoya]

How is this progressing? I tried to do this a while back with my own game that was using some code from the original tutorial series (episode 7), but I couldn't get it to work. I've been stuck ever since.

[Skalicon]

I love the idea of Z levels as different levels of the space station. This is however a bit different from separate maps since simulation needs to happen simultaneously with levels, but not necessarily with separate locations.

[vogonistic]

If we implement the multiple z-levels, then all we need is a boolean to disable simulation to support the different locations.

The PR that was working on it #681 was closed without being merged, so there hasn't been much direct progress on this issue, but it's probably not a 0.1 issue unless a lot of support for it shows up really quickly, or we run out of complicated things to do.

[Skalicon]

Getting this done early will mean that we can make sure that future development is made with Z levels in mind, and prevent double dipping from going back to make functionality support this change. Since it's a core system it could effect a lot of systems, for example, utilities like power and water, or even basic airlocking, it we consider the possibility of breaking roof or floor tiles to break airlocks or combine airlocks over multiple levels.