Links - 8^th July 2018

This article describes how game developers successfully “pull off” game development, collaborating in the absence of consensus and working with recalcitrant and wilful technologies, shedding light on the games we play and those that make them, but also how we can be forced to work together by the platforms we choose to use. The concept of “boundary objects” is exported from Science and Technology Studies (STS) to highlight the vital coordinating role of game development software. Rather than a mutely obedient tool, game software such as Unity 3D is depicted by developers as exhibiting magical, even agential, properties. It becomes “voodoo software”. This software acts as a boundary object, aligning game developers at points of technical breakdown. Voodoo software is tidied away in later accounts of game development, emphasizing how ethnographies of software development provide an anchor from which to investigate cultural production and co-creative practice.

[…]

Tools such as the Unity Engine and their associated paratexts (help forums, tutorial videos and community sites) are boundary objects within individual teams, but they are bringing increasingly wider social worlds into contact with each other as shared protocols and practices are developed — and come into conflict. These tools are agents — our mentors, producers and community organizers — bringing together different communities of practice. They structure how we interact and collaborate with each other and shape what can be said and done, both in the workplace and in the game space. However, as these game technologies become increasingly user-friendly and multifunctional, more and more of their complexity and functionality is black-boxed and removed from user view. Accordingly, as the distance between the developer and the tools-developer is increased, we can expect an increasing influence of “"voodoo” software on the design of our games. This, in itself is not a bad thing. However, given the agential role of these software tools, the politics of platforms (Gillespie, 2010) becomes an increasingly salient focus of study, as the creators of these tools design-in prescribed and proscribed uses, influencing the forms of the games we can make and the types of political statements that can be made by them (Harvey, 2015). Ultimately, the tools we choose to use structure how we enter into the world of making play, how we meet and interact with other communities and social worlds, and how we come together to collaborate.

Before database transactions, there were complexities in updating data, especially if failures happened. This held true even though the systems were centralized and avoided the complexities presented by distribution. Database transactions dramatically simplified the life of application developers. It was great while it lasted…

State means different things. Session state captures stuff across requests but not across failures. Durable state remembers stuff across failures.

Increasingly, most scalable computing consists of microservices with stateless interfaces. Microservices need partitioning, failures, and rolling upgrades, and this implies that stateful sessions are problematic. Microservices may call other microservices to read data or get stuff done.

Transactions across stateless calls are usually not supported in microservice solutions. Microservices and their load-balanced service pools make server-side session state difficult, which, in turn, makes it hard to have transactions across calls and objects. Without transactions, coordinated changes across objects in durable state need to use the careful replacement technique in which updates are ordered, confirmed, and idempotent. This is challenging to program but is a natural consequence of microservices, which have emerged as the leading technique to support scalable applications.

Finally, different applications demand different behaviors from durable state. Do you want it right or do you want it right now? Human beings usually want an answer right now rather than right. Many application solutions based on object identity may be tolerant of stale versions. Immutable objects can provide the best of both worlds by being both right and right now.

Consider your application’s requirements carefully. If you aren’t careful, you will have problems with your state that you will definitely mind.