Classifying a game as a sandbox should license much deeper and more holistic expectations about it than the ability to traverse professions. Being a sandbox has something foundational to say about how the game's value creation is to be divided between developer and player. I don't necessarily have a
settled analysis of exactly what a sandbox is, so I'll probably tweak this in the future, but my current view is roughly...
1) There should be a salient, substantial aura of
semiotic democracy (in contrast to developer intent) forming and evolving the chasm between the game's code and physical systems and features, and the value derived from the game's user experience. The developer may still play an important role, but a far less direct one. The developer's roadmap should be very abstract and adaptable, focusing on seeding an ecosystem with appropriate high-level properties, not getting players to choose to do specific things. The community is the primary driver of user experience formation and change. In hindsight, the history of the game should be evidently best characterized by the innovation and creativity of players discovering new affordances and synergies, not the sequence of version updates.
2) Much of the community-driven force of #1 should emerge from choices and actions of individuals which, self-similarly to #1, constitute and evolve their personal user experiences. A version of Mindcraft with a mandatory, built-in "Twitch Plays" mechanic (such that there were always hundreds of players contributing button inputs), or a game with an experience-dominating voting component, should not qualify as a sandbox, because while its user experience broadly would be community-driven, an individual's user experience would be only weakly driven by her own choices and actions,
as if being directly governed by a developer.
3) There should be no imposed goal to the game. This distinguishes a sandbox from something like a trading card game or collectible miniatures game, which might satisfy #1 and #2 if the creative processes of combining game elements and other affordances in novel ways play a more important role in metagame evolution and individuals' propensities for achieving victory than developer-imposed structure, but still has its victory conditions imposed top-down. Similarly for offline console games which have a predefined way to win, but grow richer in the number and structure of user experiences afforded over time, as players discover and share new routing ideas, sequence breaks, physics glitches, etc. My view is that although I would not classify violators of #3 as sandboxes, #3 is the least important criteria in terms of game design inspiration crossover (I think these counterexamples and sandboxes can and should learn a lot from each other). Note that in the case of offline console games, communities are free to (and often do) deviate from the imposed goal anyhow, i.e., speedrunning, speedrun bingo, "beat the game without unlocking Character X" or "...unlocking Item Y" or "...pressing the Z button" challenges, etc. It might start to feel appropriate to call them sandboxes when this happens, although I'm torn over whether or not to include a #4 to stipulate that sandboxes arise only out of
intentional measures of developers to limit the impact of their own intent.
User experiences of games which satisfy #1 and #2 still span a wide spectrum, from the minimization of the developer role to crucial but indirect dependence on the developer. The absolute least the developer could do is hand the player a compiler and graphics engine labeled as a game and tell them to code whatever they want. In terms of
raw potential, this approach has more than about every other game combined, but its flaws are obvious, and the sandbox category is certainly not restricted to this "pure" type. In reality, the developer is (almost?) always responsible for, at the least, writing the code and some systems and features.
It may be tempting to think a satisfier of #1 and #2 should minimize the number of constraints players face, but that would usually entail letting players set every "good" numeric value to the maximum long integer value and calling it a day, and there wouldn't be much room for player creativity at all (also note that in, i.e., every two-player, zero-sum game, any constraint for you is an affordance for your opponent, namely the affordance, "get the game into such a state that you face that constraint," and vice-versa). Apparent constraints can also be credited as valuable, indirect developer contributions to user experience in light of their juxtaposition to the creative ways players work around or through them. Completing a self-imposed goal like "beat Portal without using the Portal gun" is not a beautiful and creative achievement of the player community because there is something
intrinsically beautiful or creative about beating a game without using a Portal gun, but rather because it stands in such stark
contrast to prior perceptions of the game's top-down imposition structure. Sandboxes might take inspiration from this by designing systems and features which players are likely to "break" (either in terms of discovering glitches, or just in terms of constructing creative synergies which push systems and features beyond developers' explicit preconceptions, as in the phrase "a broken strategy"). This of course requires building the game in such a way that unforeseen discoveries are unlikely to have a trivializing effect on the overall game, and for live service games, planning light-handed reactive measures in case things do go terribly wrong.
I like to analogize game design to the
Edge of Chaos concept; too
much structure in the form of missions, trade restrictions, "newcomer friendly" simplicity, causal separation of systems and features, anti-glitch policy, etc., and there is not enough of a chasm between code and user experience for player creativity to take a leading role in the latter's formation. Too
little structure, and there is not enough prior perception of constraint to juxtapose player creativity against, and everything feels trivial. Entropia has, over the past 10-15 years, wandered far in the direction of too much structure, as planet partners competing against each other for player attention have crowded us farther and farther out of our own sandbox, and blasted us with a non-stop array of prefabricated sandcastles unsuitable for an environment of player innovation and creativity. The fact that the pitch for (L) items involves their use as "carrots" for players to chase should set off alarm bells, even as an analogy, as it portrays a very animalistic view of the Entropian as a passive recipient of a "pleasurable user experience" implemented from the top-down, rather than acknowledging the Entropian's leading role in the ecosystem in terms of user experience formation and value creation. I agree that ownership is Entropia is not real in any of the natural, legal, or blockchain senses. It is a fictional representation of ownership as a component of the universe, but is an absolutely
foundational component within that fiction. The sandbox concept is related to UL items in the sense that UL items afford Entropians choices, in virtue of our fictional implementation of ownership, which resist certain avenues of developer interference into aspects of user experience formation which properly, as per the sandbox concept, belong to the Entropian.
