Worldmaker

(re)Planning Worldmaker

A decent amount of work has gone into Worldmaker, and I kind of knew at the back of my head that there would need to be a rework but I didn't expect to do it this soon.

The core concept behind Worldmaker is putting the user behind the wheel of keystone decisions, called "Tasks" in the app. I realize now that I should have planned out a larger number of these before jumping into the code.

All tasks can be viewed in one handy popup

As development progressed, I realized that it's really important that these tasks and their associated code:

  1. Are modular
  2. Can easily have new ones added or inserted
  3. Have easy access to the state

Unfortunately as I worked, I realized I had dug myself a pretty convoluted hole of a structure where a lot of the logic was performed within the "toolbar" - a UI element appearing on the right side of the screen, and due to the state's decidedly untyped nature, things got hard to understand fast, especially if I hadn't worked on it in a few days.

The first task is more of a test case than anything. It requires the user to read a short introduction text in the toolbar, then continue to the next task.

The first task
  • Top Bar: Along the top of the screen, there's a pretty empty bar whose only real purpose is to hold the logo and the save button. In the future, app-level buttons will go here - to access options or screenshot functionality.
  • Layers: On the far left, there's a layers panel that is hidden by default. Map layers can be toggled and rearranged from this panel. Layers that are not available are locked.
  • The Map: In the center of the screen is the map. The map is directly changed by the state. When there's a state change event, the map redraws the affected layers.
  • The Toolbar: The toolbar is where the user can affect the current task or progress to the next task. Changing options in the toolbar affects the state.

User flow goes something like this:

  1. User makes a change to toolbar
  2. State changes
  3. Map changes to reflect state change

My big mistake was not to abstract the state, and fail to create an overall modularization of the different tasks as their own classes. Since a lot of logic takes place within the toolbar itself right now, I need to figure out how to organize the code and content so that the toolbar does no logic and only forwards the desired changes to a state controller that knows what the current task is and what classes will take over the necessary calculations.

My next step will be to create a proper flow chart that can be referred to when crafting a new structure for the program.