Skip to main content

Procedural Generation of Puzzles

If puzzles in games can be solved somewhat quickly, it will be a lot of work for the designer for a few minutes of gameplay for the player. One way around this problem is to come up with a way of procedurally generating puzzles. This means writing an algorithm that, given some constraints, can create its own puzzles. 

Procedural generation is common in many video games and is especially useful in roguelike games. This process allows designers to design some small 'chunks' of levels, then feed these into an algorithm that creates complete levels from these chunks. An example of this can be seen in Dead Cells (2017), which sees the player progress through areas that are different every time they enter. It would be possible for designers to manually create enough versions of these areas to ensure it is different each time. However, a more efficient method is procedural generation. An algorithm could define that there must be an entrance, an exit, a certain number of enemies, a treasure room, and a shop in each area. The algorithm would use elements created by designers to populate an area with these constraints. Another simpler implementation of procedural generation can be seen in the deck-building game Inscryption (2021). The game has roguelike sections, in which the player navigates a map from bottom to top, with different encounters along the way. The map presented to the player is different each run, so must be procedurally generated. There are certain constraint in place, such as every few encounters being a fight, and every path converging on a single point: the boss.





This approach of procedural generation could also be applied to puzzle games if the puzzles follow a certain format. It would be interesting to research the extent to which puzzles can be automatically generated. There are currently puzzle games that use procedural generation to create puzzles/levels, but these are all 2D, grid-style puzzles that are simple to create algorithms for. The intriguing area of research is the one that encompasses 3D puzzles with larger state spaces, as procedural generation demands a lot of computing power and has only become available with recent advances in computing and AI. For example, Portal (2007) presents its puzzles within 3D levels/environments, so it would be very computationally expensive to run an algorithm that procedurally generates these 3D environments, as well as testing them and evaluating their quality. 
The simplest approach that have thought of is to reduce the number of actions a player can take to as few as possible at any one point, while still providing them with an engaging experience. This is because, in order to create a computer player that can solve puzzles, the designer must create a graph of the possible moves and the resulting state of the game after each move. To use Portal as an example again, it is a 3D environment in which the player can move anywhere they choose, place items anywhere and place portals on many surfaces. The number of actions the player can take at any one time is large so the graph will be big and complex, making it near impossible for a computer to solve the puzzle in polynomial time. A game like chess is a good example of a simpler game that can be solved by computer players. It is 2D, with only 64 possible spaces for a piece to be in. Other pieces on the board and the limited movement capability of each piece decreases the state space drastically, but there is still a high number of moves the player can possibly take on each turn. The complexity of creating bots to play a game like chess is in the 2-player aspect of it. There isn't a single solution that must be found and can be found with enough trial and error, it is instead the case that the computer must be able to predict the moves in the future. This process is so complex that it was only in 1997 that a grandmaster player was beaten by a computer player created by the company IBM. A simple example of a game's compatibility with procedural generation is the Japanese game Sokoban, which takes place on a 2D grid and the player must push boxes onto buttons. The player can move one "space" at a time so the state space for the problem is quite small, opening the game up to procedural generation. 






Comments

Post a Comment

Popular posts from this blog

Semester 2 Submission

Project Outline This project is an exploration into player feedback and player reward in game mechanics. I have explored this by creating mechanics in Unreal Engine, imagining how they might be used in a game, and how a player might feel when using them. This exploration progressed into player reward in puzzle scenarios, which links into my current area of research. I looked into how visuals can create a language that the player will learn to understand while playing the game, and will guide them through problem solving in the game.  Project Context My semester 1 project was a core puzzle game, meaning the game was centred on a central puzzle mechanic and expanded from that point. I wanted to explore a mechanic that was more of a peripheral puzzle that exists as side quests to the main gameplay. Many popular game series have main gameplay mechanics with puzzles along the way, such as Batman Arkham, Resident Evil, and Tomb Raider. As these types of games are extremely popular and (a...
Post a Comment
Read more

Design Inspiration Semester 2

First person adaptation I decided to switch the view of my game from third person to first person. I made this decision because movement around the levels would sometimes give the player a confusing perspective (if they had their back to a wall for example). I moved the camera to instead hover above a pair of arms, that would be used to show the hand movements from a first person perspective. The challenge now was to recreate every animation in first person instead. I looked into first person games that think have good first person hand animations. I think Dishonored (2012) is one of the best example, as it relies heavy on the tools and abilities that centre around the player character's hands. One of my favourite aspects of the design is the way the knife moves from a regular to a reversed grip when entering stealth. The knife is clearly visible and serves its purpose in both grips and it tells the player they are in stealth mode without the need for another visual prompt (there i...
Post a Comment
Read more

Semester 2 Project Progress

13th January 2025 To begin this project, I am experimenting with creating different game mechanics. This is to build up a repertoire of skills in Unreal Engine and also see if any mechanics seem as if they can be adapted or incorporated into a game. I began by using free assets to make a character that can run around and execute an attack pattern. This was just to experiment with the assets and create a character that I could test other mechanics with. The first mechanic I created was one that lets the player grab an object and pull it toward them. When within a defined range, the player's reticle changes shape to indicate to them the object they're looking at can be grabbed. Grabbing it moves the object on an arcing trajectory toward the player. This could be used to grab a weapon to use, to bring an enemy closer to be attacked, etc. 14th January 2025 I added functionality for the player to hold an object and attack with it. When an object is pulled toward the player and reach...
Post a Comment
Read more