Currently, debugging is complicated, we have to start a server and at least one respective client.
If the client application crashes, we only know what happened, if the crash occurs before gloss opens the first window.
The logging facilities show almost no information whatsoever, if an error occurs during a game, we do not know what happened nor why it happened.
This issue is closely related to #2. Changes to #2 will ease the implementation of this feature for the client.
Improvements
Logging
The first step would be improve the logging facilities. It is not sensible to vomit every debug output to stdout, because for high level features, such as notifyfing the game that the client is ready, it is not needed and would increase the difficulty of debugging the client state.
My suggestion would be to enable multiple logging backends such that high level information will be shown to stdout or similar while debug information shall be redirected to a file or similar for low level debugging.
Replay capabilities
When we debug a client crash, it sometimes is very hard to verify that our changes have either fixed the issue or what the actual issue is. Even with enhanced logging, the problem might be hard to trace and hard to reproduce.
Thus, I suggest a replay functionality for the client.
It should support the following features:
Always save the latest application run to a local folder.
On the next run, overwrite the old logs as needed to keep the used storage space to a minimum.
If a command line flag is passed in, the logs shall be saved to a persistent location and not be overwritten in the next run.
The client can be started with the logs given as an input.
It should not be necessary to start any server application, the client logs need to suffice.
When replaying, the client should not crash on the same issue as on the original run.
However, it should be possible to check if the same issue arose on the replay.
From the logs it should be possible to replay the exact events in the exact order the client received the state changes in.
It should be possible to pause the replay at any time.
It should be possible to step through the different states of the client.
When no issue occurs in the replay, there should be no issue in the client application
Some of these points might be very tricky or actually impossible to implement at all.
There might be important features missing.
Implementation
The implementation might rely on a different executable, however, the above point of When no issue occurs in the replay, there should be no issue in the client application must still be satisfied. We do not want to introduce further hurdles when debugging.
This issue needs further discussion.
This issue is closely related to #7.
Ease debugging for Client
Currently, debugging is complicated, we have to start a server and at least one respective client. If the client application crashes, we only know what happened, if the crash occurs before gloss opens the first window. The logging facilities show almost no information whatsoever, if an error occurs during a game, we do not know what happened nor why it happened.
This issue is closely related to #2. Changes to #2 will ease the implementation of this feature for the client.
Improvements
Logging
The first step would be improve the logging facilities. It is not sensible to vomit every debug output to stdout, because for high level features, such as notifyfing the game that the client is ready, it is not needed and would increase the difficulty of debugging the client state.
My suggestion would be to enable multiple logging backends such that high level information will be shown to stdout or similar while debug information shall be redirected to a file or similar for low level debugging.
Replay capabilities
When we debug a client crash, it sometimes is very hard to verify that our changes have either fixed the issue or what the actual issue is. Even with enhanced logging, the problem might be hard to trace and hard to reproduce. Thus, I suggest a replay functionality for the client. It should support the following features:
Some of these points might be very tricky or actually impossible to implement at all. There might be important features missing.
Implementation
The implementation might rely on a different executable, however, the above point of When no issue occurs in the replay, there should be no issue in the client application must still be satisfied. We do not want to introduce further hurdles when debugging.
This issue needs further discussion. This issue is closely related to #7.