This is a biggie.
It might be time to review the structure of the entire toolkit. There are a number of crossroads to look at.
Crossroad 1: Google Sheets or Python?
I think I've already made up my mind about this one, but it deserves writing down.
The toolkit currently works along with Google Sheets, for setting data and reading simulation results. If Google Sheets are left behind, it would be possible to shift platform and language, and Python is an attractive option.
Advantages with switching to Python:
- A language I like more
- A language I want to learn more
- Unlimited execution time (which allows for much more interesting and comprehensive simulations)
- Possible to read data from different files, and output results to different files (which makes comparisons easier)
- A chance of, eventually, using machine learning for agent strategies
Advantages with staying with Google Sheets
- Much lower threshold for others to get started with the toolkit
- Quicker and easier to make short one-off simulations
Looking at what I actually use the toolkit for, it is clear that I should stay with Google Sheets. I mostly make quick one-offs, not big simulations. The biggest reason for shifting would probably be to learn Python and, in the far future, learn more about machine learning. That will be some other time.
Crossroad 2: Exclude simulation sequence from the toolbox?
The toolbox currently has a simulation function, encompassing everything in the intended simulation, and actual simulations are written as plugins with functions being called at the proper times. I think this in some ways raises the barrier to using the toolbox – you have to understand the chain of the simulation sequence before you can use the toolbox. On the other hand, you don't need to code the sequence yourself – you can just focus on a few small parts if you want to make a quick one-off.
The alternative to the current model is to just provide a number of functions, that helps a lot in simulating games but are called from a stand-alone script. It would probably make sense in many ways, but on the other hand the one-offs would end up having a lot of shared code.
A concrete difference would be that a more free structure wouldn't include a gameState object.
I'm not sure where to go with this one.
Crossroad 3: Move all/most code to a single object?
It would make sense to move all the functions in the toolbox to a single object.
I'm not sure what that does to with the classes – it would be really nice to have them all moved together in some way, but I don't know how or if that could be done in JavaScript. (Maybe it would make sense to have a base class that the others extend?)
This is a biggie.
It might be time to review the structure of the entire toolkit. There are a number of crossroads to look at.
Crossroad 1: Google Sheets or Python?
I think I've already made up my mind about this one, but it deserves writing down.
The toolkit currently works along with Google Sheets, for setting data and reading simulation results. If Google Sheets are left behind, it would be possible to shift platform and language, and Python is an attractive option.
Advantages with switching to Python:
Advantages with staying with Google Sheets
Looking at what I actually use the toolkit for, it is clear that I should stay with Google Sheets. I mostly make quick one-offs, not big simulations. The biggest reason for shifting would probably be to learn Python and, in the far future, learn more about machine learning. That will be some other time.
Crossroad 2: Exclude simulation sequence from the toolbox?
The toolbox currently has a simulation function, encompassing everything in the intended simulation, and actual simulations are written as plugins with functions being called at the proper times. I think this in some ways raises the barrier to using the toolbox – you have to understand the chain of the simulation sequence before you can use the toolbox. On the other hand, you don't need to code the sequence yourself – you can just focus on a few small parts if you want to make a quick one-off.
The alternative to the current model is to just provide a number of functions, that helps a lot in simulating games but are called from a stand-alone script. It would probably make sense in many ways, but on the other hand the one-offs would end up having a lot of shared code.
A concrete difference would be that a more free structure wouldn't include a
gameStateobject.I'm not sure where to go with this one.
Crossroad 3: Move all/most code to a single object?
It would make sense to move all the functions in the toolbox to a single object.
I'm not sure what that does to with the classes – it would be really nice to have them all moved together in some way, but I don't know how or if that could be done in JavaScript. (Maybe it would make sense to have a base class that the others extend?)