Wednesday, August 17, 2016

Procedurally Assisted Generation

Ever since my early experiments with Deity Quest, I've done a lot of work and research on procedural generation and am quite proud of the results in I Can't Escape: Darkness, which is able to generate a different layout that is still solvable every time you start a new game. However, I've come to realize a few things about procedural generation, which is why I will NOT be using traditional procedural generation in my next game.

Procedural Generation

At a glance, procedural generation sounds amazing. Instead of having to painstakingly hand-craft levels, an algorithm can generate near infinite levels and provide variety and replayability for players. However, while procedural generation can create near infinite levels, how different are those levels from one another?

Let's take No Man's Sky as an example for a moment, as everyone's talking about it anyways. There is no denying that all of the planets and animals are different, and that it is a marvel in terms of algorithms and technology. However, there are a ton of angry fans who find the game boring, stating that they are doing the same things at "basically" the same planets, over and over again.

Screenshot from No Man's Sky
So what's going on here? The key point is that even though there are near infinite distinct looking planets, if what you do on one planet is essentially the same as what you do on other planets, then in terms of gameplay, they are the same.

Here's the key point:
Procedural generation is great at creating variations on content, but terrible at creating new content.

You might ask, how is adding new levels and new planets not adding new content?
That's because I distinguish between content and assets. Lets say you make a game with infinite levels, where each level is the same except that the enemy model is replaced with a different model. This game would have infinite assets, as it would have infinite enemy models. However, no matter how different or interesting those enemy models are, isn't the game still the same level over and over again? I would call this game having only one level of actual content.

The Legend of Zelda's hand-crafted world
Hand-crafted levels add content because they tend to add new puzzles, new gameplay mechanics, and/or advance the plot. Even new hand-crafted enemy types add content if those enemy types have different attacks and movement patterns that have to be handled (by players) in different ways. It turns out to be very very difficult to get a procedural generation algorithm to produce actual new content (most experiments that attempt to do so are more in the realm of machine learning than procedural generation).

Lets go back to I Can't Escape: Darkness for a moment. As anyone who has played the game many times has probably figured out, while the actual paths you might take between rooms to get items are different every time, the general progression - the flow - of what you do is the same. For example, you have to collect the pick axe to break through walls before you can get the key to the cat door. While the details of the game are certainly different every time, in terms of the actual content, I would argue that it is actually the same every time (welp, there goes one of our major selling points). None of the gameplay mechanics or major points of progression change. And this content of the game, I designed by hand.

Screenshot of the map from I Can't Escape: Darkness

Procedurally Assisted Generation

So, with the above said, procedural generation doesn't sound as amazing as it did before. What's the point of having infinite planets if there's not something interesting and unique about each one? Might as well go back to doing everything by hand, right?

Well, procedural generation is a tool. And even if it isn't the holy grail that makes entire games for you, it is still a useful tool. While the actual content of the game still has to be created by hand, that doesn't mean procedural generation can't help out with some of the details and speed up the process of level design. And that's where my idea of Procedurally Assisted Generation came from.

Procedurally Assisted Generation is using procedural generation algorithms to take your basic content and turn it into fully detailed levels.
It is a way to speed up level creation by handling the tasks of level design that aren't very important to the core gameplay anyways.

Procedurally generated vegetation from Onyx Computing
Already, there are simple forms of procedurally assisted generation in common use. If you need to add a forest around your city, you don't model and place each tree. You have an algorithm place several tree models automatically around your city for you (the algorithm might even generate the tree models for you). Having an algorithm handle these kinds of details for you can save a lot of time.

Some of the things Procedurally Assisted Generation could do for you are as follows:
  • Add details to your scenes - trees, brush, rocks, doodads, decals (like scratches on walls). Procedural generation is a great way to add variety to your scenes without actually changing the core layout.
  • Automatically place areas - lets say you have a graph of areas and connections between those areas. Procedural generation can easily place those areas and paths between them, while adding obstacles to block players from going directly between areas that don't have connections between them.
  • Automatically generate layouts - if you want a dungeon, you could have a procedural generation algorithm generate the layout for you, and then add the puzzles and boss encounters by hand so that it is interesting and unique from other dungeons with generated layouts. If you don't care about the exact shape an area takes, this can save a lot of time.
  • Automatically generate models/variations - there are lots of algorithms out there for generating trees, buildings and making variations of other models. This can be a way to add variety to the objects and props you add to the game without having to hand-craft each one.
Example flowchart for areas in a new game I'm developing.
This is how I plan to use procedural generation in my next games going forward. The core progression and content of the game will ultimately need to be created by hand, to achieve design that is intelligent, original, and keeps the flow and player experience in mind. But, I can make a few low-detail areas by hand, and by using a progression graph, I can then string those areas together and add details to them. This method will save a lot of development time, while still ensuring that the game is exciting and that the progression and overall game structure are just as strong as if the entire game was hand crafted.

Tuesday, January 12, 2016

Tip: Don't be afraid to cut features!

We're all familiar with feature bloat. You think of a great new idea that just has to be added. Or after receiving feedback, you come up with an over-complicated way to resolve issues mentioned. The fact of the matter is, games tend to get bigger over time.

The worst scenario: you start developing a new feature, you put work into it, and then you realize that finishing the feature will be a LOT more work than you expected. You feel stuck because you don't want to waste the work you've already done, but also don't feel capable of completing everything you added.

It's easy for this to happen - and all too easy to add new features. What's a lot harder is really looking at the design and deciding where and when it is time to cut something. You worry about crippling the design, and if the rest of the systems will work properly without those elements. But it can be done, and can actually make the game more streamlined (and probably better).

I recently made a tough feature cut - I cut out a component system which allowed customization and interesting design choices for ships in a fleet-management game. We had a decent amount of progress on the system, but I realized that it would end up adding a lot of complexity to other systems and the user interface. It was definitely an interesting feature - but at the end of the day the game was about managing a fleet of ships - not micromanaging individual ships. Having one fixed action (build, repair, attack, etc) and fixed capabilities per ship is not only a lot easier to code, but also a lot clearer for the player, who doesn't have time for much micromanagement.

Wait... I have to keep track of all of these components for every ship?!?

Keeping in mind what the core of the game actually is, and how different features add and subtract to that gameplay, will definitely help curb feature bloat and keep your project focused. However, we all make mistakes, and when you realize you've made a mistake, know that it's okay to make a cut even if it means trashing work that you (and other team members) have worked on. It may end up saving you a lot in the long run (and make the game better as a nice side effect).

Tuesday, December 22, 2015

Between Success and Failure - I Can't Escape: Darkness

Today, I logged into Steam and noticed that sales for my latest game, I Can't Escape: Darkness, reached 666. A very auspicious number for a horror game, and it made me laugh. However, it also made me remember what my original goals for the game were, and how the reality didn't quite live up to my expectations. After thinking about what my expectations were, and how I defined success and failure, I decided to write my first Post-Mortem - both to put these thoughts down, and to share my conclusions with other game developers.

History
But, first a little about my studio, Fancy Fish Games. We've released three commercial games on Steam, and six free games before that (four of which were for One Game A Month). Fancy Fish Games has been around for three years (although I've been making games since I was in middle school), and consists of around five people who work part time for nothing but revenue share (kudos to them giving up their free time so that we can make our dreams reality).

The Beginning
I Can't Escape: Darkness was designed as the sequel, or as I like to think of it, the full version of I Can't Escape, our January “One Game A Month” back in 2013. I Can’t Escape was a simple atmospheric horror game in which the player is trapped in a seemingly (and in fact, literally) endless dungeon where escape consistently eludes them. Thanks to several youtubers and streamers (including Markiplier), I Can't Escape was a great success - where by success, I mean that over 250,000 people played the game and a lot of people commented and seemed to enjoy it (we didn't make a dime on the game).


The sequel was meant to take the simple idea of I Can't Escape, and make a fully fleshed out game without destroying what made the original interesting. And in that respect, I think the sequel was a success - there are certainly flaws and nit-picks that I could talk about, but the game does draw you in and creates a suspenseful, eerie atmosphere without relying on jump scares (which was part of my goal with the original). The sequel was also fleshed out with a lot new features, including overall progression, events, combat and a story.

Development
Development for I Can't Escape: Darkness took a little over a year. The core team was only three people - myself working on the code, Chase Bethea working on music and sound effects (and he did some awesome experiments with dynamic music for this game), and Matthew Poppe working on art and animations. My original plan was for the game to take four months - which as a rule of thumb I doubled to eight months, which wasn't a terrible estimate for the total development time. Working with collaborators over the internet part time is always a little unpredictable - but I had worked with both Matt and Chase before and trusted them a lot - and they didn't let me down.

The development time broke down something like this:
  • Engine Development - First Month: August 2014. Yes, I developed the engine for the game from scratch. You might think I'm crazy, or it's impossible to make an engine in one month, but I wasn't making a general purpose engine. I was modifying some old maze rendering code and developing the lighting algorithms specifically tailored for I Can't Escape: Darkness and it's gameplay needs. I've had a lot of experience developing game engines, so it really wasn't as difficult as it sounds.
    ICEDfinal.png
  • Minimum Viable Product (MVP) - September 2014. The minimum viable product included the basic gameplay mechanics - movement, exploration, items and combat. Again, you might be thinking one month is pretty short, but remember that the entire original game only took one month. At this point we launched the greenlight page with screenshots and videos.
  • Feature Complete - January 2015. This is the milestone I was estimating when I said the game would take four months. I then double that number because I know from experience that feature complete is really only the halfway point. And while it took six months to get here instead of four, it's interesting to note that it was the halfway point in development for us.
    escape.gif
    Now you might be wondering, if the engine work only took one month, and the MVP only took one month, why did it take four months to get to feature complete? The answer is that even though the MVP has the core elements of game play, it is missing content (including the various event areas and puzzles), UI, and balancing. These add up to a lot of work, and they turn what is more like a prototype into an actual game. We also took about a month off during this time between holidays, a short side project (ADventureLib) and getting Deity Quest on Steam (I launched the game May 2014, thinking it’d never get greenlit, but to my surprise it did in late december).
  • Alpha Test - February 2015. After the game was feature complete, we had to playtest, debug, and finish all the higher priority art and music assets. Then we released the game to a closed alpha to get outside feedback for the first time. I wanted to make sure the game was stable and not missing important assets so that the testers could give more focused feedback on the pacing and gameplay itself. It's also interesting to note that the game was greenlit on Steam at this point, after five months.
  • Beta Test - June 2015. We got a lot of good feedback from the Alpha Test, and there were many pacing and balancing problems we had to address (damn rats!). There were also some last minute features that we decided to add - while none of them were big, they do add up *cough*feature bloat*cough*. However, the difference between the alpha and beta test was pretty incredible. The game drew people in a lot more, the average play length quadrupled, and people began wondering about the story. One interesting thing to note here is that as you get closer to the end of development, it seems like you’re moving slower as there aren’t as many spectacular changes, but those four months of work weren’t wasted - as is clear from the difference in the responses from the alpha and beta tests.
    tutorial.png
  • Second Beta Test - July 2015. After another round of tweaks and improvements, plus cross compiling the game to Mac and Linux, we started a second round of beta testing. Meanwhile, the marketing campaign run by Justin Whirledge went into high gear at this point, with gameplay trailers released every other week.
  • Steam Beta Test - August 2015. At this point, the game was mostly done other than the final tweaks and squashing the last bugs. But there was plenty to do as we prepared to release on steam. We had to set up the store page, get the last of the asset changes in (including assets for trading cards and achievements), integrate the Steam API, get the game translated (we released in English, Spanish, Russian and German - friends, fans, and beta testers offered to translate the game for free!). Finally, near the end of August, the store page was live, and the release date of September 17th was announced. We also did a quick beta test on steam to make sure everything was working with the Steam API and the last of the changes.
  • Release! - September 17th, 2015. After a year and nearly two months, doing some final playtests, tweaks, and a marketing push (including early review copies and attack of the gifs), the game was released. It took nearly six months longer than we expected, and it was starting to feel like endless development hell (we probably could have tweaked the balance and pacing indefinitely - getting a procedurally generated game to parcel out events and progression at an interesting pace is a lot harder than it sounds), but we did it!


Three months later, we've had 666 sales, mostly positive feedback on steam, mostly negative feedback from press, some great videos and lets plays, and one amazing fan-written guide. Was the game a success? How do you measure success?

What is Success - Money?
If success is money, or even making enough to work full time on our next game, we definitely failed. The game retailed for $11.99 on steam, so 666 sales is certainly not nothing. But, even underestimating how much time we all spent on the project, we still made less than $3 an hour (after steam cuts and dividing the revenue among the team). So, it wasn't like we made no money, and it was an awesome end of year bonus for us, but it certainly won’t let us quit our day jobs.

For those of you who like charts and graphs, here's I Can't Escape: Darkness’ sales graph (with the labels removed as we're not supposed to release exact numbers). sales.png
It follows the pretty standard long tail with spikes pattern - where sales drop off very quickly after launch, but then there are spikes from sales and updates. The first big spike was our first major update (with several new secrets and improvements). The second, biggest spike was the Halloween sale including another, smaller update. The third wobbly bump of elevated sales was the Thanksgiving sale - which was not thematically fitting like the Halloween sale, didn’t include an update, and was a smaller sale, so was a lot weaker.

But let's face it - if making money was most important to us, we wouldn't be making games. There are plenty of better paying jobs we could get with our skills. So, there are other definitions of success to consider...

What is Success - Fame?
So, if we're not getting much money, how about fame - people always seem to want money and fame. Well, we certainly aren't famous, and I doubt most of you knew what I Can't Escape: Darkness was when you clicked the link. Additionally, critic reviews are almost unanimously terrible with our metacritic score at 40/100. But, on the other side of the coin, our steam reviews are 91% positive with 23 reviews, and the majority of let’s players who played seemed to really enjoy the game.
But if fame is our goal, again, we failed. Even the original didn't make us famous, and that had 250,000 plays, a lot more than 666 sales. However, while it would be nice for more people to know who Fancy Fish Games was and follow our games, we don't really do it for the fame either.

What is Success - Making a Fun Game?
At the end of the day - we make games because we want to make something creative and fun - something that we enjoy playing, and we want others to enjoy as well. And while we might not have a lot of sales, there are a lot of people who really love the game. A group of players even got together and collaborated notes to create this impressively comprehensive guide to the game.

And this is where I can say I Can't Escape: Darkness was a resounding success - and can feel good about our year long development. We might not be rich or famous, but we made something interesting that a lot of people enjoyed, and we can feel proud about that. Sure - the game isn't perfect, and you only have to read one of the critic reviews to see them point out all of the flaws, but despite that there is definitely a loyal fan base. thankyou.png
As a side note, I'll point out that even the critics who hated the game, perhaps grudgingly, had to admit that the game had a good atmosphere - which was what we set out to create.

Final Notes
There are a lot of post-mortems that talk about how successful and unsuccessful their games are only in the financial sense. However, I feel like it’s also important to think about what success means to you - as even a complete flop that no one plays could be a success if you felt it was a valuable learning experience or you gained one die hard fan who will continue to follow your games - and perhaps even beta test them or offer other help - as you continue on your game development path. This was true for Deus Shift, my very first publicly released game, which didn’t make much of a splash but gained one loyal fan who ended up both playtesting I Can’t Escape: Darkness and translating it to Russian.

Oh, and as I finally finished this post mortem and posted it, the sales have gone up to 674! The launch isn't the end, and people will continue to play and enjoy your games even years after their release! That’s quite a special feeling.

Friday, September 25, 2015

After the Darkness

It's been a while since my last blog post, and that's because I've been pushing myself hard. After the release of our first commercial game, Deity Quest, in 2014, we've been moving full steam ahead releasing our next two commercial projects, ADventure Lib and I Can't Escape: Darkness. I've also had to balance that with freelance work on the side.

So, you might be wondering how things are going with Fancy Fish Games? It's definitely been a roller-coaster of ups and downs, and despite having released two new commercial games, we're still in as uncertain of a position as we were in the last blog post. Financially, we've been making enough in sales to cover costs and distribute some well deserved revenue share to all team members. However, we're no closer to being the full time studio we dream of, and I won't even mention how low our hourly rate comes out to be (based on hours spent and revenue received). A huge thank you to all team members for sticking with me despite that!

Projects Completed



Our latest release, I Can't Escape: Darkness, has been doing decently. Financially, it's not an out of the park success, but it's currently our best seller and will surpass my pessimistic minimum revenue (if not my optimistic maximum). Additionally, 91% of the game's Steam reviews are positive, and fans seem to really like the game, which in my book makes a successful game even if it's not a financial success. Someone even posted this discussion which really made me feel like the game was worth it despite some very uncomplimentary press reviews.

We've definitely gotten a lot of negative press reviews, which is strange given how much the players seem to love the game. It's definitely been affecting my confidence, with reviews ranging from simply negative to downright nasty (not to say that there aren't positive reviews, but the majority of them are negative). I think part of the problem with the press reviews is that they are playing specifically to review the game, and so are not really letting themselves get immersed. Several of the reviews even mention how they liked the atmosphere of the game (which is definitely the core), but then give a bad score because of things they didn't like that were more secondary.

Honestly it's more important that players like the game than press - but perhaps more players would know about the game if we had some strong reviews. Maybe it's just a bad idea to put a number on something as subjective as a game in the first place?

http://adventurelib.com/

ADventure Lib, our small side project, was also greenlit and released on steam this year. After getting greenlit, we polished and finished up the game, and then added voice acting (which I believe adds a lot of hilarity). Since it was a small project and the game only takes about a half hour to beat, we released it for $2 on Steam - which got it a lot of players. It didn't do great financially, but many people had tons of fun with the game and even took advantage of the workshop to add their own personalized objects. For a small side project, that is about as much of a success as I could hope for, and I am definitely thinking about doing the campaign editor update so players can add their own stories and campaigns.

Projects Dropped



Some of you might have seen this coming, given the continued delays, but Havencall has been put on indefinite hold. The design still needs some work and has some rough edges, and the project is simply too big for a single artist to complete. One day, when we're a full time studio and have a budget, we hope to come back and finish this game, but until then, there are other game designs that we want to work on that are more reasonable given our team and skillset. If you want to read more about this decision, check out this IndieDB Aritcle.

What's Next?


That's an interesting question for us. At some lower moments recently, I was considering taking time off game dev and working only on projects that actually paid the bills. However, fans and friends have made it clear to me that I still do want to make games, and still love it when people enjoy playing my games. I have to finish up some other work this month, but I already have several game design documents prepared and will hopefully start one come October. I haven't decided exactly which game I will be making next, but it will likely be one of the most ambitious I've done yet. While it might not be the smartest idea to work on a big project when we're still trying to find a footing, I want to make something special, something that will stand out as a great game even among all the other great indie games that are constantly releasing. We may not be able to work full time, but we have a lot of skill and as long as we are cognizant of our strengths and weaknesses as a team when planning our projects, I think a larger project is definitely doable.

Look forward to another blog post announcing what our next game is!

Friday, January 2, 2015

A Year In Review - 2014

It's tough to believe it's already 2015! It's been a crazy year, with good times, tough times, and as always new projects. I went from overly optimistic at the end of 2013, to feeling like a complete failure in the middle of last year, and now I don't know what's going to happen, but that's what will make 2015 so exciting and is why I think looking back on this past year is a good idea.

Projects Completed in 2014

Deity Quest, my first commercial game, was released to very mixed reviews. I was definitely experimenting with interesting gameplay mechanics for this game, and sometimes they worked brilliantly and were a lot of fun. However, the game definitely has kinks - partly because the design was an experiment, and partly because I certainly didn't do enough playtesting. This caused some duller moments during combat and even stalemates that contributed to the feeling some players had that the game had a lot of grinding. Additionally, there is definitely a learning curve to the game, and a lot of players didn't learn enough of the mechanics to reach those "brilliantly fun" moments.

The content and areas definitely could have used more love as well. One thing I learned from this project is that procedural generation is not a valid replacement for hand-crafted content unless it is very thoughtfully put together (like I am attempting for I Can't Escape: Darkness) - in which case it actually takes a lot more time to develop than doing the content by hand. Procedural generation is NOT (and should not be seen as) an easy way out of designing content. Because of the very simple generation algorithms in Deity Quest, a lot of the areas seemed repetitive and featureless which was the second big reason that some players felt the game was a grind.

It was after the release and rough start of Deity Quest that I got kind of disillusioned with game development and posted this: http://david.fancyfishgames.com/2014/05/deity-quest-havencall-and-future-of.html . However, I certainly learned a lot from this project, and it was from Deity Quest that I realized my mistakes and designed more interesting procedural generation algorithms for I Can't Escape: Darkness. Deity Quest has also just gotten greenlit on steam, so perhaps that will bring a second life to the game: http://steamcommunity.com/sharedfiles/filedetails/?id=245330039 . I've been doing some fixes, tweaks and balance changes to the game, and I'll have another blog post when I get it up on Steam (which will hopefully be this month)!

ADventure Lib is a smaller game that I finished as a side project late in 2014. ADventure Lib's name is a pun on ad lib - it's a parody point & click style game where most of the characters, items and objects have been swapped with each other. It gets pretty ridiculous when you have to do things like defeat the fire-breathing pants, save your beloved toilet and find the potato of legend. I have yet to release ADventure Lib, mainly because I'm still trying to figure out what the best way to release it is (I have a feeling it is a fairly niche game), but this game will definitely be released in the near future (and if you're interested in playtesting, feel free to e-mail me and I may send you a beta copy).

If you're wondering why I do side-projects, I find it helps to refresh my mind, and the side projects often help me with the larger projects as well. For example I added controller support to ADventure Lib, which is being re-used to add controller support for I Can't Escape: Darkness. My favorite author, Brandon Sanderson, knows this phenomenon very well too - in his end of the year blog post he revealed that he wrote the sequel of Shadows of Self to get back on track to finishing Shadows of Self.

Ongoing Projects

I Can't Escape: Darkness is my next big project, and I am currently hoping to release a closed alpha this month. I was originally planning on releasing the full game this month, but after some playtests we discovered pacing issues that needed to be worked out, causing a minor setback. While Darkness is procedurally generated and different every playthrough, the generator is a lot more intelligent than in Deity Quest, and it can be tweaked to modify the pacing and game flow. It also has procedurally placed static event areas that have interesting art and mechanics. I know a lot of you are curious exactly what the mechanics and gameplay of I Can't Escape: Darkness will be like, but telling you too much would spoil it, as it is meant to break expectations.

What I can tell you, however, is the following:

  • There will be combat.
  • There will be puzzles.
  • Light plays an important part in the game.
  • There will be MANY tricks and traps.
  • There is a legitimate game path to escape (unlike the original where the escape was more of a hidden easter egg).
  • I still do not expect many players to escape.

Another year, and Havencall is still not done huh? Well, we did finally finish a playable version of the first third of the game in June of 2014, and submitted it to IndieCade. However, from playtests and comments from this version, it became clear that a lot of the story of the game was not coming across well - and the story is by far the best part of this game. So we've been redesigning parts of the game and focusing a lot more on how to get the story across. This means that Havencall is once again postponed, but the good news is that the game should be a LOT better when we finally finish it!

Future

This month, I'll be finishing up some changes to Deity Quest and releasing it on Steam, and also releasing a closed alpha for I Can't Escape: Darkness. If you wish to participate in the closed alpha, simply send me an e-mail (davidmaletz@gmail.com). Relatively early this year, I also plan to release ADventure Lib, so there will be several fancy fish titles coming out one after another. I Can't Escape: Darkness will certainly be released in time for Halloween of 2015, and there should be a revised Havencall playable build this year as well.

I'll likely be getting a full time job this year, as my part time endeavors and games simply aren't making much money. However, I still plan to make games and even a 40 hour work week leaves plenty of time for that. Honestly, it will be good to have financial security and be able to work on games without worrying too much about how well they sell.

What other projects do I plan to start this year? Well, I will certainly start one of the sci-fi game projects I've been wanting to make for a while (and spaceships are Matt's specialty, so you know they will look good). I've also started creating a voxel engine using I Can't Escape: Darkness's direct/indirect lighting. The lighting is very impressive, efficient and so well suited to voxel-style games that I could not resist. I'm not spending a lot of time on the voxel engine, so it could be a while before you see it or any voxel games from fancy fish games, but I do have lots of ideas, so that may be a direction I head in the not-so-near future.

2015 is already off to a good start, and I have a feeling it could be the biggest year for Fancy Fish Games yet! Look forward to future blog posts!

Tuesday, September 30, 2014

Unit Tests - A Cautionary Tale

I'll start by saying I'm not a big fan of unit tests. I've been forced to write them before, and I always find them tedious and seldom useful. However, there are cases where unit tests are useful and can save a lot of time, headache and debugging. So even if you're like me, you should still consider when it might be a good idea to add unit tests.

First off, what are unit tests? Unit tests are where you literally write code to test a section or function of your code. As a quick example, the following function:
function square(x){return x*x;}
Might have the following unit tests:
assert square(5) == 25; //Normal case, 5 squared should be 25.
assert square(-4) == 16; //Negatives, -4 squared should be 16.
assert square(0) == 0; //Edge case, 0 squared should be 0.
This tests the function with a few inputs to ensure it has the right output. If all of the unit tests are successful, than you can assume the function is more or less correct. Later on in development, you can run the tests again to make sure that it is still correct (and that nobody messed up that bit of code).

Now you might see why I hate unit tests. They can be very tedious, and typically only work for small, deterministic functions where it's pretty obvious that it works anyways. However, the idea of using a bit of code to test a much larger and more complex section of code is pretty appealing. Instead of having to test and debug output by hand countless times to make sure it's not broken or to track down a bug, you can simply run the test and hopefully find bugs before you even release the game to testers.

Of course, as I hate unit tests, I didn't originally write any for my current game, I Can't Escape: Darkness. However, a month or so ago I made a small change to the procedural generation code of the game to add a new feature. The change was small and I didn't think it would affect any of the other code. Checking the procedurally generated layout by hand many times, everything seemed to be in working order. But that's one of the downsides of procedural generation - since it is random, there can be bugs that don't appear in the majority of generations. This is exactly what that small change did - it broke an assumption from an earlier bit of the generation code that, in a very rare case, would allow a section of the map that should've been reachable to be attached to an unreachable section (instead of attaching it to a reachable section so that the player could actually get there). A month later, a team member was playing the game, and noticed that he couldn't find an essential button he needed to progress in the game. He was stuck, and looking at the generated layout, it turned out that the button could not be pressed as it was spawned down an unreachable corridor. Oops!

I'm sure you've all encountered problems and bugs like this, and some of them can be very game-breaking like this one was. Worried that other game-breaking bugs might exist and tired of manually checking generated layouts by hand, I finally decided to add a unit test. However, I didn't add small unit tests checking each function to make sure that all the parts of the whole work. What I did was one large unit test that checked the integrity of the procedural generation as a whole (and the procedural generation section in I Can't Escape: Darkness is big - about 40 classes and 200 functions). That is the kind of unit test I view as beneficial in game development - one that checks a large section that IS changed a lot, and takes less time to code than to manually check.

The unit test I have now does higher level checks like this:
assert canEnter("vwm", "lr3"); //You should be able to enter vwm from lr3.
assert canEnter ("cr3", "vwm"); //You should be able to enter cr3 from vwm.
assert !canEnter ("cr3", "lr3"); //You should NOT be able to enter cr3 from lr3 without first going through vwm.
Where cr3, lr3 and vwm are codenames for rooms, events and areas that are generated (which I will not explain so as not to spoil what you can find in I Can't Escape: Darkness).

These checks use basic pathfinding, and there are a lot of them that do the same kinds of checks I would do by eye. It ensures that all of the buttons, events and rooms are reachable, and that there are no holes in the maze that let you reach sections that you shouldn't be able to reach (without first hitting a button to open a door or exiting an event). Yes, this took some time to write and is more complex than "normal" unit tests, but it is infinitely more useful. Now, I can run this test 1,000 times or 10,000 times, and even though some bugs may be rare with procedural generation, this test has a much higher chance to catch bugs than I do by hand. This does what unit tests were really meant to - ensure that everything is working properly and saving time.

As a quick caution, I'll mention that you should be careful your unit testing code is simple to limit the chance that it itself has bugs. There's nothing more useless than a buggy unit test that misses errors, and nothing sillier than having to write unit tests for your unit tests! The test I wrote uses hand-written checks that only relies on a pathfinder that I've used many times before and am very confident that it works without bugs. Don't write a unit test that is so complex it breaks more often than it correctly checks your code.

To conclude, I think that you should start considering where in your code a unit test would be beneficial, preferably before someone else finds a game breaking bug. You'll still need to do plenty of testing and debugging by hand, but a good unit test can save you (and others) a lot of time and headache. Whenever you find yourself having to check something often (like the generated map layouts in I Can't Escape: Darkness), ask yourself whether you could automate the process with a unit test. If you can automate it, it's not too complex and it will save you time, then it might be a good idea to write a unit test. Unit tests can be useful - just don't waste your time writing unit tests for functions like square!

Saturday, August 23, 2014

Don't Get Caught in the "Last 10%" Trap!

You may have heard the expression "the last 10% of development takes 50% of the time" or some variant of it, and while in a sense it is true, in my opinion this belief is one of the biggest problems in current game development. As a game developer, this phrase makes a lot of sense to me - I am well acquainted with the last little bit taking a lot more time than expected. However, the question really is: why do I believe that polish, testing and details are "the last little bit" of development? Why do so many people value half of a game's development time as only 10% of the project? I myself have been caught up in this common misconception, and I'm writing this blog post partially as a reminder to myself that the "last little bit" is NOT little, it is as important as the rest of game development, maybe even more so.


First off, what is this "last 10%" that is so under-valued? While this varies from developer to developer, for me, I like to think of "feature-complete" (meaning all of the features are in, and the game runs) as "almost done." This leaves polishing, tweaking, balancing, play-testing and minor details to that final 10% phase. However, from experience, I am starting to realize that this "last little bit" is actually the MOST important part of a game, and certainly worth half the development time, if not more. Thinking of it as "little" not only makes me underestimate how much work is left on a project, but it also makes me frustrated at my progress near the end and even encourages me to rush that final phase of development. But this is a dangerous trap, because no matter how much potential a game has, if this essential last phase is rushed, the game will likely turn out poorly.

A good example I saw a while ago about the importance of polishing games is Juice it or lose it: https://www.youtube.com/watch?v=Fy0aCDmgnxg . While this video focuses more on the visual side of polishing, all of the details added in the final phase of development help make a game feel alive. Every little nuance and special touch makes a difference, even the ones that you think most people won't notice or care about. And without thorough testing and revision, you can't know how players will react to the game - where they get stuck, what parts are too easy or boring, what parts they miss or don't learn, what parts are exploitable or even buggy. No matter how good the game's mechanics are, without multiple cycles of testing and revision, players won't understand them or won't care. And no matter how amazing and original the core concept of the game is, if it's not polished and revised, it won't shine through. The "last 10%" is what brings a game to life, making it immersive and fun.

An example of a game that worked well because of the polish is Antichamber. It's mechanics, art and music are (in my opinion) very simple. I'm usually not even a fan of that style of gameplay. And yet, the game drew me in and had me playing for hours. A lot of attention to detail, content and great pacing made the game enjoyable. And, watching this video: http://indiegames.com/2014/04/video_breaking_down_the_seven-.html , I realized just how much effort was put into the fine-tuning of the game. It's really telling how with every conference the developer went to, the average play time increased, from five minutes to over an hour. The game took seven years to release, but that was because he didn't stop at feature complete. He kept fixing, tweaking and improving the game until it really shined. And that's what I think made Antichamber the success it was.

Quite a few games I've played recently have had an interesting concept and a lot of potential, but fall flat somewhere due to lack of polish, often causing me to lose interest half-way through (or in some cases, not really getting started at all). This is also a major flaw with my most recent game, Deity Quest. While it has interesting mechanics and many people enjoyed it, "minor" elements kept it from really shining. Elements like the lack of animations, poor progression within locations and a complicated UI that was not very intuitive. Even though the core of Deity Quest was complete, the game was lacking the "small" elements necessary to make it completely immersive. Almost unanimously players felt that Deity Quest had a lot of "grinding" (even those who enjoyed the game). But it was not a grind because the game had particularly more battles or repetitive events than other games - it was because the pacing and progression wasn't well tested and revised, so the players weren't fully immersed in what they were doing (and without immersion, any task can become a grind). The "last 10%" can seem like just icing on the cake, but it's that icing that can make or break an entire gaming experience.


Even some of my all-time favorite games have similar problems. I recently played Lands of Lore: the Throne of Chaos, and the first half of the game was very immersive, with lots of minor details, great balancing and pacing, and it was as fun as I remembered. However, the second half started to lose that polish - even though it still had interesting puzzles and combat, the pacing and balance were off, and those minor details started disappearing (to the point where there wasn't any flavor text at all in the final dungeon). While I still completed and enjoyed the game, it definitely started to lose that magic towards the end that made it one of my favorite games. While I'm sure there were deadlines or crunching that made the developers of LoL focus on the first half (first impressions are important, after all), I would say that it's better to make a game that is well polished throughout, but only half the length.

Realizing the importance of this "last little bit," and how long it takes, will help developers (myself included) design their games and budget their time wisely so they CAN add those all important details throughout the game. Do you really want to put so much time and passion into the game's mechanics, art and music, only to skimp on a part of development that is just as vital? In fact, a part that could have more impact than any other on whether players love your game or not?

The last thing I'll mention is that the "last 10%" doesn't actually have to be the last thing you do. During development it can be nice to switch between tasks so that you don't get tired of doing the same thing every day. Polishing, tweaking and adding details is not as onerous when interspersed with other elements of development - instead it can become a fun change of pace. In my current project, I Can't Escape: Darkness, even though I'm early in development, I've already added flavor text and small details like screen shakes or wall eyes squinting when you throw a mushroom at them. Additionally, getting testing and feedback early can be very beneficial; the earlier you notice changes that need to be made, the easier it is to make those tweaks. For example, even though I know the location pacing is a major flaw in Deity Quest now, at this point it would require a large effort to fix it - I'd need to restructure and perhaps completely rewrite the location API. If I had gotten this feedback during early development, it would have been much simpler to modify.


Takeaways
  • Polishing, tweaking, balancing and play-testing are not little in terms of amount of work OR impact on the quality of your final game. Get that idea out of your head if it's there.
  • Believing the above are "minor" creates misconceptions that are detrimental to game development.
  • It is better to make a smaller, well polished game than a larger, poorly polished game that has trouble immersing players.
  • Polishing your game does not have to be put off to the end, it can be done during development as well. In fact, it is beneficial to get feedback and revise as early as possible (instead of just focusing on 'getting the game done' in a mad rush).
In short, a "feature complete" game is only half the battle - don't fall into the trap of underestimating or undervaluing the other half. No matter how much potential a game has or how much passion you put into it, it will fall flat without polish, like a sketch that could've been amazing if only it had been finished.