Saturday, December 15, 2018

Aground Pre-Mortem: On the borderline, sales data, and the 70/30 Split

My latest game, Aground, is currently in Early Access. It is not dead - not by a long shot (hence PRE-mortem) - it continues to gain attention and sales every day. In fact, it is the closest game I've released to making a profit, but it's not quite there - hence the borderline. In this blog post, like in a post mortem, I'll break down sales stats for the game (thanks to Valve recently making it clear we could share them), expenses, what went right, what went wrong, and talk a bit about the standard 70/30 store split - as, if 88/12 became the standard, we would be making a profit.


I founded Fancy Fish Games in 2012, knowing I wanted make games even if I had to continue doing it as a hobby. Before Aground, we had released 9 free games and 4 commercial games with varying measures of success. We've never made enough on our games to make a profit or go full time, but with savings and freelance jobs that paid $50/hr, we were lucky enough to keep making games even without making a profit. However, it was starting to wear on me that I spent all that time and effort on good, well rated games and couldn't even make minimum wage. I was considering calling it quits and only making games as a hobby if Aground didn't do as well as it did.

In May 2017, I first came up with the idea for Aground, although the desire to make a sandbox game with more progression was there as early as 2013 after playing minecraft for the first time (if only I had actually started Aground back then...). Thinking I had an idea for the next great step for sandbox-style games, I made a prototype in June. The prototype got a mixed reception from testers and no responses from publishers, so thinking it was another failed experiment, I fixed up the prototype as best I could from the feedback I got and released the game for free in October. You can see this version of the game here: Not sure what to expect, I was surprised when it quickly became my highest rated free game (around a 9/10 or higher across different sites), with over a million plays and winning best of the month awards. My confidence in the project restored, I decided to go all in on it and run a Kickstarter to fund us until Early Access. You can read about this stage of development in this blog post if you want:


With the goal of completing the first planet and then launching the game on Early Access, we set the goal for the Kickstarter campaign at $10k and expected it to take 4 months of development time. With millions of plays, we were all expecting to blow that goal out of the water, or at least hit 200%. The reality of course is that while the Kickstarter was never in great danger of failing, we barely made it over our goal, making $13.5k. Additionally, the first planet took longer than we expected - we didn't release the early access version of the game for 5 months - so we were running on precious little funds. I wouldn't even call the first planet truly complete until our latest update, about a month ago. This was the first warning sign that even though the free version was super popular, it wouldn't necessarily translate into a successful commercial game (the free and paid markets are very different, and it's a poor conversion rate from free to paid).

We did end up making an additional $5k from late backers (via PayPal), but with our monthly expenses up to $5k a month, we were already $7k in the red by the time we launched on Early Access.

Early Access

Once we hit Early Access, we thought that things would finally start getting better. We were ready to see the red turn to green. So when we launched on August 8th and had only 69 sales the first day, we were worried - that was less than the first day of our most successful previous release I Can't Escape: Darkness (but to be fair, ICED had much better launch visibility back in 2015). However, instead of the long tail after launch we'd come to expect, with sales dropping off to nothing, they stayed consistent. I remember every day wondering… when will they drop? Can this really keep going? But it did. This could be because Aground is an Early Access game (we've never released an early access game before), but sales in the first two months remained at about 35 sales/day - with September actually being BETTER than August because of PAX West and three big youtube videos.

Then came October. I'm sure you've heard of the big October Bug by now, and like everyone else, our sales were halved, making on average 17 sales/day in October. After the bug was “fixed”, our sales recovered a bit, rising to ~21 sales/day. While it didn't fully recover, I think launch month and September were special cases, so it's probably not fair to expect it to go all the way back to 35 sales/day (of course, there were some permanent changes to the algorithm too). Honestly, from some stories we've heard, we've survived this algorithm change pretty well, perhaps because Aground sales are above the estimated median sales for a game on Steam right now. In a way, that is quite flattering - that Aground is doing better than half of the games released on Steam (I’ve heard estimates for the median being 1.5k-4k* sales total)... but it could also say more about the average game on Steam, and less about Aground.

* Estimates from this steam spy report [2017], and the median game from the csv in this achievement stat sales leak [2018].

No Launch Sale

I have not put Aground on sale at all currently, including at launch (unless you count a joke reverse black friday sale on, where Aground was actually more expensive than normal). Almost every game goes on sale at launch (you have to maximize that launch spike), and a few people thought I was crazy for this decision. I made it in part because I felt it wouldn't be fair to backers who paid full price just a few months prior, and because the game already felt very discounted at $10 (I plan to raise this to $15 at the full launch). While this could explain the relatively weak launch day, I don't think it really hurt our sales overall, and it kept the game from being devalued right from the beginning. If I do a sale before the full launch, I don't think it will be more than a token 10% off. Your early adopters are the ones most likely to be willing to buy the game at full price. I don’t believe in participating in this race to the bottom - at least not until the game gets old and you need to encourage people who might not have bought the game anyways to just get it.

Let’s Talk Numbers

Earlier, I said our expenses were about $5k a month. This mostly goes to Aaron (art) and Chase (music) - who are both accepting less than their standard rates because they believe in Aground. There are also some additional fees (like website hosting), marketing expenses, and a token $500/month to myself (which is way less than I should get and way less than I need to survive, but since I'm self publishing the game and have savings/other income, I decided I could live with that while in Early Access).

For revenue, we are currently averaging 21/sales a day, which is about 630 sales a month. Those have all been at full price (we haven't done a discount or bundle), so it seems at a glance like we're making $6,300 a month and are doing fine financially.

BUT that's not the end of the story. First, we lose about 5% to chargebacks/returns (which is actually pretty normal from what I've heard), and we lose another 5% on average to regional pricing. If you didn't know, Steam's default regional pricing is not one to one, Aground only costs 259 Russian Rubles, which is about $3.88 USD. I trust Steam's default regional pricing and knew about this, but it does mean that depending where your sales are coming from, you could get a lot less than $10 USD per sale. These take us down to $5,685.75 a month. Next, of course, Steam takes a cut. The industry standard for storefronts is to take 30% (I think this dates back to retail stores, where there is a cost in actual stocking). This leaves us with $3,980 a month, over $1k less than our expenses. We also sell the game on, and have been selling about 1-2 copies a day there, which isn't bad for itch, but not enough to make $5k a month.

We currently have over 3k sales (not including backers) and over 11k wishlists - perhaps from people waiting for a sale or the big full launch. Maybe it is just an issue of trust, and as people continue to see us releasing large and regular updates, they will be willing to take a risk on us.

The last interesting stat is that the median time played is over 6.5 hours, which is above average and shows that the game keeps people's attention.

The 30% Store Cut

There's been a lot of talk lately about whether digital storefronts actually need to take 30% to make a profit, with Epic Games offering a 88/12 split and Discord following suit with a 90/10 split. Nobody's talking about the fact that has always let you set the split to whatever you want with 90/10 being the default... but this is excellent news, as it might mean that the industry standard will change and everyone will adjust their splits accordingly.

This made me particularly excited. If Steam only took 12% like Epic Games, then we'd be making $5,003.46 a month (assuming sales continue as they have been the past 2 months) - a tiny profit over our monthly costs! I know it doesn’t sound like much. But after trying so hard to “make it” in this industry with little to no success, for nearly 7 years, it feels like a major milestone to us.

Of course, this might never happen, and what revenue split a store takes only really matters if that storefront is getting a lot of sales (I'd rather 21 sales a day with a 30% storefront cut than 1-2 sales a day with a 10% cut), but I strongly agree that storefronts taking a smaller cut would help smaller indies with their meager sales continue to do what they love and experiment with all sorts of new, interesting game ideas. I would really like this to become the industry standard for digital storefronts.

In Conclusion

Going forward, I think a lot depends on the full launch. We've had lots of people say they are interested in the game, but aren't willing to buy ANY game in Early Access, probably because it has such a bad reputation (who knows how many of the 11k wishlists fall into this category). And we are definitely going all the way to a full launch - even if it means losing $1k a month, we've already put so much into this game and there's less than a year left, so we have the savings to do it.

A part of me wonders, like with the Kickstarter launch and the Early Access launch, if I'm over-optimistic about the Full launch. Perhaps we'll transition to the full launch, get a small spike of sales, and then return to where we are currently without ever really turning a profit. Maybe that's just the way it is in this over-saturated market, especially with a retro pixel game that doesn't stun and amaze from the screenshots and videos.

But, regardless of the outcome, Aground has already done better than any of our previous games, in both revenue and reception - we currently have 105 reviews, 100% positive, putting us in the #10 slot on the hidden gems rankings - out of ALL GAMES ON STEAM (I’m not sure how much this site’s rankings matter, but it’s still nice to see). That's something to be proud of, and at the very least it means that I will finish Aground and make at least one more attempt at a large scale game before I re-consider calling it quits and only making games as a hobby.

It might seem crazy to you that I have a company that has never turned a profit, and that I can’t even pay myself minimum wage, but I’m doing what I love and the only people I have to answer to are the fans of my games. So, onwards we go, ever optimistic that a true success is around the next corner.

Wednesday, January 31, 2018

From Prototype to Kickstarter

Remember that Untitled prototype I talked about in my last blog post? It started as a simple idea, a cross between A Dark Room and Starbound, where you'd start out knowing very little and doing simple tasks like collecting wood, and slowly work your way up to a more complicated crafting and mining game with lots of systems and even space travel. This is the story of the beginning of the game Aground.

After finishing up a basic alpha version, I showed the prototype to friends, family, and various work in progress feedback threads, and the reaction was mixed. Some people loved it, some people thought it was boring, and the vast majority of players just didn't seem that interested in the game. While I thought the game was interesting, it wouldn't be the first time I enjoyed a game I made and others thought it was terrible *cough*ADventureLib*cough*.

Not sure what to do in order to improve the game, we tried contacting publishers for both monetary support and for feedback and testing. Once again, we got little interest.

Disheartened, we started wondering if Aground simply wasn't a good game. If the core's no good, no amount of additional features and work will improve it, and sometimes, as sad as it is, the best decision is to trash the project and start something new (it's bad to trash projects too early for some new and exciting idea, but it's also bad to sink tons of time and money into a project doomed to failure).

Not quite ready to give up on the idea, and having already spent a lot of time on the alpha version of the game, we decided to fix it up to the point we didn't mind sharing it publicly and post it for free. Worst case, at least it would be out there and the time we spent on the project wouldn't be for nothing. We launched this version of the game on October 24th.

After our experiences with the prototype, we had no expectations for the game. So, we were pleasantly surprised when we saw that the game was immediately well received. Aground quickly took off, and soon had more plays and a better rating than any of our past games! From disheartened, our motivation sky rocketed, and we realized we might have stumbled upon quite the gem.
It's important to remember that just because you haven't found your audience yet, that doesn't mean your audience doesn't exist.
We also learned something important. We were getting luke-warm feedback for the game because the people who we shared the game with weren't our target audience. Because the testers were mainly game developers and people I knew, it wasn't a good indicator of players on portals like Newgrounds and Kongregate. In a way, we got lucky that our last attempt before we gave up on the project found our audience, as there are many other potential audiences that don't frequent those sites. It's important to remember that just because you haven't found your audience yet, that doesn't mean your audience doesn't exist.

While we were only making money from ads and contest winnings (and not enough to support development), we now knew we had something special. With all of the feedback and excitement about the project, we finally had what we wanted before the launch. We used personal savings and went into full gear releasing updates to really make the game shine.

Today, after a big update, we launched a Kickstarter for Aground. Maybe this will be the end of Aground's evolution. Maybe the large audience from the free version will be unwilling or unable to convert to paid players. But I'm hopeful now, and perhaps what I needed most during this entire project was just to believe in it!

Thank you for reading, and I hope you're as excited about the future of Aground as I am!

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.