Guild of Dungeoneering is a game, with board game and RPG roots, that came out recently. It was created by Colm Larkin (initially) and it's worth taking a look at, to learn how to finish a game. The game is a good size for a lone dev to create in a reasonable amount of time with a reasonable expectation of it doing well commercially. It's also rather unique in that the game creators have kindly shared a lot of the process through their blog, forum posts, devs logs and interviews.
Note: For brevity I'll often shorten Guild of Dungeoneering to GoD.
What is Guild of Dungeoneering?
Guild of Dungeoneering is a turned-based game where you play special cards to create a dungeon for an adventurer to explore. You don't have any direct control over the adventurers instead you indirectly influence their actions by the order you play your cards.
Why Look At It?
One guy was able to create an interesting gameplay loop and then build that out into a fully featured commercial indie game. The steps taken to produce this game are achievable for most developers; maybe your game won't have such great commercial success but you can definitely finish a similar game to a similar standard!
It's worth asking questions like "How did this game come about?", "Why did the game creators get the scope correct? How do you estimate a games scope?" and "What general lessons can I take away from this game's development process to apply to my own projects".
It came out yesterday on Steam and sat in the top 10 all day.
At the time of writing Steam Spy was reporting 18,756 sales and Colm suggests sales might be twice that.
We're more than 2x what SteamSpy is reporting there.
The sale price ranges from ~$10 - $15 so given a few more days, one might hazard a guess of it grossing about 1/2 a million dollars. (Of course the net will be rather less; Steam has a 30% cut, there's a publisher, tax, team member percentages etc. But all that considered it's undeniably a massive success).
Exploring the game's development is going to teach us some tricks that we can apply to our own game projects. By happy chance the game has plenty of traditional role-playing mechanics which is the type of the game this site is all about!
Who Is Behind It?
This initial prototype of the game was created in Ireland by Colm Larkin. To make the final game Fred Mangan came to assist with art. Steven Gregan did the music. Owen Canavan came on as the second programmer. Oliver Garland assisted with game design.
The game was ultimately published by Versus Evil.
Colm has a blog and if you go all the way to the first post back in 2008 the goals for his game-making venture are clearly laid out.
We're approaching this as a business venture, not just a hobby!
To get stuff done and completed, you need a certain mindset and viewing your hobby as a business demonstrates a desire to finish and release. The blog shows from the beginning games were going to be a fun hobby but a hobby that produced results.
The blog then documents a few ambitious project ideas; an online multiplayer tactical turned based RPG (A lot of us have had similar ideas to this!). There's a realisation this is a probably a little ambitious to begin with so the first project is single-player tactical turned based RPG. Work happens and in 2010 we see progress, as shown below, but there's obviously a long road to travel.
It's almost a rite of passage to start an ambitious game project only be forced to abandon it when it becomes apparent just how much work is required to finish. It becomes frustrating to work on something that you know is perhaps years away from release. You have to scope down.
How best to scope down? Do game jams. A game jam generally works like this; a weekend or week is chosen ahead of time, developers around the world clear their calendars for those dates, nearer the time a game theme is chosen and developers try to create a full game in the allotted time. There's judging afterwards and sometimes prizes but the real value is that developers have the perfect environment to create something, there's an external deadline, limited time means there's no time to worry about perfectionism or premature optimization.
Colm blogs about participating in some game jams before moving on to try One Game a Month.
Colm's first go for his game a month is Dungeon Delver; the very first prototype of the game that will become Guild of Dungeoneering. So that was a good first start!
1GAM is a challenge started by Christer Kaitila for developers to complete a video game every month for an entire year! He based this on a New Years Resolution in an attempt to avoid overly ambitious games that never get finished. The original announcement blog post is here.
Why make one game a month:
- Get into the practice of finishing games
- Limited Time is a feature!
- Forced to avoid premature optimization (or any optimization)
- Avoid Perfectionism (and the Babbage Trap)
- Less time is spent on code that gets thrown away
- Make stuff. Lots of stuff!
- Build up a code base.
You're bad at guessing what needs to be done. That's why you've never finished anything. Making one game month will make you a better developer.
Finishing is the most important skill; it's the only way people get to experience what you've created. If no one ever plays what you make, does it really matter you made anything at all?
Take Away 1: Finish Small Projects
Things changed as I was actually finishing some small games. This gave me the self belief to try again with a 'real' game. When it started getting traction [...] I decided to 'go for it'. My tip for original ideas is to take part in some game jams. The theme usually means you aren't starting with a blank canvas, which actually makes it EASIER to be creative!
Have you ever finished a game on your own? Or do the ghosts of projects past line up behind you, wailing out to be finished? It's ok. It's not unusual. No one knows how to properly estimate the scope of a game but we have a solution Game Jams and 1GAM. Do these and even then scope-down. Going to try and do a game a month? Start with a game you think you could finish in a weekend. It gives you leeway if it turns out you underestimated the project, if not then you have more time for polish and new features!
Remember Guild of Dungeoneering started as a 1GAM game. Do the 1GAM and you never know, it might be something you end up releasing!
What Happened After Dungeon Delver?
The idea of 1GAM is to create a game a month. After Dungeon Delver the next game Colm made was Captains of Industry a physical card game. The idea came from the theme picked for that month; industry. Captains of Industry is a deck game, each person gets a hand of cards, there are turns and people can play cards. The first version of the game seems to have come together pretty quickly.
Captains of Industry was a physical game. Physical prototypes work very well for certain types of games (card games, board games etc). Physical games let you refine rules quickly through play-testing with other people. Physical prototypes naturally focus and simplify a game; it has to simple enough for humans to play, anything superfluous is a distraction. You're not in danger of spending 2 months on a kick-ass particle effect engine with a physical prototype; the game-loop is the only thing that matters.
Another advantage of physical prototyping is people are familiar with the concepts and tools. Cards, dice, game turns are things people already understand, there's an immediate familiarity that digital video games can lack.
Captains of Industry is a complete fun looking game and I'm sure some of the design refinements were lessons that Colm was able to apply to future games, perhaps even GoD.
Take Away 2: If You Can, Use a Physical Prototype
Physical prototypes are excellent for certain types of game, mainly those with physical counterparts; board and card games. Those types of games that can be physically prototyped happen to be the type of game a lone developer can develop in a week or two.
Community and Dungeoneering
Guild of Dungeoneering was shared with the game community extremely early. You can play the first 1GAM prototype on Colm's site here. He attended local dev meet-ups where developers played each games and swapped feedback and tips. He also set up a devblog on TIGSource.
My approach from the beginning was to share EVERYTHING. Not only that but I decided to have a playable version of the game on my site.
Don't have a meet-up in your area? Here's another interesting quote from the Gambrinous site
Not only that – but I've helped set up a meetup group for fellow 1GAM enthusiasts in Dublin, Ireland.
As Hannibal is reputed to have said
"Aut inveniam viam aut faciam." / "I shall either find a way or make one."
If you help set up a community you'll benefit from network effects and people will generally assume you're competent. This helps when you need to find people to help out! (Or people want you to help out with their projects.)
There's a fear to sharing your stuff. What if people hate it? What if everyone says you're a talentless hack and your game is an unoriginal clone of already crappy game. This almost certainly won't happen and if it does - who cares? It's just a load of disgruntled youtube commenter types. Anyone with any kind of public profile attracts a few haters.
Do nothing, say nothing, and be nothing, and you'll never be criticized. — Elbert Hubbard
Jump in. Get your stuff out early, don't hide it away until it's "ready".
Afraid if you share your work, you'll be tied to it and that people will demand you complete it? Can Game of Thrones writer George R. R. Martin say he's had enough of the series and decide not to write the last book. Yes! He can. Just because there's social pressure doesn't mean you have to cave to it. And remember if you're doing some based on one game a month your scope is already nicely limited. It won't take years to finish your game.
Make it easy for people to give you feedback. You don't have to (and shouldn't) implement every suggestion but if you hear something a lot then it suggests there's friction in your game experience that might be worth another look.
Take Away 3: Share Early.
Share something playable as early as possible. This helps build interest and creates feedback you can use to guide the development of your project. Every piece of feedback you get helps you push your project so it's trending toward fun.
You don't have to share publicly, you can share with friends or other devs at meetups.
The more people know about your game, the greater the external pressure to finish it :). A following also gives you confidence your game has market appeal and down the line makes it easier to get a publisher, if you so desire.
The Inspiration Behind Dungeoneering
The initial concept for GoD came from the board game Dungeon Quest.
After a bit of brainstorming the game I decided to make was 'Dungeon Delver' – A game where you explore a dungeon by laying out new room tiles one at a time. A bit like a 1 player version of the boardgame DungeonQuest.
In DungeonQuest players try to locate a treasure room, grab the treasure and escape the dungeon. Moveable tiles represent pieces of the dungeon and the dungeon is revealed as the game is played. Here's the blurb from box.
In DungeonQuest, players must guide their heroes through the twisting halls of Dragonfire Dungeon in pursuit of unimaginable riches hoarded by the Dragonlord Kalladra. Whoever can amass the most wealth and make it out of the dungeon before the closing of the doors seals their doom will emerge victorious.
While many similar games rely on a player to control the machinations of the dungeon, DungeonQuest is unique in that the dungeon essentially runs itself. No one at the table knows what lies around the corner, creating a new play experience every time. Additionally, DungeonQuest also includes rules for solo play, so you can even challenge Kalladra’s keep on your own!
It's a great idea to use a board game or existing game as a starting point when making your own one-game-a-month. That way you can jump right in and start implementing it without spending too much time deciding exactly what you should be doing.
Taking elements of a board game into a video game changes things, the computer can handle a lot more behind the scenes and new ideas will naturally occur. Don't worry too much about being original it will happen anyway.
Take Away 4: Don't Be Original
To grab you attention I phrased this more forcefully than I perhaps intend! For a game with a small scope, it's best to use proven ideas / mechanics and add your own twist. Boardgames are a rich seam to mine for mechanics and ideas. They're easy to physically prototype, they're relatively easy to implement in code and the core game loop already exists for you to build out from.
The Final Push
For GoD, after developing the core game, the hard work began. You can see from the TIGSoure devblog that Colm habitually worked on the game, putting in the effort to bring it to a releasable state. Along the way he brought in outside help to assist in areas where wasn't as proficient; art, sound etc. But it's best to bring in this kind of help after a few iterations of the playable game have been released and a final goal is in sight. Later on, a publisher was engaged which certainly gave a lot external pressure to pull the game over the finish line. Marking a release date with a publisher helps cut off feature creep and focuses work on the most essential items.
Here's hoping you can apply these takeaways to your own projects!