During the conference, an attendee can ask to have a comment recorded in the devlog. Just say "comment box", and mfiano will log it here. If it is something that should be discussed and addressed in the future, mention for it to be added to the Backlog instead.
These items will carry over to the next meeting's log, unless discussed and expunged or deferred as appropriate. Items marked as resolved this meeting will not be carried over.
[IN-PROGRESS] #2 Lift utilities (mfiano)
[IN-PROGRESS] #3 Write a "Getting Started" guide for the manual (psilord)
[IN-PROGRESS] #4 Construct GitHub Pages website and repo for automatic docs building/deployment (mfiano)
[IN-PROGRESS] #5 Create a new project skeleton generator (psilord)
[DEFERRED] #1 Game time shift (mfiano)
[DEFERRED] #6 Go over some comments from a new user (psvennson)
Schedule the date and time of the next meeting.
[NEW] items at the top of the list in the Backlog section, either marking them as
[DEFERRED] if we will not work on them, or marking them as
[IN-PROGRESS] if we will be working on them this stream or independently offline before the next meeting.
Review and respond to any issues or PRs on GitHub for the Virality repository.
Finish transfusing origin and some other in-flux dependency libraries into Virality.
Begin new work
Work on a
[NEW] item in the backlog.
Determine if any
[DEFERRED] item should be addressed for the remainder of this meeting.
Scheduled next meeting for 2022-12-10 @ 5:00pm CST / 6:00pm EST
Talked about the game time shift idea, and determined it is likely a non-issue, but at least a reproducible test scene demonstrating if and how much it will be an issue, should be investigated. Additionally we spoke about adding additional time stream concepts to the engine, and other reworkings of the clock and main loop codes. These were briefly recorded in #1 Game time shift (mfiano).
Responded to 3 open GitHub issues.
Determined that small work that makes a big difference is the best plan of attack, re-entering the codebase. For the foreseeable future, this effort will be focused into refactoring the code, and working on documentation. Thanks to psvennson for the write-up of what it's like as a first-time Lisp programmer and game developer trying to use Virality. We agree with his response, as expected, with Virality still being in an experimental stage of development. We don't have much in the way of documentation because most things are constantly changing. What we can do is document the modules which are set in stone, like
vorigin, as well as publish a "Getting Started" guide to get up and running, and understanding the basics quickly.
psilord mentioned that he finished the transfusion of
vorigin during our off time. This means that we now have our own stable
vorigin that we can add new utility functions to, making the main logic less cluttered and easier to reason about, and allows us to write unit tests for independent utility functions for assurance.
We worked on #2 Lift utilities (mfiano) for the remainder of the meeting, and made a good start at moving some utility functions.