Initiating a game will require us to have all the potential card and location positions for the playspace defined (for each player) as well as slots for both players.
This is roughly the outcome we’re looking for:
We’ll also need to track the player’s hand content, as well as their deck contents, so let’s break this down a bit.
Setting up the playspace:
We need to set the players up – we have a “Game Instance” table which has the following fields we can set:
Current turn = let’s zero index for our “pre-launch” turn – we can do any pre-turn operations during this time. I’ll set the default to 0.
Location 1-3 = Let’s shuffle all potential locations and deal them into these slots.
Number of turns = default is 6, but this can change based on cards played.
Current Active Player = we’ll probably do a coin toss and make a reference to a Player Session record.
Player 1 & Player 2 = References to the player session
We’ll need the following subflows:
1 – Create the Game Instance Record
2 – Shuffle cards – it should take an input of “Type” (location or player deck) and if Location, it’ll need to shuffle all active location cards.
3 – Deal Locations – once we’ve shuffled, we should deal out the 3 locations – we’ll create the “Location instance” record and return the reference to the Game instance.
4 – Add Players – Allocate the Players and do a coin-toss for who goes first.
The Game Instance flow was easy – create record from a matchmaking instance. I also added a reference to the matchmaking record just so we have tracablilty when debugging and I set the game instance as the output of this subflow (so other subflows can use that)
The Shuffle Flow was a little interesting… I want to set up a type so I can shuffle different classes of cards. The Location choice is based on the full card set… but the Player Deck comes from the Player Deck Card records, and the Live Player Deck comes from the Card Instances that are “In Deck” status.
This means that the operation to create or update records will be different for each. I probably actually need 2 subflows – one which is a generic “shuffle an array of numbers” and another which is the “build an array of numbers”. Getting the Array shouldn’t be TOO intensive – the Player deck has a maximum of 12 cards, and the Locations are a few dozen – maybe no more than 60-70 location variations. I don’t have a huge problem with that size of database operation.
Let’s do the array shuffle flow first…. we might need to do some code here somewhere. I don’t think any of the math transforms or array transforms in Flow Designer can handle a randomiser or anything like that, so I think we’ll have to resort to some code to shuffle our array of items. GIven we’re writing code anyway, maybe we should only return x number of IDs (corresponding with how many cards we want to “deal”). I’ll create a Flow Action for this:
This constitutes the first lines of code in this entire solution (not counting CSS remember?). If I wanted to be really strict, I might have been able to find an API that would shuffle an array for me and call that, but it seems like a lot of effort to avoid these this code, and shuffling is a bit tricky (and also I don’t want to rely too heavily on stuff outside of ServiceNow).
This action is both shuffling and limiting the number of records I need to subsequently look up – this should make the full flow logic a little quicker.
The next thing I need to do is get the array of IDs to send to the Action. Unfortunately there’s no “array” Flow Variable type (yet..?) so that’s why my action will work with JSON. What I’m going to do instead is use a String Flow Variable and construct the JSON of the IDs using another Subflow:
This subflow looks up all the active Locations (this gives us a record count as well as a record, so we can use that sneaky iterator flow variable to check whether we’re at the end of the objects to close our JSON string)
We start the JSON with an array [, and then we iterate through all our records adding {“ID:<the id field>}.
When we get to the end of the record list (and our iterator matches) then we close the JSON string with a ].
This isn’t really ‘code’ but we’re getting the flow to write code, so I don’t think it counts :).
At this point we’ve got the records coming back with a JSON array of IDs, and we’ve got an action that can return a limited list of shuffled IDs. We can use this list to do a second Look up record based on the IDs we want to return and stitch it all together in a master subflow:
That gives us shuffled locations with a limit. That’ll do for tonight. We can add our Location Instance record creator next, then start looking at our Player card shuffle and deal system.
Here’s roughly what that might entail:
Pre-loading the deck/hand:
Instantiate a copy of the player’s deck as an “unshuffled” deck so we know what cards we’ve got.
Some cards have an ability that happens prior to shuffle (such as automatically adding the card to the player’s hand), so we’ll first need to search for those and execute the appropriate flows. Once these treatments have occur then, let’s shuffle the remaining cards and deal the first hand of three cards.
Leave a Reply