My little piece of the digital multiverse
MindHunters – Deck building
Today I’m going to tell you about the Deck Building feature in MindHunters.
As with any trading card game, the meta-game of deck building is vital, and is a direct reflection of a player’s intended strategy. It is likely that most players will spend a fair amount of time building one or more decks, and it is important that the interface is slick, pleasant, intuitive and most importantly, functional.
In MindHunters, there are certain rules placed on decks (and the cards that they can contain).
Some simple rules include:
- Thou shalt never have a duplicate card in your deck
- Thou shalt always have one score of cards or more (i.e. 20 cards or more…)
and then there are some slightly more complex rules such as ‘Thou shalt never mix cards of opposing factions in a deck’.
Whatever these rules are, they need to be enforced during the construction of the deck (not at the end), and therefore each building action a player takes is validated by the game server. Yes, I do realise that with bad latency, deck building could be a tedious chore, however, this is a network game, and to be honest, if you can’t build a deck due to your network connectivity, then you’re probably best off not participating in the game.
With this in mind, a few basic components were identified that needed to be present:
- A way to select a deck to work with, as well as functionality to create/delete/rename decks
(the obvious stuff) - The player’s library of available cards.
Available cards are defined as cards that are not used in the currently selected deck. This will help prevent a player from adding a duplicate of a card into the deck.
- A filtering bar that will allow the player to quickly and efficiently find the cards that they are looking for.
- A list/display of cards currently in the selected deck.
The screenshot below is an early development build of the Deck Builder UI that exhibits all of these basic components….
The Deck Builder UI
As you can see, I only have one sample card graphic to work with at the moment, but it does the job nicely.
The control that displays the cards is the Card Picker control that contains all available cards the player has. The Card Picker control itself was one of the more complex pieces of code I’ve had to write in this client, and as you can see, it still needs a lot more work.
The control supports drag-and-drop functionality to allow the player to simply drag their desired card down into the deck list. This simple action causes a number of discrete units of work to kick off in the background:
- Figure out which card the player dropped into the deck
- Validate that the player has this card
- Let the server know that the player tried to add a card from their library to a deck
- The server validates all the rules for adding cards to decks and responds with either a success notification, updating the deck in question, or with an error.
- Assuming the client received a success notification, it then proceeds to update the deck data model, and removes the card from the available list of cards in the Card Picker control.
Below is a video to demonstrate the simplicity of selecting a deck and dragging a few cards into it:
The model/view of the deck (at the bottom of the screen) is based on the QAbstractTableModel/QTableView coupling in the Qt framework. The pattern has worked well for all of the data display controls I’ve had to create for the app so far (including the Game Room and Library viewer, and the proxy filter/sort models will be used to provide the filtering behaviour I need once I write the code for the filtering options at the top of the screen.
Thats it for now. I may write a bit more of a technical article on the actual Card Picker control if I have enough time (and once I figure out some nasty scaling oddities I still have to deal with).
