notes.org 6.2 KB

Process

  1. count players
  2. find a vacation target
  3. find a means of travelling to get there
  4. example:
  5. taxi to airport
  6. plane to other country
  7. bus
  8. it is important when travelers leave their home
  9. travelers or the game master needs to write down delays or the program needs to keep track of them

To do [2/14]

  • [ ] Make all ask-user-... procedures take an additional keyword argument
  • named ~input-port~, which defaults to ~(current-input-port)~ or use fluids / parameters.
  • [ ] general descriptions / explanations of means of transportation, on the
  • same level as the "event" attribute, simply to be displayed when that step of the journey starts
  • [ ] ask for route change first, then ask for delay
  • [-] 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
  • [ ] add neutral events
  • [ ] art sale during transport
  • [ ] 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
  • [ ] general events
  • [ ] pandemic
  • [ ] diarrhea
  • [ ] vulcano erruption
  • [ ] solar flares / solar winds
  • [ ] terrorists
  • [ ] "knallharter regen"
  • [ ] weather changes
  • [ ] think about idea: delay or additional costs effect:
  • specify value
  • random centered around value
  • if no value specified ask player
  • [ ] discomfort accounted for
  • [ ] nightmares
  • [ ] people smoking next to you
  • [ ] uncomfortable seat
  • [ ] did I lock my door?
  • [ ] give log level to log procedures or make a macro
  • [ ] Add more events:
  • 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?)
  • [X] Perhaps let users choose the effects of the event by choosing an action they want to do when the event happens.
  • [ ] add named command line arguments, to override config and set things like:
  • [ ] random seed
  • [ ] difficulty
  • [ ] min probability
  • [ ] max probability

Feature: Karma

  • [ ] neutral events that give positive and negative choices
  • [ ] pick up or not pick up person while riding the bike
  • [ ] positive or negative karma points
  • [ ] karma points
  • [ ] calculation: (karma points * positive/negative multiplier specified by
  • event) + prob. of event
  • [ ] initial karma in general config (additional difficulty adjustment)

Feature: Actions

  • [ ] allow to always choose an action, even with empty action list, because
  • there is always the choice of specifying a custom action

Feature: General events

  • [ ] add general events to the configuration and program, which can happen with
  • any means of transportation

Feature: Validation

  • [ ] effects array can be enum members

Feature: Summary [0/1]

  • [ ] count number of events that happened to a player -> traveler state

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
  • into the program

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.