viluon / cccitygen Goto Github PK

How should non-rectangular Rooms be handled? What about hallways and such?
Possible solutions:

• Make Rooms use more than 4 Walls, 1 floor and 1 ceiling
  • This introduces issues like how should these be assembled together, how to keep track of where everything is and how to actually construct such Rooms, because points A and B are just not enough.
• Make Rooms link to surrounding Rooms and let some of their Walls be zero size, or let them have less than 4 Walls
  • This introduces issues like how should these Rooms be linked together and how should they be constructed, but allows structures like hallways to be built from individual segments.
• Create a new class for more abstract handling of rooms which would join individual cells
  • This would make handling of Rooms a little more logical and would also prevent weird linking issues from the second idea. This new class could be called Room and the cell could be something like RoomCell

This issue has been derived from #1

Add overloads for easier manipulation with Point3D.

• __tostring
• __len
  • This should return math.sqrt( self.x ^ 2 + self.y ^ 2 + self.z ^ 2 )
• __add and __sub
• __mul and __div
• __mod
• __pow
• __eq
• __lt
• __le

Note: The comparison metamethods should simply compare the x, y and z values, and return true if all of the conditions match.

This issue has been derived from #1

Grid3D should use Point3D for size and origin fields.

This issue has been derived from #1

Rooms should use Spacing for population of Buildings.

Currently, cccitygen uses a customized version of dofile() to load files. That is, honestly, a terrible solution. For these tasks, require() (unavailable in the ComputerCraft environment) should be used instead.

This issue has been derived from #1

These tasks have to be made into issues:

• Add overloads for Point3D
• What about the constructor chain interface?
• Grid3D should use Point3D for origin
• Rooms are somewhat limited. They can only have 4 walls. What about non-rectangular rooms?
• Grid3D:resize()
• Should room floors be limited only to the inner area (exclude the borders with walls)?
• Move stuff from ToDo to GitHub Issues (done because the ToDo.md file has been deleted and this is in fact an issue 😛 )
• Implement require(), dofile() is dumb
• Building should keep a list of outside walls
• IDuplicable?
• Generalize Palette, add RoomPalette
• Use RoomPalette in :populate() along with BuildingPopulator or something similar
  • BuildingPopulator will contain a list of rules such as what Rooms the building should use and how should they be connected, how many of them etc
  • BuildingPopulators will define Building types, for example a family house vs. mall etc
  • BuildingPopulators should have a clue about how the building is structured (floors, staircases, elevators?)
• Rooms should hold the information about windows, Buildings should only link to them

Note: The fact that a task here is checked means that it has been made into an issue, it doesn't mean it's solved.

An interface for method chaining of constructors. ISupportsConstructorChain would set the __call metamethod to the constructor of the implementing class, which would allow constructs like

local a, b, c = Point3D ( 1, 2, 3 ) ( 2, 3, 4 ) ( 3, 4, 5 )

This issue has been derived from #1

Should the Wall object that serves as a floor/ceiling in a Room be limited only to the inner area of the Room? As it is now, the borders of floors and ceilings overlap with the room's walls, which means that floors and ceilings have to be built first and walls "on top" of them.

This issue has been derived from #1

As of now, Grid3D can only be resized when created. That means Window cannot be implemented, because it extends Wall which extends Structure which extends Grid3D, and Window needs to be reoriented when Window:fitToWall() is called.

This issue has been derived from #1

An interface generalizing the :duplicate() method. Many classes currently implement the :duplicate() method (in fact, all classes should have one). An interface could however generalize this. The constructor for the interface would have to require information on how should the actual class constructor receive arguments (what fields in what order).

This issue has been derived from #1