And now, I would like to direct your attention to me doing something incredibly ridiculous. Yes, yes, the online Flash version of Forge War might be old news to some people, but the more heavily I get into this whole board game publishing business, I feel more and more overwhelmed at how much stuff needs to get done in terms of marketing and planning and whatnot, and when I pile on the development of an electronic game to that, well, sometimes it feels like I am trying to do the job of at least 3 people.
Seriously, it’s just me here, talking to manufacturers, establishing an online presence, play-testing and tweaking the game, communicating with artists and designers – and writing thousands and thousands of lines of code. It’s silly, and the bottom line is that I have no idea whether all the time and effort put into coding is going to have any positive effect on the sales of the game.
If I put all that effort into marketing the game in other ways, would that pay off more? There’s no real way to know.
Here is what I do know though: people want to see whether a game is good and enjoyable before they buy it, and normally that is done in Kickstarters by sending a prototype out to reviewers and then hoping these reviewers have the time to make some sort of video of the game (ideally) or some sort of article. The problem is that 90-95% of these reviews are just game descriptions or videos of the reviewer explaining how to play the game, and then you might get a paragraph or 1 minute of video at the end where some small amount of opinion comes out. And it’s always positive.
I’ve learned to take all this business with a grain of salt, because seriously, who is going to bash a Kickstarter game? It’s just sort of mean-spirited.
But what else I know is that different people like different games. Forge War is not for everybody, just as Dungeon Roll or Agricola aren’t for everybody. People figure out if a game is something they’d enjoy by experiencing the game as fully as possible (which is maybe why these “reviews” spend so much time on objective overviews). But this results in sort of a consumer double-think, where people are clamoring for reviews, when what they really need to make their decision is just to experience the game. Self-shot game-play videos are great, but a lot of backers still want those third-party videos as if the campaign creator is trying to fool them in some way.
So I’ve gone out on a limb and decided to take a completely different approach by letting people experience the game as closely as possible through actually playing the game online. Of course there will be game-play videos for people more interested in the aesthetics and 3rd party reviews because, well, it’s still necessary, but I’m hoping that sitting down and actually experiencing the mechanics will help people make a solid decision about whether this is something they want to actually buy.
But aren’t I giving away the milk for free? Absolutely not. While someone can get a feel for the mechanics by playing the game online, that is just a facsimile of a tabletop experience. We play board games instead of video games because we want that tactile, social experience of sitting around the table with a group of friends moving wooden pieces on a board. The point is to get a first-hand feel of the mechanics, but I don’t think a screen can ever capture a board game’s essence. It can just make you think, “Oh, the way this game works is pretty great – I think if I bring it to my next game night (or a game night a few months down the road, as the case may be…), we could have a really fun time with it.”
My concern then, is to at least try and match the Forge War experience as closely as possible with the online version – something that can communicate the mechanics clearly. But, of course, there are a number of obstacles to that. Writing code is not like writing board game mechanics in the same way that human intelligence cannot be reproduced through programming. It may take you 15 minutes to explain the rules of a game to a person, but it will take many, many months to communicate those same rules to a computer through code.
And then there are bugs and miscommunications, and all of it is just a very long, involved process that normally requires an entire team of artists, designers and testers. Testers, just like with board games, are extremely important because there is no way for one person to glean every tiny little thing wrong with their product. What if I click on the merchant, then open the quest tab and then hit cancel? These are things that need to be addressed because when that product goes live, you want your audience to have the most stream-lined experience possible, and you’re probably only going to get one opportunity to do so. If the program crashes, they’ll probably just go do something else and forget about you.
So I guess I sort of feel sometimes like I am jumping off a cliff, and I’ve gotta sew myself a parachute on the way down. Nobody’s ever tried it before, and it could work, but it is going to require a lot of effort and there are a load of different things that could go wrong.
So where exactly am I with coding? Well, I am debugging the “quest management” portion of the quest phase right now. After that is dispersing quest rewards, then turn transitions and stage transitions. I’m hoping to have some sort of fully working code by the end of the month, but, like I said, it may take more time and more people to get that code free of bugs.
How exactly the online version fits into my time table will be covered in part 4, but next time I’m going to talk about all the things I never realized needed to be done before researching Kickstarter projects online.
Would you like to help with testing the code? Please let me know in the comments or an e-mail!