I finished up the fast and loose galaxy editor v.0.0.1 this morning. It’s certainly not glamourous, but it’s functional, and that’s what modern development is supposed to be, right? Make it work, refine it. Make it work, refine it…ad nauseum.

FlexLayout

The first thing to talk about is FlexLayout.

FlexLayout is a way of defining a modular layout for an app. It uses a nested JSON configuration to generate “panels” which can be dragged and dropped within the window to create different layouts of the user’s choosing. It also provides the ability to drag and resize dividers. While my job is to create an initial layout that looks nice and presents everything where I think it should live, FlexLayout allows users to re-arrange the panels to fit their own workflow style.

That being said, I’d also like to disable this functionality if I can, because my layout is the best layout.

Galaxy Management

The Galaxy Management screen is where things start. Here, I have the “Big Bang” button at the top which will generate a whole new galaxy, but if there’s data in the database, the lower-left panel will populate with three tabs worth of data (the last tab, jump gates, isn’t complete yet as that generative system is undergoing review).

The first panel lists all sectors. I always vacillate between “Sectors” and “Systems”; technically a sector is a slice of a larger piece, while a system in this context would be a solar system, so I might favor system over sector eventually. The data in the sectors tab is very basic, and not finalized; it’s useful for testing but is kind of garbage for a working game. Each sector has an ID for internal use, and a tag which will be how we pass references between the client and server. The name is, of course, how the sector will be displayed to the user. The [x,y] field is where a sector lives in the theoretical layout of the galaxy, and is critical for working with the jump gates. Major and Minor indicates if the sector is a major or minor hub, and this also affects the jump gate generation. The Star is the type of star in the sector, and which I hope to use to affect the planetary composition during generation, but I need to do more research on that. Finally, the sector’s Status indicates the general state of the sector. This will affect a player’s ability to move through the sector, as certain statuses will make things easier, more difficult, or downright dangerous.

The edit form allows me to change all of the data except the ID, although right now there’s no validation behind the mask. I could, for example, put sector 65 above into the [x,y] of another sector and the app wouldn’t complain. The goal of this UI (and the others as well) is to be able to tweak settings, and not perform a wholesale update of every data point in the database. Eventually sectors will have better ID values, better tags, and nicer names assigned to them during the Big Bang. But if I ever need to move a sector or find that the galaxy is too generous with G-class stars, I can make adjustments as needed.

Next is the Planets editor. Of all the existing data generation processes, this one is going to need the most revision because there’s a lot that goes into being a planet. Right now, I have the same ID, Tag, and Name fields as sectors have. Here, I also have the Sector ID which holds a planet.

Then comes the Orbit, Type, and Sub-type values. Right now, these assignments are standardized and very general. A sector can have up to 8 planets, or orbits. In each orbit, there’s a 50% chance of having any planet at all. Each orbit value, should it be assigned a planet, will have specific planet types, and some of those will have sub-types. Orbits 1, 2, 3, and 4 have terrestrial planets. Orbits 5 and 6 will have gas planets, and orbits 7 and 8 will have ice planets. Within orbits 1,2, 3, and 4, a terrestrial planet can be metallic or rocky sub-type, but orbit 3 — modeled after our own solar system — can have a third sub-type: temperate. Right now, planets in the other orbits do not have sub-types, but I hope to break down gas into different gas types, and ice into different ice types. What I want to do is to build on this generation by looking at the assigned star type and then using reference info, decide which orbit actually gets which types of planets.

The Habitable and Population values are super-generalized right now. While T/T (terrestrial temperate) planets are habitable for humans, it’s not impossible for humans to have colonies on other, less naturally hospitable worlds. Any planet can be “habitable”, but it’s a matter of setting population expectations accordingly. A temperate world could have billions of people, while a terrestrial rocky planet could have low millions, and a gas planet only a few thousand living in stations in the upper atmosphere.

The last editor I have is for Stations. These are super-rudimentary because I don’t really know how these are going to work. I mean, yes, I know: stations are gateways to services like shipyards, markets, banks, and rumor-mills. As they are just representations on the map that players will click on to access services, there’s not a lot going on. I might eventually want to add a way to upload or cycle through different icons or images representing the station, and I haven’t even touched the “faction” system yet which will play a part in a player’s ability to Do Business, so there’s a lot more to add to this section.