Process

count players / collect routes
find a vacation target(s)
write routes (player configs)
ask whether delay should play a role
if delay should play a role, ask players how much time they have to get from one means of transportation to the next

To do

Unit testing [0/2]

[ ] Make all ask-user-... procedures take an additional keyword argument
[ ] Write tests.

Miscellaneous [0/1]

[ ] ask for route change first, then ask for delay
[ ] general descriptions / explanations of means of transportation, on the

Preset values [0/1]

[ ] think about idea: delay or additional costs effect:
specify value
random centered around value
if no value specified ask player

More events [0/5]

[ ] hiking: bridge on map does not exist in reality (delay)
[ ] fall into a into stream when trying to jump over it (effect? -> slow -> delay?)
[ ] forgot meds (effect: need to head back -> delay?)
[ ] forgot food (effect? -> hungry -> slow -> delay?)
[ ] art sale during transport

[-] add positive events
[X] get to know a person on the flight -> person gives you a ride to your hostel
[ ] find a wallet
[ ] find bottle of champagne
[ ] free smoke
[ ] find someone's phone and this person turns out to be your new crush, who will accompany you
[ ] an old acquaintance whom you meet on the flight invites you to eat English muffins
[ ] train arrives earlier
[ ] anything arrives earlier
[ ] arrive from international flight and a new queue is opened up for the customs service (luggage checking)
[ ] you are the n-th customer and get a free
[ ] upgrade to your hotel room
[ ] or flight class
[ ] train compartment class

Logging [0/1]

[ ] give log level to log procedures or make a macro

Features

Discomfort [0/1]

Discomfort could cause global events like sitting down and crying, which delays travelling.

Discomfort could make some events, which require a lot of attention to avoid, more likely.

[ ] discomfort accounted for
[ ] nightmares
[ ] people smoking next to you
[ ] uncomfortable seat
[ ] did I lock my door?

Command line [0/1]

[ ] add named command line arguments, to override config and set things like:
[ ] random seed
[ ] difficulty
[ ] min probability
[ ] max probability

Karma [3/3]

[X] neutral events that give positive and negative choices
[X] pick up or not pick up person while riding the bike
[X] positive or negative karma points

[X] karma points
[X] calculation: (karma points * positive/negative multiplier specified by

[X] initial karma in general config (additional difficulty adjustment)

Actions [0/1]

[X] Perhaps let users choose the effects of the event by choosing an action they want to do when the event happens.
[ ] allow to always choose an action, even with empty action list, because

General events [0/7]

[ ] add general events to the configuration and program, which can happen with
[ ] pandemic
[ ] diarrhea
[ ] vulcano erruption
[ ] solar flares / solar winds
[ ] terrorists
[ ] "knallharter regen"
[ ] weather changes

Validation [0/1]

[ ] effects array can be enum members

Summary [1/2]

[X] count number of events that happened to a player -> traveler state
[ ] show summary table

Summary visualization [/]

visualize the statistics in the summary

Feature: Locations [0/1]

[ ] events for locations
[ ] on arrival at location process possible events
[ ] the manager of the hotel which you stay at really likes you
[ ] effect: no costs for the hotel
[ ] you get an upgrade for your room

Design decisions

Best design decisions

The best software design decisions are those, which help with development and maintenance of the software. Of the design decisions made in this project, the following seem to have been the most beneficial:

writing JSON schemata for validating JSON configuration files

If there is a configuration related error, assuming, that the JSON respective schema is correct and as intended, this makes sure, that the mistake is not in the structure of a configuration file, but indeed in the program running with that configuration loaded. It takes one more thing off ones mind, making it reliable.

introducing the abstraction of an "event outcome"

This greatly simplified dealing with events and event actions and simplified the code, which I was not quite satisfied with. Goes to show again: If one finds a good abstraction, one can make the code much more readable.

Still unsure

splitting up the configuration files

positive aspects

This seems to make it easier to update the separate configuration files, as mistakes can be found more easily, for example when the validation fails or when there is a simple syntax error.

It enables me to quickly list all available means of transportation.

negative aspects

It makes editing via search and replace or keyboard macros in Emacs take a bit more time.

It might be a good trade-off.

using alists for handling the configuration even after loading the JSON files

On one hand the alists are very convenient to access using the extra functions I have implemented for that purpose, but on the other hand the code relies on data being alists and vectors in many places.

Additional data abstraction procedures could be introduced to limit the required changes in case of configuration loading changes to the data abstraction layer, but would it be worth it in this case? How often, if ever, if the way configuration is loaded going to change? And why would alists not be a good choice for data, which is as small as the configuration of a program like this one?

I could probably have used hash tables or something like that to store the configuration, but all that would achieve is swap the alist procedure calls with calls to hash table procedures.

notes.org 6.5 KB Permalink History Raw