Merging tiles into paths

[quark]

@eightohnine

Correct me if I’m wrong, but for now I understand this as follos.

Correction time LOL

The are only 3 classes
Cell - the parent class
CellLine and CellArc - 2 child / sub classes

The method getCell is used to instantiate and return one of six different objects. If you look at the code you see that only objects of type CellLine and CellArc are instantiated.

In Java the act of extending a class is called inheritance and there is semantic relationship between a child class and its parent which is expressed

a child class is a kind of parent class

therefore
CellLine is a kind of Cell and
CellArc is a kind of Cell

Note that as we move down an inheritance tree the class changes from generic type (parent) to specific type (child).

If you look in my code we have a single list of type Cell

ArrayList<Cell> cells = new ArrayList<Cell>();

but we can populate it with both CellLine and CellArc objects. because

a parent class object reference can reference itself or any child class object

To draw the cells we have the code

  for (Cell c : cells) {
    c.draw();
  }

I have removed the two lines that showed the yellow dot because they are not needed.

Note that all three classes have a draw() method and the one used depends on the class instance referenced by c. This is called polymorphism.

In object orientation inheritance and polymorphism are incredibly useful concepts to understand and use.

Personally I would have the Cell classes simply store

• its position in the display,
• the layout of tracks inside the cell, and
• links to the two cells it links with

They would not control the actual the movement animation. I would have another class called Tracker (or something similar) it would have two primary fields

1. the cell where it is located and
2. the position within the cell (the parametric variable t in the range 0 to 1 inclusive)

The tracker object would simply interrogate the cell by passing t and get a display position back. So the tracker object is managing its own movement which is good.

Just a couple of other points - the code I provided has a single track in the cell but your original pictures show 4 tracks in a cell. Here is an image of my JavaScript implementation.

The circuit has 8 x 5 cells and every cell has 4 tracks each having its own colour and the 4 trackers (cars) have matching colours. Each cell has a two letter ID, in the top-left cell we have SE which means the forward direction of the arc starts SOUTH and ends EAST. Now look at cell (1, 3) we have ES and the arc starts EAST and ends SOUTH we need this to create continuous tracks (follow the red car’s route

So we still have just three classes but now 4 straight types (NS, SN, EW, WE) and 8 arc types (SE, ES, NE, EN, SW, WS, NW, WN).

The track length inside an arc cell depends on the track position, so if the car is to travel at constant speed this needs to be taken into account. Yet another challenge

I’ll stop there for the moment but if you want to see my JavaScript implementation just let me know.

[eightohnine]

OK, wow, corrections have landed indeed.

I was honestly too rushed with my initial reply, and haphazardly got “classes” and “objects” mixed up. (Aside from also overlooking that a path can be taken in two directions). So, three classes, resulting in the listed 12 object permutations.

I think that I’ve now got a better understanding inheritance and polymorphism as well. Powerful stuff. Especially managing “different” objects in one array(list).

Currently I’m stuck with my head in one implementation for my initial idea (see attached screenshot). I’ll try to push this direction further for now, but may come back to you for that JS code implementation of yours.

Thanks!!