Wednesday, June 28, 2017

Prototypes, Card Games and the Future

With </reality> released and no new games announced yet, you might be wondering what's next for Fancy Fish Games? That's a question I've been wondering myself, and have decided to take my time considering ideas and making prototypes before jumping into the next big thing. But there are a few things I know, and I'd like to share them with you.

Untitled Card Game

Firstly - we designed a city-building card game about a year ago, but it received only a lukewarm response from friends and family during playtests. So we scrapped it until a few months ago, when I came up with a way to improve it, and we've basically completely redesigned it at this point. It's gotten a very positive response since then and it's a lot of fun, so it is likely we will do a Kickstarter later this year to be able to make the art for the cards and print them.

Untitled Prototype

Next, I've made a prototype which you can play online here: Flash Version , HTML5 Version (has bugs on some browsers). I don't want to say too much about it as part of the gameplay is unlocking things and the surprise factor of not being certain what comes next, so give it a try. However, I am looking for feedback on this to determine if I should continue to develop it into a full game or not - and what parts are fun, and what needs more work/improvement.

I Can't Escape 3

I've also begun work on I Can't Escape 3 - a direct sequel to I Can't Escape: Darkness. It's currently at an early prototype stage, and there are some gameplay issues we need to work on before we jump into full development on this project, but it is probably coming in the not too distant future.

There are also other prototypes and possible projects that we are considering, but we'll let you know in future blog posts!

Monday, May 29, 2017

TransFuse Post Mortem

This is the story of TransFuse, a game made in 48 hours for the Butterscotch ShenaniJam.

The Idea

At the start of the Jam, I rolled the theme: "Electric Leech." At first, we were at a loss about what to do - as while the theme brought a vivid picture to mind, it didn't really inspire any particular gameplay for us. All of our ideas were just games with electric leeches (and a few of the ideas were just leeches... the gameplay was pretty questionable). However, eventually I came up with the idea for a tower defense game where the enemies were leeches, and they both sucked your blood (leech) but also gave you power which you needed to build towers (electric). This double-edged enemy type was a very interesting twist to the tower defense gameplay - and changed the game from trying to have an impenetrable defense (letting as few enemies through as possible), to balancing how many enemies got through and how quickly.

About two hours into the jam, we had finalized the idea and came up with a quick design document for it.

The First Day

After we came up with our idea and design document, we had about four hours left in the first day to make something. Aaron sent me quick placeholder art and I got to work setting up the grid and pathfinding for the ground leeches. I also looked through old code of mine and reused a bunch of stuff - mostly utility classes and the tower placement (and also a lot of the animation/display stuff). By the end of the day, there was no UI, but you could place towers that did nothing (except block leeches), and watch the leeches pathfind through your towers to reach your ship. Not really a game yet, but a good milestone.

The Second Day

The only full day of the jam, this was where the majority of the work happened. By the end of this day, the game was very playable (and very fun, which is always a good sign). There was no title page, game over or victory screens, and you couldn't power/unpower or sell towers, but you could place towers which would automatically fire at leeches (including aiming for targets closer to your ship and leading - firing at where the leech will be instead of where it is), and you could fire the cannon and the majority of the UI was in place.

The Third Day

Ideally, the third day of a jam is left for polishing, tweaking, and submitting. That was most of what we did (plus the title, game over and victory screens and the tower menu where you could power/unpower and sell towers). I also added the notifications so you could see how much blood/energy leeches took when they reached your ship, and did some balancing. Obviously the game isn't perfectly balanced and there are no tooltips, but for only 48 hours I am quite pleased with where it ended up. I also had to create the video for the game, which I didn't realize I needed until 2 hours before the deadline so it was a little bit of a crazy rush making that and adding the last of the art/music to the game, but we did it (with a whopping 5 minutes to spare).

Final Thoughts

Overall I think the jam went very well, and I feel like we accomplished a lot in only 48 hours. While it's not perfectly polished and there's a ton of features that would be nice to add (like more towers, tower upgrades, more enemy types, ship upgrades, and a level or wave based progression), I feel that it is pretty complete and fun.

Monday, February 13, 2017

A Year In Review 2016

I haven't been very active on my blog, but I wanted to at least keep up with the year in review posts, where I look back on what happened in the past year and discuss my thoughts/plans for the future. The previous end of year reviews are here:
As you can see, Fancy Fish Games has been a constant roller coaster of highs and lows, of built up expectations and crashing dreams. It's already been over 4 years, and I Can't Escape: Darkness is the closest thing we've had to success. We've actually gotten a lot more sales since then thanks to the Steam Discovery Updates and the Halloween Sale, but we still haven't been able to realize our dreams of becoming a full time dev studio. Despite our uneven footing and uncertain future, we have been getting a lot better at designing and developing games, so we're definitely improving - if not as fast as we had once hoped.

So What Happened in 2016?

For those of you who have been following us, you probably noticed we had no major releases in 2016. In fact, our only release was Quotidian, our 2016 Global Game Jam entry (if you haven't yet, you should try it - it's very short, and very good for having been made in only 48 hours).

The rest of the year was largely brainstorming, prototyping, and freelance work until around July, when we started working on </reality> (more on that later).

The only playable prototype I'll share with you today is Medieval Tactics. It's a neat TBS with some city building aspects inspired partly by the board game Settlers of Catan, but it's kind of lackluster and doesn't really add anything new to the genre, so I haven't made any plans to go further with it.

Beyond the Stars

The prototype we spent the most time on was Beyond the Stars, which I have shared a few screenshots of on my blog and twitter. It's gone through many revisions, but the basic idea was an FTL-like game where you control a fleet of ships (instead of just one), and your score is based on how many civilians survive. However, this turned out to be very difficult to manage (as a player), and there weren't enough options for defending civilians besides ordering ships to defend other ships. We started planning a simplified, but multiplayer version where each player commands one ship in the fleet (and the rest of the ships are AI controlled). However, this became overwhelming very quickly, and we still couldn't find where the "fun" in the game was, beyond complex management that only die-hard fans of strategy/simulation games would enjoy.

Our conclusion with Beyond the Stars was that the basic gameplay needed more thought, and adding bells and whistles would only hide, not remove, those issues. For now, on HOLD.

Voxel Engine

After I Can't Escape: Darkness, I was inspired to make a Voxel Engine for future block-based 3D games. It mostly started out as a hobby/side project (and I coded the voxel mesher in OpenCL, which was interesting), but now we are planning to use it for I Can't Escape 3 (not yet announced). I also wrote a layer-based voxel editor for designing rooms and worlds.

Early screenshot of a room in I Can't Escape 3

The engine supports ramps and 3D models (including bone animations), and should be useful for many games in the future. And yes, I am crazy for writing my own voxel engine from scratch, but that could be the topic of a whole separate blog post.


After experimenting with many game prototypes, none of which stuck for long (besides Beyond the Stars which I explained above), we were unsure what to make next. We really liked the basic story behind one of the prototypes, but the RPG-ish gameplay wasn't that interesting. Natalie started expanding the story and moving away from the original game, and eventually we realized if we scrapped the gameplay, it would make a very interesting Visual Novel. That was how </reality> was born - the only remnant of the original gameplay being a short nod to it where Jacob explains that Vitalia will eventually be a creature-taming game based on a loyalty system.

Thus started our next big project. We decided to use Ren'Py, as it had basically all the features we wanted out of the box (and I'm not afraid of a little Python coding). I kind of consider </reality> Natalie's project, as she is doing all the art and wrote the first draft of the story. I wrote the original outline, and did a little coding, and a lot of formatting the story into the Ren'Py format, but most of my work on this game has been script editing (and there seems to be endless editing to do on a story this large).

</reality> was successfully funded on Kickstarter and we recently released the Steam Coming Soon page! Development is going pretty smoothly, and we still hope to release by the end of March (coming up really fast) or mid April at the latest. We also made an offical </reality> website with pre-order/late backing options available.

Global Game Jam

Last month we attended the Global Game Jam again and created Wavebreakers in 48 hours. It was my first time using Unity (at the request of the two other programmers on the team), and we were perhaps a little too ambitious for such a short period of time, but the game idea is definitely interesting and we might eventually polish it to the point where we feel comfortable releasing it to the public. But, even if we don't, it was a good experience, and I got a handle on Unity pretty fast if I ever need to use it again (for work or my own games).

The Future

Obviously, between now and the end of March we're going to be pretty busy finishing up </reality>. However, I have been brainstorming ideas for our next game(s) and even made another new prototype (codename "Witch Academy") while waiting for </reality> art from Natalie.

2017 Goals:
  • Release </reality>!
  • I Can't Escape 3 - Matt, the artist for I Can't Escape: Darkness has already written a design document and started designing rooms in the Voxel Editor. We probably won't be able to release this year, but definitely next year. The only thing I'll tell you about this game until we announce it formally is that it's a direct sequel to I Can't Escape: Darkness, taking place after escaping the tomb (and killing the heart, with all the consequences of doing so).
  • Witch Academy - After </reality> is released, this will be the next project I work on with Natalie. I should be able to work on both this and ICE3, and I already have the game design document and a prototype of it working. This also probably won't be released until early 2018.
  • We might try to release one other game this year, but if we do, it will be a smaller one. I did work on a few small prototypes with Aaron, an artist I met last year, and two of them could end up being pretty interesting.

So, we should have a lot of interesting releases between now and early 2018! After that, we still want to make Beyond the Stars (if we can make the gameplay fun), and I also have a few ideas that I want to experiment with in the Voxel Editor (you can see one world I made above using Kenny's voxel textures).

So, we may have slowed down, but we definitely aren't giving up, and we have some pretty ambitious games planned!

P.S. My game ideas spreadsheet (which I created to organize all my ideas, design documents and prototypes) now has 38 entries! We won't make all of them, and not all of them are good, but that's still pretty wild.

Friday, October 28, 2016

Natalie Maletz: < /reality > Demo and Plans

I don't do a lot of re-blogging, but I decided to re-blog Natalie's latest blog post as it's very relevant to what we are currently working on (and </reality> is more her project, so I'll let her say all the things).

Natalie Maletz: < /reality > Demo and Plans: Happy [almost] Halloween! It's weird. Unlike most years in late October, the thing I am most excited about right now is not spooky cos...

In other news, I Can't Escape: Darkness is currently 70% for Halloween! That means you can experience all this spooky eeriness for about the price of a cup of coffee! o.o Happy Halloween!

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.

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 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.
  • 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.
    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.
  • 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.