Storage of driven times
Situation in Elma 1
The way Elma 1 stores times has a few shortcomings:
- Only 10 best times are kept for both play modes.
- For external times, the level file is modified each time the top 10 changes. This makes some things inconvenient:
- It's harder to share the level because the times need to be erased first.
- It's slightly harder to check whether two level files are equal because the top 10 data needs to be ignored.
- Only 2 decimals of times is stored.
- Some "obvious" information is not stored, such as timestamp for the time.
Elma 2 should not have the above limitations. My suggested goals are the following:
- No limit for the number of times stored per level.
- Times in 3 decimal accuracy.
- External times should not be stored in the level file because they don't really belong there.
- Internal and external times should be stored in the same manner (instead of internal times being stored somewhere else like state.dat in Elma 1).
- Each time should include an optional reference to the corresponding replay file. All rides don't need to have a saved replay, but it makes sense to store all times (because it's cheap).
- Unfinished rides should be stored too (e.g. how many apples, time at death).
- Each set of restrictions should have its own time table per level.
So where to store the times?
One possible idea for storing times is to have one metadata file per level. This may work fine for a while, but as the number of times grows in a level, reading and writing the file becomes increasingly slower.
This is why I suggest to store all locally driven times in a proper database (SQLite3).
Ride would have the following columns:
- ride id (primary key)
- result type (finish/not finish/something else?)
- result data (time/number of apples)
- id of replay (optional)
- level id
- restrictions (this can include the number of players in the ride)
Two more tables are needed:
and an association table
- ride id
- player id
The last two tables are not absolutely necessary but they reduce redundancy; the slightly worse option would be to store player names directly to