Note: For anyone new to this blog, this is a postmortem of our first indie title, The Sharpest Blade. It is a puzzle-platformer game; you can read about the release here.
We've given our game, The Sharpest Blade, some time to frolic in the fields, but we believe that now is a good time for a postmortem. Well, I realize a little more might be appended to the game, so it isn't technically “finished,” but I think a postmortem is called for anyway. Especially for all of you looking to really see what happened during development.
Statistics
First, I'd like to provide a few statistics. There have been 102 downloads of the game, with 39 coming from GameJolt, 50 coming from IndieDB, and 13 coming from Itch. Here are the distributions of each platform, by day:
GameJolt
IndieDB
Itch
Each platform had the most downloads on the day of our release; hopefully some of those had to do with the blog post we made on release day. Over time, of course, the downloads declined. There is nothing too special about that. Now, however, we must examine what went right, and what went wrong.
What Went Right
Team Composition
Team composition has a lot to do with how smoothly a project goes. Luckily for us, our team consists of 3 brothers, who share similar goals and, well, understand each other. Enough said.
Project Size
I am actually very pleased in this regard. Every thread or guide regarding breaking into the independent game development industry says to start small. Really small. Given our time frame of about 2 to 3 weeks, I do not think we could have created a better-sized project. The game had a standard control scheme, not too many animations or graphical work, no complicated physics, and a very small story to wrap it up. Coincidentally, we decided to make a puzzle game because it would not require aesthetic beauty or advanced programming or heavy audio demands. The strength and simplicity lay in the level design. In fact, I recommend that anybody starting out try a puzzle game first. I am not saying that making a great puzzle game is easy—it is definitely not. But you can probably come up with something fun amd practical that is easier to create than, say, an advanced battle mechanic for a RPG or a fighter.
Pipeline Management
In order to be efficient with every iteration of asset creation, the pipeline must be understood and managed well. That is, I should be able to create a tile, see it how it performs in the game, and adjust it if need be—all very quickly. In order to get to this stage though, we spent about a day understanding how what how Tiled accepts a tileset, what size I should make each tile, how large the tile animation should be, etc. For example, Joraaver made the tile size a square, 32 pixels by 32 pixels. I had to ensure that each tile I drew stayed within those boundaries. The difficulty lay in the fact that I drew each tile in Flash. Thus, each tile was a vector shape, and when I exported it as a PNG, the raster didn't quite line up with the 32x32 box. Usually, the problem was that the top of the tile did not align with the top of the image. Thus, I created a Photoshop action to do that. With that, I could feed the entire tile animation PNG sequence into Photoshop as a batch process, and then compile a spritesheet of the modified images using ShoeBox. Taking care of this early meant that I could try different animations without wasting time waiting to see how the animation looks on screen. The same goes for sound effects. In an ideal world, however, I wouldn't have to wait for the programmer to implement it. We would have some sort of system developed to just swap in different animations or music without digging into code to do it. This was not necessary this time, however, because the project was small and the programmer was sitting in front of our eyes, for the most part.
“Alpha” Testing
We showed the game to about 10 friends for what could be called “alpha” testing. There were 8 levels then, but we wanted to make sure that others thought the concept was fun before actually creating the rest of the game. For larger products, alpha-testers who are not your friends are important. For this scale, though, we got a preliminary idea of how players would navigate the empty space before them, how quickly they would learn that they could change their midair direction, and how well they caught on to patterns or implemented the title in the level. It was interesting to note that those not new to gaming immediately switched their directions when trying to find new tiles and were very touchy with the keys. However, others discovered this ability at the K.I.S.S level, where it was necessary to reverse your direction to get past the level.
What Went Wrong
Marketing Time
Ah, marketing--part of the reason this blog exists. I am not saying that we did not approach marketing well. We spread the word as best we could, reached out to friends and family, and networked along the way. I think we did a fairly good job, given that it was not good enough to send to send to big gaming sites (although a web version of the game may have helped). This section is about underestimating the time it took to do all the marketing and finish, such as writing the blog posts, talking to friends, and getting all 3 distribution platforms set up. All the little things add up. Getting screenshots, writing an official game description, designing the Itch game page—these are things that I was not expecting to spend too much time on, but did. Now that I look back, I would say that the finishing touches, as far as getting the game distributable, should have had a whole day assigned to it. Making blog posts like this one also took more time than I thought because spelling and grammar should all be correct, and just writing a cohesive collection of thoughts is sometimes harder than one may imagine.
Level Design and Final Playtesting
These two are listed together because I believe they are inherently related, at least in our case. We released on a Sunday. The day before that, Saturday, we set up the distribution pages. We also designed the last 12 levels on Saturday. That was a mistake. The levels should have been thought through much earlier in order to thoroughly playtest them, adjust them, and so forth. Instead, what happened is that the initial 8 levels were well thought through and tested, and the other 12 were only seen by 1 tester. Also, a very major issue popped up during that one tester's experience that put us back by almost half a day. What should have been happening on Saturday was some fine tuning and wrapping up, but what actually happened was entirely different. We ended up having some levels where jumping maniacally was enough to get past, which was something we wanted to avoid entirely. Never underestimate the power of playtesting. The game is made to be played, so if you don't test how well it plays, then you have very little idea of knowing how players will respond to it.
Remarks about the Game
I am pleased with the game's response as of now. It was a small project with a small following, so I wasn't expecting a huge number of downloads. The comments left behind by players were all positive, which was nice, and currently the game has a rating of 4.3/5 on GameJolt. I want to thank all those who played the game, especially those who followed the blog to the game's release. It was a pleasure documenting the development; hopefully it helped those of you looking to make your own games.
Now, is the game dead? I don't think so, but I can't be sure. A patch or two might be released, but I see some real potential for a level editor. I'm imagining a sort of database of levels, all player created, with the titles being facts, phrases, or wisdom of any sort. It could be in any language too, which would be pretty cool. Of course, we would need the time to create that, which I'm not sure school will allow us, but I don't think it is impossible. If you like the idea of a community-created collection of levels to play, built with a level editor, let us know in the comments!
Conclusion
I hope you gleaned some useful information from this analysis of our development over the past couple of weeks. Very soon Joraaver will make a post about the “major issue” we ran into, and what we did to solve it. Since it was a programming issue, prepare for some heavy, yet interesting, analysis!