3 articles tagged “game-development” — software, engineering, and related writing by idmontie.

Game Development blog posts - idmontie's Portfolio

"use strict";
const {Fragment: _Fragment, jsx: _jsx, jsxs: _jsxs} = arguments[0];
function _createMdxContent(props) {
  const _components = {
    mermaid: "mermaid",
    p: "p",
    ...props.components
  };
  return _jsxs(_Fragment, {
    children: [_jsx(_components.p, {
      children: "We are starting to see a rise of novel use-cases for AI in products and games using LLMs. Rather than the simple chatbot like experiences we have seen in the past using AI, we are starting to see feedback systems being added to these experiences, providing additional context to the LLM than just the past conversation."
    }), "\n", _jsx(_components.p, {
      children: "A typical game loop for this type of system would look like:"
    }), "\n", _jsx(_components.mermaid, {
      chart: "graph LR\n  Rules --> LLM\n  InputStates[\"Input States\"] --> LLM\n  LLM --> OutputState\n  OutputState[\"Output State\"] --> GameEngine\n  GameEngine[\"Game Engine\"] --> InputStates"
    }), "\n", _jsx(_components.p, {
      children: "Rules can be describes as written-word description, with an additional set of rules telling the LLM to reply using JSON output of a given schema. In this area, I have had success giving LLMs descriptions of output schemas in Typescript and asking for a JSON response that adheres to the type. Other methods of getting a consistent schema are more than likely possible here, as well as additional output methods."
    }), "\n", _jsx(_components.p, {
      children: "When the asynchronous task of creating and output state is complete, the Game Engine in this case can read, parse, and apply that new state to the world. Any additional interaction would then lead to the next set of input states that can be given to the LLM as a JSON blob."
    }), "\n", _jsx(_components.p, {
      children: "For a more concrete example, we can imagine a game where we want our player to interact with a set of agents. The input states would be the state of each agent, the user’s interaction, and maybe some global environment data. The rules may be how each agent should behave, the rules of the game, and additional context. The LLM would take these inputs, and the output is instructed to be the next state of each agent. When the LLM returns this data, the Game Engine read it and applies it to the game’s representation of each agent, showing the player the impact of their actions."
    }), "\n", _jsx(_components.p, {
      children: "I’m looking forward to more novel use-cases for LLMs!"
    })]
  });
}
function MDXContent(props = {}) {
  const {wrapper: MDXLayout} = props.components || ({});
  return MDXLayout ? _jsx(MDXLayout, {
    ...props,
    children: _jsx(_createMdxContent, {
      ...props
    })
  }) : _createMdxContent(props);
}
return {
  default: MDXContent
};


<p>We are starting to see a rise of novel use-cases for AI in products and games using LLMs. Rather than the simple chatbot like experiences we have seen in the past using AI, we are starting to see feedback systems being added to these experiences, providing additional context to the LLM than just the past conversation.</p>
<p>A typical game loop for this type of system would look like:</p>
<mermaid chart="graph LR
  Rules --&gt; LLM
  InputStates[&quot;Input States&quot;] --&gt; LLM
  LLM --&gt; OutputState
  OutputState[&quot;Output State&quot;] --&gt; GameEngine
  GameEngine[&quot;Game Engine&quot;] --&gt; InputStates"></mermaid>
<p>Rules can be describes as written-word description, with an additional set of rules telling the LLM to reply using JSON output of a given schema. In this area, I have had success giving LLMs descriptions of output schemas in Typescript and asking for a JSON response that adheres to the type. Other methods of getting a consistent schema are more than likely possible here, as well as additional output methods.</p>
<p>When the asynchronous task of creating and output state is complete, the Game Engine in this case can read, parse, and apply that new state to the world. Any additional interaction would then lead to the next set of input states that can be given to the LLM as a JSON blob.</p>
<p>For a more concrete example, we can imagine a game where we want our player to interact with a set of agents. The input states would be the state of each agent, the user’s interaction, and maybe some global environment data. The rules may be how each agent should behave, the rules of the game, and additional context. The LLM would take these inputs, and the output is instructed to be the next state of each agent. When the LLM returns this data, the Game Engine read it and applies it to the game’s representation of each agent, showing the player the impact of their actions.</p>
<p>I’m looking forward to more novel use-cases for LLMs!</p>


We are starting to see a rise of novel use-cases for AI in products and games using LLMs. Rather than the simple chatbot like experiences we have seen in the past using AI, we are starting to see feedback systems being added to these experiences, providing additional context to the LLM than just the past conversation.

A typical game loop for this type of system would look like:

```mermaid
graph LR
  Rules --> LLM
  InputStates["Input States"] --> LLM
  LLM --> OutputState
  OutputState["Output State"] --> GameEngine
  GameEngine["Game Engine"] --> InputStates
```

Rules can be describes as written-word description, with an additional set of rules telling the LLM to reply using JSON output of a given schema. In this area, I have had success giving LLMs descriptions of output schemas in Typescript and asking for a JSON response that adheres to the type. Other methods of getting a consistent schema are more than likely possible here, as well as additional output methods.

When the asynchronous task of creating and output state is complete, the Game Engine in this case can read, parse, and apply that new state to the world. Any additional interaction would then lead to the next set of input states that can be given to the LLM as a JSON blob.

For a more concrete example, we can imagine a game where we want our player to interact with a set of agents. The input states would be the state of each agent, the user’s interaction, and maybe some global environment data. The rules may be how each agent should behave, the rules of the game, and additional context. The LLM would take these inputs, and the output is instructed to be the next state of each agent. When the LLM returns this data, the Game Engine read it and applies it to the game’s representation of each agent, showing the player the impact of their actions.

I’m looking forward to more novel use-cases for LLMs!


AI Feedback Systems

"use strict";
const {Fragment: _Fragment, jsx: _jsx, jsxs: _jsxs} = arguments[0];
function _createMdxContent(props) {
  const _components = {
    a: "a",
    h2: "h2",
    p: "p",
    ...props.components
  };
  return _jsxs(_Fragment, {
    children: [_jsx(_components.p, {
      children: "One of the first PC games I played was Starcraft and the expansion Starcraft: Broodwar. We didn’t have a PC, so I had to play it on a friend’s computer, but I remember being immersed in the real-time strategy gameplay."
    }), "\n", _jsxs(_components.p, {
      children: ["Later, I would get a PC and bought my own copy of Starcraft. This was years later, but the community for the game was still impressive. Joining one of the older Starcraft forums, I discovered “mods” for the game. The most popular ones were just graphical changes, but that concept of changing a game to display your own graphics was so interesting to me. I’m not sure how I stumbled on it, but I found ", _jsx(_components.a, {
        href: "http://www.staredit.net/",
        children: "http://www.staredit.net/"
      }), " (yes, it’s still active!) and I learned that you could do so much more than just change the graphics of Starcraft with mods. There were people in the community working on hooking into existing Starcraft code to modify the gameplay and graphics using C++."]
    }), "\n", _jsx(_components.h2, {
      children: "Diving deep"
    }), "\n", _jsx(_components.p, {
      children: "In order to create these mods, we needed to know the hex address of different functions that Starcraft would call during them game. And to do anything meaningful, we also needed to know the structure of units and sprites and where those were stored as well. A lot of this base work required using tools like OllyDbg to analyze the assembly of the Starcraft executable, and ArtMoney for analyzing the memory of the game while it was executing."
    }), "\n", _jsx(_components.p, {
      children: "I used OllyDbg to find what functions Starcraft would call during execution – from common functions like the game-loop, to highly specialized functions like checking supply limits. ArtMoney let us determine how structures like units were laid out – where each unit’s health was stored, how much damage each weapon would do, and more."
    }), "\n", _jsxs(_components.p, {
      children: ["Most of this information was shared in forums, chat rooms, and a few disparate sites for looking up hex addresses. Of course, no write up about modding Starcraft is complete without mentioning all the work from ShadowFlare (check out ", _jsx(_components.a, {
        href: "https://sfsrealm.hopto.org/",
        children: "ShadowFlare’s realm"
      }), " for all the work they did), the great people at Staredit.Net, and plenty of others who built amazing tools to work with Starcraft files. All these sites were amazing resources for figuring out file specs and working with the Starcraft engine."]
    }), "\n", _jsx(_components.p, {
      children: "However, each time I wanted to write a new mod or experiment with an idea, I’d have to look up all of this information across all of these sites."
    }), "\n", _jsx(_components.h2, {
      children: "Bringing it together"
    }), "\n", _jsx(_components.p, {
      children: "The goal with GPTP (General Plugin Template Project), was to take all of this work that the amazing modding community had done and bring it together into a C++ Visual Studio project that could be copied for a new mod."
    }), "\n", _jsx(_components.p, {
      children: "My initial idea was simple: take all of the code for injecting new function hooks into Starcraft and wrap it in some very friendly functions. When a modder would come in to create a new project, they would have three functions exposed to them to work with: gameStart, gameLoop, gameEnd (I don’t remember the exact names I gave them at the time)."
    }), "\n", _jsx(_components.p, {
      children: "I released the initial GPTP back in 2008-2009. This included the project setup for compiling and producing a QDP file that could be loaded into Starcraft. Additionally, it contained known structures and hex addresses that developers could use to build their mod. The Intellisense autocomplete feature really helped developers leverage these structures."
    }), "\n", _jsx(_components.h2, {
      children: "The power of open source"
    }), "\n", _jsx(_components.p, {
      children: "I made the original version of GPTP back in high school, but I didn’t have time to continue to work on it when I went to university. I returned to the community a decade later, and found that not only was the community still alive and working on mods, but that they were using GPTP. At this point, GPTP was unrecognizable from my original work; the goal was the same, but the quality of the code was greatly improved and the number of hooks, known structures, and addresses was much more impressive."
    }), "\n", _jsxs(_components.p, {
      children: ["You can view the project on Github: ", _jsx(_components.a, {
        href: "https://github.com/SCMapsAndMods/general-plugin-template-project",
        children: "general-plugin-template-project"
      }), "."]
    }), "\n", _jsx(_components.p, {
      children: "I’d like to thank open source for this sort of development. The amount of work that has been continually added onto this project couldn’t have been done without all the contributions from the community."
    }), "\n", _jsx(_components.h2, {
      children: "Does it still work?"
    }), "\n", _jsx(_components.p, {
      children: "I recently went back to Starcraft modding as a fun little project. I wanted to hop in and see how easy or difficult it would be to create a mod in 2020."
    }), "\n", _jsx(_components.p, {
      children: "One of the harder things to do in 2020 is find all the tools and initial setup for modding Starcraft. Some of the modding sites are down for good, and with them the knowledge they contained."
    }), "\n", _jsx(_components.p, {
      children: "But, I pulled together the tools (thanks PyMS), pulled together tutorials and other instructions into a Notion document, and created my first Starcraft mod!"
    }), "\n", _jsx(_components.p, {
      children: "Gathering all the tools was the hard part. After that, it was actually very straightforward creating a new GPTP template and mod. All of the known structures and hooks are pretty self-explanatory and I was able to even add my own hooks once I found the hex addresses using OllyDbg."
    }), "\n", _jsx(_components.h2, {
      children: "Looking forward"
    }), "\n", _jsx(_components.p, {
      children: "Starcraft modding is like an ancient art at this point. There isn’t a large audience for it, so in general, any new mod will be played by maybe 10 people. But to me, it’s a combination of nostalgia, hard work, tinkering, discovery, and creation that makes it so much fun. That feeling of finding a new function to hook onto, writing C++ code that injects itself into it, and then running the code in the Starcraft engine and seeing it work is a special kind of rewarding experience."
    }), "\n", _jsx(_components.h2, {
      children: "Thanks"
    }), "\n", _jsxs(_components.p, {
      children: ["I’d like to give thanks to everyone who has ever contributed to the modding community for Starcraft. There are so many names that I couldn’t possibly name them all, but please check of ", _jsx(_components.a, {
        href: "http://staredit.net",
        children: "http://staredit.net"
      }), " if any of this interests you."]
    })]
  });
}
function MDXContent(props = {}) {
  const {wrapper: MDXLayout} = props.components || ({});
  return MDXLayout ? _jsx(MDXLayout, {
    ...props,
    children: _jsx(_createMdxContent, {
      ...props
    })
  }) : _createMdxContent(props);
}
return {
  default: MDXContent
};


<p>One of the first PC games I played was Starcraft and the expansion Starcraft: Broodwar. We didn’t have a PC, so I had to play it on a friend’s computer, but I remember being immersed in the real-time strategy gameplay.</p>
<p>Later, I would get a PC and bought my own copy of Starcraft. This was years later, but the community for the game was still impressive. Joining one of the older Starcraft forums, I discovered “mods” for the game. The most popular ones were just graphical changes, but that concept of changing a game to display your own graphics was so interesting to me. I’m not sure how I stumbled on it, but I found <a href="http://www.staredit.net/">http://www.staredit.net/</a> (yes, it’s still active!) and I learned that you could do so much more than just change the graphics of Starcraft with mods. There were people in the community working on hooking into existing Starcraft code to modify the gameplay and graphics using C++.</p>
<h2>Diving deep</h2>
<p>In order to create these mods, we needed to know the hex address of different functions that Starcraft would call during them game. And to do anything meaningful, we also needed to know the structure of units and sprites and where those were stored as well. A lot of this base work required using tools like OllyDbg to analyze the assembly of the Starcraft executable, and ArtMoney for analyzing the memory of the game while it was executing.</p>
<p>I used OllyDbg to find what functions Starcraft would call during execution – from common functions like the game-loop, to highly specialized functions like checking supply limits. ArtMoney let us determine how structures like units were laid out – where each unit’s health was stored, how much damage each weapon would do, and more.</p>
<p>Most of this information was shared in forums, chat rooms, and a few disparate sites for looking up hex addresses. Of course, no write up about modding Starcraft is complete without mentioning all the work from ShadowFlare (check out <a href="https://sfsrealm.hopto.org/">ShadowFlare’s realm</a> for all the work they did), the great people at Staredit.Net, and plenty of others who built amazing tools to work with Starcraft files. All these sites were amazing resources for figuring out file specs and working with the Starcraft engine.</p>
<p>However, each time I wanted to write a new mod or experiment with an idea, I’d have to look up all of this information across all of these sites.</p>
<h2>Bringing it together</h2>
<p>The goal with GPTP (General Plugin Template Project), was to take all of this work that the amazing modding community had done and bring it together into a C++ Visual Studio project that could be copied for a new mod.</p>
<p>My initial idea was simple: take all of the code for injecting new function hooks into Starcraft and wrap it in some very friendly functions. When a modder would come in to create a new project, they would have three functions exposed to them to work with: gameStart, gameLoop, gameEnd (I don’t remember the exact names I gave them at the time).</p>
<p>I released the initial GPTP back in 2008-2009. This included the project setup for compiling and producing a QDP file that could be loaded into Starcraft. Additionally, it contained known structures and hex addresses that developers could use to build their mod. The Intellisense autocomplete feature really helped developers leverage these structures.</p>
<h2>The power of open source</h2>
<p>I made the original version of GPTP back in high school, but I didn’t have time to continue to work on it when I went to university. I returned to the community a decade later, and found that not only was the community still alive and working on mods, but that they were using GPTP. At this point, GPTP was unrecognizable from my original work; the goal was the same, but the quality of the code was greatly improved and the number of hooks, known structures, and addresses was much more impressive.</p>
<p>You can view the project on Github: <a href="https://github.com/SCMapsAndMods/general-plugin-template-project">general-plugin-template-project</a>.</p>
<p>I’d like to thank open source for this sort of development. The amount of work that has been continually added onto this project couldn’t have been done without all the contributions from the community.</p>
<h2>Does it still work?</h2>
<p>I recently went back to Starcraft modding as a fun little project. I wanted to hop in and see how easy or difficult it would be to create a mod in 2020.</p>
<p>One of the harder things to do in 2020 is find all the tools and initial setup for modding Starcraft. Some of the modding sites are down for good, and with them the knowledge they contained.</p>
<p>But, I pulled together the tools (thanks PyMS), pulled together tutorials and other instructions into a Notion document, and created my first Starcraft mod!</p>
<p>Gathering all the tools was the hard part. After that, it was actually very straightforward creating a new GPTP template and mod. All of the known structures and hooks are pretty self-explanatory and I was able to even add my own hooks once I found the hex addresses using OllyDbg.</p>
<h2>Looking forward</h2>
<p>Starcraft modding is like an ancient art at this point. There isn’t a large audience for it, so in general, any new mod will be played by maybe 10 people. But to me, it’s a combination of nostalgia, hard work, tinkering, discovery, and creation that makes it so much fun. That feeling of finding a new function to hook onto, writing C++ code that injects itself into it, and then running the code in the Starcraft engine and seeing it work is a special kind of rewarding experience.</p>
<h2>Thanks</h2>
<p>I’d like to give thanks to everyone who has ever contributed to the modding community for Starcraft. There are so many names that I couldn’t possibly name them all, but please check of <a href="http://staredit.net">http://staredit.net</a> if any of this interests you.</p>


One of the first PC games I played was Starcraft and the expansion Starcraft: Broodwar. We didn’t have a PC, so I had to play it on a friend’s computer, but I remember being immersed in the real-time strategy gameplay.

Later, I would get a PC and bought my own copy of Starcraft. This was years later, but the community for the game was still impressive. Joining one of the older Starcraft forums, I discovered “mods” for the game. The most popular ones were just graphical changes, but that concept of changing a game to display your own graphics was so interesting to me. I’m not sure how I stumbled on it, but I found [http://www.staredit.net/](http://www.staredit.net/) (yes, it’s still active!) and I learned that you could do so much more than just change the graphics of Starcraft with mods. There were people in the community working on hooking into existing Starcraft code to modify the gameplay and graphics using C++.

## Diving deep

In order to create these mods, we needed to know the hex address of different functions that Starcraft would call during them game. And to do anything meaningful, we also needed to know the structure of units and sprites and where those were stored as well. A lot of this base work required using tools like OllyDbg to analyze the assembly of the Starcraft executable, and ArtMoney for analyzing the memory of the game while it was executing.

I used OllyDbg to find what functions Starcraft would call during execution – from common functions like the game-loop, to highly specialized functions like checking supply limits. ArtMoney let us determine how structures like units were laid out – where each unit’s health was stored, how much damage each weapon would do, and more.

Most of this information was shared in forums, chat rooms, and a few disparate sites for looking up hex addresses. Of course, no write up about modding Starcraft is complete without mentioning all the work from ShadowFlare (check out [ShadowFlare’s realm](https://sfsrealm.hopto.org/) for all the work they did), the great people at Staredit.Net, and plenty of others who built amazing tools to work with Starcraft files. All these sites were amazing resources for figuring out file specs and working with the Starcraft engine.

However, each time I wanted to write a new mod or experiment with an idea, I’d have to look up all of this information across all of these sites.

## Bringing it together

The goal with GPTP (General Plugin Template Project), was to take all of this work that the amazing modding community had done and bring it together into a C++ Visual Studio project that could be copied for a new mod.

My initial idea was simple: take all of the code for injecting new function hooks into Starcraft and wrap it in some very friendly functions. When a modder would come in to create a new project, they would have three functions exposed to them to work with: gameStart, gameLoop, gameEnd (I don’t remember the exact names I gave them at the time).

I released the initial GPTP back in 2008-2009. This included the project setup for compiling and producing a QDP file that could be loaded into Starcraft. Additionally, it contained known structures and hex addresses that developers could use to build their mod. The Intellisense autocomplete feature really helped developers leverage these structures.

## The power of open source

I made the original version of GPTP back in high school, but I didn’t have time to continue to work on it when I went to university. I returned to the community a decade later, and found that not only was the community still alive and working on mods, but that they were using GPTP. At this point, GPTP was unrecognizable from my original work; the goal was the same, but the quality of the code was greatly improved and the number of hooks, known structures, and addresses was much more impressive.

You can view the project on Github: [general-plugin-template-project](https://github.com/SCMapsAndMods/general-plugin-template-project).

I’d like to thank open source for this sort of development. The amount of work that has been continually added onto this project couldn’t have been done without all the contributions from the community.

## Does it still work?

I recently went back to Starcraft modding as a fun little project. I wanted to hop in and see how easy or difficult it would be to create a mod in 2020.

One of the harder things to do in 2020 is find all the tools and initial setup for modding Starcraft. Some of the modding sites are down for good, and with them the knowledge they contained.

But, I pulled together the tools (thanks PyMS), pulled together tutorials and other instructions into a Notion document, and created my first Starcraft mod!

Gathering all the tools was the hard part. After that, it was actually very straightforward creating a new GPTP template and mod. All of the known structures and hooks are pretty self-explanatory and I was able to even add my own hooks once I found the hex addresses using OllyDbg.

## Looking forward

Starcraft modding is like an ancient art at this point. There isn’t a large audience for it, so in general, any new mod will be played by maybe 10 people. But to me, it’s a combination of nostalgia, hard work, tinkering, discovery, and creation that makes it so much fun. That feeling of finding a new function to hook onto, writing C++ code that injects itself into it, and then running the code in the Starcraft engine and seeing it work is a special kind of rewarding experience.

## Thanks

I’d like to give thanks to everyone who has ever contributed to the modding community for Starcraft. There are so many names that I couldn’t possibly name them all, but please check of [http://staredit.net](http://staredit.net) if any of this interests you.


Revisiting GPTP - the Starcraft modding toolkit

"use strict";
const {Fragment: _Fragment, jsx: _jsx, jsxs: _jsxs} = arguments[0];
function _createMdxContent(props) {
  const _components = {
    a: "a",
    h2: "h2",
    li: "li",
    mermaid: "mermaid",
    p: "p",
    ul: "ul",
    ...props.components
  };
  return _jsxs(_Fragment, {
    children: [_jsx(_components.p, {
      children: "Dark Emblem is an NFT project that was sparked by the idea of combining cards games with Crypto Kitties. You can buy packs, open them to collect random cards, and then use those cards to battle raids with others."
    }), "\n", _jsx(_components.p, {
      children: "To support all of the functionality, I created a WAX contract, written in C++, that I deployed to the WAX Blockchain. This contract handled the creation and storage of packs and cards, along with defining an in-game currency DREM."
    }), "\n", _jsx(_components.p, {
      children: "There was also a server that would sync with the changes on the Blockchain and provide some additional metadata on top of that. While Blockchains like ETH have stable public APIs that can be used to query data from the Blockchain through 3rd party vendors, WAX does not have the same maturity there. This meant that we would need to proxy requests that would normally be made to a WAX API mode through our servers instead."
    }), "\n", _jsx(_components.p, {
      children: "I also created a UI application to interact with the server and the Blockchain. The infrastructure ends up looking like:"
    }), "\n", _jsx(_components.mermaid, {
      chart: "graph LR\n  WAX --> Dfuse\n Dfuse --> Listener(Dark Emblem Listener Service)\n  Listener --> Redis\n  Redis --> API(Dark Emblem API)\n  API --> Dapp\n  WAXEndpoint(WAX Endpoint) --> Dapp"
    }), "\n", _jsx(_components.p, {
      children: "One of the first steps to interacting with the dapp is to sign in. The authentication flow is similar to an oauth sign in where we let the user sign in with a third party authenticator and then issue a challenge for the user to verify they are who they say they are. At this point we issue a JWT for further API requests."
    }), "\n", _jsx(_components.mermaid, {
      chart: "sequenceDiagram\n  Dapp->>+3rdPartyAuthenticator: Request sign in\n  3rdPartyAuthenticator->>+Dapp: Wallet name\n  Dapp->>+DarkEmblemAPI: Request nonce\n  DarkEmblemAPI->>+Dapp: Send nonce\n  Dapp->>+3rdPartyAuthenticator: Sign nonce\n  3rdPartyAuthenticator->>+Dapp: Signed nonce\n  Dapp->>+DarkEmblemAPI: Send signed nonce\n  DarkEmblemAPI->>+Dapp: JWT"
    }), "\n", _jsx(_components.p, {
      children: "Once a user is logged in, they can fully interact with the Dark Emblem WAX contract via the UI. They can purchase packs, open them to get cards, and then use those cards in the Dark Emblem universe. The UI lets users combine Hero cards together to “Ascend” them into a new card. Or they can burn 3 Equipment cards to “Transmogrify” them into a single, better equipment card."
    }), "\n", _jsx(_components.p, {
      children: "Users can also participate in Raids, where they stake their cards to defeat an enemy monster – gaining $DREM and XP when they beat the monster."
    }), "\n", _jsx(_components.p, {
      children: "Dapp Schemas and Atomic Assets"
    }), "\n", _jsx(_components.mermaid, {
      chart: "classDiagram\n  class Card {\n    name: string\n  img: string\n  traits: number[]\n  matronid: number\n  sireid: number\n  rank: number\n  packid: string\n  cardtype: string\n  website: string\n  twitter: string\n  mintedat: number\n  rarity: string\n  cooldown: number\n  xp: number\n  }\n  class Raid {\n  asset_id: number\n  owner: name\n  staked_at: number\n  raid_id: number\n  }\n  class Staked {\n  asset_id: number\n  owner: name\n  staked_at: number\n  raid_id: number\n  }\n"
    }), "\n", _jsx(_components.p, {
      children: "The Dark Emblem project involves a lot of moving parts, and I’d love to dive deeper into each technical aspect in future blog posts."
    }), "\n", _jsx(_components.h2, {
      children: "Additional reading"
    }), "\n", _jsxs(_components.ul, {
      children: ["\n", _jsx(_components.li, {
        children: _jsx(_components.a, {
          href: "https://www.darkemblem.com/blog/post/2023-04-02-new-site-released",
          children: "Dark Emblem Blog Announcement"
        })
      }), "\n", _jsx(_components.li, {
        children: _jsx(_components.a, {
          href: "https://capsulecat.com/blog/04-02-2023-dark-emblem-update/",
          children: "Capsule Cat Announcement"
        })
      }), "\n"]
    })]
  });
}
function MDXContent(props = {}) {
  const {wrapper: MDXLayout} = props.components || ({});
  return MDXLayout ? _jsx(MDXLayout, {
    ...props,
    children: _jsx(_createMdxContent, {
      ...props
    })
  }) : _createMdxContent(props);
}
return {
  default: MDXContent
};


<p>Dark Emblem is an NFT project that was sparked by the idea of combining cards games with Crypto Kitties. You can buy packs, open them to collect random cards, and then use those cards to battle raids with others.</p>
<p>To support all of the functionality, I created a WAX contract, written in C++, that I deployed to the WAX Blockchain. This contract handled the creation and storage of packs and cards, along with defining an in-game currency DREM.</p>
<p>There was also a server that would sync with the changes on the Blockchain and provide some additional metadata on top of that. While Blockchains like ETH have stable public APIs that can be used to query data from the Blockchain through 3rd party vendors, WAX does not have the same maturity there. This meant that we would need to proxy requests that would normally be made to a WAX API mode through our servers instead.</p>
<p>I also created a UI application to interact with the server and the Blockchain. The infrastructure ends up looking like:</p>
<mermaid chart="graph LR
  WAX --&gt; Dfuse
 Dfuse --&gt; Listener(Dark Emblem Listener Service)
  Listener --&gt; Redis
  Redis --&gt; API(Dark Emblem API)
  API --&gt; Dapp
  WAXEndpoint(WAX Endpoint) --&gt; Dapp"></mermaid>
<p>One of the first steps to interacting with the dapp is to sign in. The authentication flow is similar to an oauth sign in where we let the user sign in with a third party authenticator and then issue a challenge for the user to verify they are who they say they are. At this point we issue a JWT for further API requests.</p>
<mermaid chart="sequenceDiagram
  Dapp-&gt;&gt;+3rdPartyAuthenticator: Request sign in
  3rdPartyAuthenticator-&gt;&gt;+Dapp: Wallet name
  Dapp-&gt;&gt;+DarkEmblemAPI: Request nonce
  DarkEmblemAPI-&gt;&gt;+Dapp: Send nonce
  Dapp-&gt;&gt;+3rdPartyAuthenticator: Sign nonce
  3rdPartyAuthenticator-&gt;&gt;+Dapp: Signed nonce
  Dapp-&gt;&gt;+DarkEmblemAPI: Send signed nonce
  DarkEmblemAPI-&gt;&gt;+Dapp: JWT"></mermaid>
<p>Once a user is logged in, they can fully interact with the Dark Emblem WAX contract via the UI. They can purchase packs, open them to get cards, and then use those cards in the Dark Emblem universe. The UI lets users combine Hero cards together to “Ascend” them into a new card. Or they can burn 3 Equipment cards to “Transmogrify” them into a single, better equipment card.</p>
<p>Users can also participate in Raids, where they stake their cards to defeat an enemy monster – gaining $DREM and XP when they beat the monster.</p>
<p>Dapp Schemas and Atomic Assets</p>
<mermaid chart="classDiagram
  class Card {
    name: string
  img: string
  traits: number[]
  matronid: number
  sireid: number
  rank: number
  packid: string
  cardtype: string
  website: string
  twitter: string
  mintedat: number
  rarity: string
  cooldown: number
  xp: number
  }
  class Raid {
  asset_id: number
  owner: name
  staked_at: number
  raid_id: number
  }
  class Staked {
  asset_id: number
  owner: name
  staked_at: number
  raid_id: number
  }
"></mermaid>
<p>The Dark Emblem project involves a lot of moving parts, and I’d love to dive deeper into each technical aspect in future blog posts.</p>
<h2>Additional reading</h2>
<ul>
<li><a href="https://www.darkemblem.com/blog/post/2023-04-02-new-site-released">Dark Emblem Blog Announcement</a></li>
<li><a href="https://capsulecat.com/blog/04-02-2023-dark-emblem-update/">Capsule Cat Announcement</a></li>
</ul>


Dark Emblem is an NFT project that was sparked by the idea of combining cards games with Crypto Kitties. You can buy packs, open them to collect random cards, and then use those cards to battle raids with others.

To support all of the functionality, I created a WAX contract, written in C++, that I deployed to the WAX Blockchain. This contract handled the creation and storage of packs and cards, along with defining an in-game currency DREM.

There was also a server that would sync with the changes on the Blockchain and provide some additional metadata on top of that. While Blockchains like ETH have stable public APIs that can be used to query data from the Blockchain through 3rd party vendors, WAX does not have the same maturity there. This meant that we would need to proxy requests that would normally be made to a WAX API mode through our servers instead.

I also created a UI application to interact with the server and the Blockchain. The infrastructure ends up looking like:

```mermaid
graph LR
  WAX --> Dfuse
 Dfuse --> Listener(Dark Emblem Listener Service)
  Listener --> Redis
  Redis --> API(Dark Emblem API)
  API --> Dapp
  WAXEndpoint(WAX Endpoint) --> Dapp
```

One of the first steps to interacting with the dapp is to sign in. The authentication flow is similar to an oauth sign in where we let the user sign in with a third party authenticator and then issue a challenge for the user to verify they are who they say they are. At this point we issue a JWT for further API requests.

```mermaid
sequenceDiagram
  Dapp->>+3rdPartyAuthenticator: Request sign in
  3rdPartyAuthenticator->>+Dapp: Wallet name
  Dapp->>+DarkEmblemAPI: Request nonce
  DarkEmblemAPI->>+Dapp: Send nonce
  Dapp->>+3rdPartyAuthenticator: Sign nonce
  3rdPartyAuthenticator->>+Dapp: Signed nonce
  Dapp->>+DarkEmblemAPI: Send signed nonce
  DarkEmblemAPI->>+Dapp: JWT
```

Once a user is logged in, they can fully interact with the Dark Emblem WAX contract via the UI. They can purchase packs, open them to get cards, and then use those cards in the Dark Emblem universe. The UI lets users combine Hero cards together to “Ascend” them into a new card. Or they can burn 3 Equipment cards to “Transmogrify” them into a single, better equipment card.

Users can also participate in Raids, where they stake their cards to defeat an enemy monster – gaining $DREM and XP when they beat the monster.

Dapp Schemas and Atomic Assets

```mermaid
classDiagram
  class Card {
    name: string
  img: string
  traits: number[]
  matronid: number
  sireid: number
  rank: number
  packid: string
  cardtype: string
  website: string
  twitter: string
  mintedat: number
  rarity: string
  cooldown: number
  xp: number
  }
  class Raid {
  asset_id: number
  owner: name
  staked_at: number
  raid_id: number
  }
  class Staked {
  asset_id: number
  owner: name
  staked_at: number
  raid_id: number
  }

```

The Dark Emblem project involves a lot of moving parts, and I’d love to dive deeper into each technical aspect in future blog posts.

## Additional reading

* [Dark Emblem Blog Announcement](https://www.darkemblem.com/blog/post/2023-04-02-new-site-released)
* [Capsule Cat Announcement](https://capsulecat.com/blog/04-02-2023-dark-emblem-update/)


game-development posts

AI Feedback Systems

Revisiting GPTP - the Starcraft modding toolkit

Dark Emblem Rewrite