GroundBattle Units like Ships as Unit

For what's not in 'Top Priority Game Design'. Post your ideas, visions, suggestions for the game, rules, modifications, etc.

Moderator: Oberlus

Post Reply
User avatar
Space Kraken
Posts: 101
Joined: Mon Jan 06, 2014 3:33 pm

GroundBattle Units like Ships as Unit

#1 Post by Adamant »

I dont know how actual Troops are implemented but would like
if these could buld similar like Ships and Fleets while they can
get loaded into Baracks or Trooper SpaceCrafts while Gear to
deal Load and Unload from Ship deals with same for Planet
resp Barracks there to determine what Unload means especially:
Invasion or Station.

I miss Kind of SpacePort for Planet that Ships from Planet can
return from Orbit to SpacePort resp analog Trrops from Barracks
transfered to free TroopShips in Orbit.

If Troops thought as Kind of SpaceCrafts these are like Ships
without Drive and Need instead Orbit TroopShips inside Orbit
to change from Barrack to Ship while thus the TroopShips dont
get wear out by Invasion while the Barrack-Production gets
important as Source for Troops.

It seems reasonable to think of Troops as Kind of SpaceCrafts
with liited Capacities for Movement, offering same Mechanism
for SpaceCrafts to land on Planet eg to aim for omit potential
EnemyContact while as Load on SpaceCrafts these Units change
to Kind of Passenger analog to Cargo for unliving Items. Means
when Trooops get Unit-Class from Ship with new Limitations
resp Features (can not move like Colonizer Base while can
enter SpacePort resp Barrack on Planet but need SpaceCraft
in Orbit with suited Storage Type and free Capacity) think
same Time for Issues of CARGO and FREIGHTER, to factor
that in as useful Constraints to solve it more generic and
thus also offer Opportunity to utilize it easily when later
Idea comes up to move specific Loads with Freighters made
like ordinary Ships but special Cargo-Pods as Interior, given
like Mark-I Designs and used from Economy while Player
does not get in Touch with that civilian SpaceCrafts while
same Mechanism for traditional SpaceCrafts can get used
to calculate Impacts from foreign hostile Fleets. Think
simply of 2nd tzpe of Fleet the Player does not have to get
in Touch by Management same like for known Type of Fleets
and SpaceCrafts (BUT COULD!!) while Simulation gets
new Meanings to behave more rational.

However, I would like to have managable Gear for Supply
and Deposit for Fuel Militaric Bases do Kind of stationary
Supply while Military Tanker could get used to remote Resupply
of Fuel similar like Scouts do remote Recon Services. Player
does than can control Fuel Supply similar like Recon Service
from Scout. TroopShips do similar Kind of Troop-Supply while
there is actually no Way to reuse unloaded Troopers while
their PayLoad are Troops from Production ... I prefer Barracks
as Site where the Player get his Troops while Production by
Industry appears somewhat strange inclusive implicite safe
Wear Out by Invasion.

I do here primary ask for Troops for GroundBattle build from
same Class like SpaceCrafts with just different Features like
seen for ColoiyBase which can not travel between Nodes and
Barracks as Source for Troops BUT point to additional Aspects
above to factor in as Hint for the right Way while same factored
in provides Opportunity to use same Code InfraStructure to
realize later - if wanted - also Fuel and Tanken or Freigheter
and Wares without Need to implement a 3rd or 4th Set of
Classes which do almost the complete same.

Repeat the brief Point:

That we have:
Production >> SpaceCraft >> Orbit

That I propose:
Barracks >> Troop >> Trooper

Opportunity for:
Barracks << Troop << Tropper (Relocation -> Invasion?)

Analog for SpaceCraft:
Production >> SpaceCraft >> SpacePort -- as Kind of Storage
SpacePort >> SpaceCraft >> Orbit -- instead stall Production start on Demand --
SpacePort << SpaceCraft << Orbit -- analog reverse Landing for SpaceCrafts

We may consider then how to deal Damage from Attack for landed/planetary Gear and InfraStructure
when Player say: oh, that landed SpaceCrafts are annoying - why we can not attack them?
Same Issue exist already for planetary Gear and Infrastructure and we can deal that with
same Code.

Used as EXAMPLE for potential SpinOff (Option for FREE - no Need to utilize it that Way - we just
could.. that is an Option .. due to worse Experience I feel to have stress some Aspects really clearly
to have better Chance to avoid MisUnderstandments!) of that Change we can do same Way this:

Fuel-Depot >> Tanker >> Remote Node >> Supply Fleet (we dont have to but CAN)
Industry >> Product >> Freighter
Industry << PRoduct << Freighter (Trade/Supply)
Pure Cyan harms PhotoReceptors doubtless - even half Portion appears mysterious.

User avatar
Space Kraken
Posts: 101
Joined: Mon Jan 06, 2014 3:33 pm

Re: GroundBattle Units like Ships as Unit

#2 Post by Adamant »

I still did not use in Game but saw in Tec.Tree Tec for Planetary StarLanes
which means to me that a Planet gets moved like a SpaceCraft.

When make the Planet as another Kind of SpaceCraft then PlanetSystems
appear like Members of a Fleet while the Star represents that Fleet as
Object. We could think also about the Star as Kind of Freighter and the
Planets are its Cargo.

When think that Way we can think of Menus for Star with Planet as another
Kind of Fleet View. I wonder what that other FleetView offer for regular
As there are in Scope of that Interpreation different Kinds of Fleet and SpaceCraft
implemented I ask how to deal that Matter in Way of ReDesign of Code with Aim
to unify these different Fleets and SpaceCrafts to a single Class and just Config
of Attributes explain of SpaceCraft is a Planet or a Troop. From Perspective
of Code we simply put one or multiple Things into another things while from
Perspective of Player wont Like when a Troop puts a PlanetSystem into Pocket
as Souvenir and nobody would note it.

If you wonder how to do that the Matter is exactly same like for FileSystem and
File and Folder - while we can assume each Folder represents a File which is same
Time a Folder. The technicla Term here is DataStructure BTree.

Consider Kind of Vector which can store other Vectors:

Vector <Vector <Object>> and first Object represents the exterior Vector as whole.

But we would get Trouble with Type while Stacking -- I dont like STL, btw.

class AObject {}; //AObject - abstract - common Handle

class VoidObject : public virtual AObject {// oh, there is nothing..
VoidObject() {} // how overwrite the Object CTOR? - to term Cascade from Recursion below..
bool isFree(){return true;} // oh, there is nothing..
bool move (AObject location) {/*immitate do nothing*/ return true;} // nothing moved succesfully

class GObject : public virtual AObject { // this one is something..
Object** object; // first item represent itself
bool canMove; // generic Attribute for generic Ability
int capacity ; // stuff related to Accounting and Management
Object () {
object = new Object*[capacity];
*object = new Object(); // Group representing Object, eg THE Fleet, or A Frighter
for (int i=capacitiy; --i; ) {object=VoidObject();} // valid Pointr-Entries for nothing
bool isFree() {return false;} // item explains it occupies Slot
bool move (AObject location) {if (!canMove) {notify(Player, "cant moce!"); return false;} perform_the_move_issues();}

class SpaceCraft : public virtual GObject {// Special Object - for special Abilities.. ?
SpaceCraft() {this->canMove=true; this->type="SpaceCraft";}
GObject() {return *this;} // we use specific CTORs for special Types of Object but deal them then as Generic Objects
void beep() {} // One fits all - how deal call Generic Objects resp Planets to beep? We dont like this Class Way!

GObject* daStuff = new SpaceCraft(); // we dont cast or check Types

*daStuff.beep(); // Segmentation Fault... stupid special beep - Fleet know to beep but not Planet

I did not deal with Access Policies while I use exclusively private for ALL Properties, while Methods
can be public or some have Friends or be totally private - I dont deal with const as I dont deal that
Way with Safety of Objects their internal States but accss them via Methods exclusively and Policies
for these Methods and dont care about Compiler CompileTime-Protection as that does Method-Policy
as well and if need better Protection than use temporary Message-Objects containing primitve Stats
and make Copy from to keep Object's internal States and Data protected. That works for plain Abuse
like Utilization like give as Parameter Object one know to be located to perform direct Things I dont
support resp try to avoid by Approach. So Caller can modify later his const Argument anyway that
does not matter to Objects internal State as the later Happening of a previous Argument - no need
to const it resp when Getter called for State a Copy of States get returned instead the Sates itself
and so worry lesser about that replied Message Object.

Brief Explanation of Approach is Ego-Perspective for Object in Way of Caller ASK to do something
but Object decide about that Proposal and do like it like.. eg move through wall - I dont think
that is rational to do. Sure does Object (code) enusre that there is no Way to ByPass Things
which are inside Authority of Object its Scope. Means eg Caller Fleet can ask Ship to change
Name with concrete Proposal but Ship decide how to deal with PRoposal while Policy explains
if Fleet is allowed to ask. So that is Perspective for Programmer to design Class resp Instance
Behavior and perform that Way as Lawer for Object and dont care of Fleet is angry about any
refused Proposals (their Programmer says your Ship refuse the Naming! Right! Ship does not
accept any URL like Names, ya know? Try something else! Ship like Names which end -is like
Philis or Doris, small Hint. ;))
Pure Cyan harms PhotoReceptors doubtless - even half Portion appears mysterious.

User avatar
Space Kraken
Posts: 101
Joined: Mon Jan 06, 2014 3:33 pm

Re: GroundBattle Units like Ships as Unit

#3 Post by Adamant »

Think Object is in Association and have good Lawer and knows exact what is inside its Scope
and what is outside. Eg Ship knows to join a Fleet while Fleet can refuse the Join due to
bad Name of Ship. Object is also lazy and tries to delegate all Work it can when it concerns
Scope of another Class. Eg Shio-Name is a serious Matter - and we need smart Class
ShipName : String and thus can outsource that complex Matter into specific Class Ship just
say my ShipName Lawer said that Name is inpropriate to me.

Objects are like of PersonalChiefs resp PRofession Inventor and eg Ship-DesignWork figure
out complex Issue of Navigation require a professional Captain and thus Shio delegate
Calls for Navigation to the Captain which know better how to do that.

Consider a Company with 1000 hired Personal with HotWater-Chief-Engineer with Stuff
while anohter 3.-Man-Company tell they do also the CleaningJob and wont hire a Profi
for .. but we dont have to deal a Lot with Payment but with ImplementationWork due
to OR due to NOT created Classes. Consider a Smith which can do all with Metal
Customers think of while an Engineer can perhaps deal really good with Design of
Material to absorb ShockEnergies but can not drill any Hole inside that Material.
To design a new AutoMobile you may feel better with the Engineer while if you
want to drive a small Company that forges Fences you prefer Service from plain
Smith - I wont say one is better than the other but better suited.

Eg Matterr of ShipNames is not that stupid than it may appear - if generalized and
that Class CTOR gets another Class with Grammatic Data Table like Rule that
Names have to end with -is for any special Species which name that Way than
that Class would even get another Assistant Name-Syntax-Carrier to serve other
Species as well. Think as Business Man and Matter are the real performing
Programmers and you can either rationaliz Problem so small that each single
Method gets implemented as Functor .. or reverse all Stuff inside a single Class
and go the C-Code-Style Way and solve all in sinle NameSpace resp ClassSpace
while the rational Way is between resp even somewhat closer to the more
detailed Side as you rare think it is to fine and strip it down while are more
likely to think the Matter is to complex to get dealt inside single Class with
wired Code - better rationalize Problem resp Approach into different Aspects
while you could try preparation, mainprocessing and postparation as Approach
to reorganize Job and Code or do perhaps take arbitrary Attributes like Address
for Node odd or even and put that Node to according Process which do effectively
the really exact same but that way can perhaps better utlize MultiCore-Systems.

I dont see any clear Advantages from latter Approach aside of splitted PayLoad
for Cores and would focus on real Differences for PayLoad to safe that Way an
IF-Condition per specialized Thread which deal that IF as Set.

However, Matter of BTree for Objects goes a totally different Direction then that
implemented and I doubt it is best Approach to adapt BTree by plain Assembling
into existing Code-Tree but guess simpler is to cut down temporarily the Feature
List and start with alternative Design Approach which does support in general
Way basic Features like Inspect Object, move to or inside outside, resp enter
and leave etc while the existing Code-Tree can still provide Help as Library for
specific Problems like ... Code for GUI pffers q&d ProtoType to get something
working that the Tester can inspect States of Object ... eg the Queues are not
that bad to scroll through List while it would need some Reftting to work with
new DataStructure ... eg there is Star selected and Fleet and Planets are listed.
Next want to see what Inventury of WARES there are inclusvie Freighter and

Now Attention! Matter of BTree above is that: we say its all SAME and just
Object and we can group and insert them in arbitrary Ways, Troop into Trooper,
Fuel into Tanker, Ware into Freighter and SpaceCraft into Fleet. BUT we can
in that Scope also put BlackHole into Pocket or SpaceCraft into Fuel.

We have another Idea how the Things shall finally behave and therefore avoid
several Things like above listed and need for any Meaning. We dont want to
explain for a specific Object that it is allowed to enter that or that Fleet or
that and that Orbit but explain it to be Member of Class SpaceCraft (what?)
and explain for Class SpaceCraft, it is allowed to enter or join Fleets and
dito for Orbits. There are Things we consider to be customizable. EG for
Technology Planetary StarLane we need that Object first to resist all Request
to move to anywhere while later it may move using regular Mechanism but
wont like as Player, if we order a Fleet to Combat at remote Destination and
find surprisingly own Planet there inside Combar ... no no - its a DeathStar!
Move on! and therefore need some Kind of Control to manage if we think
Planets to be Kind of FleetMember and behave according to Fleet-Commands
or stay into his Orbit or Location. We can think of any Feature to change
that Behavior for Planet fine also for SpaceShips but the most comfortable
Way is to have Kind of Control about custom ClassificationSystemSystem
that we can define arbitrary Classes like Class Fleet and join that Planet
to be Member of that Fleet and thus represent Kind of SpaceCraft even
that Membership have not to get provided from any Implementation Class
in C++ Planet or SpaceCraft. So what is the most plain Way to tell that
Object it joined any custom Class like here CustomClass Fleet and same
Way CustomClass SpaceCraft that we can easily in that Scope keep that
Object like it is but handle as SpaceCraft when let it join as SpaceCraft
an Instance of CustomClass Fleet.

The plain Issue about that means we may consider Kind of additional
ClassificationSystem implemented in C++ perhaps similar like that we
use to implement it.

Basic Features expressed by MethodCalls:

CustomClass CC:
CustomObject OC;

bool relatation = CC.isSubClass(CC); //
bool relatation = CC.isInstance(OC); //
bool relatation = CC.isMember(OC); //
CC* classes = CC.superClasses();
CC* classes = CC.subClasses();

Brief Profile: Methods to ..
- determine Relations betwen Classes CC and Instances resp Members.
- maintain Relations between Classes CC and Instances resp Members.

EG Freighter (can) get Trooper resp join a military Fleet as Supplier or BlackHole gets petted and join the Army

At this Level I does not discuss if BlackHoles are allowed to get petted or Planets allowed to use StarLanes but
when Intention is to allow that this does not require a large Rewrite of Implementation Code adding Casts etc
to the Source and due to many additional IFs inside Code resp CodeSize BIN larger and thus Game slower but
same allow small Set of Code to deal with making Planets next able to move StarLanes.

That Way it is btw possible to give GasGiants their own Moon-Systems analog PlanetSystem for Star resp also
the SolidDwarf-Planets can have same Way none, one to two Moons and thus offer Opportunity for the Game
as Fleet can perhaps really hide behind Moon what actually is just dealed by Stealth-Attribute while GasGiants
still can not have Moons suited for Colonization.

Readers may note that different Threads cocern to same resp at least similar Gear. Someone made a Thread
and explained his Happiness and Sadness about BlackHoles having Planets instead Stars and I explained there
that Planets are IMO potentially alright but for Stars we know absolute sure that they orbit on BlackHoles and
if there are Stars orbiting we may ask why these Stars are not allowed to have Planets as usual. Next Day in
Scientific Paper may set that there can not exist stable Orbits for Planets around Star around BlackHoles but
here I deal with Matter that Game could easily support Planets orbiting Stars orbiting BlackHoles and use
StarLane no Matter what Science or GameStrategy tell or decide. Its about technical Approach and not about
which possible Features from Approach finally get enabled resp utilized. It's about Replaccement of many
special Class which do mostly same or similar with small Set of Classes which can do that all and more.
Pure Cyan harms PhotoReceptors doubtless - even half Portion appears mysterious.

Post Reply