Who am I?
I’m Nicholas DiMucci. I work as a software engineer for a large company during the day and for the past three years or so, I worked on Demons with Shotguns nights and weekends, forming MindShaft Games along the way.
Demons with Shotguns? What is that?
*insert copied and pasted pitch*
Demons with Shotguns is the ultimate couch fragger gibfest! Armed with a powerful shotgun, bullet deflecting shield and power-up tarot cards, 2 to 4 local players will battle it out to collect each others souls in 9 different competitive game modes across 4 realms & 40 arenas. It’s frantic local multiplayer action at its bloodiest!
Or just watch the release trailer.
And check it out on Steam
Demons with Shotguns was first posted on Steam Greenlight on Janurary 21, 2015, exhibited at PAX East March, 2015, was Greenlit on March 29, 2015, launched as an Early Access title on June 25, 2015 and transitioned to full release on April 25, 2016.
If for some crazy reason you're interested in a more complete "Making Of" story of the game, then you can check out Angels, Devils, and Boomsticks: The Making of Demons with Shotguns by David L. Craddock.
Alright, so why am I reading this?
The hell if I know! I suppose I learned a few things, not only as a developer, but as a "business person" and the business of indie game development. I figured I’d write a proper postmortem, in case anyone cares. You'd be foolish to listen to anything I say, but crazy to ignore it completely.
Ultimately though, I’m writing this as sort of a cautionary tale, and I will be as brutally honest as possible. I’m not here to blame anyone or anything for why I’m not ordering a Tesla and wearing money hats right now. My failures are my own and no one elses. That said, I firmly believe my results are the rule and not the exception.
What did I do right?
The way I architectured the game’s code base. Following a MVC-like pattern, and using dependency injection, I was easily able to separate the game’s logic from the view, which made it dumb easy to add different game modes and features. StrangeIoC is the framework I used and will continue to use for every Unity game I create for the foreseeable future.
I used Unity. Writing engine code takes a lot of time. I almost did go that route, but ultimately decided to leverage already existing tools and technologies to aid me, and that played a huge part in me being able to finish the game. There was nothing planned that would warrant needing to write a custom engine. Yes, this did lead to me wrestling with Unity at times, but overall it was a good decision and I’ll continue to use Unity for the foreseeable future.
Found an artist willing to work for revshare. This was more luck, but I randomly hooked up with a good and dedicated pixel artist that was willing to work for revshare, and he stuck with the game through the very end and we were able to communicate very well over just email.
Hired a well known composer. For the game’s soundtrack, I picked a composer (VHS Glitch) that was not only amazing, but very popular, or at least as popular as I could afford. This doubled as free marketing and exposing the game to even more people than if I went with a cheaper, lesser known composer. If there’s one thing you could never say about the game, it’s that the soundtrack isn’t amazing. Seriously, go give the soundtrack a listen.
Got the Shacknews community involved. As a long time member of the Shacknews Chatty community (over 10 years now), it was the first place I reached out to if I need to hire some help, and it’s never failed to exceed my expectations.
Nailed the game feel. I think I did a good job with the feel of the game. It feels a lot of fun to play and gives nice feedback when appropriate. Player actions affect the environment and are visceral.
Shield mechanic. Early in development, the game was simply just shooting each other. It lacked depth and strategy, and was really only fun for a few minutes before becoming boring. Introducing the mechanic of using a shield to block and deflect shots (potentially back at someone else for a frag) really completed the game’s design. This is where a lot of the fun and depth comes from, learning to think one step ahead of your opponent and find opportune times to shield block.
Small scope. I didn’t go crazy with my ambition and scoped the game fairly small, which ensured I would be able to actually finish it in a somewhat timely manner, all while still creating a game that didn’t make too many compromises.
What did I do wrong?
Didn’t release soon enough. I started developing Demons with Shotguns before the local multiplayer train came through, with titles like TowerFall and Samurai Gunn. When they hit, I was both really upset (because I wasn’t first to market) but also really happy because they were so popular and sort of validated my game idea. However, the train blazed through and the local multiplayer craze really didn’t last that long, and I simply couldn’t develop Demons with Shotguns fast enough to take advantage of it. The same game released even just one year earlier (from the EA release) would have been much, much more successful, I feel.
I released too closely to a competing game in the same genre. I released the Early Access version just a few weeks after Duck Game. Bad idea, since Duck Game was published by Adult Swim Games, which was able to provide better marketing than anything I could compete with, and it had online multiplayer, so DwS became a very difficult sell.
I didn’t design around networking. This goes in hand with my previous points. At the time, I had no intention of adding networking support to the game, and the design of the movement, game feel and weapons reflect that. This is very much a “hindsight 20/20” thing, so I don’t beat myself up about it much, but I still see it as a lesson learned and will design future games with networking in mind. No one cares about just local multiplayer anymore.
I didn’t play enough games. Quite frankly, I just didn’t study enough games, both in the same genre, and overall. I never really designed a game before, and I think it shows in Demons with Shotguns. I learned a lot while developing it, but I feel I could have learned a lot more by studying other games and looking at other games for inspiration for how they solved similar problems.
Exhibited at PAX East. I don’t know if this was a mistake, per se, because it was an awesome experience and I’m glad I did it, but it was a lot of money, for no measurable gain. My original goal for attending was to help boost Demons with Shotguns through the Steam Greenlight process, but the number of votes and comments received after the show probably wasn’t worth it, and I have no way of knowing if the very, very small bump in Greenlight activity during this time helped get the game approved any quicker, or not; the whole Greenlight process is annoyingly opaque. Sure, I got to watch thousands of people play my game, all of which loved the game with several groups of friends coming back for multiple plays, which all ultimately brought home a list of playtesting feedback, but I could have obtained that just as well without having to spend four figures. That money could have been used more wisely. I also couldn’t network much since I was only one of two people manning the booth.
The game was really hard to playtest. It’s not easy developing a game that you can’t play alone. I’d often have to develop an idea and wait weeks before having an opportunity to playtest it with 4 people. You can also imagine how difficult it’s been finding bugs. I ended up mapping the keyboard to control two different sets of characters, which I learned how to control independently with one hand, so I could at the very least battle against myself.
Level design. Some arenas were designed well, some simply aren’t. The fact that I was dead settled on designing 40 arenas total also made quality suffer a bit, I think. I also think I could have done better with the arena interactivity.
Tarot cards don’t communicate their intent clear enough. This is probably the number one feedback I receive about the game. Usually, people don’t know what a particular tarot card is suppose to do. I made attempts to fix this, and did for some cards, but you just need to play the game and experiment to eventually learn what they all do. I oftened wondered why games like Binding of Isaac, what has a near identical type of system, works better, and I think it largely has to do with how the power ups in Isaac (usually) only affect the player's ability to shoot or move, so it's easy to understand what a power up will do (simply shoot and move and see what has changed). Compare this to DwS where tarot cards can change a lot more then just how a player shoots or moves, and can even effect all other players. It's ultimately a lot more confusing.
I should have pushed team members more. I should have been better about asking the game’s artist to rework some stuff. This is nothing against the game’s artist and his abilities. He did a fantastic job and I would have no hesitation with working with him again in the future, but looking back I should have said “this is good, but go back and try it a different way” a lot more. I basically accepted first-pass work far too often and could have done a better job communicating my ideas and vision.
Used Unity lighting. Don’t do this if you’re developing a 2D game. Unity’s lighting system isn’t efficient at all and doesn’t work well in a 2D game. Instead, use a two buffer blend lighting system such as https://github.com/prime31/SpriteLightKit
Designed and developed singleplayer way too late. All during development, I knew I needed to offer some singleplayer action, but I kept bouncing around on what that’d be. It wasn’t till after the Early Access release that I started developing something (which is now the End of Times mode). This is why End of Times is only 5 arenas long, and isn’t a major attraction of the game (the Versus game modes are). As a result, I didn’t feel too comfortable marketing the game with big mention of a singleplayer game mode. If I started developing it much sooner, I could have created more depth (and breadth) for the mode, and it would have been easier to pivot the game away from being a local multiplayer exclusive experience (for reasons mentioned above).
Didn’t understand the importance of proper, actual marketing and advertising. “Build it and they will come” is not a business model to follow. No one cares about your game. You need to make them care. While a great game (note the word great) is needed above all else, knowing how to market and advertise is equally important and something I didn’t know how to do beyond spamming Twitter and cold emailing streamers and press. These tactics rarely work anymore (did they ever?) If you don’t know how to market, and if it’s not something you can afford, then you need to work a publisher, plain and simple.
What I’ll do differently
Don’t be strong headed. While I’ll never claim to know everything, I need to learn more from others. I need to deeply study games and their design, and learn how they work, and how they don’t work. While developing DwS, I mainly made decisions largely based on how it “felt” to the overall system. I need to be better about understanding design decisions and how they impact the game exactly. I also need to keep a constant finger on the pulse of the industry, both from a design and marketing/trend perspective.
I need to take more risks, both in marketing strategy and design. It’s important to have deep knowledge of games, past and present, but my own games need to bring something new in order to make them worth playing. This is very scary because I’ll never know if what I’m doing is right or worth doing, but I need to try out new ideas, and make my mistakes, quickly. Faster iterations of playtesting prototypes.
I need to be more willing to make drastic changes, especially earlier in a game’s development. If something isn’t working, I need to be more willing to rip it out and start again. I was very afraid to do this while developing DwS, mainly in fear that if I kept doing that, I’d never finish, and I still feel there’s truth to that, but sometimes it’s necessary and I need to be willing to take the few steps back. I can’t ignore obvious design flaws.
Don’t shy away from technical challenges. I admit, if I thought something was going to be a big technical challenge, I’d immediately try to find an alternative or shy away from it completely. This was largely because time was a big constraint (I worked on this nights and weekends only) and I wanted to make sure I actually finished the game. I need to try and have better foresight of what these may end up being much earlier in the game’s development so that I can plan and prepare for them properly. Indie games are way too competitive to back down from a challenge.
Get a concept artist involved. Later on in the game’s development I worked with Milan Jaram who created amazing promotional art. This showed me how important and helpful a great concept artist can be in shaping and realizing the game’s initial vision, especially to other team members. It’s hard communicating ideas and having visual pieces to aid in that really helps.
Plan to pitch to a publisher. It’s really hard to get noticed, which is why you need proper marketing and advertising. That’s why I strongly feel that if you’re out to make a good game, then just don’t bother. You need to make a great game that you can pitch to a publisher who can get the game coverage. I’m noticing that any of the “indie” games that get streamer and press coverage are actually backed by some publisher (Devolver Digital, Adult Swim Games, Chucklefish, etc.) It’s seemingly rare that a indie game has a really successful launch without a publisher now. There are exceptions, but we’ve ultimately come back around full circle.
More emphasis on networking. Cold emailing press and streamers doesn’t work anymore, so I need to find other ways of networking. I don’t know how I can do this short of trying to attend as many industry events as I can and befriend people on Twitter, but if I can’t land a deal with a publisher for the next game, then I’m relying solely on word of mouth, which is bad. Again, this is where a publisher can help. They have a strong network of contacts, some of which will only work through them, so you need to leverage it.
I will never edit my own trailer. I’m terrible at it, and a trailer is one of the most important marketing tools for your game. I did my own Greenlight and Early Access trailers, which were mistakes.
Better menus. The game’s menus never sat right with me. I could never get them to a point where I was 100% satisfied. They’re completely functional, but have no pizazz to them. I feel menu’s are important because they are the first thing your player experiences when they pick up your game. Shody menus can leave a bad first impression.
Do bottom-up design. The next game I design, I want to design with focus on the actual components and subsystems first, and then shape them together into a experience. I want to start thinking in less in terms of “let’s have a game where players fight each other with shotguns in gothic arenas!” (top-down) But more in terms of “let’s have a game that rethinks defensive mechanics in a shooter” (bottom-up). There are arguments for the pros and cons of each way of designing, but that’s what I want to try.
Screenshots & Videos Journal<