Monthly Overview for June

General:

  • Changed the look and feel of the buttons so that they look more button-y to the user.
  • Ditto for factories, which now have a slightly different look than the elements you take out of them.
  • Fixed a save error that didn't appear in my testing environment.  
  • Changed the win screen so that any click doesn't switch it off.  This means you won't accidentally click out and not get to see the confetti.

Graphics Refactor:

The purpose of the graphics refactor is to allow rescaling so that players can build larger logic diagrams.  This will involve creating scalable classes that use Game() or Viewer() information to rerender base objects upon a rescale.

  • Actions:
    • Worked on the ColorScheme() class.

Screen Refactor:

The purpose of the screen refactor is to move all game logic into the Game() and Screen() classes rather than in a series of functions that swap the game state between them.

Current Plan for Screen Refactor

  1. Push all actions on the Win and Retire screens into Game() and Screen() objects. 
  2. Push all actions in the Login screen into Game() and Screen() objects.
  3. Work on the selection screen to get levels and tutorials into Game() and Screen objects.
  4. Push all actions in the Selection screen into Game() and Screen() objects.
  5. Work on moving the program into the Game() object so that it's manipulable.
  6. Integrate parts of that into the Win and Retire screen.. (i.e., you can move stuff around, but not alter the program).
  7. Work on moving inputs in the game() function into Game() and Screen() objects.
  8. Push Game screen into the Game() and Screen() objects.
  9. Integrate the Win and Retire screens.
  • Work completed in June:
    • Screen integration has begun.
    • All screens now use internal game states in the screen loop, allowing for the integration.
    • Win, Retire, and Login screens are still handled by functions, but have a standard organization that ignores the specific content of the screen.  There are some minor differences in the code, but that is because certain actions aren't used in those screens.
    • An event handling method has been implemented in the Screen() class that cycles through buttons and action objects active for that screen.  All button evaluations are now in those screens.
    • Created a specialized container for the confetti on the win screen, allowing me to put the confetti into the game Screen() object.
    • All clock operations are now integrated into the Game() object.
    • Created three levels in the screens: background, middle (action) ground, and foreground.
    • Screen set-up has its own function, pulled out of main().  Abstracting out the logic from the control functions added more and more logic to main() that wasn't in the control loop but will need to be done when main() is removed. 
    • Created a Message() class that outputs text with a variable in a simple way.  Also created a FadeIn() class that takes a message and fades it in from BLACK to whatever color (WHITE or YELLOW).
  • Created some simple Action classes that are held by the screens.  The actions are fairly simple: they couple one event or type of event with a method from a single object, either a game or a screen so far.  The action classes are attached to the relevant game screens, and when a screen is active, each event is passed through every listener to see if their action should be activated.  They are broadly keyboard listeners or mouse listeners, and several have been made so far.
    • Integrated close button decoration into a Quit() action.
    • Created a KeyInput() listener that modifies a string variable from input.  Only uses caps and only uses
    • Created a SingleKey() listener that couples a key to an action.  Right now it only controls the enter button, but it can be used for keyboard shortcuts later. 
    • Made an AnyKey() listener to allow the screen to advance on any keyboard input. "Press any key to continue."
  • Patches:
    • Game logic in the main() function is now screen based.  This entire function disappears when the screen integration is completed, but this means
    • Game screens only take the game object as an argument, taking all their information from it.
  • To Do:
    • Allow moving the game pieces around after the win (but no adding/removing elements) (May)

Other Ideas:

  • Button Action: Activate buttons on MOUSEBUTTONUP if the mouse is still over the same button as it was when the game received a MOUSEBUTTONDOWN command.
  • Help Screen (April): Create an in-game help screen.
  • Tip Jar (April): I know you want to help support the game.
  • Level Randomization (April): Randomize level label so that player cannot know what the puzzle is before he clicks on it.
  • Level Unlock (April): Only allow players to work on levels with more switches if a certain percentage of previous puzzles are completed (perhaps all).
  • Unlimited Level Size (April): After graphic refactor, allow players to play levels of arbitrary size.  Game logic already allows this, but there may be a few specifics with the graphics and so on that need to be taken care of before this actually works. 
  • Logic Table: Show level's logic table to player.
  • Save Play State (April): Save the game during play.
  • Win Quality (April): Give more stars for wins with fewer elements in the program or for harder puzzles (see Difficulty Levels, above)

Program Elements:

  • Probe Light: Allow players to insert a probe at various points so that they can see what the output of a sequence of logic is.
  • Ground (May): Integrate a ground so that solutions are only viable when all buttons are connected to something.  Current change in thinking is to include only one ground, vertical at the bottom of the play area, so that player can only ground buttons.
  • Difficulty Levels (April):  Need to include difficulty levels by changing the available gates.  Hard level: NOR-only.


Other Things to Do for Graphics:

  • Different pointers for different purposes:
    • Mostly use the arrow, but
    • Add a pointy finger over the buttons, and
    • Add a grabby hand for movable objects and factories, that
    • Becomes a closed hand when pulling something around, while
    • Showing a soldering iron over pads and while drawing wires, while
    • becomes a clasp when the end of a wire is over a terminal. 
  • Border for play area.
  • Draw convincing trash can. (April)
  • Change "1 Switch", "2 Switches" labels to some kind of graphical depiction. (April)

Other Versions:

I am not satisfied with having only a Windows version of this software.  I would like to expand to other operating systems or delivery methods.  In order, the priorities are:

  • Web Version (includes: learn JavaScript)
  • Android Version (includes: learn Java, etc.)
  • Mac Version (need a Mac to use Py2App)