trystyncote / scripted-video

This is a project that attempts to produce an animation-looking video based on a given script.
MIT License
0 stars 0 forks source link

Restructure the formatting again. #20

Closed trystyncote closed 1 year ago

trystyncote commented 1 year ago

To pretense, I think that working about the formatting is wise, but I would need to rewrite the program again to compensate for it.

First of all, I think the way the formatting works out is not intuitive. To repeatedly call the CREATE and DELETE attributes would make sense if I was working with a database, such as SQL format. But in the video script, I may need to hide an object to eventually re-show it. That means that the best-use may be a series of CREATE tags, then a series of MOVE tags, and finally all the DELETE tags (which is redundant).

Instead, I think I'll be going forward with #17, and force a timeline of events. This comes with an immediate concern -- I still need a series of initialization for the traits of various objects. I think I want to take inspiration from how Web Development occurs (HTML/CSS/JS). In HTML, you define the structure, and in CSS you define the styles and aesthetic. Ignoring JavaScript's part to play for the time being (probably how I'm going to implement custom functions via #16).

I think I would like to split behaviour into multiple files -- one that defines the timeline as it corresponds to the video, and one that defines what the objects look like. Beginning with the timeline file (let's call it 'svTimeline' for the time being), I think the syntax should be simple. Maybe something like this:

>> BEGIN
// any sub-commands that occur at the start.
>> 10f
// jump straight to frame 10 and do something here.
>> +2f
// go forward 2 frames (this would bring us to frame 12 in this example).
>> END

I think the syntax for commands could still be SQL-type syntax. For example, HIDE <object> or SHOW <object> could be used for the aforementioned hiding and re-showing of objects. ALTER <object> could be for changing the state of an object.

The stylesheet would be next (let's call it 'svDesign'). And to be honest, I think it should be based directly on how CSS behaves. Though to be honest, I think I greatly prefer SCSS formatting with nesting, to make intent more clear and demonstrate relationship between objects. Either way, I'd get to create syntax that looks like this:

*object {
    attribute: value;
    // various attributes could go here.
}

There could also be a series of commands for movement (similar to CSS's 'keyframes' sequence), but for now I think that the ALTER tag in the svTimeline file would be good for proof-of-concept while I'm testing this.

Finally, there is another issue: How is the program going to know what file is the svTimeline file, and which is the svDesign file? How will it be able to find these files? Where is the metadata (current found via the HEAD command)? I think the solution to these questions is a masterscript ('svMasterscript', probably).

The masterscript will probably take a YAML formatting style, similar to this:

metadata:
    window-width: /*VALUE*/
    window-height: /*VALUE*/
    // ... etc
design: 
    // design script name/path
timeline:
    // timeline script name/path

This way, metadata doesn't need to be repeated between scripts, and I could add functionality to concatenate two svTimeline scripts together with the same styles/designs.

trystyncote commented 1 year ago

Closed in response to #26.