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