Andrew wrote:Only thing I see which needs mentioning is some kind of locking mechanism. Especially with binary files, the last thing needed is two people trying to edit a copy of the same document.
Pseudonym wrote:Andrew wrote:Only thing I see which needs mentioning is some kind of locking mechanism. Especially with binary files, the last thing needed is two people trying to edit a copy of the same document.
Let me repeat what is on the Insomniac blog:
The DB/server runs locally on the machine of everyone who is using a tool. It is the "model" in model/view/controller. That's all. It avoids the need for implementing load, save, undo, redo etc for any tool we write, because it just has to be written once. There is no need for locking because only one person will be using it.
Checking in an asset is a different story. For that, the DB/server or tool can publish to git or something, and the locking can be handled there.
mrout wrote:Just one thing: binary files should never, ever, ever, ever, ever touch git.
+ start the local server
+ open local editor(s) of choice
editor requests binary files and JSON metadata from server
+ make changes
editor keeps track of only what changed; delta-JSON sent to server
server updates changed files on disk
server saves undo/redo data in database
+ undo a change
request is sent to server
server replies with "reverse" delta for the relevant session
server updates its undo/redo stack (in the database?)
(background) the client/editor is polling the server for changes
server sends back updated documents (or delta)
(background or user controlled??) sync with remote/master files
Perforce or some other git tool performs the sync with a remote repo.
(background) the tracker notifies the server that files were changed on disk
the server updates the database
wrongu wrote: editor keeps track of only what changed; delta-JSON sent to server
wrongu wrote:Would this system require the dev team to build a custom editor for each "component" (for lack of a better word..)?
wrongu wrote:Why can't git touch binary files - is it a problem of large storage space or the fact that "diff" is meaningless for them?
wrongu wrote:Might there be a lag between making a change and receiving the updated document(s) from the server?
wrongu wrote:in what ways are the files on disk different from the DB documents (apart from literal data formats)? Are they meant to mirror each other at all times?
Pseudonym wrote:Did that help?
wrongu wrote:The last piece of the puzzle for my understanding is the way that the JSON control-documents are eventually incorporated into the game. The 3D location of a sound source, for example, is usually not going to be a static property like it would in a movie. It is instead probably bound to the state of some other object, like a laser.
Users browsing this forum: No registered users and 1 guest