I first learnt about Minnesota Bus whilst relaxing on a shady patch of grass somewhere in Machakos, Kenya. More specifically, here, to be exact. In our off-time, myself and the other volunteers liked to spend our time catching up, having a drink or two, and playing cards. This led to many exchanges of card games between the UK volunteers and our Kenyan counterparts, with one specific game becoming a fast favourite of all of us: Minnesota Bus. It was explained to me as a game that one of us had picked up on our travels around America in a year past, the rules only half-remembered, and the name; completely forgotten. What was remembered was a rather drunk Minnesotan man explaining this Ride-the-bus style game. And so, the name stuck.
With the memory fully engrained in me, even after returning to the UK, I realised that this would be a perfect opportunity to prove what I’d learnt of the Unity engine, so far. I started with an initial proof of concept, with a single card model, which would cycle through all 52 cards in the deck (along with the rear image). Upon this, I built a simple animation coroutine which used a standard bell curve which dictated the card’s X scale transform property over time, such that, at it’s peak, the card was 0 unit’s wide and then returned back to it’s original width. This created the illusion that the card was flipping over – with as much visual fidelity as was required at this early stage of development:
One card is great, but doesn’t make for a terribly exciting card game. As such, I made a class that would be called at the beginning of each new game, which was tasked with generating a deck of cards, shuffling said deck and then allocating cards to either the player or the dealer, depending on whom the instance of the class belonged to.
Once this was implemented, I needed to move the sprite rendering aspects out of the model itself, and into its own view class – and from here, you can probably predict which architectural path I decided to go down. In this view, I declared and populated a list of all card objects (irrespective of owner) and then, using a listener, only re-render these objects should their values change or if the controller tells it something is going on.
The final component, the Game Controller, operated the game loop and implemented the varying rules depending on the round, as well as a few other features, such as displaying win-loss text on the screen and resetting the game if the player loses.
For a quick run-down of the rules, on the first round, the player must if the card they are about to turn over’s suit is red (Hearts or Diamonds) or black (Clubs or Spade). Then the player must decide whether the card is higher or lower than the previous card they flipped, and then, whether the next card will be within the previous two cards (inclusive) or outside. For the final round, the player must correctly guess the suit of the final card. If the player is found to be wrong on any of these rounds then the deck is reshuffled, progress resets and, as the rules dictate, they must take a drink.
Once I felt satisfied with the core gameplay components, I decided to spend the remainder of my time polishing aspects that I hardly looked into prior to this project, most notably: sound. I found a good set of suggestions on how to begin an audio manager and imported the sound effects, but still struggled with my idea of having music play throughout the game, rather than just resetting upon a new scene. The solution, as is becoming the pattern now, was found here. While pushing my knowledge of resource management in C#, well, specifically Unity, this was a fun exercise to explore just how malleable Unity could be at times, perhaps despite it’s best efforts.
So, there you go! As it stands now, I have managed to put together a rather solid, if not simple, prototype. In the future, I hope to come back to this and add the ability to enjoy the fully Minnesota Bus experience – which is to say, with other people. But, for now, Enjoy*!