█29█29█29█29█29█29█29█29█29█29█29█29█29█29█29█29█29█29█29█29█29█29█29█29█29█29█29█29█29█29█29█29█29█29█29█29█29█29█29█29█29█29█29█29█29█29█
Asteroids Game
├── Meta
│   ├── Users
│   │   └── Brendan Rood
│   │       ├── Student Employee
│   │       └── Programmer
│   ├── Timestamp
│   │   ├── 8/17/23
│   │   └── 5:30pm
│   ├── Location
│   │   ├── Physical Location
│   │   │   └── Maple Grove, MN
│   │   └── Digital Locaiton
│   │       └── LARSLab, UMD
│   └── Relevant Sources
│       └── GoogleDrive/SharedDrives/BrendanTemp/SecMisGame/Program/*
├── Purpose
│   ├── Peterson wanted Brendan to attempt to make a "Real" minigame
│   └── Brendan did this by recreating something similar to the game he found in createJS
│       └── https://createjs.com/demos/easeljs/game
└── Asteroids
    ├── New Minigame added
    ├── User controlls space ship with arrow keys and may shoot with space
    ├── When a bullet hits an asteroid it breaks apart into 3 smaller ones
    ├── Small asteroids do not produce further offspring when broken
    ├── If the player mannages to destory all asteroids, proceed() is executed
    └── If the player is struck by an asteroid, back() is executed
█28█28█28█28█28█28█28█28█28█28█28█28█28█28█28█28█28█28█28█28█28█28█28█28█28█28█28█28█28█28█28█28█28█28█28█28█28█28█28█28█28█28█28█28█28█28█28█28█28█28█
SimonSays and Activity_Converter
├── Meta
│   ├── Users
│   │   └── Brendan Rood
│   │       ├── Student Employee
│   │       └── Programmer
│   ├── Timestamp
│   │   ├── 8/15/23
│   │   └── 5:30pm
│   ├── Location
│   │   ├── Physical
│   │   │   └── Maple Grove, MN
│   │   └── Digital
│   │       └── LARSLab, UMD
│   └── Relevant Sources
│       └── GoogleDrive/SharedDrives/UMDLARS/BrendanTemp/SecMisGame/Program/*
├── New Minigame - Simon Says
│   ├── Purpose
│   │   └── Wanted to demonstrate a full minimum deliverable with a few key requiriements
│   │       ├── Game must have a "pass" and "fail" state.
│   │       └── Game must require a modicum of problem solving.
│   │           └── Accomplished by reacting to a random prompt.
│   └── Description
│       ├── User is presented with four colored buttons
│       │   └── Red, Yellow, Blue, Green
│       ├── User is presented with a prompt text asking them to click a certain colored button
│       │   └── The chosen color for the prompt is determined randomly
│       ├── If the user clicks the correct color, they navigate to the rewards screen
│       │   └── PASS condition
│       └── If the user clicks a different color, they navigate back to the overworld
│           └── FAIL condition
├── Activity Converter
│   ├── To resolve some issues with circular dependencies, a "dependency injection" solution had to be followed.
│   ├── The only place where this applies is overworld launching minigames.
│   │   └── This matters because overworld.js CANNOT import anything that extends the minigame class.
│   ├── Overworld.js creates an abstract activity which it initalizes with all the data it chooses.
│   ├── It then also populates to ".convertTo" feild with the name of the activity it wishes to be converted to.
│   └── EX: var x = new Activity(gamestate); x.convertTo = "SimonSays"; is converted to x.instanceOf("SimonSays") == true
└── Going Forward
    ├── Discuss with Peterson about what to do next, as most basic features are there.
    └── One idea: Inventory is not quite done yet. Create a game that can dynamically provide inventory objects?
█27█27█27█27█27█27█27█27█27█27█27█27█27█27█27█27█27█27█27█27█27█27█27█27█27█27█27█27█27█27█27█27█27█27█27█27█27█27█27█27█27█27█27█27█27█27█27█27█27█27█27█27█
Return to Operability
├── Meta
│   ├── Users
│   │   └── Brendan Rood
│   ├── Timestamp
│   │   ├── 5:30pm
│   │   └── 8/13/23
│   ├── Location
│   │   ├── Physical
│   │   │   └── Maple Grove, Minnesota
│   │   └── Digital
│   │       └── LARSLab, UMD
│   └── Relevant Sources
│       └── GoogleDrive/SharedDrives/UMDLARS/BrendanTemp/SecMisGame/Program/*
├── Preliminary Observations
│   ├── Brendan is not sure what state he left the program in, but when he went to poke at it over break it was broken.
│   └── Today, he returned it to a state of semi-operability.
│       └── Program boots and can navigate though the gamestates and aactivities, but some issue still exist.
├── Modeling after the new origin-prototyping schema
│   ├── Most of the issues with the code were related to objects still trying to draw their absolute positions
│   └── This is in contrast to the intended solution of defining your shape at the origin and having it placed automatically.
├── Specific features still broken
│   ├── All GameObjects produced in GameObjects/text.js are not being displayed properly.
│   └── The game seems to resize canvas elements when the canvas is resized (which shouldn't be possible???)
└── Going forward
    └── I think it makes sense to finish cleaning up the origin-prototyping migration and then work on a minigame
        ├── Idea of "minimum deliverable such that correct & incorrect inputs exist, and require a modicum of problem solving.
        └── EX: 4 colored buttons and a text box tells you which one to press.
█26█26█26█26█26█26█26█26█26█26█26█26█26█26█26█26█26█26█26█26█26█26█26█26█26█26█26█26█26█26█26█26█26█26█26█26█26█26█26█26█26█26█26█26█26█26█26█26█26█26█26█26█
Solution to drawing override
├── GameObject and DrawObject are merged.
├── GameObject contains 4 new methods
│   └── draw()
│       ├── rotatecanvas()
│       │   └── rotates the canvas to GO's rotation
│       ├── drawMethod()
│       │   └── actual implimentation of how to draw the object
│       └── resetcanvas()
│           └── rotates the canvas back to 0
├── draw(), rotatecanvas(), and resetcanvas() are never re-implimented in derived classes, so they always default to super case
└── drawMethod() is always overridden and never calls super(), allowing the implimentation to differ
█25█25█25█25█25█25█25█25█25█25█25█25█25█25█25█25█25█25█25█25█25█25█25█25█25█25█25█25█25█25█25█25█25█25█25█25█25█25█25█25█25█25█25█25█25█25█25█25█25█25█25█25█25█25█25█25█
Major Refractoring Planning
├── Meta
│   ├── Users
│   │   └── Brendan Rood
│   │       ├── Student Employee
│   │       └── Programmer
│   ├── Timestamp
│   │   ├── 7/24/23
│   │   └── 1:00pm
│   ├── University of Minnesota Duluth
│   │   └── LARSLab
│   └── Relevant Sources
│       └── GoogleDrive/SharedDrives/UMDLARS/BrendanTemp/SecMisGame/Program/*
├── Purpose
│   ├── Brendan and Peter have decided that some major changes need to be made to how the program operates
│   ├── A greater focus on anonymous functions is desired rather than dynamic classes
│   ├── Current Implimentation
│   │   ├── Assumption is that users will define custom objects within activities
│   │   └── Objects are made extremely modular to support custom objects of any content
│   └── Intended Implimentation
│       ├── Assumption would be that users meerly instantiate custom objects defined in lib files external to activity
│       └── Objects do not need to support all cases because they just expose basic interfaces
├── What needs to happen
│   ├── Changes to DrawObject
│   │   └── DrawObject becomes a class with far fewer components
│   │       ├── Memebers
│   │       │   ├── DrawCenter
│   │       │   │   └── The (x,y) point where drawing should be in reference to
│   │       │   ├── DrawRotation
│   │       │   │   ├── The rotation of the object in radians, which the entire object is rotated by
│   │       │   │   └── context.rotate(angle); - globally rotates the context for drawing
│   │       │   └── DrawData
│   │       │       └── A function as variable that describes how to draw the DrawObject, including color, fill, style, etc.
│   │       └── Methods
│   │           └── draw() - executes this.DrawData at location this.DrawCenter and rotation this.DrawRotation
│   └── Changes to GameObject
│       └── GameObject becomes a class with far fewere components
│           ├── Members
│           │   ├── Origin
│           │   │   └── The (x,y) point where the object is centered at
│           │   ├── Rotation
│           │   │   └── The rotation of the object in radians, which is used for drawing and calculation
│           │   └── DrawObject
│           │       ├── NOT IN CONSTRUCTOR; DEFINED IN LIBRARY
│           │       └── Object representing how and what to draw for this GameObject
│           └── Methods
│               └── update()
│                   ├── ALL GAMEOBJECTS MUST HAVE THIS FUNCTION
│                   ├── central and standard function that is called on all gameobjects by activity.
│                   ├── Base class simply executes this.DrawObject.draw();
│                   └── Derived classes are intended to add all intended behavior here bfore calling super.update();
└── Acknoledgements
    ├── This will break literally everything.
    ├── The entire codebase relies on the current implimentation of GameObject and DrawObject.
    ├── This is neccesary for making the platform servicable.
    └── In the event that things are so broken that i need to start over, the commits before 1:00pm on 7/24/23 are a good rolling-back point.
█24█24█24█24█24█24█24█24█24█24█24█24█24█24█24█24█24█24█24█24█24█24█24█24█24█24█24█24█24█24█24█24█24█24█24█24█24█24█24█24█24█24█24█24█24█24█24█24█24█24█24█24█24█
7/24/23 Meeting
├── Meta
│   ├── Users
│   │   ├── Brendan Rood
│   │   │   ├── Student Employee
│   │   │   └── Programmer
│   │   └── Peter Peterson
│   │       ├── Professor
│   │       └── Leader
│   ├── Timestamp
│   │   ├── 7/24/23
│   │   └── 12:30pm
│   ├── University of Minnesota Duluth
│   │   └── LARSLab
│   └── Relevant Sources
│       └── GoogleDrive/SharedDrives/UMDLARS/BrendanTemp/SecMisGame/Program/*
└── TODO: Changes to DrawObjects
    ├── Drawing as Function
    │   ├── Instead of drawobjects being controlled by an array of points, instead migrate to a parameter that is an anonymous function of how to draw it
    │   │   └── This would allow circles, rectangles, sprites
    │   ├── To ease development, make a seperate class system that allows for preformated basic shapes
    │   │   └── Example, an object, "rectangle", who's only existance is to return an anonymous function describing context.strokeRectangle
    │   ├── Could also be useful to clean up the need for distinct gameobjects for things not reperesentable by drawPoints
    │   │   └── EX: text objects
    │   ├── Could also be useful to clean up DrawObject's color and shouldfill feilds, as could have fixed defenitions as in ./../[4]
    │   └── Possible Solutions - !!!
    │       ├── Instead of users creating gameobjects dynamically, what if all objects were required to be classes that were constructed within activities?
    │       └── This could work! Example:
    │           └── /MinigameTypeOne
    │               ├── /minigametypeone.js - implimentation of activitiy
    │               └── /minigametypeone_lib.js - defines the custom GameObjects (and DrawObjects therewithin) used in the activity
    └── Object rotation
        └── should also add a standard way of rotating GameObjects and have that translate to a rotated DrawObject
█23█23█23█23█23█23█23█23█23█23█23█23█23█23█23█23█23█23█23█23█23█23█23█23█23█23█23█23█23█23█23█23█23█23█23█23█23█23█23█23█23█23█23█23█23█23█23█23█23█23█23█23█
Basic Reward Protocol
├── Meta
│   ├── Users
│   │   └── Brendan Rood
│   │       ├── Student Employee
│   │       └── Programmer
│   ├── Timestamp
│   │   ├── 7/24/23
│   │   └── 11:59am
│   ├── University of Minnesota Duluth
│   │   └── LARSLab
│   └── Relevant Sources
│       └── GoogleDrive/SharedDrives/UMDLars/BrendanTemp/SecMisGame/Program/*
├── Purpose
│   └── There must be a standard way for minigames to pass new items to the gamestate inventory
├── Distinct seperation of Inventory from Gamestate
│   ├── New classes at gamestate/inventory.js
│   ├── Inventory is a class that holds Items
│   │   └── class also contained in inventory.js
│   ├── Inventory provides a way to access the this.inventory and this.additions members
│   └── Inventory also provides a standard function for adding all values of this.additions to this.inventory, and then setting this.additions to null
├── Creation of new "Text" gameobjects
│   ├── Standard object to be added to the canvas for displaying text
│   └── TODO: support multiline content
│       └── JS fillText does not support newlines; this neccesitates subdraws at line offsets (eww)
├── Intended operational flow
│   ├── Minigames can reference the gamestate.inv, where they can create new Item objects and add them to this.gamestate.inv.additions via inv.addItem(item)
│   ├── The reward screen then displays the newly aquired items (currently at top of screen) and the (old) total inventory contents (currently at bottom of screen)
│   ├── The reward screen then calls inv.processAdditions() to migrate additions to inventory before exiting to minigame
│   └── This allows minigames to dynamically add items to the gamestate inventory.
└── Next steps
    ├── Rewards screen is ugly
    │   └── Unlike abstract minigame or demo, reward will not be overridden so puting some attention into making it look presentable is reasonable.
    ├── Text newline support
    │   └── ./../../../[3]/[1]
    └── Meeting with Peter Peterson will be happening in the next few minutes (as of time of writing)
█22█22█22█22█22█22█22█22█22█22█22█22█22█22█22█22█22█22█22█22█22█22█22█22█22█22█22█22█22█22█22█22█22█22█22█22█22█22█22█22█22█22█22█22█
A Complete Prototype
├── Meta
│   ├── Users
│   │   └── Brendan Rood
│   │       ├── Student Employee
│   │       └── Programmer
│   ├── Timestamp
│   │   ├── 7/17/23
│   │   └── 5:00pm
│   ├── University of Minnesota Duluth
│   │   ├── Physical Locaiton: MMADLab
│   │   └── Digital Presence: LARSLab
│   └── Relevant Sources
│       └── GoogleDrive/SharedDrives/UMDLARS/BrendanTemp/SecMisGame/*
├── Description of Accomplishments
│   ├── Curent build features a nearly feature-complete demonstration of the program's flow.
│   ├── Overworld -> Demo (Minigame) -> Reward -> Overworld
│   │   ├── Demo is a Derived class of Minigame
│   │   └── Demo displays the aux "Difficulty" parameter, showing passing in dynamic minigame arguments.
│   └── Limitations
│       ├── No standard protocol established for passing rewards from Minigame to Reward
│       └── No standard protocol for displaying rewards on rewards screen
├── Refractoring
│   └── Lib
│       ├── Abstract
│       │   └── AbstractLib.js
│       │       └── Now contains "Rectangle" Class- used for Button shape
│       └── canvasElements.js -> button.js
│           └── Subdividied into a .js file that contains only buttons and their derivatives
│               ├── Includes TextButton
│               └── Includes ArrowButton
└── Looking Forward
    ├── Immediate Goal: ./../../[1]/[2]/*
    └── Afterwards: Make Demo and Rewad more descriptive and demonstrate them to minigame implimenters.
█21█21█21█21█21█21█21█21█21█21█21█21█21█21█21█21█21█21█21█21█21█21█21█21█21█21█21█21█21█21█21█21█21█21█21█21█21█21█21█21█21█21█21█21█21█
Preparing for new Activity Archetecture
├── Meta
│   ├── Users
│   │   └── Brendan Rood
│   │       ├── Student Employee
│   │       └── Programmer
│   ├── Timestamp
│   │   ├── 7/10/23
│   │   └── 5:00pm
│   ├── University of Minnesota Duluth
│   │   └── LARSLab
│   └── Relevant Sources
│       └── GoogleDrive/SharedDrives/UMDLARS/BrendanTemp/SecMisGame
├── Restructuring Files
│   ├── Subdirs were added to reflect compatmentalization within base classes.
│   ├── Minitest.js is temporary and needs to be ported to ./Program/Activities/Minigame/Demo/demo.js
│   └── Libraries were also broken apart at ./Program/Lib/*
│       ├── AbstractLib.js - Abstract concepts as objects
│       │   └── class Point
│       ├── gameobject.js - Class containing the primary abstractions for drawing elements on an HTML canvas.
│       │   ├── class DrawObject
│       │   └── class GameObject
│       └── canvasElements.js - Classes of common gameobjects for easier reuse
│           └── class Button
├── Moving document listeners
│   ├── Was running into an issue where every time a new activity was created, more listeners were added without old ones being removed.
│   │   └── Issue was significant because document.removeEventListener cannot operate on anonymous functions require to preserve 'this'.
│   └── Issue resolved by having exactly one set of listeners declared in the main class rather than in each activity.
│       └── Listeners call into this.activity to replicate the original functionality.
├── Lossy == vs. Lossless ==
│   ├── Was running into an issue where the click listener was convincing objects to click themselves, even at point (null,null).
│   ├── Realized this was because in JS, "(null,null) != (null,null)" but "(null,null).toString() == (null,null).toString()".
│   └── Point.toString() was implimented as a way to preform "lossy comparison" to reach desired behavior.
└── Current Implimentation
    ├── Game launches directly into Overworld Activity
    ├── Clicking a node launches the ABSTRACT minigame activity, which immediately errors, launching Reward.
    ├── Reward activity contains an unlabled square at the center of the screen. When clicked, this returns to Overworld activity.
    └── Updates to Overworld are handled by the "proceed" and "back" functions in the minigame abstract class.
█20█20█20█20█20█20█20█20█20█20█20█20█20█20█20█20█20█20█20█20█20█20█20█20█20█20█20█20█20█20█20█20█20█20█20█20█20█20█20█20█20█20█20█20█20█20█20█20█20█
Archetecture Meeting - A little less modular
├── Meta
│   ├── Users
│   │   ├── Brendan Rood
│   │   │   ├── Student Worker
│   │   │   └── Programmer
│   │   └── Peter Peterson
│   │       ├── Professor
│   │       └── Employer
│   ├── Timestamp
│   │   ├── 7/10/23
│   │   └── 12pm-1pm
│   └── University of Minnesota Duluth
│       └── LARSLab
├── Meeting Notes
│   ├── Demonstrated current capabilities
│   ├── Discussed future plans
│   ├── Discussed modifications to archetecture
│   └── Discussed next meeting time (7/24)
├── Breaking apart activities
│   ├── Demonstrated a need to less modular activities due to the difficulty in implimenting them.
│   ├── Decided to break apart the activities into 5 main activity types.
│   │   ├── Main Menu
│   │   │   ├── Initial screen that the user loads into. Contains "New Game" and "Continue" buttons.
│   │   │   └── Transitions TO: Overworld.
│   │   ├── Overworld
│   │   │   ├── Primary node graph state for navigating across levels.
│   │   │   └── Transitions TO: N Minigame(s).
│   │   ├── Minigame
│   │   │   ├── A standard interface for loading a minigame. contains a minigame object who's implimentation differentiates each minigame.
│   │   │   └── Transitions TO: Rewards.
│   │   ├── Rewards
│   │   │   ├── A screen providing notifications of aquired upgrades or hints.
│   │   │   └── Transitions TO: Overworld.
│   │   └── Ending
│   │       ├── Final screen congradulating the player for completing the game.
│   │       └── Accessible by completing the final node of the Overworld.
│   └── As discussed in ./../[1]/[2], there is a desire to make minigames more modular.
│       ├── Instead of each minigame extending activity, each minigame should extend "Minigame", which itself extends activity.
│       ├── This allows for more universal and independent implimentaiton of disperate minigames by different developers.
│       └── Useful to create a "demo" minigame to demonstate the interface to developers.
├── Distinction between "GameState" and "ActivityState".
│   ├── It does not make sense to pass around the full game state between activities.
│   ├── Instead, we should hold the GameState in permanent memory and instead modify it between activities.
│   │   └── Activities would require a reference to the GameState obj.
│   └── Current Thinking:
│       ├── Overworld Tree
│       │   └── Includes accesibility and replay of nodes
│       └── "Inventory"
│           └── Includes waht powerups have been collected
└── Saving and Loading
    ├── We want to find a way to reinstantiate the most recent game state for the player across sessions.
    ├── We will accomplish this by having a cookie that is a big json of the GameState.
    ├── This is not a priority and can come later in development.
    └── See json stringify.
█19█19█19█19█19█19█19█19█19█19█19█19█19█19█19█19█19█19█19█19█19█19█19█19█19█19█19█19█19█19█19█19█19█19█19█19█19█19█19█19█19█19█19█19█19█19█19█19█19█19█19█19█19█19█
JS Modules and Program Activities
├── Meta
│   ├── Users
│   │   └── Brendan Rood
│   │       ├── Student Employee
│   │       └── Programmer
│   ├── Timestamp
│   │   ├── 7/7/23
│   │   └── 4:30pm
│   ├── Univesity of Minnesota Duluth
│   │   └── LARSLab
│   └── Relevant Sources
│       └── GoogleDrive/SharedDrives/UMDLARS/BrendanTemp/SecMisGame/Program/*
├── Purpose
│   ├── Now that the node graph is implimented, preperations must be make to start implimenting the minigames.
│   ├── To this end, the code needs to be cleaned up to support those minigames because its getting very large.
│   └── This was accomplished by using JS Module Syntax to split the code into disperate .js files.
│       └── index.html only has a very small script to get the process started.
├── Today's Progress
│   ├── Activities
│   │   ├── Program has been restructured to work under an archetecture of "activities".
│   │   ├── Each activity extends the Activity class in activity.js, and reperesents a single object that is drawn by the main loop.
│   │   ├── The main loop is contained in a "Main" object defined in main.js. It holds one activity object.
│   │   ├── Every 10ms main passes an update() call down to its activity, as well as checks if that activity's "transition" var != null.
│   │   ├── When this var != null it reperesents that the activity wants to exit and transition to a new activity.
│   │   └── Contents of ActivityTransition
│   │       ├── Name of the class representing the new activity to transition TO.
│   │       ├── A full copy of the activity being transitioned away FROM. Used re reinstantiate and resume the activity when relevant.
│   │       │   └── This is possible via Object.assign(this,savestate);
│   │       ├── Class may also contain any number of additional members representing desired parameters.
│   │       │   ├── These additional parameters are set up crudly within each activitiy's "navigate" function.
│   │       │   ├── EX: super.navigate(NextName); this.transition.difficulty = 7;
│   │       │   └── Creates these parameters on the fly, reciving class needs to know what to look for dynamically.
│   │       └── Think of the resume copy being similar to a callback but instead of a function it is a object.
│   ├── Essential Library
│   │   ├── EssentialLib.js
│   │   ├── Certain common classes are used too frequently to be absent. These classes will be contained here which is a standard import.
│   │   └── Current content is the "Point" class.
│   ├── Favicon.ico
│   │   └── This is the image that is displayed for the tab in the browser. The current one is stolen from UMD's website.
│   └── Preserving "this" across Scopes in JavaScript!
│       ├── Brendan finally figured out how to preserve "this" contexts across scopes.
│       └── For a detailed breakdown see GoogleDrive/SharedDrives/UMDLARS/BrendanTemp/SecMisGame/Insights/PreservingTHIS.mhtml.
├── Need local Webserver
│   ├── CORS makes it impossible to develop the program in a static html enviroment anymore.
│   ├── Instead, a webserver MUST be put up for the client to be able to get the disperate .js files.
│   └── python3 -m http.server 8080
└── Going Forward
    ├── Code should be all set up for the implimentation of a test minigame activity.
    └── Test activity will be a canvas with text that displays the input parameters and a button to exit the activity successfully.
█18█18█18█18█18█18█18█18█18█18█18█18█18█18█18█18█18█18█18█18█18█18█18█18█18█18█18█18█18█18█18█18█18█18█18█18█18█18█18█18█18█18█18█18█18█18█18█18█18█18█18█18█
Hard-Coded Locations and Class Inheritence
├── Meta
│   ├── Users
│   │   └── Brendan Rood
│   │       ├── Student Employee
│   │       └── Programmer
│   ├── Timestamp
│   │   ├── 6/30/23
│   │   └── 5:30pm
│   ├── University of Minnesota Duluth
│   │   └── LARSLab
│   └── Relevant Sources
│       └── GoogleDrive/SharedDrives/UMDLARS/BrendanTemp/SecMisGame/Program/RawHTMLTesting/Proto5.html
├── Prioritising the Minimum Deliverable
│   ├── Following two weeks of agony, Brendan realized that he should stop working on the node placement system.
│   ├── Instead, he should focus on producing something that works even if it isn't super pretty.
│   │   └── This can always be changed at a later date if time allows.
│   └── This will be accomplished by simply hard-coding the connection points for the time being.
└── Code Rewrite (again)
    ├── Code was almost completely rewritten with class inheritence in mind.
    │   └── This is the first time in my entire career class inheritence has made sense -_-
    ├── Explanation of Current Classes
    │   ├── Primitive Classes
    │   │   └── Point - Describes an X,Y point.
    │   ├── Base Classes
    │   │   ├── DrawObject
    │   │   │   ├── Describes where and how and object should be drawn.
    │   │   │   │   ├── Provides reference to drawcontext.
    │   │   │   │   ├── Provides a color value.
    │   │   │   │   ├── Provides a bool as to whether or not to fill or outline shapes.
    │   │   │   │   └── Provides an array "drawPoints" that represent an abstract shape that will be executed by iterating down the array.
    │   │   │   ├── Provides ability to draw an unlimited number of subDraw objects that will be drawn and mannaged by this object.
    │   │   │   └── All draws are made relative to this DrawObject's local origin.
    │   │   │       └── This is kept up to date via the encapsualting GameObject calling updateOrigin() on it.
    │   │   └── GameObject
    │   │       ├── Describes the location of an object.
    │   │       ├── Provides a central update() prototype.
    │   │       ├── Contains and manages a DrawObject.
    │   │       └── Distinguishes "moveBy()" and "moveTo()" and impliments them.
    │   └── Derived Classes (extends GameObject)
    │       ├── Node
    │       │   ├── A distinct "node" on the graph.
    │       │   ├── Contains 4 Socket objects.
    │       │   ├── Overrides update() to control state.
    │       │   ├── Overrides draw() to set the node's color based on its state.
    │       │   ├── Overrides draw() to call draw on the node's encapuslated sockets.
    │       │   └── Impliments click() to modify the node's state if the click was within the node's boundary.
    │       ├── Socket
    │       │   ├── Represents one of the 4 squares on the edges of nodes to which branches are connected.
    │       │   ├── Impliments new variable "isPlugged".
    │       │   ├── Impliments new variable "parent" from the provided Parent Node.
    │       │   └── Does redifine any methods; uses super for all but constructor.
    │       ├── Branch
    │       │   ├── Represents the arrow that connect the sockets of two related nodes.
    │       │   └── Reimpliments most features of GameObject.
    │       │       └── Particularly draw(), which is so different that it doesnt even call super.draw().
    │       └── Tree
    │           ├── Represents the primary container for the program.
    │           │   └── Encapsulates an array of nodes and an array of branches.
    │           ├── Handles the logic of adding a new node to the schema with growNewNode().
    │           ├── Passes draw(), moveBy(), and update() calls down to all encapsualted GameObjects.
    │           └── Passes click() down to all encapsulated nodes.
    └── Horrific Initialization Stack
        ├── Within Main ~Line 600 there is a massive stack of PushNode() commands. This populates the main Tree object.
        └── This is not ideal and a better solution is desired.
█17█17█17█17█17█17█17█17█17█17█17█17█17█17█17█17█17█17█17█17█17█17█17█17█17█17█17█17█17█17█17█17█17█17█17█17█17█17█17█17█17█17█17█17█17█17█17█17█17█17█
Polar Placement (again)
├── Meta
│   ├── Users
│   │   └── Brendan Rood  
│   │       ├── Student Employee
│   │       └── Programmer
│   ├── Timestamp
│   │   ├── 6/26/23
│   │   └── 6:00pm
│   ├── University of Minnesota Duluth
│   │   ├── Physically: MMADLab
│   │   └── Virtually: LARSLab
│   └── Relevant Sources
│       └── SecMisGame\Program\RawHTMLTesting/NodePlacement.html
├── Acknowledement of incomplete solution
│   ├── Today brendan tried creating a tree generated from a virtual depth-first-search stack.
│   ├── This implimentation successfully drops nodes in the correct order.
│   └── However, It does not respect space limitations between a parent and its children so overlap occured.
├── Explanation of Algorithm
│   ├── Each node now also contains a "placementWidth" value.
│   │   └── Represents the "area" this node's children may occupy.
│   ├── Each child of a node has a width equal to the parent's width divided by the number of siblings plus one.
│   ├── The left side of a parent is given by parent.center.x - (parent.placementWidth / 2)
│   ├── child.center.x = leftSideOfParent + (childWidth) + (childWidth * siblingIndex);
│   │   └── siblingIndex is the relative position of this particular child compared to its peers in this.parents[0].children
│   └── child.center.y is the tree's root position plus a fixed multiple of the depth
└── Going forward
    ├── Immediately following the code that does the above algorithm VirtualTree/transformVirtual() values must be parsed as polar and converted to cartesian.
    ├── Angle = node.center.x / node.root.placementWidth
    ├── Distance = node.center.y * fixed amonut
    └── This will trasnform the tree to a "free tree" as seen in SecMisGame\Insights/gd-constraints.pdf
█16█16█16█16█16█16█16█16█16█16█16█16█16█16█16█16█16█16█16█16█16█16█16█16█16█16█16█16█16█16█16█16█16█16█16█16█16█16█16█16█16█16█16█16█16█16█16█16█16█
Node Graph Untangle Day 2
├── Meta
│   ├── Users
│   │   ├── Brendan Rood
│   │   │   └── Programmer
│   │   └── Peter Peterson
│   │       ├── Professor
│   │       └── Leader
│   ├── Timestamp
│   │   ├── 6/16/23
│   │   └── 5:00pm
│   ├── University of Minnesota Duluth
│   │   └── LARSLab
│   └── Relevant Sources
│       ├── Files
│       │   └── SecMisGame/Program/RawHTMLTesting/Proto3.html
│       └── Documents
│           └── https://cs.brown.edu/people/rtamassi/papers/gd-tutorial/gd-constraints.pdf
├── Rewriting the program
│   ├── Original implimentation was bad because Brendan did not fully understand how to use JS.
│   ├── Program completely reimplimented (except for spread features) compared to Proto2.html
│   ├── New implimentation makes greater use of for(let item of itemList) to be more readable.
│   │   └── Previous implimentation made use of class for(let i = 0; i < itemList.length; i++)
│   ├── New implimentation makes greater use of static functions to improve understandability.
│   │   └── Statics used when operating on two distinct objects, the result of which does not directly manipulate either object.
│   └── New implimentation has improved the style parameters passed to objects.
│       ├── See new class, "ObjStyle"
│       ├── Class consists of dynamic arrays of each value to enable greater specificicity while maintaining a single structure.
│       └── Does nececcesitate keeping track of indecies though!
├── Initial Placement
│   ├── Migrating towards polar placement.
│   ├── See ./../../[0]/[3]/[1]/[0] Page 31
│   ├── THE INFO COMMUNICATED ON THIS PAGE WAS NOT FOLLOWED!
│   ├── Tried an implimentation that just dropped nodes a fixed distances from the origin that were multiples of a constant radius.
│   └── This led to very large distances between nodes and overlap.
└── TODO: doing ./../[2]/[1] correctly
    ├── If Brendan had actually read page 32 of the doccument, he would have realized that theres a much easier way to do this.
    ├── Must spend time converting the nodes into a tree diagram.
    │   ├── Must formally ditch the idea of multiple parents.
    │   └── Would we want to just use this as the end result?
    ├── Once a tree diagram is reached, convert from cartesian to polar.
    └── SEE PAGE 32 OF ./../../[0]/[3]/[1]/[0]
█15█15█15█15█15█15█15█15█15█15█15█15█15█15█15█15█15█15█15█15█15█15█15█15█15█15█15█15█15█15█15█15█15█15█15█15█15█15█15█15█15█15█15█15█
Node Placement
├── Meta
│   ├── Users
│   │   └── Brendan Rood
│   │       ├── Researcher
│   │       └── Programmer
│   ├── Timestamp
│   │   ├── 6/12/23
│   │   └── 5:30pm
│   └── University of Minnesota Duluth
│       └── LARSLab
├── Summary of Progress
│   ├── Nodes will now try to push eachother away to untangle the map.
│   ├── Nodes untangle at 360* rather than the original implimentation of just 8 directions.
│   ├── Important Functions:
│   └── Proto2.html/class Point/static movePointsAwayFromEachOther(pointA, pointB, distance)
├── Things that still need to get done
│   └── Current implimentation does not always result in a "Clean" graph.
│       ├── Potentially fixed by dumping the whole graph and restarting if there is branch overlap.
│       │   └── This is not actually that computationally expensive with a modest graph. Overlap is uncommon.
│       ├── Potentially fixed by attracting linked nodes to eachother.
│       │   ├── Partially implimented but currently disabled, see class Node > objContractLinked()
│       │   └── "linked" nodes reffer to a node's direct parents and children.
│       └── Potentially fixed by pushing branches away from eachother.
│           └── Brendan tried this solution but it was very confusing. Consider revisiting.
└── Misc JavaScript Syntax Discovery
    └── JS does indeed have a foreach system
        └── for(let object of objectList)
█14█14█14█14█14█14█14█14█14█14█14█14█14█14█14█14█14█14█14█14█14█14█14█14█14█14█14█14█14█14█14█14█14█14█14█14█14█14█14█14█14█14█14█14█
Learning *Vanilla* Javascript
├── Meta
│   ├── Users
│   │   └── Brendan Rood
│   ├── Timestamp
│   │   ├── 6/9/23
│   │   └── 12:00pm
│   ├── University of Minnesota Duluth
│   │   └── LARSLab
│   └── Relevant Sources
│       ├── Internet
│       │   └── https://www.phind.com/ - AI assistant for rapid discovery
│       └── Files
│           └── Google Drive/Shared Drives/UMDLARS/BrendanTemp/SecMisGame/RawHTMLTesting/Test.html
├── Guiding Mindset
│   ├── Taking a step back
│   │   ├── Brendan does not know enough about vanilla JS to be diving into an IDE.
│   │   └── He will instead focus on manipulating an HTML canvas directly via JS embedded in an HTML document.
│   └── AI assistance
│       └── ./../../../[0]/[3]/[0]/[0] will be used to help with the rapid aquisition of JS knowledge.
└── JS Syntax
    ├── Declaring Functions
    │   ├── JS NEVER specifies function return type!
    │   │   ├── Normally, "string myfunction(arg)"
    │   │   ├── In JS, "myFunction(arg)"
    │   │   └── All functions are asumed to return dynamic "var"
    │   │       └── Can include void!
    │   ├── JS NEVER specifies function argument type!
    │   │   ├── Normally, "string myfunction(int number)"
    │   │   ├── In JS, "myfunction(number)"
    │   │   └── All function parameters are assumed to by dynamic "var"
    │   └── When to use the "function" keyword
    │       ├── "function" keyword is only needed when defining a function outside of a class
    │       └── Within classes, everything at the first scope down is assumed to be a function already.
    │           └── "function" keyword is needed if a helper function is declared in a class method.
    ├── Forming a "main loop"
    │   └── setInterval() can call a function after n milliseconds, if used on itself creates a "main" loop
    │       └── EX: function draw() { ...; ...; ...; setInterval(draw, 10); }
    └── Arrays
        ├── Arrays are declared in 3 ways
        │   ├── var arrayName = [item1, item2, item3, ...];
        │   │   └── Array declared with []
        │   ├── var arrayName = new Array(item1, item2, item3, ...);
        │   │   └── Array declared with Array "new" constructor
        │   └── var emptyArray = new Array(sizeAsInt);
        │       ├── Empty array declared with fixed size.
        │       ├── This creates explicitly null entries! Push goes to the end of these!
        │       └── Consider using "=new Array()" to have the list be of 0 length for pushing.
        └── Populating an array
            ├── arrayName.push(value);
            │   └── Adds the value to the end of the list.
            └── arrayName.fill(value);
                └── Populates all indicies with an empty value to equal the provided value.
█13█13█13█13█13█13█13█13█13█13█13█13█13█13█13█13█13█13█13█13█13█13█13█13█13█13█13█13█13█13█13█13█13█13█13█13█13█13█13█13█13█13█13█13█13█13█13█
Why not Vanilla JavaScript?
├── Meta
│   ├── Users
│   │   └── Brendan Rood
│   │       ├── Researcher
│   │       └── Programmer
│   ├── Timestamp
│   │   ├── 6/9/23
│   │   │   └── Date of Discussion
│   │   └── 6/12/23
│   │       └── Date of Entry Authoring
│   ├── University of Minnesota Duluth
│   │   └── LARSLab
│   └── Relevant Sources
│       └── Internet
│           └── HTML MIDI Example
│               └── https://surikov.github.io/webaudiofont/examples/midiplayer.html
├── General Post-Summary
│   ├── What we are trying to do for this project really doesnt warrant the complexity of an IDE.
│   ├── We should instead see how far we can get using "vanilla" JS and HTML5.
│   ├── Pros:
│   │   ├── Brendan doesn't really know JS super well so starting at the base level will be easier than diving into an IDE.
│   │   ├── Even easier for a browser to Execute (fewer libraries).
│   │   └── No chance for vulnerabilities (beyond that of JS, which would hopefully be patched with haste).
│   └── Cons:
│       ├── Might be missing out on some IDE streamlining.
│       │   └── These benefits require a level of profficency that Brendan simply does not currently posess.
│       ├── Reduces Abstracton.
│       │   └── We can create our own abstraction!
│       ├── Must handle sound system ourselves.
│       │   ├── This isn't neccesarily bad and can provide a useful learning opportunity.
│       │   ├── Starting place ./../../../../[0]/[3]/[0]/[0]
│       │   ├── CLARIFY: I would really prefer we use MIDI for any music so it takes less space in the browser.
│       │   └── CLARIFY: .mp3 preffered for sound effects due to very small size.
│       └── Must handle Auth/Tracking ourselves
│           └── See ./../../../../[2] - major topic
└── Discussion of Authentication vs Tracking
    ├── There is no reason to "authenticate" users for this project.
    │   └── Authentication requires handling usernames/passwords and we aren't willing to do that!
    ├── Instead, let's just track users via a cookie.
    │   ├── Cookie can be "exported" from one browser and "imported" to another to allow for not losing progress when changing machines.
    │   │   └── This option would be avalible on the main menu.
    │   └── Tracking allows us to either connect a savestate to the user's cookie or embed the save state directly in said cookie.
    │       ├── Embedding savestate in cookie might not be preferable as it would allow for exchanging progress.
    │       └── Meerly connecting savestate to auth token might be better as it ensures each user completes the exercise independently.
    └── Savestate archetecture requires we have a way to import and export the entire game's state to a text reperesentation.
        └── As tempted as brendan is to use .csv, .json might actually be the correct choice here. .csv would become unreadable.
█12█12█12█12█12█12█12█12█12█12█12█12█12█12█12█12█12█12█12█12█12█12█12█12█12█12█12█12█12█12█12█12█12█12█12█12█12█12█12█12█12█12█12█12█12█12█12█12█12█
Exploration into CreateJS
├── Meta
│   ├── Users
│   │   └── Brendan Rood
│   │       ├── Researcher
│   │       └── Programmer
│   ├── Timestamp
│   │   ├── Original Date
│   │   │   ├── 6/5/23
│   │   │   └── 10:00am-4:00pm
│   │   └── Date of Entry Authoring
│   │       ├── 6/12/23
│   │       └── 12:00pm
│   ├── University of Minnesota Duluth
│   │   └── LARSLab
│   └── Relevant Sources
│       └── Internet
│           └── CreateJS
│               ├── Homepage - https://createjs.com/
│               ├── Most Relevant Example - https://createjs.com/demos/easeljs/game
│               └── Docs page - https://createjs.com/docs/easeljs/modules/EaselJS.html
└── Summary Post-Discussion
    ├── Discovery Phase
    │   ├── MelonJS was proving too limiting to be useful for this project, a new IDE was desired.
    │   │   └── MelonJS is clearly designed for games with set "tilesets" and "maps".
    │   │       └── We have neither of these things.
    │   └── CreateJS was found as a promsing alternative.
    │       ├── Ever more generic and down-to-the-metal than MelonJS.
    │       │   └── Should mean less complexity, but also less abstraction.
    │       ├── Provided many more worked-though examples to reverse engineer.
    │       └── IMPORTANT: Did not require a server to test! All code was executed directly when loading the HTML.
    ├── Investigation Phase
    │   ├── Brendan Poked around with CreateJS for 6 hours on 6/5/23.
    │   ├── Brendan worked primarilly on reverse-engineering and repurposing the example of ./../../../[0]/[3]/[0]/[0]/[1]
    │   ├── Brendan was unable to make significant progress
    │   │   ├── RETROSPECTIVE: Brendan did not understand general JS enough to make meaningful progress.
    │   │   ├── Doccumentation was a bit vague.
    │   │   ├── Lots of ambiguous keywords.
    │   │   └── Although many examples were provided, no "tutorial" is avalaible.
    │   └── Brendan eventually gave up for the day as the experience gave him a migrane.
    └── Results
        ├── CreateJS was found to be too difficult to program in for it to be a viable alternative IDE.
        ├── CreateJS as a Security Vulnerability
        │   ├── The evening of 6/5/23, Brendan received an automated message from github informing them that CreateJS has some security vulnerabilities.
        │   └── Peter Peterson noted that CreateJS has not been updated in around 5 years.
        └── CreateJS was determined to only be an acceptible option if the vulnerabilities could be mitigated or did not impact what we wanted to do with it.
            └── Brendan desented and requested CreateJS not be used at all.
                ├── Part of their desent was due to an uncertanty in how JS syntax worked.
                └── Brendan decided to procus on understanding "vanilla" JS syntax before using an IDE.
                    └── This was followed up on 6/9/23.
█11█11█11█11█11█11█11█11█11█11█11█11█11█11█11█11█11█11█11█11█11█11█11█11█11█11█11█11█11█11█11█11█11█11█11█11█11█11█11█11█11█11█11█11█11█11█11█
melonJS's program structure
├── Meta
│   ├── Users
│   │   └── Brendan Rood
│   │       ├── Student
│   │       └── Researcher
│   ├── Timestamp
│   │   ├── 5/26/23
│   │   └── 3:30pm
│   └── UMD
│       └── LARSLab / ACM Lounge
├── How files are laid out
│   ├── ./index.html
│   │   ├── the dummy page that the browser receieves before the JS can execute
│   │   │   └── contains "<div id="screen"></div>
│   │   │       └── This acts as the placeholder that is later overwritten
│   │   ├── imports the entire melonJS library as a web request
│   │   │   └── ex: import { device } from 'https://esm.run/melonjs@13';
│   │   └── imports ./js/index.js from local directory of server
│   │       └── requires ./../[0]
│   └── ./js/index.js
│       └── parent pointer for all acutal code
│           ├── provides imports to all other .js files
│           └── ex from header of index.js
│               ├── import * as me from 'https://esm.run/melonjs@13';
│               ├── import game from './game.js';
│               ├── import resources from './resources.js';
│               ├── import PlayerEntity from './entities/player.js';
│               ├── import { SlimeEnemyEntity, FlyEnemyEntity } from './entities/enemies.js';
│               ├── import CoinEntity from './entities/coin.js';
│               └── import PlayScreen from './screens/play.js';
└── Opening melonJS projects
    ├── Open the root directory in microsoft visual studio code as a "folder"
    │   └── Folder containing index.html and index.css
    ├── Modify code that is eventually imported as a result of index.js
    │   └── Or have index.html do more onloads
    └── Executing "python3 -m http.server <PORTNUMBER>" with wsl at ./../[0] directory to start a webserver at localhost:<PORTNUMBER> that serves index.html
█10█10█10█10█10█10█10█10█10█10█10█10█10█10█10█10█10█10█10█10█10█10█10█10█10█10█10█10█10█10█10█10█10█10█10█10█10█10█10█10█10█10█10█10█10█10█10█10█10█10█
Launching a Webserver for melonJS
├── Meta
│   ├── Users
│   │   ├── Brendan Rood
│   │   │   ├── Student
│   │   │   └── Researcher
│   │   └── Peter Peterson
│   │       ├── Professor
│   │       └── Mentor
│   ├── Timestamp
│   │   ├── 5/26/23
│   │   └── 2:30pm-3:00pm
│   └── UMD
│       └── LARSLab
├── Difficulties
│   ├── Brendan experienced difficulties getting the webserver to start to launch the "platformer" example of melonJS
│   │   └── He was doing this through GIT BASH
│   └── Discovery of issues
│       ├── GIT BASH is not capable of creating the webserver via python
│       │   └── Use WSL instead
│       └── Browser was caching the website in it's broken state
│           └── Resolve this by holding shift while clicking reload in Google Chrome
└── Walkthrough as solution
    ├── Open wsl
    │   ├── Linux virtual enviroment
    │   └── Not a virutal machine
    ├── Navigate to the root of the webserver
    │   ├── wsl starts at /mnt/c/WINDOWS/system32
    │   │   └── "/mnt/c" corresponds with "C:"
    │   └── For "platformer" MelonJS example this was example-master/platformer
    ├── Execute "python3 -m http.server <PORTNUMBER>
    │   └── Requires instillation of python3 from microsoft store
    │       └── Current version on brendan's computer is 3.11
    ├── Navigate to localhost:<PORTNUMBER>
    └── SHIFT + Refresh as needed
█9█9█9█9█9█9█9█9█9█9█9█9█9█9█9█9█9█9█9█9█9█9█9█9█9█9█9█9█9█9█9█9█9█9█9█9█9█9█9█9█9█9█9█9█9█9█9█9█9█9█
JS IDE Selection Meeting
├── Meta
│   ├── Users
│   │   ├── Brendan Rood
│   │   │   ├── Researcher
│   │   │   └── Student
│   │   └── Peter Peterson
│   │       ├── Leader
│   │       └── Professor
│   ├── Timestamp
│   │   ├── 5/26/23
│   │   └── 12:30pm - 1:30pm
│   ├── University of Minnesota Duluth
│   │   └── LARSLab
│   └── devlog_ChoosingAnIDE.txt
│       └── Root Node 8 - "JS IDE Narrowing the Search"
├── Goals / Purpose
│   ├── We need to select an IDE to use to develop the securit misconceptions video game.
│   ├── We need to define some robust requirements this project needs to succeed.
│   └── We need to establish a shared location to push work to.
│       ├── Shared Google Drive?
│       └── Github?
├── Meeting
│   ├── Presentation of findings
│   │   └── Presented ./../../../[0]/[3]
│   ├── Presentation Discussion
│   │   ├── Where would authentication be stored?
│   │   │   ├── Rationalle: We need to be securea bout user datas in a game about securit data lol.
│   │   │   ├── We do not feel comforatble storing user data on a 3rd party site.
│   │   │   └── However, storing it as a 1st party we have certain ethical considerations,
│   │   │       └── Use local cookies?
│   │   └── Spinning off Minigames
│   │       ├── Peter's Idea: Minigames as internal Windows
│   │       └── P2: Nodes open new sites?
│   │           └── Popups or Popunders
│   ├── Post-Presentation Discussion
│   │   ├── Integration of Minigames
│   │   │   ├── Brendan does not want to directly impliment the mini games
│   │   │   ├── Game takes in a list of avalible minigames ot refelct the current misconception being explored.
│   │   │   │   └── Game state changed silently, user cannot see games of another lesson.
│   │   │   └── Now all misconceptions make sense to be minigames in this engine.
│   │   └── Assesesment bundle structure
│   │       ├── Teach
│   │       ├── Execute
│   │       ├── Evaluation
│   │       └── These are done for the entire scope of the game, not level-by-level.
│   ├── Discussion of Requirements
│   │   ├── Platform
│   │   │   ├── Run in browser
│   │   │   └── No components needed to download
│   │   ├── User data
│   │   │   ├── Do not store user data locally or at a 3rd part
│   │   │   └── Use cookies instead
│   │   └── Upkeep and mainenance
│   │       ├── Ideal Timeline
│   │       │   └── Work for 5-7 years.
│   │       └── Should be infiniately supportable without the influence of a company
│   │           ├── Does PlayCanvas have a potential to break this?
│   │           ├── Does GDevelop have a potential to break this?
│   │           └── melonjs's gernericness helps this.
│   ├── Verdict
│   │   ├── Start with developing under melonJS
│   │   │   ├── Good longevity
│   │   │   ├── Gerneric
│   │   │   │   └── Don't need fancy stuff
│   │   │   └── Certain conditions that warrent changing IDE
│   │   │       ├── Fulfill ./../../../..[3]
│   │   │       ├── Must be reasonably effienct
│   │   │       └── Must be relatively easy to develop in
│   │   │           └── Key consideration must be actually getting the program done
│   │   └── Established protocol for Minigames
│   │       ├── Whatever it is we stick to it.
│   │       │   ├── Contained into current page?
│   │       │   ├── Contained in new Page?
│   │       │   └── Contained in additional Program?
│   │       ├── All activites must be recreated in javascript 
│   │       │   ├── Not burdened by legacy support - do not consider existing programs as requirements of implimentation.
│   │       │   └── Establish container structure and then get other developers to make the minigames.
│   │       └── Planning
│   │           └── Spend the next few workdays exploring potential schemas of melonJS parent, draft doccumentation, present to peter, and then find evelopers.
│   │               ├── Standard schema of Arguments
│   │               └── Standard schema of Returns
│   ├── Minigame Planning
│   │   ├── Future Meeting to discuss and brainstorm various minigames for each misconception
│   │   └── Brendan plans to impliment at least some of the mingames after the parent API is done.
│   └── When we plan to meet next
│       └── Set up a meeting time with Peter on a Monday or Friday once the parent API is done with a dummy mini game
│           └── Represents minimum delieverable
└── File Sharing System
    └── Google Drive
        ├── Shared Drives + Goole Drive Desktop allow for efficent file syncing
        ├── Brendan added to GoogleDrive/Shared/UMDLARS as viewer
        ├── Brendan added to GoogleDrive/Shared/UMDLARS/BrendanTemp as content mananger
        └── Peter will move files from personal acocunt to shared drive
            └── If datastructure is changed in such a way that it effects BrendanTemp, brendan will be notified
█8█8█8█8█8█8█8█8█8█8█8█8█8█8█8█8█8█8█8█8█8█8█8█8█8█8█8█8█8█8█8█8█8█8█8█8█8█8█8█8█8█8█8█8█8█8█8█8█8█8█8█8█8█8█
JS IDE Narrowing the Search
├── Meta
│   ├── Users
│   │   ├── Brendan Rood
│   │   │   ├── Writer
│   │   │   └── Presenter
│   │   └── Peter Peterson
│   │       └── Presentee
│   ├── Timestamp
│   │   ├── 5/26/23
│   │   └── 12:00pm
│   ├── University of Minnesota Duluth
│   │   ├── LARSLab
│   │   └── ACM Lounge
│   └── Internet
│       ├── MelonJS - https://melonjs.org/
│       ├── GDevelop - https://gdevelop.io/
│       └── PlayCanvas - https://playcanvas.com/
├── Purpose
│   ├── Of the JS IDEs I have discovered, these 3 are the ones I want to seriously consider
│   └── Each seems quite capable of fulfilling out needs, although all have strengths and weaknesses.
└── IDE Options
    ├── MelonJS - https://melonjs.org/
    │   ├── At a Glance
    │   │   ├── Website looks awful in exactly the way that gives it CS credibility.
    │   │   ├── Open Source.
    │   │   ├── Free under MIT License.
    │   │   │   └── Free to monitize, close source, etc.
    │   │   └── Emphasis on adding plugins to do exactly what is needed and nothing more.
    │   ├── Ease of Development
    │   │   ├── Open Soure
    │   │   ├── Allegedly easier to develop for than many JS IDEs.
    │   │   └── Provides some basic example projects.
    │   └── Parameters of Development
    │       ├── Product Parameters
    │       │   ├── HTML5
    │       │   ├── JS Version ES6
    │       │   ├── WEBGL2
    │       │   └── WebAudio
    │       └── Product Implimentation
    │           ├── Scene Hierarchy
    │           └── On-Demand only draw calls
    ├── GDevelop - https://gdevelop.io/
    │   ├── At a Glance
    │   │   ├── Open Source
    │   │   ├── MIT License
    │   │   │   └── Free to monitize, close source, etc.
    │   │   └── Block-style coding
    │   │       └── Line coding may be possible in standalone IDE program.
    │   │           └── Need to check this.
    │   └── Prameters of Development
    │       ├── Build Options
    │       │   ├── Web
    │       │   ├── Mobile
    │       │   ├── iOS
    │       │   ├── Android
    │       │   └── Standalone (.exe)
    │       ├── Ease of Implimentation
    │       │   ├── Comes with prexisting Authentication Systems
    │       │   │   └── Useful for saving user's progress
    │       │   └── Comes with many already completely worked-thorugh example projects.
    │       │       ├── Very useful to reverse Engineer.
    │       │       ├── https://gd.games/texugozap/super-chicken-td
    │       │       │   └── Proves viability of reseorce manangment and AI.
    │       │       └── https://gd.games/arthuro555/to-do-gd-jam
    │       │           └── Prove viability of dynamic behaviors.
    │       └── Barriers to development
    │           ├── Block-based coding can be quite clunky to start off with.
    │           └── Might not be capable of spinning off seperate "minigame" .exe(s).
    │               └── Minigames could be recreated as seperate scenes that are navigated between.
    │                   └── Would take additional work hours.
    └── PlayCanvas - https://playcanvas.com/
        ├── At a Glance
        │   ├── Extremely Similar to Unity
        │   │   ├── Scenes, Hierarchies, Prefabs, Materials, Shaders, etc.
        │   │   ├── Need to see if has smilar behavior schema as Unity scripts.
        │   │   └── Need to see how the 2D development system works.
        │   ├── Open Source
        │   ├── Not Free*
        │   │   └── See ./../../../[1]/[1]/[0]
        │   └── Shockingly powerful Collaboration tools
        ├── Source and Price
        │   ├── Open Source
        │   └── Can do anything under "Free" plan but all products are public domain
        │       └── As a university this isnt necessarily bad for us.
        └── Realtime Collaboration
            └── "Create apps faster using Google Docs-style realtime collaboration"
█7█7█7█7█7█7█7█7█7█7█7█7█7█7█7█7█7█7█7█7█7█7█7█7█7█7█7█7█7█7█7█7█7█7█7█7█7█7█7█7█7█7█7█7█7█
Play Canvas Exploration
├── Meta
│   ├── Users
│   │   └── Brendan Rood  
│   ├── Timestamp
│   │   ├── 5/26/23
│   │   └── 11:45am
│   ├── University of Minnesota Duluth
│   │   ├── LARSLab
│   │   └── ACM Lounge
│   └── Internet
│       ├── https://playcanvas.com/
│       └── https://playcanvas.com/features
├── Insights going in
│   ├── 2D and 3D
│   ├── NOT OPEN SOURCE
│   ├── NOT FREE
│   │   └── "Free" plan allows for full creation but all intelectual property is pulic domain
│   │       └── This is not necessiarily a bad thing for us.
│   └── Some Syncronus Collaboration elements?
│       └── IMPORTANT: ./.. is very important if it proves true.
│           └── Does prove true. See ./../../../../[2]/[2]/[1]/[0]/[0]
├── Exploration
│   ├── Open Source!
│   │   └── Is actually open source, website that directed me here was incorrect.
│   ├── First Impressions
│   │   ├── It's unity. It literally looks like Unity.
│   │   │   ├── OOC
│   │   │   ├── Shaders/Mats
│   │   │   ├── Transforms
│   │   │   ├── ? - Scripts
│   │   │   └── ? -  2D development
│   │   │       └── 2D development process not shown.
│   │   └── PlayCanvas is willing to host our games for us?!
│   └── "Built for teams"
│       ├── "PlayCanvas has many team features such as chatting with your teammates directly from the Editor and built-in version control."
│       └── https://playcanvas.com/features
│           ├── IMPORTANT: "Realtime Collaboration"
│           │   └── !!! "Create apps faster using Google Docs-style realtime collaboration" !!!
│           ├── On-device dev and test
│           │   └── Similar to android studio microbuilding
│           ├── Debugger Features
│           │   └── Uses browser-based debugging tools
│           └── PlayCanvas Engine
│               └── Totes and demonstrates an advanced WebGL Engine.
└── Conclusion
    └── Add to IDE short list.
█6█6█6█6█6█6█6█6█6█6█6█6█6█6█6█6█6█6█6█6█6█6█6█6█6█6█6█6█6█6█6█6█6█6█6█6█6█6█6█6█6█6█6█6█
GDevelop Editor First Impressions
├── Meta
│   ├── Brendan Rood
│   ├── 5/26/23, 11:10am
│   ├── LARSLab / ACM Lounge, UMD
│   └── Internet, https://editor.gdevelop.io/
├── Purpose
│   ├── To push that bright blue "try online" button in the browser and see what its like
│   ├── To explore some of the platform's features and limitations
│   └── NOTE: It is apparant that the browser-based demo editor is significantly weaker than the IDE program
├── Exploration
│   ├── Editor
│   │   ├── Although the IDE may be free, all asset bundles cost a few dollars per
│   │   │   └── This is not a bad thing as we will be producing our own assets
│   │   ├── Event system, while intuitive, is somewhat limited in what events it can trigger on
│   │   ├── Some Object-Oriented features present like prefabs, object variables, and object functions/behaviors
│   │   │   ├── These behaviours are limited, but you can create new ones or search for aux ones made by others.
│   │   │   └── Lack of apparant "traditional-coding" interface makes this confusing.
│   │   │       └── May be present in IDE program rather than web demo
│   │   ├── Very much allows for RAPID development if I could figure out how to do = instead of ==
│   │   └── Has some excellent fully-worked-through example projects to reverse engineer
│   │       └── Seriously look into this futher if we go with this
│   └── Examples
│       ├── https://gd.games/texugozap/super-chicken-td
│       │   ├── Example of divergent behavior from prefabs
│       │   ├── Example of simple yet sufficent AI
│       │   └── Example of resource system and building mannagment
│       └── https://gd.games/arthuro555/to-do-gd-jam
│           └── IMPORTANT: Example of behaviors that not only change but are fully dynamic
│               ├── I can add a new rule of "when i press g toggle all platforms"
│               └── This would not be easy to do even with traditional code, rep++
│                   └── Statement about versatility, even if roundabout to get there.
└── Further Research
    ├── Does the standalone IDE program resolve some of my problems?
    │   └── Problems essentially boild down to: I want the option of a traditional coding experience.
    ├── Would GDevelop's authentication system work with whatever server we end up hosting this on?
    └── Does such a simple program even have the ability to spin up aux .exe?
        ├── IMPORTANT: ./..
        └── This is relevant because of our philosphy for others to design the minigames under a standard schema.
█5█5█5█5█5█5█5█5█5█5█5█5█5█5█5█5█5█5█5█5█5█5█5█5█5█5█5█5█5█5█5█5█5█5█5█5█5█5█5█5█5█5█5█5█5█
GDevelop Exploration
├── Meta
│   ├── Brendan Rood
│   ├── 5/26/23
│   ├── 11:00am
│   └── Internet, https://gdevelop.io/
├── Insights going in
│   ├── Website appears to be similar to melonjs in that it is simple, efficent, and non-pandering
│   ├── OPEN SOURCE - Rep++
│   └── MIT LICENSE - Rep++
└── Exploration
    ├── IMPORATNT: Schema appears similar to "Scratch" in that coding is done in blocks rather than traditional "code".
    ├── Website has a "try it online" butotn front and center
    │   ├── https://editor.gdevelop.io/
    │   └── FORMATING: Will branch this into a new TreeEntry
    ├── Build Options
    │   ├── Web
    │   ├── Mobile
    │   ├── iOS
    │   ├── Andrioid
    │   └── Standalone (.exe) -> Distributiors like Steam
    ├── Focus on 2D "8-bit" graphics
    ├── Wiki for Further Reading
    │   └── https://wiki.gdevelop.io/
    └──	IMPORTANT: Comes with built-in Authentication Systems
        └── May be particularly useful for saving a users progress across sessions
█4█4█4█4█4█4█4█4█4█4█4█4█4█4█4█4█4█4█4█4█4█4█4█4█4█4█4█4█4█4█4█4█4█4█4█4█4█4█4█4█4█4█4█4█4█
Preliminary 2 Electric Boogaloo
├── Meta
│   ├── Brendan Rood
│   ├── 5/26/23, 10:30am
│   ├── LARSLab / ACM Lounge, UMD
│   └── Web Browser, https://www.makeuseof.com/game-development-top-javascript-engines/
├── Purpose
│   └── It is essential that I look at more than one website to get an idea of what's out there.
└── Suggestions
    ├── melonJS
    ├── Babylon.js
    │   ├── Referenced previously
    │   └── 3D focus makes non-viable
    ├── Phaser
    │   ├── Referenced previously
    │   ├── not free, not open source
    │   └── bad taste in my mouth
    ├── PixiJS
    │   ├── Referenced previously
    │   └── Website focus rather than Game Development
    ├── Kiwi
    │   ├── NEW entry
    │   ├── Open Source
    │   ├── HTML5
    │   ├── Renderers
    │   │   ├── WebGL (version not specified)
    │   │   ├── multi-touch
    │   │   └── 2D canvas
    │   ├── Larger focus on building to native .exe
    │   └── Larger focus on sending to iOS appstore via Cocoon.js
    │       └── Explore Cocoon.js further
    ├── Play Canvas
    │   ├── NEW entry
    │   ├── 2D and 3D
    │   ├── Built in editor similar to Unity
    │   ├── NOT FREE, NOT OPEN SOURCE
    │   │   ├── Features are free but while on the "Free Plan" anyon can look at your project.
    │   │   ├── All assets made under the "Free Plan" are public domain.
    │   │   ├── ./../[0] and ./../[1] are not *neccesiarily* a problem for us as a University.
    │   │   └── Not open souce; rep--
    │   └── Syncronus Collaboration
    │       └── Totes ease of collaboration
    │           ├── IMPORTANT: Look into this further.
    │           └── Can't we already do this via GitHub?
    ├── GDevelop
    │   ├── Seems similar to melonJS in that it is relatively basic but effective
    │   ├── OPEN SOURCE; rep++
    │   ├── "Intuition-based event system"
    │   │   └── Look into what this means
    │   ├── MIT license
    │   │   └── Allows for monitizaion, public domain vs not, etc. (Full Intellectual property control)
    │   └── High contender to go against melonJS.
    └── Impact.js
        ├── Not open source
        ├── "Advanced Industry Tools"
        ├── Review reads more like a sales pitch- in stark contrast to the other entires on the list.
        ├── Does tote the "Versatile Weltmeister Level Editor"
        └── Not super interesed in pursuing this one further.
█3█3█3█3█3█3█3█3█3█3█3█3█3█3█3█3█3█3█3█3█3█3█3█3█3█3█3█3█3█3█3█3█3█3█3█3█3█3█3█3█3█3█3█3█3█3█3█3█3█3█3█3█3█3█
PixiJS Exploration
├── Meta
│   ├── Brendan Rood
│   ├── 5/26/23, 10:20am
│   └── LARSLab / ACM Lounge, UMD
├── Insights going in
│   ├── Open Source
│   ├── 2D focus
│   └── Seems to be an in-between of melonJS and Phaser in terms of pandering
└── Exploration
    ├── Focus on 2D WebGL rendering only(?)
    ├── Toted Features
    │   ├── Fast
    │   │   └── One of the fastest JS rendering systems there is
    │   ├── Flexible
    │   │   ├── Focus on APIs
    │   │   ├── Most of the backend is handled by the program itself.
    │   │   └── More focus on designing.
    │   └── Free
    │       └── Open source
    └── Seems much more focused on WEBSITE design rather than Game Design.
        └── Specific features affirm this. Lots of features that would not be useful to us.
            └── Would also cause bloat.
█2█2█2█2█2█2█2█2█2█2█2█2█2█2█2█2█2█2█2█2█2█2█2█2█2█2█2█2█2█2█2█2█2█2█2█2█2█2█2█2█2█2█2█2█2█2█2█2█2█2█2█2█2█2█
melonJS Exploration
├── Meta
│   ├── Brendan Rood
│   ├── 5/26/23, 10:00am
│   └── LARSLab / ACM Lounge, UMD
├── Insights going in
│   ├── The self-declaration of being "particularly beginner friendly" is enticing.
│   └── Having a platform that relies on plugins allows avoiding uneccesary bloatware.
└── Exploration
    ├── Website is actually designed like crap in the way a CS-oriented product would be.
    │   └── This is in contrast to phaser which seemed very much more like a product.
    │       └── Is Phaser even free?
    │           └── NOT AT ALL, HUGE LIMITATIONS ON WHAT YOU CAN DO IN THE "Free" VERSION
    ├── Front page clarifies explicitly that it develops for HTML5 and is *OPEN SOURCE*
    ├── Toted Features
    │   ├── Fast
    │   │   ├── HTML5
    │   │   ├── ES6
    │   │   ├── WEBGL2
    │   │   └── WebAudio
    │   ├── Free
    │   │   ├── Released under permssive MIT Liscense.
    │   │   └── No cost, forever.
    │   └── Elegant
    │       ├── Scene graph is a hierarchy of containers.
    │       ├── Updates and drawing operations are dispatched seperately.
    │       └── Draws are opt-in; add compute-only renderable for AI, special effects, etc.
    └── Observations
        ├── Products appear SIGNIFICANTLY simpler than what was seen on Phaser
        │   ├── Products resemble games for the Nintendo GameBoy.
        │   └── This is not a bad thing considering what we are trying to do.
        ├── Features - https://melonjs.org/#features
        │   ├── Quite comprehensive, if simple.
        │   └── Sufficently compatible across platforms.
        └── Examples
            ├── Literally includes an interactive browser example
            │   ├── https://melonjs.github.io/examples/platformer/
            │   └── Phaser certainly didnt do this!
            └── https://melonjs.github.io/examples/
█1█1█1█1█1█1█1█1█1█1█1█1█1█1█1█1█1█1█1█1█1█1█1█1█1█1█1█1█1█1█1█1█1█1█1█1█1█1█1█1█1█1█1█1█1█1█1█1█1█1█1█1█1█1█
Phaser Exploration
├── Meta
│   ├── Brendan Rood
│   ├── 5/26/23, 10:00am
│   └── LARSLab / ACM Lounge, UMD
├── Insights going in
│   └── Phaser might be a good choice because we are primarilly developing for web
│       └── Focus on HTML5 will be essential for this
└── Exploration
    ├── Website is currently in a basic state due to being rebuilt
    │   └── Full website avalible at https://web.archive.org/web/20230331125854/http://phaser.io/
    ├── Renderers
    │   ├── WebGL
    │   └── Canvas
    ├── Compiling to
    │   ├── Web (native)
    │   ├── iOS
    │   ├── Andriod
    │   └── .exe (3rd-party tools needed)
    └── Seems like an effective tool at producting 2D flash-esk games
        └── This is perfect for the simple and abstract menu schema I am imagining
█0█0█0█0█0█0█0█0█0█0█0█0█0█0█0█0█0█0█0█0█0█0█0█0█0█0█0█0█0█0█0█0█0█0█0█0█0█0█0█0█0█0█0█0█0█0█0█0█0█0█0█0█
Preliminary Research
├── Meta
│   ├── Brendan Rood
│   ├── 5/26/23, 9:45am
│   ├── LARSLab / ACM Lounge
│   └── Internet Browser
└── https://www.codewizardshq.com/javascript-games/
    ├── Possible Engines
    │   ├── PixiJS
    │   │   └── 2D
    │   ├── BabylonJS
    │   │   └── 3D focus - not helpful
    │   ├── Phaser
    │   │   └── Desktop and Mobile HTML5 support
    │   ├── melonJS
    │   │   ├── Plugin focus
    │   │   └── More beginner friendly compared to other IDEs
    │   └── Three.js
    │       └── 3D focus - not helpful
    └── General guidelines
        ├── create a canvas inside of <style></style>
        ├── create startGame function annd define variables and getCanvas inside <script></script>
        ├── call startGame in <body></body> on load.
        └── for further instructions see ./../..