While browsing reports of flow sessions at Dreamforce, I came across two guys claiming to implement an Entire Heckin’ Blackjack inside of Flow. This is My Kind of Dreamforce Session, but I wasn’t able to make it because they keep Product Managers very busy at Dreamforce. As of this moment I’m still waiting for the video to get posted, but in the meantime I asked them to write a blog post. As you can see, this flow involves everything: Steps, Debugger, Lightning Component, Formulas. It’s really impressive, and the blog post is presented here.

============

Architect: Sean Dukes
Coder: Luke Kozakewycz

By Sean Duke

It all started at a Salesforce user group. I was doing a presentation on Lightning Flow. I’d used a ‘Hello World’ Lightning component and showed how you could change the greeting based on the region of the person. It went down pretty well, but it was hardly the rich user experience you read about.

Fast forward a few weeks and for some reason I had the idea that Blackjack would be a great visual use case. I sketched out a basic design and it seemed like it ought to work, so I submitted the idea as a Dreamforce talk. I didn’t expect things to go any further, so it was something of a surprise when a few weeks later, the email came through. “Your idea has been accepted, can you run us through your slides next week?”

“Yes, of course.” There followed an interesting few days where we put some slides together and tried to turn those early sketches into something that at least proved that what we wanted to do was possible.

“The first thought that struck me was that I’d never played Blackjack.”

The first thought that struck me was that I’d never played Blackjack. There could be experts in the room. I needed to truly understand how to play the game, so I wouldn’t get found out. I hunted around the internet and interviewed a couple of people who had played. My initial ideas weren’t far off, but, now that I had my user stories, it was interesting how much like a real project this was becoming.

In Blackjack, you typically have more than one deck of cards and they’re not shuffled between every hand. But they are shuffled. The first job was to get those cards and shuffle them. Salesforce doesn’t have a random number function, which would have made our life easy, so we had to come up with another way.

If you think about it, when you shuffle cards it isn’t random. The order they start in determines the order they end up in. We didn’t need random, we just needed unpredictable. So how do you do that?

There are in fact several ways you could do this. This is mine …

The solution we came up with was to use two objects. The first object was the base deck. This contained the 52 cards, with their value, an image url, the name and whether the card was an ace or not. We also assigned each card a different five-digit prime number.

For the first shuffle, we looped through the base deck and added two of each card to a new sObject Collection. As we did that, we calculated a number we call the seed.

The formula was pretty simple.

The formula was pretty simple. Multiply one thousand plus the time the user was created in hundredths of a second by the card prime number and then by a second five-digit prime number. This gives you a number of between twelve and fourteen digits. We then take the right hand seven digits which is our first unpredictable number.

VALUE(RIGHT(TEXT([Card prime number]*([Time Created]+1000)*[Prime number 1]),7))

When we add the second card, we use a different prime number. We now have 104 cards in an sObject collection with 104 unpredictable seed numbers and we save this to a second object called Card Deck that has a lookup to the user. If we sort by this, then each card deck will have a different card order for each player unless they created their accounts at precisely the same second.

We don’t stop there.

We don’t stop there.We use a second field called the shuffle order. This is a formula field that multiplies the seed by a ten digit prime number and by the record number of the card in the card deck (a sequential number) and then we take the middle seven digits. This is the field we actually sort by. Even if two players started at exactly the same time, their shuffle orders would be radically different.

Shuffling again is simple. All we do is copy the shuffle order to the seed field and this creates a new shuffle order. It works really nicely.

It’s easy and satisfying to test this. The first thing to do is create a list view that shows the user’s cards.

Then you go to the shuffle flow — we have a separate flow because we re-use it in several places.

Now you click the debug button and enter in the user ID, which is the only input parameter required by the flow and click Run.

It’s worth noting that this debug method actually does run and changes data. It’s not something you want to be doing in your production org with an untested flow! For our purposes though, it’s great. Click refresh and you can see the result.

So shuffling was a good start and relatively straightforward. Now for the game itself. This was definitely the heavy thinking part. The breakthrough came when we started to look at the journey of each individual card.

We load the shuffled deck into an sObject Collection and then follow each card around. We use a series of variables to record what is happening with the player and the dealer and then we make decisions based on the value of those variables.

It took a while, but this is what we ended up with.

Break this down and the first part of the flow is all about getting ready. The right hand loop represents the playing of a single hand and the left hand loop runs when that hand is over and we get ready to play the next one. Simple 🙂 In all we ended up with 34 elements in the flow and four of those are to stop people cheating!

We should probably confess at this point that we decided splits, doubling and insurance were out of scope for our project. I have no doubt we could add those things in now.

A couple of things we noticed as we went along. Firstly, we were really diligent about creating descriptions on every flow element as a first step. Writing in long hand exactly what we expected to happen at each stage made completing each element much easier and the whole thing was easier to debug. The other thing that was interesting, was that the more efficient and the more correct our flow became, the fewer elements we had and the more elegant the flow itself appeared. I’m particularly proud of the fact that in the whole flow, we only ended up with one crossing connector and though I’ve tried, I can’t see a way to get rid of it. It will be interesting to see what this looks like when we put it in the new Flow Builder.

One thing that helped to keep the flow manageable was using formulas. For example, we have an assignment step where we work out the outcome of the game when the dealer has finished playing. We could have done this with a decision element and five assignments, but we were able to achieve the same thing with one assignment and a formula. Our assignment step sets the value of the GameOutcome variable to a formula result. This trick really cut down on complexity.

We tested our game as we were building it using a variation on that original ‘Hello World’ component. We had a view showing us the player’s card deck and then put our component onto a page, then we could compare the two side by side and make sure the game was behaving as we expected. This was crude and we didn’t have hit and stand buttons, but it was very useful.

At this point we had a working game and my coding skills had reached their limit. It was time to call in a professional! The Lightning component we built looks great, but it does remarkably little work. The screen element passes various values into the flow so that we know what we want to display. It has a timer, so you can see the cards being dealt out and it does look pretty, but that’s effectively it.

The only time the Lightning component changes a value is when the player hits stand. There’s an attribute called DealToPlayer. This will be true if it’s the player’s turn and if the player hits ‘Stand’ then this changes to false and is passed back to the flow. The flow does the rest.

Now all we needed to do was drag our flow onto the Lightning community home page (or in this case onto a Contact page for testing) and that was that.

We had our game and we could and did take it to Dreamforce. We even managed to get the whole audience playing in our special community and we had prizes, including for the fastest loser! Overall, it was great fun and a hugely interesting learning experience. If you want to find out more then, when the recording comes out, you should watch it.

Architect: Sean Dukes

Coder: Luke Kozakewycz

We both worked on bits of all of it.

© Sean Dukes 2018