• Landing gear 2x2
• Bridge 3x3
• Static missile 2x4
• Dynamic gun 4x4
• Static engine 2x3
• Dynamic engine 3x3
• Quarters 3x4
• Fueltank 3x9
• Generator 3x4
• Magazine 2x3

Part is constructed of cells: this is easy to grasp and helps with rotation of part.

Since corridors have to be one tree, they have to be more common connection type.

Cell type:

• Impassable
• Corridor: Corridors have to be connected to bridge. Parts without corridor connections are not hermetic. Corridors are battle space and repair space.
• Corridor with utilities: Utilities form its own networks. Parts not connected to any utility network have no light. They connect power, fuel and ammo sources and users.
• Functional room with specific type Edge between cells:
• Wall/floor/ceiling - must separate different room types
• None
• Load bearing wall/floor/ceiling: You do not have to connect parts load bearing walls - but then this module becomes a leaf. Nothing else can be connected to leaf module.
• External armor

Interaction points:

• Doors
• Ladders
• Equipment

Load bearing root node:

• Node in the module that if lost connection to load bearing walls will cause module to snap off

I would like structure of the part to be defined once, not like 4 times for each of it possible orientations. This means that doors/hatches/ladders need to placed as post processing step.

Algorithm for post processing connection of parts.

• If unconnected load bearing wall separates different room types, degrade it to wall, other wise remove it.
• Merge same room types between parts - remove walls
• Each room (not part) has to have 1 door connection with each neighboring room
• Build navigation in each room
• Connect all doors and action points with shortest path
• Glue together path that run closely
• Replace non functional rooms of certain size in 3 dimensions with specific render.
• Smoothing out:
  • Cutting: of corner of cell, or cutting off half diagonally
  • Filling: inserting cutoff corner, or entire slope

• Mark edges as:
  • outside - belongs to one cube
  • flat - belongs to 2 cubes
  • inner - belongs to 3 cubes or to 2 diagonal cubes
  • invisible - belongs to 4 cubes

Possible outputs:

• 6 sides connected - 0 outside edges
• 5 sides connected - 0 outside edges
• 4 sides connected - 1 outside edge
• 3 sides connected - 3 outside edges - corner cut
• 2 sides connected - 5 outside edges
• 1 side connected - 8 outside edges

Fill inner edges, cut outside edges

• if you need to cut one edge - that is slope
• if you need to cut 3 - cutoff corner

Ambiguous cases:

Problem with smoothing - when you have an entire edge of big cube - you will be able to cut off only corners. But it is preferable to cut an entire edge, is int it? And that is possible only if you are looking not at single cube, but at entire shape...

We can not merge stuff between parts - this will make destruction per part impossible.

Cells are used for part z dimension as well. Cells in Z dimension share same room type as in base layer.

Minimal Z dimension of part is 0, and it will have central cell - one we blueprint and run and calculate stuff with. Plus back and front cells - for rounding off connections in 3d. When switching to inside view of the ship you see only central layer and back cells, front cell is hidden - basically you cut ship.

Parts can have extra Z dimension - for turrets - minimal is 1. That means that in addition to 3 cells of depth, they have 2 more in front and 2 more in background for total of 5. You need to layers for same reason - to smooth out transitions between parts.

Highest you can go is z dimension of 2, so your turrets can clear other turrets. With total maximum depths in cells or 9

Geometry that represents function of part - one per part only - we do not need to confuse players. They should look at part first and foremost from function perspective - i.e. part core is what they care about, part layout is just afterthought.

Can occupy multiple cells.

Cells occupied by parts core still get post processed as all other cells for purpose of floors\walls and ladders\doors - because can not afford just to make impassable.

Have special geometry to render, that can be static or contain animations - like turrets. Geometry is mirrored - i.e. central cell layer is made from config, as all other cells.

Purpose:

• For in editor and ingame look/sound/animation/sfx
• For editor\reward ui
• For editor assembly of ship
• For ingame performance parameters

JSON - best support in the engine.

Arrays [] preserver order - using it for cells

{
  "type": "gun",
  "gun":
  {
  }
  "specs":
  {
     "mass": 100,
     "cost": 100,
     "turret": 
  }
  "model":
  {
  }
  "cells":
  [
    "+ + +",
    " A   ",
    "+ + +",
    "     ",
    "+ + +"
  ]
}

Cells have to be marked as belonging of parts core.

I.e. interaction point is actually like a door into player facing wall - that is part of special geometry render.

Finally - ship processing is happening in 3d as well. But for the rest of the game it does not matter. Well may be for destruction, and for projectiles and animations and vfx id does matter, but for game play - it should not. Would be nice if after post processing all 3d structure would have been removed.

Hmm why I should not use just acii art to represent part layout? For later - now it is not important.

What will be my MVP?

Start game stright into editor interface.

Some part on paletter.

Select and paint it on the grid.

Save \ load

How to make menu for save load, and panel with buttons?

Is edit area UI or models? What are other options?