Part 2: Modelling the Data in my Marvel Snap Clone

Building out the tables in ServiceNow for my Marvel Snap clone has been interesting.   

I started with the most atomic object I’d need – a Card Definition.  This needs to house the Cost, Power and Ability data for all the cards that exist in Marvel Snap.  I found a webpage with a database of Marvel Snap cards (https://marvelsnap.io/) which also had an underlying API.  I inspected the browser session to see how the page loads and found that the API was pretty easy to understand:

Base URL: https://marvelsnap.io/api/search.php

Query Params:

Type (character or location)

Sort (by field)

Limit (integer)

Offset (for paging, zero indexed).

This returns an array of Cards in a JSON object, so I based my Card Definition on this payload:

“card”: [

{

“id”: 1,

“name”: “Abomination”,

“type”: “Character”,

“cost”: 5,

“power”: 9,

“ability”: null,

“date_added”: “2022-05-20 08:46:03”,

“status”: null,

“variants”: “1_526,1_525,1_524,1_521”,

“pretty_url”: “abomination-1”,

“method”: “Starter Card”,

“slug”: “Abomination”

},

]

From there I started to think about some of the relationships I need – When a card is in play, it gets modified and its status and location changes, so I probably need an “instance” of the card to represent what’s happening to it while in Play – Card Instance record.

The Card Instance exists in the context of a location (In the player’s deck, in their hand, in the playspace, discarded, etc), so let’s also have a Location Instance to store that during play.

Because we’re tracking things in context of the game that’s being played, we probably also need a Game Instance to represent that.

In order for a Player to have their own set of cards in their deck to be shuffiled into Card Instances, we should have a container for the Player Deck that contains their preferred deck at that time – a Player Deck record with child Player Deck Card records which represent the cards that the player has in their deck.  Player Decks should belong to a user.

Finally, in order to connect two users attempting to start a game, we’ll need a Matchmaking Queue.  This lets player one start queueing and allows player two to find an unresolved matchmaking session before the Game Instance is created.

This seems like a solid data structure, and I can sort of visualise it in my head, but I also don’t want to waste time diagramming it… I wondered if ChatGPT could help?  I asked ChatGPT with Dall-E to diagram it all for me based on the following prompt:

Can you please draw an ERD which shows the following tables: Player Deck Card, Player Deck, Card Definition, Card Instance, Matchmaking Queue, Location instance, Game Instance, Player Session, User

 

A Player Deck consists of many Player Deck Cards.

 A Player Deck Card can be related to a single Card Definition.

Many Player Sessions can be related to a single Game Instance.

Multiple users can be related to a Matchmaking Queue.

A Single Game Instance can be related to a single Matchmaking Queue.

A Player Deck can be related to a single User.

Many Location Instances can be related to a Game Instance

A Card Instance can be related to a single Location Instance

A Card Instance can be related to a single Card Definition

 

The results weren’t amazing – typical hallucination representations, and not really good enough for what I want: 

Then I got to thinking – ChatGPT is pretty good with code, and there’s probably some code -> Diagram frameworks…. I found something called Mermaid Live which has a markup language for Diagrams, so I asked ChatGPT to generate that code for me: 

And this gave me a pretty reasonable ERD for my little app:  

 

This is all pretty good!  Shows how the app works pretty well and helps me to keep my relationships well structured!  I’ll need to go through and update the table names to be more correct, but all in al the structure of the app is coming along!