Then clients and servers would be free agents, extend that (abstract) class and activate/implement only what they care to.

This will have the advantage and disadvantage of hiding away all the details, while enforcing a minimal API.

That might be one way to go about it, certainly.

But another would be the path we have taken here: simply decorate the code in RMI fashion.

It's not too bad, after all:

• remote objects are those in separate programs (even on the same machine)
• remote objects have interfaces (like business cards) for their remotely accessible methods
• such an interface does the same job as WSDL for web services
• remote objects refer to each other through references whose types are those of the interfaces
• interfaces and classes need to import, extend specific rmi types
• setting up a server, client is done through a set of specific, self-contained steps
• a server is just as much a network peer as a client; the server appears however in the phone book
• that is, the client's telephone number (access url) is not listed, whereas the server's is

At the end we will even argue that not only this is not too bad, but that it is in fact good, because:

• learning RMI, as above, in CS1/CS2 strengthens OOP awareness in students,
• while preserving a high-motivation context, thus increasing its effectiveness

OK, now we can continue to develop the game knowing that the server and the clients are separate programs.

Separate programs on the same computer or on different computers: it doesn't matter.

That, in fact, is the whole essence of this method.