The cost of proprietary tools

Is a digital creative work, made through the use of proprietary software tools, actually still owned by its creator? When so much of the technology and tool stack is not controlled by creators, is the creative work truly an expression of the creators mind?

If a proprietary software company goes out of business and the editing software goes away with it, there is no way to either finish the work or make adjustments to it.

One might keep the assets, but the code and the software specific configuration are mostly useless. Even more severe, all the knowledge acquired that’s bound to the domain of the editing software is suddenly worth nothing. Communities around that product disperse, friendships found online might fade away.

Not owning the means of production

Not owning the tools and resources required for the creative work puts every creator under the blessing of the tool maker. If the tool maker decides to make changes to the tool that breaks a workflow, the creator has no say in it, if this change does not affect a large amount of other users as well and a critical mass speaks up. Trying to create a living or building a business on top of proprietary software makes this situation even more stressful.

Not being able to control what actually goes into the product

When the editing software is closed source, the creator has no knowledge of what actually happens inside the binary export. A game engine in its free version by default might gather statistics about the platform its exported binaries are running on, even the software tool itself on the creators own device. It’s not unlikely for future iterations of those “free” engines to increase the amount of data collection to get an advantage over one another and even add DRM measures in lockstep with the hardware platforms, who are trying to close off their ecosystems.

It can be argued that any tool carries a bias towards how it’s used and leaves a sort of “silent imprint” on the work created. If the tool is proprietary, that imprint can’t be changed.

There isn’t a way to freely share the sources of the work with another person, as there is always a part which the creator doesn’t own themselves

If work based on proprietary tools is shared, the other person is forced to use that tool themselves. If proprietary libraries and add-ons are used in the process, the other person would have to purchase those as well, thus perpetuating the vendor lock-in. Same goes for knowledge shared about the tool.

Artisanship

The higher the tools level of sophistication, the less understanding of the process and inner workings of the creative work stays with the creator. Important knowledge about a craft might even cease to exist among creators, making them completely dependent on the proprietary tools. Some knowledge might even be lost forever.

This leaves the creative in a position like a mere factory worker having just a very slight touch on the actual work, before the work heads off to the market (commercial or not). The proprietary tools are costly, some even take a percentage cut, and the usual places to sell creative work are now owned by platforms taking another cut, and some payment providers are taking yet another one on payout. In the hit-driven video game market, this makes building a sustainable income even harder.

In the larger picture, the platforms can be considered an extension of the tools and often come with their own means to provide a streamlined experience from creation to monetization, that is even incentivized through deals where users of an engine might be getting a special discount on their share cut when selling through the same vendors platform.

Coming back to the image of the factory worker, it leaves them in a very dependent state from start to finish:

• having no knowledge about either the inner workings of the tools they use or a big chunk of the underlying process of their craft
• an invisible hand guiding their work in the way the tool maker sees fit, exerting control over what actually can and can’t be made
• promoting vendor lock-in when sharing their work or knowledge
• the platforms externalising all risk for a failed product

Conclusion

The current state of video game creation might seem uniquely compelling, but it’s in fact very restricting and clamped down looking through a commercial lense. It ties into the consolidation that is happening with the big internet platforms, which crush or buy competitors to grow into a handful of megacorporations. The fight is in full swing right now, the first victim being the independent creative.

Current efforts on decentralization, like the crypto and blockchain technologies might truly democratize the creative digital process, as they’re heavily biased towards cutting out middlemen and empowering the individual. But these technologies still have to prove themselves.

Using Unitys Asyncoperation Completed With Anonymous Callback Function

Say you want to load a scene asynchronously and need to trigger an event right after the scene has loaded, a quick two-liner does the job.

AsyncOperation asyncLoad = SceneManager.LoadSceneAsync(this.DefaultLevel, LoadSceneMode.Additive);
asyncLoad.completed += operation => MessageDispatcher.SendMessage("MENU_START");

Pushing Cinemachine Camera to Do a Hard Position Change With Ontargetobjectwarped

While switching my camera system on Super Space Arcade from a classic camera rig to Cinemachine, I stumbled over an issue where the virtual camera would change its position smoothly, even though I set the transform to a new value. In my case, I need a hard reset of the camera position for the linear track being reset, to not run into overflow errors.

The way this can be achieved with Cinemachine I dug up somewhere in the forums, is

CinemachineComponentBase.OnTargetObjectWarped(Transform, Vector3)

The first parameter is the moving objects transform, the second is the transform offset. In my case, the code looks something like this

CinemachineVirtualCamera vcam = this.GetComponent<CinemachineVirtualCamera>();
vcam.OnTargetObjectWarped(playerTransform, new Vector3(0,0,-trackResetZ);

Xbox 360 Controller Driver for Macosx Including Mojave

After setting up Mojave on my MacBook I realized I’ve had to install the XBox 360 Controller driver again. Somehow that was really hard to find among many outdated sources, so I’m putting this here for anyone searching for it and myself for future reference.

The driver is available at Github here.