There's only a very small chance that our architecture will be right the first time. So, I propose to do things incrementally.
When looking at the (preliminary?)
task list, I think that the
small demo I've posted earlier today satisfies task 1 and a part of task 2.
Now, for the rest of task 2 and 3, I propose the following architecture:
Both the Server and the Client application will be constructed following the Model-View-Controller paradigm. Because I'd like to keep things simple for this step, the applications will be console based. Instead of transmitting the timestamp of the game, the applications will transmit the map.
The View and Controller part of both applications will be done properly at a later time. We will focus on the model, for now.
The model of the client will look like this:
Omg... Visio 2000 gives really bad images
The
Map interface is used by the View and the Controller to access the map. It is implemented by the
MapCache class, which stores (caches) individual
Tiles. The tiles are retrieved from the server through the
ClientSocket class. Communication is done with
Packets, which are created by the
PacketFactory.
Everybody still reading?
Now the server:
The server has a
ServerSocket which is comparable to the ClientSocket class in the client, but still quite different. Perhaps those two classes can share a super class. We'll see. We can always refactor in the future. The ServerSocket connects to the real
Map, which happens to support all the same actions as the Map interface in the Client.
Notice that some classes are shared between Server and Client:
Packets are only a medium to transmit information. Hence, it makes perfect sense to share these classes between the two applications.
Now... What is the purpose of all this. A prototype/demo/pre-alpha/whatever version of Transport Empire must satisfy these requirements:
- The server must store a map of at least 16x16 tiles, with each tile having a height.
- This map will be generated at random when the server is started.
- The client will subsequently ask for two snapshots of 8x8 tiles and displays them on the console. After the second snapshot, the first is requested again. Here's where the cache should prevent excessive network communication.
The following items will be milestones for task 3:
- Creating the two Socket classes. Creating a Packet object, serializing it, transmitting and reconstructing it on the other side.
- Answering to an arrived packet
- Creating a random map at the server
- Requesting and receiving the map by the client
- Caching the map
Anyone willing to help is welcome.