Nicholas Sceusa

Gameplay and Level Designer

nicksceusa@gmail.com

Game Design Exercise: Adding Complexity - 8/15/25

Recently I have begun tackling some game design exercises. This is to give myself more experience thinking through projects and analyzing my choices. This one comes from “Think Like a Game Designer” by Justin Gary.

Game Design Exercise: Make a Complex Game from A Simple One

• Take a simple game (such as Tic Tac Toe) and add depth to it

• Go through the design loop and see how it feels

• What got better about the game?

• What got worse?

• Was the tradeoff between depth and complexity worth it?

As a side note – while the book does not have a specific definition of complexity, it seems the overall descriptions tend to focus on the number of options available to the player as well as the overall mechanics and rules to create the gameplay. In short – more complex rules, increased mechanics, and options for the player.

Depth is defined as how intellectually stimulating the experience is. I would also suggest that depth arises out of how the mechanics apply to the overall game from simple "in the moment" decisions all the way to the end game.

The game I decided to utilize was Tetris. While simple, the game can become challenging very quickly. In case you have never played Tetris, the main gameplay loop involves manipulating a series of shapes, known as tetrominoes, and attempting to stack them to create solid horizontal lines. When a line is created, it is cleared from the area, allowing you to stack more shapes. The goal is to play as long as possible via avoiding the stacking of shapes. If any block touches the top of the screen, the game ends. Here is a rough outline of the gameplay loop:

I started brainstorming and thought of adding some secondary gameplay. Since the blocks reminded me of Legos, I thought it would be interesting to have the player create some form of structure and hold off an invading army of some kind. You could go with alien spaceships for a sci-fi feel or invading Vikings for either a historical or fantasy aspect. Unfortunately, the more I thought about it, the more unfeasible the idea appeared.

While the initial idea was interesting, these new details created more questions. How does the army attack the fortress? Do they destroy a block each? Should the blocks have stats? Does it make sense to have different types of blocks like iron or stone? Do they attackers have energy which is used up as they attack the blocks? What about the structure? Do they climb, or attack horizontally until blocks up above the fall?

Furthermore, this idea goes against the main goal of Tetris – make horizontal shapes so you can clear the game space and keep building. This was such a glaring issue that I decided to abandon this idea altogether. I realized my RPG focused brain was kicking in and it was not assisting with the game design. It added more complexity but worked against the main design and removed depth instead of adding it.

I recalled reading in “Rules of Play” by Katie Salen and Eric Zimmerman, a book I highly recommend, how all games are a simulation of something. However, as we approach creating a more realistic simulation, adding more detail, complexity, and graphical fidelity, we move away from a game and the simulation becomes a replication of real life. This penchant for adding in more realistic details at the cost of gameplay is commonly known as the “Immersive Fallacy”. Essentially it is a belief that games benefit primarily from higher graphical detail.

While I love graphics as much as the next guy and it can benefit certain types of games, the goal of a game is to create gameplay and fun. That means interaction and choices. Not just how it looks or how complex it can become. And in this case my detailed focused brain was leading me in the wrong direction. I was adding unneeded complexity to Tetris and "realism" which did not benefit the game. I had to tone it back.

I went back to the drawing board and attempted to think of a mechanics that would add some depth without moving away from the core gameplay. After some thinking, I thought of rotating the Tetris play area. At certain periods the screen would rotate in 45, 90, or 180 degrees, causing players to manipulate shapes from different angles. Existing blocks would shift down and the player would need to work with this "new terrain" while manipulating blocks on a angle. Here is the new gameplay loop along with some pictures of the initial idea":

The new loop is very similar to the original. A slight tweak was made to check for horizontal lines before doing a “top of screen” check. This is to ensure that the player could have a chance to clear blocks before getting a game over.

A few other details also need to be considered:

Screen Adjustments – players would have a reduced area of play, particularly with 45-degree angles view. The screen might need to be extended or adjusted in some cases so players still have room to maneuver blocks.
Out of Bounds – Traditionally there is only 1 part of the screen, specifically the top, that is out of bounds. This is not an issue for when the screen is rotated 90 or 180 degrees. However, the 45 degree angle has two “top” parts since the corner of the screen is now directly up. Which should be out of bounds? Should it be the smaller length of the rectangular area that is pointed up?
Shifting Blocks - will the shifting blocks make it impossible for the player to continue? Can they be "locked out" of the game?

The 45-degree angle rotation is proving to have its own set of complications. It is possible that it might need to be cut for clarity, but I would be interested in seeing how it performs in a prototype.

The only thing to determine now is how often the screen rotate and when. I decided that the rotations should occur on time delay as opposed to score. This would give players a chance to get used to the mechanics and more experienced players opportunities to earn a higher score. I experimented a bit with a spreadsheet and come up with this chart as a starting point.

Essentially the rotations start out slow with some variability on the exact time. Every 5 rounds (or after every 5 screen rotations), the rotations increase in frequency every 20 seconds, then swap to 10 second when it reaches the minute mark. The randomness factor also decreases to avoid drastic variability in the rotations. The speed of the blocks still increase constantly after each rotation. I put in a random number here, but it will primarily depend on how the speed is calculated in the program. Eventually things proceed to the point where the screen rotations almost continuously, but the speed should be kept reasonable to give players a chance to continue playing. This may require a separate chart and will definetly require more testing.

I also experimented with the plotting the timing using a linear equation and a parabolic arc if we want some more gradual changes instead of the ‘stepped’ version I outlined in the spreadsheet. I played around with the numbers in my composition book and on https://www.desmos.com/, then plotted them out for reference.

I think this idea has more depth but not necessarily more complexity. In this case, this is a good thing. Not all games need complexity to be fun! It was surprising how this exercise was more challenging than anticipated. It was good practice and it gave me a chance to observe my own tendencies in design. Not to mention this shows how designing something that is simple (or reasonably so) is sometimes more difficult then designing something complex. I will plan to do more exercises in the near future!

-Nick

Page updated

Google Sites

Report abuse