diff --git a/content/en/build/games/index.mdx b/content/en/build/games/index.mdx
index 8c770c984a..829db10fee 100644
--- a/content/en/build/games/index.mdx
+++ b/content/en/build/games/index.mdx
@@ -48,3 +48,51 @@ However, [James P. Carse's notion of finite and infinite games](https://www.yout
Infinite games are to finite games as a [container to the contained](/learn/module-7/), or a background to the stage, or a field to the players moving on it. They are played for the sheer pleasure of acting. Being able to **express life's joy, and have it be heard as such**, is the deep why we will explore in the course of our time together.
> To exercise one’s capacities to their fullest extent is to take pleasure in one’s own existence, and with sociable creatures, such pleasures are proportionally magnified when performed in company. From the Russian perspective, this does not need to be explained. It is simply what life is. We don’t have to explain why creatures desire to be alive. **Life is an end in itself**. And if what being alive actually consists of is having powers — to run, jump, fight, fly through the air — then surely the exercise of such powers as an end in itself does not have to be explained either. It’s just an extension of the same principle.
+
+## Practice
+
+If you'd like to consider these idea from a practical game designer's perspective, in the specific context of blockchains, we suggest Kernel fellow Ronan Sanford's essays, linked below. In particular, he makes the case for infinite games as **interoperable**, **permission-less**, **persistent**, and **immutable**.
+
+> A game or world isn't confined solely to its code or smart contract; it comprises the code (i.e. the digital physics), the players, and their inputs, as well as the interactions among players themselves, the community. It's this very aspect that allows us to understand how such a world can be expanded with new, previously unimagined rules.
+
+
+
+
+
+**Infinite Games**
+
+
+
+
+
+
+
+
+
+
+
+**Natural Composability**
+
+
+
+
+
+
+
+
+
+
+
+We also recommend that, if you are developing blockchain games actively, you take a look at
+
+
+
+[autonomous worlds network](https://aw.network/posts/lively-worlds) for visionary ideas and content, and
+
+[mud.dev](https://mud.dev) as either a starting point, or inspiration for your own framework and approach.
+
+
diff --git a/content/en/build/games/infinite.mdx b/content/en/build/games/infinite.mdx
index 7de3a49e2f..ff78a758a3 100644
--- a/content/en/build/games/infinite.mdx
+++ b/content/en/build/games/infinite.mdx
@@ -9,28 +9,6 @@ featuredImage: images/shares/learn.png
-This piece looks at infinite games in very broad way. If you'd like to consider the idea from a true game designer's perspective, in the specific context of blockchains, we suggest Kernel fellow Ronan Sanford's essay, linked below. In particular, he makes the case for infinite games as **interoperable**, **permission-less**, **persistent**, and **immutable**. Of these properties, immutability may seem at odds with the work of Dr. James P. Carse, which we cover in detail here, until you realise that an inherent property of the medium is "forkability".
-
-This is likely the most interesting meta-point of Ronan's analysis: you need not include complicated governance mechanisms to have a game which is both immutable and yet which can be updated when necessary, given that it exists on a shared ledger where it can be copied and redeployed (which applies not only to the contractual logic, but the state itself).
-
-
-
-
-
-**Infinite Games**
-
-
-
-
-
-
-
-
-
-
-
# And Beyond
Dr. Carse wrote [**Finite and Infinite Games: A Vision of Life as Play and Possibility**](ttps://books.google.com.ph/books/about/Finite_and_Infinite_Games.html?id=ObLBJ_w2ZlcC&printsec=frontcover&source=kp_read_button&redir_esc=y#v=onepage&q&f=false) in 1986, years before blockchains and the internet. This is a feature common to much of the work you will find in Kernel: it is both timely and timeless. It addresses the pertinent issues of the day, but it does so with such insight and wit that the conclusions which can be drawn from it apply across our shared histories.
diff --git a/package.json b/package.json
index b84ab9b00a..35dde91d30 100644
--- a/package.json
+++ b/package.json
@@ -39,7 +39,7 @@
"gatsby-remark-embed-video": "^3.2.1",
"gatsby-remark-images": "^5.12.0",
"gatsby-remark-responsive-iframe": "^4.11.0",
- "gatsby-source-filesystem": "^3.14.0",
+ "gatsby-source-filesystem": "^3.15.0",
"gatsby-transformer-json": "^3.14.0",
"gatsby-transformer-remark": "^4.11.0",
"gatsby-transformer-sharp": "^3.15.0",
diff --git a/static/images/build/natural-composability.png b/static/images/build/natural-composability.png
new file mode 100644
index 0000000000..d7dd6cd9c4
Binary files /dev/null and b/static/images/build/natural-composability.png differ
diff --git a/yarn.lock b/yarn.lock
index 1a3afcc046..e6b17b4978 100644
--- a/yarn.lock
+++ b/yarn.lock
@@ -7943,17 +7943,17 @@ gatsby-remark-responsive-iframe@^4.11.0:
lodash "^4.17.21"
unist-util-visit "^2.0.3"
-gatsby-source-filesystem@^3.14.0:
- version "3.14.0"
- resolved "https://registry.yarnpkg.com/gatsby-source-filesystem/-/gatsby-source-filesystem-3.14.0.tgz#ae2b930091a932b33270cb9cc2d9caaf0abc1742"
- integrity sha512-Gg5GGxiWXhjapWMYdXOGk7zp+ajYowS+xNmaDUkL1gH+IQLvE18XbvKh00B/HiFaHm4azJfS2QRrRI/mPTZX+w==
+gatsby-source-filesystem@^3.15.0:
+ version "3.15.0"
+ resolved "https://registry.yarnpkg.com/gatsby-source-filesystem/-/gatsby-source-filesystem-3.15.0.tgz#2ecee63279d267e9cc324ad1cb5facf033a1cdd8"
+ integrity sha512-Th8AOeOryWrwgsApQkn7KnhGs6DFUQ/RXgOI+1gnBUGm5ym3Am8Zg8djgwiaiFUoB9dyVTgHF58rmJF47RgHZQ==
dependencies:
"@babel/runtime" "^7.15.4"
chokidar "^3.5.2"
fastq "^1.11.1"
file-type "^16.5.3"
fs-extra "^10.0.0"
- gatsby-core-utils "^2.14.0"
+ gatsby-core-utils "^2.15.0"
got "^9.6.0"
md5-file "^5.0.0"
mime "^2.5.2"