next »

[nestoriaan]

The next feature in the pipeline for Corsair was docking. Ever since we introduced the concept of smaller support ships (in contrast to the large module built capital ships that are the bread and butter of the game) we have discussed how we should handle docking. We really wanted to have the possibility for a capital ship to carry a number of smaller support ships (for example mining shuttles or fighters).

A docked Margay shuttle.

How exactly this should work in the game has gone through several iterations. First we had an idea about special docking modules in the form of platforms. Later we tried actual hangar bays with doors that could open and close. Finally (unless we change our mind again ) we settled for a simpler solution and decided to use existing connectors as possible docking points.

Docking dampers being modelled.

As long as a connector is not blocked by something, a support ship can attach itself to it using it's docking dampers. When docked the pilot of the support ship can chose between sitting in the shuttle, or in the capital ship bridge (or cycle around between seats if more shuttles are docked with the same capital ship).

The docking process.

It is of course still possible to store support ships in a capital ship's cargo hold, but these will take longer time to launch since you need to manually place them on connectors (or if you want to make it even more difficult, drop them in space and make EVAs to reach them).

A shuttle piggy backing on a capital ship.

[Zireael]

I like the art style and the modularity. I saw a demo mentioned upthread but no apparent download link...

[nestoriaan]

Hi!

Nice that you like the style of our game!

The demo is quite outdated by now. It's web-based (so no download, but unfortunately Chrome only) and can be found on our web site.

Here's the direct link:
https://alpha.corsair-game.net/demo

Much has happened since then, as you will notice if you try it. We have migrated to Unity and updated almost all of the features in the game.

[nestoriaan]

The old mining system in the web demo wasn't awful, but when we migrated to Unity and changed a lot of other things, not the least the look of the game, it felt strange having the Spaceman shooting oversized mining drones towards asteroids with what was essentially only bare hands.

We had already toyed with the idea of a dedicated mining shuttle (the Skimmer), and after we finished the docking feature it fell naturally to let the mining shuttle land on an asteroid and mine for resources directly. This however required a somewhat redesigned shuttle with foldable landing legs.

The landing legs on the Skimmer.

We kept the mining drone concept, but changed these into something the player can manufacture in a Habitat and drop manually in space.

A mining drone flying towards an asteroid.

If they are dropped from an inventory they will scan their surroundings for nearby asteroids and automatically fly towards the nearest one, if it's within range.

A mining drone extracting resources.

When a mining shuttle or mining drone has landed and started mining, resources will now and then appear in the vehicle's inventory until it's full.

A Skimmer shuttle drilling for resources on an asteroid.

[nestoriaan]

Even if we had a damage system of sorts in the old web demo, it was always a very crude one. In the demo, modules could be detached from a construction as the result of weapon fire, but they could never be damaged or destroyed themselves.

A Lynx shuttle taking damage.

This was of course a simplification and we have now created a much more interesting damage system. Now weapons, collisions, explosions and engine exhaust all give damage to modules. Every module has an armour rating (the number of hits that are ignored) and a hit point number. Modules that have lost a few hit points are superficially damaged, but continue to function as normal. If they loose more hit points they become lightly damaged, a state that negatively effects their functionality. If they loose even more hit points they become severely damage, a state that usually results in total malfunction of the module. Finally if all the hit points are lost the module is destroyed.

A lightly damaged A4 cargo hold module.

Tanks are special in that they can explode. The more damage they sustain the higher the risk of explosion is. If a tank blows up it will damage nearby modules and usually cause massive amounts of damage to a ship or space station.

A Lynx shuttle colliding with a cargo hold, damaging both.

[NineTattooedDragons]

Looking great. Any chance of a first-person view? Nothing like building a ship, then being able to walk around inside it.

[nestoriaan]

Hi and thank you!

We have actually thought about having module interiors in the game. We agree that it would be great fun to be able to walk (float?) around inside the ships and space stations.

This would however demand a copious amount of work, since the interior of every module and support ship would have to be created (and not the least be designed in a logical way).

A first step in this direction could be to create 3D-cockpits where the player have the ability to look around, but we have chosen to first focus on the core elements of the game (resource gathering, manufacturing, module building, exploration and NPCs).

[nestoriaan]

With the damage system implemented the next logical step was to create some form of weapon. The goal at this point in time was not to create a complex array of armaments, but just to get something simple into the game that we could play around with.

A tank blows up as the result of cannon fire.

What we ended up with was a very basic cannon that fires two projectiles every second. As of now the Ishtar module and the Banshee fighter have been given this weapon function.

A Banshee attacking.

Despite the simplicity it is surprisingly fun to shoot things, especially tanks that can blow up!

A Banshee fighter leaves after having attacked a large construction.

[nestoriaan]

Sometimes in gamedev you have to take a step backwards in order to move ahead, even if that means abandoning work you were quite pleased with.

After having created a number of textured asteroids with normal and AO-maps, we ran into problems regarding colliders. It turned out that our requirements for the asteroids were difficult to achieve with the present design.

On the one hand we needed asteroids that were movable objects in the physics world, but we also wanted to land on them with mining shuttles and drones. Since physics objects in Unity need to have convex colliders with a limited number of triangles (maximum of 255), these two requirements did not add up. If we used simplified colliders for our asteroids, landing on them would look bad in many cases.

To solve the problem we chose to make simpler asteroids made up of several low-poly segments. This also made it possible to procedually create varied asteroids, something we always wanted to do but had posponed.

A test with procedurally generated low poly asteroids.

These new asteroids are of course much less realistic looking than both the original ones and the ones we made with normal and AO-maps, but in a way this look is more in line with the clean art style we have chosen for the rest of the game.

The new asteroids in the game.