The Viscosity of Work, somewhat wrong Warcows and Fields of Focus. Also Orbits… yeah.

There seems to have been a sudden spike in views on this blog. A very unusual one, that I can not trace back to myself, refreshing over and over.

So - hello to all you new arrivals, I really wish I could show off more, but here we go.

I recently devoted a lot of my time to adding Orbits to the overall mechanics (since this should be a core element), and this made me re-think my focus. While I thought about presenting the Player with a 'Galactic Cluster' of around 1024 stars (with probably way more possible), the whole thing would not have gone very well with the focus on tactics and detail. Also I want asteroid colonies… several thousand asteroids per solar system (or of every second one… it doesn't really change much there.) would be possible to randomly generate, save and load when relevant, but the tactical depth of such a 'terrain' would become null and void, the moment ships could just FTL in and out at will. Also all the potential of orbital mechanics would go to waste.

Also I wrote a little script to shovel stars, exoplanets and other known objects from various catalogues into the xml-format I decided to use for saving things, and it turned out to be a potentially huge project in itself. Just parsing the Saturn-system with all it's bodies is far simpler for a start, so that's what I decided to use for now.

This being said, multiple star-systems could potentially make a comeback at a later stage, when more important things are working.

On Orbital Mechanics:

I'm still working on automatically generating the correct Orbits for Saturnian bodies from the data I can make the program extract from real catalogues. Until that's working, I'm testing the whole thing with random objects and orbits.

And it works.

As of now, all objects except the center of attraction are N-bodies that interact (with limits) are theoretically able to collide, have their orbits altered, and/or their mass changed.

I've also recorded a video to illustrate the Orbital-Module better.

Another big part I still have to figure out is how to adequately represent a complex map like the Saturn-system, making it useable and looking good without ruining too much of the potential realism I could get in by using real catalogue-data to generate the model, what would be content for a future post.

Also using the vector -module to visualize the Orbits got me thinking about other features, such as…

On shiphandling:

I'm still undecided what shiphandling should be in, what would be too gimmicky, and what would be a good Idea. The problem with such features is, that one can not test them on an early stage very well, and all are equally possible. 

Some examples: The ships in short range are being rendered per part, including their interiors and eventual damage maps plus crew moving trough them.

Just placing the Camera inside would offer a lot of interesting, but potentially very useless features, such as a 'walktrough' mode and a 'cockpit' view. 

Since the Player is probably busy sending around damage-control crews, giving orders, selecting targets and brooding over deeper tactical decisions (such as stop spinning, to be able to dodge kinetics better, while potentially taking more laser damage), or even issuing Commands to ships within the same squadron. Also vessels seldom face each other, neither do they come close enough to be actually visible, making a cockpit view a exercise in 3D interface design, or a pointless (but possibly quite fun) endeavour of staring into blackness.

I will write up a list of currently planned features, and put it up as a additional page on this blog, right after I finish writing this.

Anyway, the following actions are within the core concept:

• Decide facing and Orientation of one's own ship. This includes spinning to evenly distribute ablation and heat from incoming lasers, and probably using certain drives as offensive weapons. (I've still got to do my research on the actual usefulness here)
• Send crewmen around. Also a big 'strap down' button for sudden accelerations.
• Alert-states, also known as 'Battlestations' and 'Seal these goddamn suits"
• Damage control issues, depressurizing sections, fighting fires, trying to hotfix critical systems, manually do things with failed automation, rescuing crewmen from hazardous areas.
• Deploy and eventually control Drones and other automated parasite vehicles.
• Give general commands to subordinate ships when in a Squadron.

Also:

• Plot transfers,
• Dock with friendly bases,
• refit, repair and exchange modules and their loadouts
• hire crew, send them on leave, keep their stress level low, discipline them if neccesary
• obtain fuel and supplies
• push trade-goods around
• Also potentially building and mining should be possible.

The wrong Warcow, or «we need a look»

I have also tried out various ways of texturing, trying to keep the look of ones ship as customizeable  and as constant as possible at the same time. My primary Idea is to use a single textured cylinder that would be projected onto the ship's hull, to maintain consistency between the various modules used, with them having a selection of details that would be imposed over the map that would have been generated that way.

This approach currently has the significant drawback of textures wrapping wrong around points and rounded surfaces (such as nosecones, spherical tanks, toroid forms and their like)

I also added a sort-of freestyle texturing session, but I'm currently not satisfied with the results.

 I'm currently not sure, but I'm also fantasizing with just going with the graph-paper look I used in previous images, if I can't come up with satisfying textures. (I'm fairly certain I will ;) but just in case)

Yeah, that's it for now. I don't know if it's too early to ask people for feedback, but I suppose such will emerge once the Project reaches the 'right' stage for something like that.

Performance, Python and the glorious battle of the Spherical War Cows.

I really wish I could tell a lot of things I have achieved in the past weeks, but I rather save it for the next update.
You know, sometimes life happens, but there is a couple of things I have got.

At the moment it's absolutely possible to run a text-based version of the game, but aiming proves kind of difficult by typing cartesians, especially without visual representations, also I have discovered that my choice of keeping the single parts of it that separate also has it's merits, since the BGE still seems to have trouble with some Graphics Cards, left alone multithreading.
At this point, there is one single module containing about 12 functions that connect the 'game' to Blender's OpenGL 'Game-Engine', and with rewriting said module, the whole thing could virtually be ported to any other front-end over night, especially since I had to rewrite parts of how it handles physics since - it turns out that Bullet is rubbish for simulating orbital mechanics. Who would have thought.

After browsing the Kepler star-catalogue, and a list of known exoplanets, I have decided to ditch the procedurally generated galaxy in favor of our familiar local bubble, simply because it's entirely possible, and games like Elite set the standard. Now the function that used to place stars with one of three algorithms, written to create appealing star formations also places stars the 'boring' way, by picking coordinates and names from a save file (rather than rolling dice), meaning that random generation will still be an option, hence not the default one.

The jump from february's version to may's also revealed how combat might feel in the finished game, in short - there ought to be a detailed tutorial, because the mechanics I decided to put in are pretty unusual, and can potentially become very complex. Imagine slowly rolling your ship to distribute incoming laser-heating and therefore prolonging the lifetime of it's hull while sacrificing the ability to effectively dodge big kinetics, or shielding your radiators with your ship's hull, potentially rendering some of it's turrets less usable.

At the moment it begins to look (Hey, I'm curious as well) like a bizarre cross between Starfleet Battles, FTL and Tower Defense.

Further decisions - commanding multiple ships will probably happen more often than initially planned, with detailed control only being available for the player's ship. Reasons for that is the expected complexity of micromanaging one ship, and the general survivability of the player.
Difficulty will be resolved by a Space-Opera slider in the options menu, probably similar to the difficulty settings seen in the Silent Hunter series, with high settings in Space Opera making instakills and heat death far less likely, while they will probably be the norm on lesser settings. This ought to be intensively tested though, especially since potential instakill sounds like a real no-fun thing to me.

Depending on how friendly life is to my time within the next weeks, we might even be able to see the first playable demo emerge.

Wish me luck.

More about ships.

While the galaxy-map plus it's generation come along nicely, I am also working on the shipbuilder, and general shiphandling system. The ships will be put together by using a varying set of modules (dependant on the port where the re-fitting or building is done), each with different attributes and options.
The whole thing will start with a cockpit (usually contains two seats, some with a payload option to add two more), and a number of hardpoints where further parts can be put.

Here are some sample configurations I mocked up while trying out the code for the actual shipbuilding module.

The lower two ships could be considered the Universe's equivalent to other places' spacefighter with crews from 2 to 8 individuals, possibly 10, while the upper two could be considered small 'starships' (or 'destroyers' if you like spaceboats).

While the shipbuilder has quite a way to go yet, there is one more point I've been working on.

The default view of your ship, when it's not docked or landed anywhere will either be the interior (cockpit/cic/wherever), or 'outside' view, from where you can issue commands to your crewmen, and perform all neccesary tasks.
To do this effectively, the 'outside view' will also support a 'cutaway' mode where you can conveniently see inside your ship's sections, and send your crewmen around to man stations, perform repairs, put out fires - pretty much like in FTL, but with 3D graphics.

Starships.

So this will be a game with a multitude of inhabited planets orbiting quite some stars, and somewhat detailed crews to push around… right, there ought to be spacecraft.

 Of course in such a title said spacecraft should be as modular as possible, not only because this allows for a very detailed damage system and more interesting flight-physics, but also because the players can build their own starships from modules. (also the NPCs build their ships from modules, what should be good for quite some variance), but wait, there is more.

I personally deem not space sim complete, when there is not a cockpit view. If you can expect it from semi-historical flight sims, you should be able to expect it from your regular space dogfighting game, even if it makes not that much sense.
From this point on, it's pretty trivial (from a technical standpoint) to allow free movement inside the ship, pretty much like we know it from Silent Hunter 5. But this time in space, and with Role-playing mechanics in it. Interacting with your crew should be one of the most important parts of the game.

Procedural Cluster generation

Since we now have the ability to roll up an arbitrary number of unique planets, we will need stars for these to Orbit.

The basic Idea is that the titular 'Incident' (that's the main plot) only has two to four fixed planets it involves. Although those planets will be randomly generated as well, they will have certain 'hardpoints' from the plot. The course of said metaplot will evolve semi-procedurally, depending on the cluster that was created. Distances and ressource availability may affect the movement of large fleets, this should also influence maximum playtime in a much more elegant and unpredictable way than say a timer.

As said - the cluster will be generated when the player begins a campaign, and will be able to share both - the save file and the seed that generated this particular playing experience.
 

 the Images seen here are all fully generated 3D galaxies with 0 to 3 inhabitet planets per star. This boils down to about 450 - 650 inhabited planets for the whole cluster. (yes, since this is - to a certain part - supposed to be a trading simulation, I want the cluster to be full of inhabited worlds)

Procedural Planet Generation works.

The Planet Generator currently is just a terminal program, but never the less, it's the first Milestone in making "The Taurus Incident" (title could be subject to change).
Currently it is working with lots and lots of text output for me to check for any bugs. Of course the whole thing will run in the Background (to be exact once at startup), when the Cluster is first generated.

Working on Linux has it's merits when working with interpreted Languages such as Python, since it is relatively simple to have a terminal window 'watching' the code (eg. running it in a certain interval) this makes for a dirt-cheap way to get direct feedback on written code and also makes saving a lot a standard practice.

The 'Planet Generator' is currently saving the Planets in a XML-like form to be both - easily query and editable. Currently the 'Cluster' will be generated on start of the game, and players will be able to share their unique Clusters.
This should also provide a conveniant way of modding the game once it's out there - you will just have to edit some xml-files. Installing mods will be as easy as copying a savegame.