Of fleets, scale, and mostly-terrible pencil sketches

[jackS]

So, while doing some figurative spring cleaning, I managed to dredge up some quick (and messy) sketches that I'd done for a VS-art-related expedition in cat-herding back ~2010.
I figured I'd drop them somewhere more visible than where they were interred before I forget them again.

The chief point of the sketches (an attempt at 2D profile, as 3D sketching is, um, beyond me, since most 2D sketching is still a bit beyond me, really) was to do sets of ships from the same faction, at scale, next to each other for a sense of scale and design similarities. Now, these sketches need more than a bit of artistic translation -- which is to say, that the craft in the lower left of

is actually intended to look like the ship on the left of from https://vsdesigndocs.googlecode.com/svn ... _guide.pdf

Also, many of the doodads on the ships hull were meant to be symbolic placeholders for the artists I was working with at the time (indicating shield generator doodads, radiators, etc.) and are NOT intended to be taken literally. But the scale of the ships themselves is mostly right to a first order at ~20000:1 @ the original size of 13"x8.5" (which should yield ~6 km for the length of the largest ship in that image, iirc)

Ships pictured are (as per my notes), from largest to smallest:
Leonidas {it's an artillery piece, really. Well, 3 artillery pieces if you want to get technical.}
Anaxander {built for the wrong war, but still the granddaddy of all modern Aeran cruisers}
Agasicles {shoots the smaller ones so the big boys can specialize}
(frigate, non-specific) {border patrol for the vindictively paranoid} [slightly oversized wrt scale]
(corvette, non-specific) {say hello to my little friend}
Areus {escorts friendly corvettes, antagonizes shipping, biggest of the Aeran smallest} [oversized wrt scale]

I also have one of these sketches for the Rlaan which is self-annotating wrt. scale and which ships are there https://docs.google.com/a/7kelvin.com/v ... jIxOWI1OGE

I seem to recall also having an annotated version of the Rlaan sketch that pointed out what a lot of the (semi-symbolic)structures were intended to be, but I haven't found it as yet, and if I can't find it, I may just have to make another annotated version.

So, fwiw, this is the sort of stuff that I find when I do spring cleaning, so to speak. Make of it what you can/will.

p.s. also - I can't seem to get the bbcode for resizing the image to work *shrug*.

[ezee]

ah ah ah !
THE BIG PICTURE , in all means .


That is very cool , for my VS culture , thank you !
( And your Aeran's colony in the lost sector send praises to you )

Sure , these sketchs will be used as starting point .
Your scaling system will be precious to .
I want to be able to load in Blender actual models ,
then build new ones with their reference .

( I also need to know how is orientation in the VS render engine .
Left or right handed coordinates system ? )

[jackS]

Found the annotated Rlaan image:

https://docs.google.com/a/7kelvin.com/v ... jc4ZWIxY2Q

It labels the repeated bits among the various Rlaan ships

[ezee]

Thank you !

I've been in the wiki and found the page that contains the Aeran's fleet .
http://wiki.vega-strike.org/Category:Produced_By:Aera
If i can't import actual models in Blender , i will use the pictures to make new models
for cinematics .

And i will do the same for the Rlaan .
http://wiki.vega-strike.org/Category:Produced_By:Rlaan

But if we start to make content for the " fraternal war " epoch , there will be room for
new vessels design ( 1000 years before cold sea technology ) ?


I wonder what is the priority for the new 2d com animations .
I made the aeran because Darkvixen was working in the concept , but what specie would
you like to have prior in the com display ?

[jackS]

Well, actually, all of the Aeran ships need new models (if they're going to go along with the art style guide) so I wouldn't fret much about whether or not the existing models can be easily imported to blender -- the only one that's even partially modeled (according to said guide) is the Anaxander I checked into the masters directory in svn. Sadly, it's the Anaxander from page 4, and not the Anaxander from page 5, so there's a lot of additional work to be done to make it pretty.

There's also http://2.7kelvin.com/portfolios/Aeran-A ... eet-makeup. Some browsing on 2.7kelvin (the website I built for working with some external artists (a class at AISF) on a VS-art related project back ~2010) will also uncover some general musings(See: general guidelines column) on VS spaceship design in general as well as specific to various species/factions that is, at least, internally consistent with the circa 2010 Aeran style guide I linked to in an earlier post in this thread.

That said, there's also a very clear question of goals to be answered before going down a rabbit(modeling) hole, so to speak -- the two tasks of highest long term utility, albeit of lesser immediate game-effect, would be to:
A) do first-order mockups of a larger number of Aeran craft (rather than detailed models of a smaller number) so that the general Aeran aesthetic is clearly available in a 3D format for all future artists.
B) deconstruct said mockups into a (preliminary) library of (external - and possibly internal) building block parts that function akin to a custom "build-your-own-Aeran-ship" Lego set.
I have some (non-Aeran) example images I'll fish out of my old e-mails from the period to explain what I mean by B.

A), however, I think is much more important than anything else. VS has lots of models. Many of them are even quite aesthetically pleasing. What we don't have is a set of well defined art guides and associated examples that effectively document what we were hoping to achieve in ways that are easily communicated to those not 1) already intimately familiar with VS and 2) in a more universal, visual, language. Without A), it would be very difficult to, for instance, task artists with making vessels that evoke similar motifs indicative of a given designing group, but are from a distinct time period or for purposes not yet imagined in the game so far.

A) is an infrastructure building task, and, as such is often considered a bit thankless -- we certainly suffered from similar things at the engine level by skipping directly to implementing things rather than building the tools or doing better organization via data-driven approaches that would have made future tasks (generating content, doing translations) easier. However, while I wouldn't dream of asking you to not build pretty and complete models, I'm compelled to mention my opinion that the scaffolding work of tasks like A) might be more useful to VS in the long run.

Speaking of motifs, part of the 2010 efforts was to try to do some high-level silhouette re-design (it would invalidate most existing models, fwiw, although most existing models are already highly non-canonical, so that never bothered me ). I'll try to see if I can dredge up any of the actual commentary. If not, I can summarize one of the key points fairly quickly. The Human/Aeran/Rlaan/Uln ships were to be redesigned such that they could easily be distinguished in silhouette in terms of engine placement: Aeran - primary engines along central axis of movement, Human - primary engines at the end of projections perpendicular to central axis at 90 degrees, Rlaan - what engines? = bulbous protrusions with shield-like bits built around reactors at various points around the vessel, Uln - ring-shaped primary engines (similar silhouette to the node drive rings of human ships in Sword of the Stars if viewed head-on, but with A) both forward and backward exhaust B) multiple rings for larger vessels and C) the ship suspended from the ring, often with the ring at the middle, for smaller ships).

[jackS]

( I also need to know how is orientation in the VS render engine .
Left or right handed coordinates system ? )

I think it's right-hand, with Y+ vertical and Z+ forward, but it's been so long I'd have to check. An easy way to do so would be to poke at a long, skinny model and see if the largest coordinate is Z.

[ezee]

Thank you jacks .

I think you use a good strategy and i am ok to follow your instructions .
If we agree with the fact that Blender could be the official tool ( just because it is free and powerfull ,
but can also work with lightwave , 3Ds etc ... ) , it is easy to do the A and B phases , and to distribute them
via a .blend file that is able to contain more than a mesh but also texts , python scripts , bullet physics , animation ,
texture packed etc ... ) . Very good design for the workflow .

The step A is easy and don't need further explanations .

But with the point B , i will need the Klauss point of view relative on how the
meshs can be imported in VS .
I mean , Blender is able to create an object ( vessel ) that contains more than
one mesh ( sub parts of the vessel ) .
The question is : Is VS able to load a mesh and his submeshs , or we must load
them as separate meshs objects ?
( i like your page in http://2.7kelvin.com/spaceship-aestheti ... dular-ship )

Definitivly it's a good idea to think ' fleet ' and no ' hyperdetailed single-forever
-alone vessel made by a genius artist that will never have the time to make the entire fleet " .


Good , i hope fellows artists will soon join us .
So first , it's a matter of scale i think .
Then sub parts .
Texture and post-processing effects will be at the end of the pipe .
One last thing , sub parts could/should be animated ?


Edit :

Speaking of motifs, part of the 2010 efforts was to try to do some high-level silhouette re-design (it would invalidate most existing models, fwiw, although most existing models are already highly non-canonical, so that never bothered me ). I'll try to see if I can dredge up any of the actual commentary. If not, I can summarize one of the key points fairly quickly. The Human/Aeran/Rlaan/Uln ships were to be redesigned such that they could easily be distinguished in silhouette in terms of engine placement: Aeran - primary engines along central axis of movement, Human - primary engines at the end of projections perpendicular to central axis at 90 degrees, Rlaan - what engines? = bulbous protrusions with shield-like bits built around reactors at various points around the vessel, Uln - ring-shaped primary engines (similar silhouette to the node drive rings of human ships in Sword of the Stars if viewed head-on, but with A) both forward and backward exhaust B) multiple rings for larger vessels and C) the ship suspended from the ring, often with the ring at the middle, for smaller ships).

roger that !

[loki1950]

There is a small Python app that uses Python's built in GUI lib Tk for importing models into the game it needs at bit of work to handle the new split version of units.csv. It acts as GUI for mesher.exe that is in the \bin folder of the installed VS while allowing you to edit units.csv(add ship stats,mount points etc) it is in the svn repo @ http://sourceforge.net/p/vegastrike/cod ... /modtools/

Enjoy the Choice

[ezee]

This one ?
https://sourceforge.net/p/vegastrike/co ... erter/NEWS

May be my life will be easier , thank you loki !


But a way to go from bxfm to .obj will be useful too .
hey , phenixstorm is back in the svn , soon here ?

[loki1950]

That's the one mesher also does the conversion back to .obi and .obi -> .mesh (ogre mesh) run it from a DOS window with --help as an argument for usage it is also documented in the wiki.You can check the source of mesher in the VS svn tree at
vegastrike\obiconv\mesher remember that the current version of UnitConverter does not handle split units.csv

Enjoy the Choice

[ezee]

i have tried mesher from dos box already , from bxfm to Obj with the llama .
But failed ... I will try again .
To have the actual VS models editable must be done .
That will give an idea of the scale to use , and upgrade them if they need to .
( in the wish list there was a need for more vessel subparts to target )

[jackS]

So, with respect to submeshes - there's a design question and what the engine can support, and they're currently actually somewhat independent for forward progress being made.

If you look at, say, the Clydesdale, you'll see that it's made of 3 meshes. However, from an engine perspective, there's no logical subdivision of the Clydesdale as a unit corresponding to these three meshes -- it's purely aesthetic (different damage maps, but same underlying unit that either is or is not damaged).
Now, from an art development perspective, we need units to be decomposed into component parts for future engine developments but there's no problem with units acting as they currently do despite being made of multiple meshes, so that's just something to be done, since all current models are neither built modularly out of components and most aren't even subdivided (Still need to upload the fleet-from-common-parts pics). Now, at some point, there'll have to be a fair bit of engine revisioning in order to actually have a better stat<->art asset mapping than the current subunit scheme provides (subunits being problematic both from a resource perspective as fully fledged simulation units, and problematic in requiring a strict hierarchy - there must be a top-level unit that supports all of the subunits, so if it goes pop, the whole thing magically explodes), but until then, at least we can build the modularly designed and sub-divided meshes.

[ezee]

so if it goes pop, the whole thing magically explodes), but until then, at least we can build the modularly designed and sub-divided meshes.

Okay , and each part could/should also be a RigidBody in the Physics engine ?
That would give intersting effects , when you are shooting a large vessel , and that
you see physical parts of the bandit separate then explode .
( if you give to that object a lifetime before exploding , like for a particle , you create some cool post action effects .
Or in chain explosions ! )

Okay ...
For me , there is no problem , i can in two clicks make two meshes join and form a mesh ( that will not
share vertices some times ! ) , or split a mesh in x number other meshs .

The problem will be for the import/export engine side .
And how Physics handle the submodules .
( the engine split the mesh in subs , each sub is attributed a rigidBody ( or the most appropriated Ode obj ) ,
after x lifetime elapsed the parts explode )

Edit : in fact , The cargo is already an example in the engine .
We could try to make the cargo explode after x time ?
A cargo with a bomb ...

The easy way is to simply remove the sub from the scene while the 2d explosion occurs .

[Deus Siddis]

Wow, you would never imagine the Rlaan craft were meant to look like that from the in game art and written descriptions. It seems unusual that they are so far from radial symmetry despite both being spacecraft and being designed by radially symmetrical creatures.

Are those cylinders on the outside of the Aera capitals weapons? If so it might be difficulty to hit any target less than a kilometer in radius with them being so far off center. Unless they independently tracked but that might be difficult to animate given their length and connective structure.

(subunits being problematic both from a resource perspective as fully fledged simulation units, and problematic in requiring a strict hierarchy - there must be a top-level unit that supports all of the subunits, so if it goes pop, the whole thing magically explodes), but until then, at least we can build the modularly designed and sub-divided meshes.

Another crippling issue with current subunits is that there doesn't seem to be a direct way to control a subunit. So if your engines are in a subunit(s) then you cannot move unless you switch over to it or order its AI to fly somewhere for you.

Tangentially, a funny side effect of non-hierarchical modularity would be that if a ship is broken in two by the destruction of connecting section(s), it could become two new functional ships. "You have only made me stronger!"

[ezee]

"You have only made me stronger!"

very good , i like this idea !

A technology based on nanites could achieve that .
Like a worm , a lizard and other strange alien creatures already do .

[loki1950]

A technology based on nanites could achieve that

Read the section on the Nano Plague in the background/history doc no nano tech

Enjoy the Choice

[ezee]

FIXME A better description is required.

http://wiki.vega-strike.org/Terminology:Nano-Plague

The nano-plague somehow prevents nanites from working properly.

Okay

[ezee]

Back with the Vessels c++ side ( something very weird is that you can find " missile " as
name for this object , but a vessel is still a unit or gameUnit . Very confusing naming
convention , that was never achieved i guess :

/**
* GameUnit contains any physical object that may collide with something
* And may be physically affected by forces.
* Units are assumed to have various damage and explode when they are dead.
* Units may have any number of weapons which, themselves may be units
* the aistate indicates how the unit will behave in the upcoming phys frame
*/

That is a very good starting point .
But this design suggest that final objects are built upon GameUnit , as GameUnits are generic bricks.

template < class UnitType >
class GameUnit : public UnitType

As programmer , it would be logical to find :

class Vessel : publicGameUnit

Consider this :

GameUnit * ga ; // do you think i can fly ?
Vessel * ga ; // do you think i can fly ?

Or this :

I am a GameUnit , and i hold a lot of other Units .
What type are my units ?

against

I am a Vessel , and i hold a lot of other Units .
What type are my units ?

So in the core of the actual system , things are working but following a non-human
standard logic ( the first step is a good calling convention ).
GOOD READING ABOUT THAT:

Premature optimization is the root of all evil
Donald Knuth wrote, "Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%."
In general, correctness and readability considerations trump code performance issues for most of your code. For a small fraction of your code, you may have to sacrifice readability to improve performance. Such optimizations should be carried out when the project is nearing completion. You have a better idea of the performance critical code when you have a working system.
That said, it is important to recognize that many optimization techniques are just sound programming practices as they improve performance as well as code readability. Such techniques should be applied right from the project start.

source: optimization_is_the_root_of_all_evil
I am an alien too ( ), but we should make efforts to make our plans human-readable .
Not all humans are bad .


Off topic:
https://www.youtube.com/watch?v=XP9cfQx2OZY


Edit :

So, with respect to submeshes - there's a design question and what the engine can support, and they're currently actually somewhat independent for forward progress being made.

I've found the code's part that deal with split :
( and it is human readable )

void GameUnit< UnitType >::Split( int level )
{
static bool split_subunits = XMLSupport::parse_bool( vs_config->getVariable( "graphics", "split_dead_subunits", "true" ) );
if (split_subunits)
for (un_iter su = this->getSubUnits(); *su; ++su)
(*su)->Split( level );
static float debrismassmult = XMLSupport::parse_float( vs_config->getVariable( "physics", "debris_mass", ".00001" ) );
Vector PlaneNorm;
for (int i = 0; i < nummesh();) {
if (this->meshdata) {
if (this->meshdata->getBlendDst() == ONE) {
delete this->meshdata;
this->meshdata.erase( this->meshdata.begin()+i );
} else {i++; }} else {this->meshdata.erase( this->meshdata.begin()+i ); }}
int nm = this->nummesh();
string fac = FactionUtil::GetFaction( this->faction );

CSVRow unit_stats( LookupUnitRow( this->name, fac ) );
unsigned int num_chunks = unit_stats.success() ? atoi( unit_stats["Num_Chunks"].c_str() ) : 0;
if (nm <= 0 && num_chunks == 0)
return;
vector< Mesh* >old = this->meshdata;
Mesh *shield = old.back();
old.pop_back();

vector< unsigned int >meshsizes;
if ( num_chunks && unit_stats.success() ) {
size_t i;
vector< Mesh* >nw;
unsigned int which_chunk = rand()%num_chunks;
string chunkname = UniverseUtil::LookupUnitStat( this->name, fac, "Chunk_"+XMLSupport::tostring( which_chunk ) );
string dir = UniverseUtil::LookupUnitStat( this->name, fac, "Directory" );
VSFileSystem::current_path.push_back( unit_stats.getRoot() );
VSFileSystem::current_subdirectory.push_back( "/"+dir );
VSFileSystem::current_type.push_back( UnitFile );
float randomstartframe = 0;
float randomstartseconds = 0;
string scalestr = UniverseUtil::LookupUnitStat( this->name, fac, "Unit_Scale" );
int scale = atoi( scalestr.c_str() );
if (scale == 0) scale = 1;
AddMeshes( nw, randomstartframe, randomstartseconds, scale, chunkname, this->faction,
this->getFlightgroup(), &meshsizes );
VSFileSystem::current_type.pop_back();
VSFileSystem::current_subdirectory.pop_back();
VSFileSystem::current_path.pop_back();
for (i = 0; i < old.size(); ++i)
delete old;
old.clear();
old = nw;
} else {
for (int split = 0; split < level; split++) {
vector< Mesh* >nw;
size_t oldsize = old.size();
for (size_t i = 0; i < oldsize; i++) {
PlaneNorm.Set( rand()-RAND_MAX/2, rand()-RAND_MAX/2, rand()-RAND_MAX/2+.5 );
PlaneNorm.Normalize();
nw.push_back( NULL );
nw.push_back( NULL );
old->Fork( nw[nw.size()-2], nw.back(), PlaneNorm.i, PlaneNorm.j, PlaneNorm.k,
-PlaneNorm.Dot( old->Position() ) ); //splits somehow right down the middle.
delete old;
old = NULL;
if (nw[nw.size()-2] == NULL) {
nw[nw.size()-2] = nw.back();
nw.pop_back();
}
if (nw.back() == NULL)
nw.pop_back();
}
old = nw;
}
meshsizes.reserve( old.size() );
for (size_t i = 0; i < old.size(); ++i)
meshsizes.push_back( 1 );
}
old.push_back( NULL ); //push back shield
if (shield)
delete shield;
nm = old.size()-1;
unsigned int k = 0;
vector< Mesh* >tempmeshes;
for (vector<Mesh *>::size_type i=0;i<meshsizes.size();i++) {
Unit *splitsub;
tempmeshes.clear();
tempmeshes.reserve( meshsizes );
for (unsigned int j = 0; j < meshsizes && k < old.size(); ++j, ++k)
tempmeshes.push_back( old[k] );
this->SubUnits.prepend( splitsub = UnitFactory::createUnit( tempmeshes, true, this->faction ) );
splitsub->hull = 1000;
splitsub->name = "debris";
splitsub->Mass = debrismassmult*splitsub->Mass/level;
splitsub->pImage->timeexplode = .1;
if (splitsub->meshdata[0]) {
Vector loc = splitsub->meshdata[0]->Position();
static float explosion_force = XMLSupport::parse_float( vs_config->getVariable( "graphics", "explosionforce", ".5" ) ); //10 seconds for auto to kick in;
float locm = loc.Magnitude();
if (locm < .0001)
locm = 1;
splitsub->ApplyForce( splitsub->meshdata[0]->rSize()*explosion_force*10*splitsub->GetMass()*loc/locm );
loc.Set( rand(), rand(), rand()+.1 );
loc.Normalize();
static float explosion_torque =
XMLSupport::parse_float( vs_config->getVariable( "graphics", "explosiontorque", ".001" ) ); //10 seconds for auto to kick in;
splitsub->ApplyLocalTorque( loc*splitsub->GetMoment()*explosion_torque*( 1+rand()%(int) ( 1+this->rSize() ) ) );
}
}
old.clear();
this->meshdata.clear();
this->meshdata.push_back( NULL ); //the shield
this->Mass *= debrismassmult;
}

[jackS]

Wow, you would never imagine the Rlaan craft were meant to look like that from the in game art and written descriptions. It seems unusual that they are so far from radial symmetry despite both being spacecraft and being designed by radially symmetrical creatures.

Are those cylinders on the outside of the Aera capitals weapons? If so it might be difficulty to hit any target less than a kilometer in radius with them being so far off center. Unless they independently tracked but that might be difficult to animate given their length and connective structure.

(subunits being problematic both from a resource perspective as fully fledged simulation units, and problematic in requiring a strict hierarchy - there must be a top-level unit that supports all of the subunits, so if it goes pop, the whole thing magically explodes), but until then, at least we can build the modularly designed and sub-divided meshes.

Another crippling issue with current subunits is that there doesn't seem to be a direct way to control a subunit. So if your engines are in a subunit(s) then you cannot move unless you switch over to it or order its AI to fly somewhere for you.

Tangentially, a funny side effect of non-hierarchical modularity would be that if a ship is broken in two by the destruction of connecting section(s), it could become two new functional ships. "You have only made me stronger!"

The Rlaan ship aesthetics have gone through several revisions -- these sketches are mostly consistent with what I could get the artists I was working with at the time to produce, which wasn't quite as on-target as the Aeran art style guide, but *shrug*. In particular, i'd probably play up the radiator/shield fins a lot more in size, but then I also wouldn't be able to see the ship bodies underneath in my sketches (see also, the title of this topic). As to why the ships aren't themselves radially symmetric, what I tell myself goes something along the lines of 'if the human aesthetic for "fast" when applied to spacecraft evokes a rather avian appearance even in the absence of atmosphere, then applying the same logic to the Rlaan may produce spaceships that look like their homeworld's "flyers" such as they are.' When that answer doesn't satisfy me, I tend to go with "artists like certain symmetries?" and shrug. Now, as for the internals of the ship, those are clearly going to be Rlaan-centric and their habitats may look entirely different (then again, consider the appearance of coral (the colony) vs. coral the hydroid polyp...).

Those long trios of cylinders on the Aeran craft are (badly drawn) coil guns(="mass drivers") running the length of the vessels (and, since ships=weapons-platforms, are a big part of the reasons the vessels are the size they are). They're pretty much strictly anti-capital/installation artillery-type weapons, so, if they can aim enough to get that 1Km radius down to a 250-500m radius, they'll hit other capital vessels just fine. Maybe part of why the coils are as wide as they are is to allow slightly off-center firing of a << radius projectile (clearly, the projectile is much smaller than the exterior of the tube as drawn, or the number of rounds carried would be miniscule) without moving the coil path itself? At standard engagement ranges (since there's no meaningful damage fall-off from range for a mass driver), even a slight angle of deflection from dead center could provide a decent sized cone. On the other hand, if you get close enough, then you'll have a heck of a time aiming. The Anaxander, the smaller of the two cap-ships, predates the Rlaan-Aeran war and wasn't designed to counter the Rlaan propensity for knife-fight ranged capital engagements, so the balance in armament for other ships differs. The Leonidas is explicitly designed with what amounts to "siege" artillery for obliterating the fixed fortifications at jump points, so that explains why it's still heavily based around the longer-ranged engagement designs for the fixed-forward weaponry.

There are numerous fixes that should eventually be put into how subdivided bits of a unit should interact with each other - fortunately, the development of modularized art can be done independently of any of these actually working yet

[Deus Siddis]

Were particle beams or at least capital scale spinal mounted particle beams mainly supposed to be a human technology? From the concepts it seems like the rlaan mainly rely on lasers while the aera rely on drivers and missiles for offensive weapons.

As to why the ships aren't themselves radially symmetric, what I tell myself goes something along the lines of 'if the human aesthetic for "fast" when applied to spacecraft evokes a rather avian appearance even in the absence of atmosphere, then applying the same logic to the Rlaan may produce spaceships that look like their homeworld's "flyers" such as they are.' When that answer doesn't satisfy me, I tend to go with "artists like certain symmetries?" and shrug.

So basically you would have preferred radial symmetry then?

The Anaxander, the smaller of the two cap-ships, predates the Rlaan-Aeran war and wasn't designed to counter the Rlaan propensity for knife-fight ranged capital engagements, so the balance in armament for other ships differs. The Leonidas is explicitly designed with what amounts to "siege" artillery for obliterating the fixed fortifications at jump points, so that explains why it's still heavily based around the longer-ranged engagement designs for the fixed-forward weaponry.

So newer aeran capitals would have been designed to deliver tighter grouping at close range then?

Is there a minimum distance between electromagnetic thrusters and electromagnetic accelerator weapons for them to not interfere with each other? Is that why they are so far apart?

[jackS]

Were particle beams or at least capital scale spinal mounted particle beams mainly supposed to be a human technology? From the concepts it seems like the rlaan mainly rely on lasers while the aera rely on drivers and missiles for offensive weapons.

As to why the ships aren't themselves radially symmetric, what I tell myself goes something along the lines of 'if the human aesthetic for "fast" when applied to spacecraft evokes a rather avian appearance even in the absence of atmosphere, then applying the same logic to the Rlaan may produce spaceships that look like their homeworld's "flyers" such as they are.' When that answer doesn't satisfy me, I tend to go with "artists like certain symmetries?" and shrug.

So basically you would have preferred radial symmetry then?

The Anaxander, the smaller of the two cap-ships, predates the Rlaan-Aeran war and wasn't designed to counter the Rlaan propensity for knife-fight ranged capital engagements, so the balance in armament for other ships differs. The Leonidas is explicitly designed with what amounts to "siege" artillery for obliterating the fixed fortifications at jump points, so that explains why it's still heavily based around the longer-ranged engagement designs for the fixed-forward weaponry.

So newer aeran capitals would have been designed to deliver tighter grouping at close range then?

Is there a minimum distance between electromagnetic thrusters and electromagnetic accelerator weapons for them to not interfere with each other? Is that why they are so far apart?

I don't know that the Rlaan ships needed to be radially symmetric, but I had some different ideas regarding geometry (including simply asymmetric) than the artists ran with - I think what's there is okay, but I'm not as moved by it. That could just be a personal issue. I'd still think that it's a better starting point toward an art guide than we had before that experiment ran its course.

Weaponry-wise, the Rlaan were set up to have no projectile or missile weapons whatsoever, heavy weaponization of gravitics, and lasers sprinkled in for good measure. The high-level idea was that, while Rlaan "fighters" featured lower peak accelerations than Human/Aera fighter-craft, the drop in peak acceleration as ships scaled up wasn't as steep for the Rlaan, which, combined with omni-directional acceleration profiles, lead to Rlaan capital ships employing highly maneuver-and-pursue oriented tactics leading to knife-fight range engagements and exercises in tanking damage. The Rlaan are the only group that has a ship that is (human-designated) a BB rather than a BC.

The Aera were a bit heavier on driver tech than humans for their capital weaponry, but were otherwise not terribly picky. Preferred tactics are standoff range artillery duels, wherein the drivers and missiles (same damage at any distance) can be employed to full advantage. The Aeran fleet is organized a bit differently than the human ones, with packs of corvette-scale torpedo launching ships being one of the mainstays of their offensive thrusts rather than "bomber" class strike craft. Strike craft are more intercepter/superiority oriented, designed to be employed defensively and as torpedo-boat escorts while the capital employ their axial weapons and missile batteries. The primary Aeran fighter guns were combination damage weapons designed to have at least some shield penetration. I think a theme that was intended to be played on was that the Aeran weapons always wanted to make sure that any given shot would hurt at least a little whether or not shields were involved.

Humans definitely have some high-end particle-beam weaponry in their arsenal, but faction-by-faction vary a bit on capital weapons loadouts. Unadorned weaponry tends toward gravitics (because the math was interesting for them), missiles are ubiquitous, etc. Lots of strike craft employed as interceptors, superiority, and bomber mission craft. Forsaken fleet loadout is very differently oriented due to economic constraints (largest ship class is effectively a DE) with heavy use of glass-cannon style gunboats for anti-capital purposes rather than their own capital vessels.

Uln craft were intended to be highly divergent among the lower order and higher order craft (peasant mobs on the one hand, armored knights on the other). The latter vessels, while very few (small economy) are covered in what amounts to the Ancient equivalent of aluminum siding, but which still makes better armor than anything anyone else can produce. Sadly for the Uln, not only is it a non-renewable resource, but its armoring properties make it very difficult to work with. The pride of the Uln navy thus has the dubious honor of likely being battered to bits internally, or deprived of all of its radiator surfaces, long before its armor gives out. Ulnish weaponry on these capital vessels is an eclectic mix of what they could repurpose from their homeworld, develop themselves, or buy from the other polities. Aside from their missile barges, weapons tend toward whatever is either cheaper to fire (for ships meant to see use) or more impressive to fire (for those mostly there to be menacing). The bulk of their capital fleet is deployed around their homeworld, so logistics has never been required to be terribly advanced for the Uln. Ulnish small craft are cheap, flimsy, and considered highly expendable. The Uln, like the Shmrn, heavily employ in-system ships, with their most common lacking in any form of FTL drive. The Uln have not seen major naval combat for generations. Most Ulnish fleet actions are internal political events and/or related to interactions between the Uln government and organized crime elements (none of the previous categories are distinct).



As for why the guns are so far apart... that's probably mostly a question of symmetry and redundancy. The Aera build their vessels around what is essentially an armored tube core that houses the primary fore/aft engines and primary reactor(s). There surely would be some minimum distances between electromagnetics, but that wasn't a design constraint I was actually considering at the time.

[ezee]

The Aera were a bit heavier on driver tech than humans for their capital weaponry, but were otherwise not terribly picky. Preferred tactics are standoff range artillery duels, wherein the drivers and missiles (same damage at any distance) can be employed to full advantage.

That is the precious information needed to build a specific AI behavior for aeran . ( and other species that you describe very well ).
I like your precise definition of details in a global system .

All your previous post is to be coded now .

I would like to see the fleets deploy their forces in the VS Universe as you describe them .
More and more i think " fraternal war " is the perfect background for that strategy's game to be revealed .

Thank you Jacks for this precious help .