Yep, believe it or not, the old-school ethernet "hubs" (note, not a switch) would actually just broadcast everything received on any RX pair out all the other TX pairs.
As such, you did indeed have issues with collisions.
From wikipedia:
An Ethernet hub, active hub, network hub, repeater hub, multiport repeater or hub is a device for connecting multiple Ethernet devices together and making them act as a single network segment. It has multiple input/output (I/O) ports, in which a signal introduced at the input of any port appears at the output of every port except the original incoming. A hub works at the physical layer (layer 1) of the OSI model. The device is a form of multiport repeater. Repeater hubs also participate in collision detection, forwarding a jam signal to all ports if it detects a collision.
Emphasis mine.
There is an article about building a passive hub (that only supports three devices) here.
There was a question about this particular passive-hub-topology on electonics.stackexcahnge here.
Use switch
RS485 has a bus topology. The big problem is that if you have star topology, every ray of the star has to be terminated. This way, the master transmitter will be loaded with 16x||120Ω = 7.5Ω. Of course such small impedance will overload the transmitter.
There is another solution however. You should use a switch and connect the master only to the ray you want to communicate. I am not sure how exactly this schematic has to be implemented...
One of the solutions is to use a multiplexer and 16xRS485 transceivers - such as SN75176 or similar.
Another way is to use one transceiver and some analog multiplexers with low enough internal resistance.
(Or even electromechanical relays as a some kind of ultra-conservative design :) )
Connect the network in star without termination
It is clear, that if there is no termination resistors, the RS485 network can be safely wired in star topology.
The additional research lead me to this article, that states that for relatively short lines, the termination resistors can be omitted. The term "relatively short" depends on the transmission speed and for 9600bps is about 600m (stated in the article).
I made the same approximated calculations and for 20m line the transmission speed is around 1Mbps.
The condition is that the delay of the signal in the lines for 3 or 4 full trips (enough to dump the reflections) must be shorter than the half time of 1bit transmitted.
Well, in the article there is a presumption that the bit is checked near the middle of the bit width, but some receivers make several sampling of the bit in order to decrease the errors. In this case probably the acceptable speed will be even lower.
Best Answer
I would suggest either RS485 or CAN; RS485 has the advantage of almost universal availability (if you've got a UART, you can have RS485; if your UART has automatic RTS control, you have a perfect RS485 solution). You can find cheap, small devices that will go up to several megabaud as well.
CAN is a little more robust, but if your microcontroller doesn't have the peripheral it can be an additional cost you're not willing to add to the project. CAN's main advantage over RS485 (IMO) is that in the case of bus contention, a complete message will still get through; If two devices start talking on an RS485 network, nothing intelligible is received and there is no built-in means of bus management, so you have to take care of this in software.
For your given speed and given that I don't believe the microcontrollers you mentioned have built-in CAN controllers, I'd suggest a token-based RS485 network. Essentially none of the nodes speak until it's their turn to speak, and this is done though the passing of a "token" (a short network message granting the use of the bus) to each of the nodes in turn. It's relatively easy to set up, is far more reliable than CSMA/CD and I think you could have something up and running within a day or so.