↑ LandmarkFilmProductionSystem
Page Created: 6/25/2014 Last Modified: 5/2/2018 Last Generated: 5/6/2024
I had not programmed anything since my LinearDepression days, but my film project made me push myself again.
After I finished my script, I began seriously thinking through the logistics of producing it. I had pre-optimized a lot of my script to make it easy for me to produce, but it was still epic in scale compared to my previous short films.
So I began tracking actors, props, wardrobe, and sets in a large spreadsheet, sorting by columns to visualize the information.
Then I started seeing the dreaded optimization problem again, but in this case my number of variables was immense. So I began breaking down my spreadsheet into two spreadsheets, making relationships. I tried using pivot tables, but I was still stuck in 2 dimensions. And to make things worse, as I worked on the production elements, I began to see problems with my script, so I kept going back and editing it, which then caused ripple effects in my spreadsheet.
You see, the problem when you pre-optimize something very large, is that any minor change causes ripple effects in the overall structure, so you have to edit the entire thing over and over to maintain the optimization. Otherwise, you have a multi-dimensional mess on your hands.
I learned that the hard way. In breaking the traditional Hollywood-style modularity, I had to suffer the consequences. But it was too late to go back. So I asked my brain to give me the power to solve this problem. And, probably borrowing my mirror neurons for systemizing tasks, it did.
I started to realize that what I really needed was wiki to see the connection in my film, and a database, to extract defined relationships with precision, and so began moving all of my information into Didiwiki and Open Office "Base". I spent many weeks doing this.
But it didn't feel right to use two separate systems. Any changes I made in one, I had to make in the other. I thought there has to be another way, and I asked the universe for knowledge, and it gave me Celtx.
Celtx blew my mind. It broke the rules of film production and fused the script and production elements into one. But at the time I was using it, it was new and full of bugs. It also "uploaded" my script for processing, something I didn't like. And when I went to fix it, my information was being corrupted in an XML database. It wasn't like Didiwiki, in nice flat files that I could edit.
At this point, I thought, what I really need is a flat-file wiki that can also act as a database, and then I found TWiki, and later Foswiki, a more open fork.
Foswiki is genius. It is simply the best wiki ever designed, but most people have never heard of it. It's not just a wiki, it is actually a "document-oriented database", but they strip everything to the core and strive for simplicity. It is a variant of a NoSQL database, and not a relational database in the normal sense.
So I ditched Celtx and wrote several Bash scripts to move all of my flat file data from my old spreadsheets and Didiwiki over to Twiki/Foswiki and began to create my first document-oriented database. My previous training and experience in Lotus Notes made this easy, but it took me months to build.
I then began to understand why Web 2.0 was so important. It was the ONLY way to visualize and manage this new entity I created, my film, a dynamic art form that you have to see into and then translate into the real world. There is simply no other tool that can do this.
That's when I began reading about the NoSQL movement and had an epiphany: Foswiki is using a perfect database model for human beings, it is a model of the Semantic Web that is forming world-wide.
A flat-file wiki is the most flexible of databases. You can add connections at lightning speed, but performing searches is "fuzzy".
A relational database is the opposite, adding connections means changing the schema, but performing searches is 100% accurate and very, very fast.
But a document-oriented database is somewhere in-between. You can make connections, but you don't have to worry about a schema. You offload the job of search to the CPU and disk. It is slower, but it can perform searches like a relational database.
The genius is that you can be inside the data, looking at it from different angles. And if you run into problems with data corruption, you can just reach out and fix them. There is no database structure to corrupt.
And the introduction of tags, hashtags, backlinks, transclusion, breadcrumbs, recursive search, and macros enhances this.
Tags quickly form folksonomies, another visualization tool, extremely valuable when you are trying to understand your own film or any art form arising from your own mind.
So I built a system which incorporated all of these elements, and then edited my script to further optimize it and the film production. And it didn't stop there--I then built an entire cloud-style system using it, which my production team would all use to simultaneously manage the film production.
Take that Hollywood! This is the new medium.
I later used what I learned from LFPS to create my OswaldCluster which is running this web site, but I continue to use Foswiki for my film production, as it is a real-time wiki that allows multiple people to use it.
I later applied my knowledge to create the OscarPartySystem for one of my friends.
Comments