Gentleman’s Gambit is a collectible card game (or CCG) built for PC in Unreal 4.8. The game sets two players against each other, each of which have 3 Gentlemen who use insult cards to reduce each other’s integrity until one team is ashamed enough to quit. As a collectible card game, there are some cards which are objectively better than others, though these tend to be rarer. This collectibility is key to our monetisation system, where players can choose to buy packs of randomised cards. While we didn’t manage to implement some features before the end of the project, we managed to implement each major feature and even had time for a bit of polish and testing. The following is a list of what went wrong, what went right and what we’ve learned from the experience.
What Went Right
Gentleman’s Gambit was made over a six-week period, which was a time limit we were given from the outset. As such, we were able to scope our project for that time, and that’s something I think went extremely well. While we did have to cut features – something I’m learning is inevitable – we only ended up cutting things that we were always aware may not make it into the game, such as a taunt system. However, that means all our essential features made it, and we had time to polish non-essential areas such as menus.
This is because we successfully scoped our game for the time frame. Developing card game meant we could easily scale the scope forward or back depending on how successful we were at developing according to our schedule, and while some cards didn’t make it, that was the point.
Humour is a big part of Gentleman’s Gambit, and so far it’s been well-received. People find the art and the text funny, which is a big win – it was essentially a joke we told six weeks ago and only just found out now that it’s funny. Writing comedy is extremely difficult, probably because it’s so subjective, but we seem to have found a point at which everyone who’s played it has enjoyed and gotten a laugh out of something. None of our previous games have had humour written into them, despite generally being silly enough to be funny, so this was a good experience.
Gameplay and Deck Building
The gameplay came together nicely, which I think was more of a happy coincidence than anything. We didn’t spend as much time iterating the design as we normally would, because initial testing was mostly positive. We realised as more cards were designed that combos create themselves – for example, we’d create a card that does X and it would work with a card that does Y which we’d created weeks before. These card combinations are essential to CCGs and it was an interesting experience to see them come together naturally. After some early balancing we found that each deck stood on it’s own as well, and that – at least at this stage – no card or combination is obviously overpowered.
What went wrong
There was one feature we had to cut that wasn’t something we considered optional, and that was networking. I don’t know exactly what went wrong, but the networking just wasn’t finished and implemented in time for our final build, so we’ve settled for a rudimentary AI to show off the mechanics. Playing against other players is the entire point of the game, so not having this feature is a big miss for us – though not necessarily essential, it is something that’s very disappointing to miss out on.
Something we were always aware of but never managed to implement was a better atmosphere for the game. In the screenshot above you can see the board, well-lit, floating in a strange void. Our earliest build was set beside a fireplace, indoors, with whisky and cigars along the side of the board, which was much better atmospherically. While this is something we chose to cut because of our time constraints, it’s still a real shame, because it’s lost a lot of the identity of the game along the way. Were we to revisit this project, improving the atmosphere would be a high priority.
What We Learned
Implement major features ASAP
Like everything else, this is extremely obvious in hindsight. Networking shouldn’t have been left as long as it was, because in the end it hurt our game – this is something that should have been implemented as soon as possible. All major features should be included as early as possible for various reasons, and not including one was an issue.
Keep documentation up-to-date
I didn’t include this in “what went wrong” because I don’t think it hurt our end product, but it would still be good practice to improve our documentation in the future. It was fairly old, and if we’d all been in a horrible accident, nobody would have been able to make the same game based on the documentation we had.
In the end, we managed to create a well-polished and fun game, even if it didn’t have everything we’d wanted, and we’re happy with the end result. We plan to continue similar development methods in the future, with some tweaking to accommodate for what wrong this time – but it feels like we’re closing in on something without too many glaring issues! Thanks for reading.