# Squad Games
Jesse B. Miller, Ezra Weller

- Paper on just Squad protocol and DAO, with a side focus on practical application
- examples:
- video platform (simple platform w components)
- games (more complex fractal)
- operating systems (fully generalized, from operating down to however detailed)

- Paper on just SDK for Mods, with a note on the protocol (more informational, less evangelical)

#### Table of Contents
[Vision](#Vision)
[Squad Protocol](#Squad-Protocol)
[Squad Games SDK](#Squad-Games-SDK)
[Squad DAO](#Squad-DAO)
[Extrapolation](#Extrapolation)
[Appendices](#Appendices)

## Vision
This paper describes:
1. the Squad protocol, a protocol for attaching licenses and markets to user-contributed content;
1. the Squad Games SDK, a proposed SDK enabling Squad to serve the usecase of videogame mods; and
1. the Squad DAO, a decentralized, community-owned organization that runs an instance of Squad.

To ground the narrative in practical application, we look through the lens of videogame mods.

### The Missed Opportunity of Mods
In the language of videogames, "mod" refers to a modification created by fans: a new level, a new character, or even an entirely new game made by rearranging the original's pieces.

Many of today's most popular video games started as mods created by community members, including:

- Battle royale games like Fortnite
- MOBA games like League of Legends and Dota 2
- Counterstrike-style games like CSGO and CrossFire
- Team Fortress-style games like Overwatch
- Autobattlers like Teamfight Tactics
- Tower defense games like Flash Element TD

Modding and mod-makers, however, remain marginalized in the games industry:
- Games offer at best minimal support for mods and aren't built with mods in mind, making modders lives more difficult than necessary.
- Modders typically draw no income from the mods they build, giving up all ownership of their work to the parent game's company. When mods do take off as in the above examples, game companies build stand-alone versions that capture most of the value.
- Games with large modding communities lack effective curation for their mods. It's difficult for players to find the mods they like best.

What would the videogame industry look like if the creativity engine of modding was properly supported?

If modders owned their contributions and earned from their success, more people would mod and existing modders would create more. If players could also readily discover the best mods, game communities might become powerful economic engines---multi-sided marketplaces with strong network effects. Such a system might bring to videogames the kind of innovation Youtube enables for video content.

Squad Games is for mod-driven game developers, the modders who build for them, and the players that attracts. Squad Games helps players find games and mods they love. It helps modders to be found and to own and sell their work. It enables game developers to foster healthy modding and player community that multiplies the value of their game.

### Towards Better Modding
To fulfill the promise of videogame mods, we propose thata a system must include three feature areas:

1. **Open modding**: anyone can contribute mods that they retain ownership of.
1. **Compensating mod-makers**: mod-makers can own and draw income from their work, especially when the game they are modding is revenue-generating.
1. **Mod discoverability**: game players can effectively discover and use the mods they will enjoy most.

## Squad Protocol
Such a system can be built using Squad, a new protocol for attaching licenses and markets to user-contributed content.

### Contributions
Data is submitted to the Squad protocol in the form of "contributions," which have three parts:

#### Content
This field contains the main content, or a reference to the main content, of the contribution---in Squad Games, this will often be a mod.
#### License
The license is a set of rules (code or human language) that dictate the legal usage of the content.
#### Market Configuration
The market configuration shapes the automatic market maker that will be attached to the contribution (see below). In our current implementation, the market configuration must include the Ethereum address of a curve contract:

contract Curve {
  function buyPrice(supply, units)
  function sellPrice(supply, units)
}

This curve contract can implement any logic in the `buyPrice` and `sellPrice` functions.

The market configuration may also include revenue sharing information.

### Submitting and Storing Contributions
A `submitContribution()` function stores a new contribution and creates a linked automatic market maker using its market configuration.

### Automatic Market Makers (AMMs)
Automatic market makers are markets that replace human-submitted order books with algorithms, often ensuring that the market is always liquid for both buyers and sellers.

Squad provides an AMM factory contract on Ethereum called Autobond. When contributions are submitted, Autobond checks that the configuration is valid and launches a [bonding curve](https://medium.com/linum-labs/intro-to-bonding-curves-and-shapes-bf326bc4e11a) AMM that uses the contribution's `Curve` contract to allow buying and selling of a new token. This AMM can be used in conjunction with the contribution's license to allow applications to use the contribution's content compliantly.

- **we probably want a primer of some kind of bonding curves here**

#### Drawing Profit from Bonding Curves
Because Autobond allows custom buy and sell curves, there are many ways creators can profit from their AMMs in Squad. We focus on one here: rights to first purchase.

- Maybe also include dividends from different buy and sell curves

Bonding curves with positive buy and sell slopes have the property that tokens bought at supply X can usually be sold for a profit at supplies greater than X. With this in mind, Squad gives the submitter of a new contribution the right to buy any number of tokens during the submission, before anyone else has a chance to do so. The creator can sell their tokens back to the curve at a profit if anyone else buys tokens, with the amount of profit depending on the equations of the curves and the supply.

## Squad Games SDK
The Squad Games SDK will build on the Squad protocol to serve the use-case of videogame mods.

### Open Modding via Metadata-driven Games
Squad allows submitting new contributions, so it's simple for an SDK to help game applications offer this functionality to users. To take full advantage of this and make mod-creation accessible to the largest set of users, we propose that game-makers build _metadata-driven_ games.

In a metadata-driven application, key pieces of the infrastructure are defined by metadata types, rather than being hardcoded. Anything that matches the metadata type can be swapped into the application seamlessly, and creating new infrastructure can be as simple as filling out a form. Build such a form for your game application and connect it to the SDK, and you have an excellent user experience for mod-creation.

[Squad Chess](https://github.com/SetMatchGames/squad/tree/develop/packages/app-spec-squad-chess) is a demonstration of this idea. It's a chess application that defines metadata patterns for pieces and formats (lists of pieces with boards and starting positions) and includes forms for creating both.

### Compensating Mod-makers via Licenses and AMMs
Because the SDK uses the Squad protocol, new contributions include not only their content, but also a license and configuration for an automatic market maker (AMM).

The SDK will implement some boilerplate licenses and AMM curves that games can offer to mod-creators. To start, these will include licenses and curves that:
- Require users to buy $X worth of a mod's token in order to play with it in a game
- Automatically share the mod's revenue with mods it references, or correspondingly, require mods that reference it to share revenue with it (see below)

To begin with, mod-creators will be able to profit by exercising their rights to first purchase.

#### Mod Revenue Sharing
It is possible for the content of contributions in Squad to reference other contributions. In these cases, licenses and automatic market makers can be used to share revenue between contributions that reference in each other.

For example, a card game application using the SDK might define a "format"-type mod whose content is a list of "card"-type mods. Format licenses might indicate that
1. players must buy the format for $10 in order to play games using it, and
1. 50% of that money should be split evenly between the cards in the format.

The second point can be implemented directly into the AMM by submitting a mapping of `addresses -> revenue-share percentages` when creating the format's bonding curve. Any funds sent to buy tokens from the format's curve can then automatically be split with the curves that the format uses.

#### Ensuring Compliance with Licenses
Complying with licenses in the Squad protocol is not a completely trustless process. There are a few reasons for this, chief among them that contribution data is intended to be public. Applications must be trusted to enforce licenses on their end.

To facilitate this, the SDK will include functions to check license compliance for a specific set of licenses, which can be expanded over time. A list of license options is available in the [Appendices](#Appendices).

A network effect around mod-creation also supports license compliance: mod-creators will prefer contributing work to applications that enforce licenses, and game players will generally prefer to play games with more modding activity.

As a last line of defense, licenses may also interface with existing legal systems, allowing mod-creators to bring legal action against offending applications.

### Mod Discoverability via Market Curation
Data generated by AMMs---people purchasing mods---can be used to curate contributions effectively.

Most curation on the internet today is popularity-based. The number of upvotes, likes, shares, and purchases a piece of content receives largely determines how often platforms show it to users. AMM data makes most such curation methods possible in the Squad, and the Squad Games SDK will include a number of them.

To begin with, the SDK will provide basic curation methods like ordering contributions by the total value locked in their bonding curves ("TVL" in decentralized finance) and by the acceleration of their TVL.

Later on, methods that include user behavior, such as ordering based on a user's own purchase history or the similarity of their history with others, may be added. Many of the same techniques employed by mainstream recommendation systems such as Amazon's can be applied here.

#### Other Curation Methods
It's worth noting a few other powerful types of curation that can be built on top of Squad.

First, items can be ordered by age using the datetime they were first submitted, and this information can complement other data in more complex methods. Second, Pagerank-style curation is available when contributions reference other contributions in standard ways.

### Example User Story
An example of how we imagine this system being useful:

1. Developers make a mod-driven videogame
3. They release to an early adopter community and offer ownership and revenue sharing to both players and modders
4. The community builds more content for the game than the developers could have ever hoped to build. Most of it is average or not very good, but some of it is weird and cool and more innovative than the developers could have ever hoped to build (see battle royale, MOBAs, Autobattlers, Tower Defense, class based shooters, etc.).
5. The mod market built into the game uses market information to help users find and buy the mods they'll love.
6. The game developers offer modders and players ownership of the game in proportion to their contributions to the community giving them governance rights over the future of the game and their community.
7. The co-op that results goes on to create more value and stability for themselves than any game developer team could every hope to maintain on their own

## Squad DAO
We envision the Squad protocol, along with a Squad Games SDK and other potential development tools, being operated by a decentralized, autonomous organization: the Squad DAO.

We choose this approach for three reasons:
1. Growth: the opportunity for participants to earn ownership shares of the platform is a strong, unique incentive for participation. Legal decentralization also opens up new funding opportunities.
1. Sustainability: a well-designed stakeholder model and governance system ensures that the DAO will continue to make decisions aligned with the Squad ecosystem.
1. Ethics: common organizational models like corporations and non-profits are oft-criticized for treating their workers and/or customers unfairly. We intend to include both groups in governance here.

### Stakeholder Model
Good decentralized governance requires power to be distributed to people according to their stake in the system. Squad has a few major stakeholder groups:
1. Users, the people purchasing tokens from AMMs so they can use contributions
1. Contributors, the people creating and submitting contributions
1. Investors, the people who put their money behind a belief in Squad's growth
1. Workers, the people building the Squad protocol and related services

Though these groups have disparate types of stake, we attempt to reduce all their stakes to a single variable---voting power---in order to include them in the DAO.

User, contributor, and investor can all be reasonably modeled by funds locked into bonding curve AMMs: users buy in order to get utility, contributors buy in order to profit from their work, and investors buy in order to get a return later.

Worker stake can be modeled by the monetary value of the work they do: each time the DAO commissions a project, it may give voting power to the commissioned workers pro rata to their pay.

The stakeholder modeled is yet to be detailed fully.

### Governed Territory
Manage protocol + software
- Canonize official versions of software (protocol implementations, SDKs)
- Configuring that software
- Allow and support lists (verified/audited/supported licenses and curves)
- Params
- tax rate
Operate the network
- In-network dispute resolution (censoring misbehaving contributions from Autobond & curation)
Spend Revenue
- Ecosystem grants, dev funding, marketing, etc.

### The Path to Decentralization
PMF
1. building and capital-raising
1. centralized operations

Decentralization
1. decentralization tests
1. ownership distribution & decentralized operations

## Extrapolation
Other benefits we expect:
- better balance
- faster releases of new content for games
- Faster to market

Expanding beyond games

## Appendices
### Licenses
- EULA text that must be displayed to the user and that the user must click "accept"
- Fixed amount of the definition token that must be held by a user
- Fixed price spent on the definition token
- Greater than some percent of revenue shared by a collection with the collected definitions

---

- Revenue sharing built into the AMMs
- Definitions have an owner managed weighted list of other definitions (addresses?) to share revenue with
- Used for licensing and incentives
- The SDK provides tools for the games to implement enforcement of the licenses that contributors select. For example a contributor might select a license that requires users to purchase $10 worth of the definition.
- The software would use SDK functions to check that a user did make that purchase before loading the configuration into the game for them.
- There may be license agreements *between* definitions too.
- In the case where a definition is a collection of other definitions the software would use SDK functions to sensor, and refuse to submit, collections that do not meet the licensing requirements of the definitions it collects. For example a definition may require that a collection share more than 10% of its revenue, split evenly, with the definitions it collects.
-