Game Design

Hey everyone,

This isn’t specific to Unreal in any way shape or form, but I wanted to start a thread where we can discuss elements of game design, and how we can improve the games we develop, and in turn, the games we play. I frequently see developers take to UE4, or any other engine, full steam ahead - they have played many games, developed few (or none), and want to borrow mechanics from numerous existing titles to make their magnum opus.

How many times have you seen someone working on “Well, it’s kind of like Zelda meets Dark Souls!”, or “I’m making an MMO that combines Minecraft and DayZ and WoW!”. Well, you probably haven’t run into those in specific, but I hope it gets the point across. Often times developers will attempt to utilize mechanics from a game, or several games, without understanding why or how those mechanics were implemented, which often leads to a dead end in development. I hope that by sharing trials and tribulations, as well as resources, tips, and just commentary about game design, we can help each avoid the numerous pitfalls of game development.

A problem I see frequently is that developers start with an interesting idea, and only after the idea has been realized, they attempt to make it “fun” by adding mechanics, and systems, and unlockables, and achievements, et al, rather than starting with a fun concept, and adding systems that support and improve the already fun concept. I’ve done a terrible job of condensing the idea of bottom up game design, so just read the articles below:

Top-Down / Bottom Up Game Design

Another new series attempts to dissect games & their mechanics by Keith Burgun, called 3 Minute Game Design, is really well done. Try and support this guy on Patreon if you find the videos interesting - I think the medium and format make these ideas far more approachable than some of the alternatives.
It can be found here:
I believe the heart of the issue for many is that they want a game that plays like “X”, but combines aspects of “Y”, without understanding why either played the way they did, or why they were successful. It’s for this reason that it’s simply not enough to say “…because, uh, Zombies!” anymore - they’ve been done to death, and for all of the wrong reasons. Games have successfully used zombies in the past, and will continue to use them in the future, but we’ve seen a lot of junk come down the line that piggyback on the core mechanic of zombies and all that they entail.

Another great resource is David Rosen’s talk at GDC '14. If you’ve got the time, I promise it will be worthwhile. David goes on to explain how, before any and everything else, he made moving around in his game world (Overgrowth) fun in and of itself. This will not translate to every game, but I hope this gets the general theme across. He also discusses some of his old game jam entries, and how implementing basic functionality (such as the procedural animation) became cornerstones of Overgrowth.

Another rather large discussion in and of itself is level design. We’re fortunate enough to have so many talented environmental artists and level designers here that some might think the discussion isn’t worth having, but for every awesome scene we see in the WIP section, there are a hundred developers scratching their head, and wondering why their levels and scenes feel inadequate.

Being able to physically tell a story through your environments is important. Physical exposition can be tricky, and a lot of developers get caught up in the micro-detail of a level, which can often times be counter productive. Rather than focusing on relaying information and direction to players through the world, they focus on insignificant aspects that most players will never enjoy or even appreciate. In the same way that writers call words “real-estate”, in an attempt to convey how precious each and every letter is, level designers should in turn realize that only the most important (macro) visual aspects of their level will ever be necessary to playing the game.

A tangential, but supplemental argument - Mini-Maps are stupid:

Here’s another great resource for level design that hopefully everyone is aware of:

Specifically, this is a good write-up that should apply to most indie developers:

Magnar uses a “wide brush”, focusing on macro elements initially, and follows up with a detail pass to get important micro detail only once the level is almost complete.

If people are interested, I would be glad to post more resources and continue this discussion. I am also setting up my blog to follow my own development, the challenges I encounter, how I resolve them, and my thoughts on games and game design in general.

Does anyone have thoughts, questions, or links to resources the community might find helpful? If so, post them here!

An interesting post and to answer your question, “Nothing original ever gets created.” This is evident in movies where remakes and remakes of remakes of remakes are remade. Also when an original idea does see life it is often met with negativism simply because its out of the norm.

Advent Rising comes to mind. But even this game down to its core borrows mechanics from other games.

Stranger’s Wrath combines many mechanics with great visuals and story. But again its an original idea mixed with standard mechanics.

I am also guilty of this as my game which I am working on is derived from multiple mechanical aspects such as 3rd person camera and so on. But I will attempt to be different from the rest with fresh ideas.

Not sure if what i said made any sense.

I’d actually never heard of Advent Rising until now, pretty interesting stuff.

I also agree with you - it seems as though lot of what we’re seeing on a computer or movie screen are derivative, if not a remake/reboot. I’m always excited when something not associated with an existing IP comes out.
I don’t mind seeing derivative gameplay mechanics in a game, it’s just that it seems a lot of games are becoming derivative for the wrong reasons. Not every game needs a mini map, or an exclamation mark over an NPC’s head to indicate something of importance. A couple of big titles come out with a feature that works very specifically for their game is then used by the entirety of the next generation.

This video does a pretty good job of communicating the idea. I don’t agree with everything, but there’s a lot he gets right:

Another design trend I see here, on greenlight, kickstarter, etc… is huge, open world games. Don’t get me wrong - there is definitely something awesome about the scope of certain games, but many games fall flat on their face in this respect; they feel repetitive, and worse - empty, like huge wastelands. It’s long in the tooth now, but one of the games that exemplified this was Kingdoms of Amalur. I understand the game started as an MMO (or had plans to become one), but it should never have felt like a single person running around in an unpopulated WoW server.

Similarly, procedural generation can be used to great effect in some games, but it’s hard to get excited over a games that feel devoid of a human touch, and since many of these huge games rely on procedural generation to some (or great) extent, it seems like kind of a waste. Why not focus on a small, detailed/set dressed area instead? I think most players would rather explore a smaller area and find something worthwhile, than a huge one, with absolutely no purpose.

What it comes down to is, for most games, they should focus on a couple of things and execute them really well, and build mechanics as an extension of the main gameplay - to facilitate the point of the game - rather than a bunch of independent systems. For example, ICO was extremely basic, and is still kept in quite high regard by many, and had only a handful of actual mechanics.

As I progress in projects of my own, I sometimes find myself midway implementing a feature because it’s a “staple” of a horror game, but is rather unnecessary, and would have otherwise limited the end product. I’m working on a VR horror game, and after I had added a flashlight to the game, I realized that I was making every horror game ever. I then added a cell phone instead; not a new one, either, one without a super bright LED, or a modern AMOLED screen. The protagonist using a Nokia for torch increases tension significantly, as it throws off substantially less light. The flashlight has become THE empowering device of many horror games; stripping that away from someone leaves them vulnerable. I still haven’t decided if I am even keeping the phone-as-a-torch mechanic yet, but since the cellphone plays a somewhat significant role as it is, it feels right.


very very very, very interesting reading stuff…
Just my 0,02€ on this :slight_smile: :

Absolutely true. I think one of the reasons that Zombies get so much screentime in computer games (or films for that matter) is the reason that they dont require much story logic to do what they do.
If I want the player to be attacked, then there must be a logical motivation for the attacker. If it is a (living) soldier, farmer or housewife, you need to establish why they would attack the player. Zombies on the other hand just need to be Zombies, thats enough explanation.
Another reason might be found on the legal side. If I kill zombies in a comoputer game, I kill non human entities, which will result in a different rating that if “humans” would be the opponents.
In countries like Germany this makes a huge difference. Of course I could make a game where I only shoot animals (abolutely allowed), but animals cant wield firearms and hence not shoot back. The result would be pretty boring. So the zombies are often the only option left to legally have a humanoid enemy in a game.
A side note on the legal thing: Not only national governments or transnational institutions like the EU impose content restrictions. As far as I know Epic itself does not allow AO rated content to be released through UE4.

Many people might underestimate the consequences of design decissions. They block out a level and start working on the first detail section. That section is now refined to exhaustion. What they dont realize is that the level of detail then also would need to be applied to the rest of the level as well. If I have 200 equal “places” in my level and I add detail to one of them, it would also need to be done for the other 199. So every step on the first detail section actually costs 100 fold.
But that is not only happening to (amateur) game developers. :slight_smile: When they made the film Tron, they used composits (8 per frame) for the various scene elements. For the integrating the glowing effects on the optical printer, 3 hand inked masks had to be created, for each composit.
Then they decided that they would need more composit layers and large portions of the film ended up with up to 12 layers. Then they realized that this meant over a million(!) additional hand drawn masks required. They ended up hiring entire Korean sweatshops and used a fleet of hired trucks for temporary storage…
So yes, love to detail can get the best of us, even professionals :wink:

I think all thst minimap and other gameplay helpers are implemented to make the game more attracted to the ADHD player types who actually dont want to invest time learning the game and its mechanics, but would prefer a win-now button.

Its for the studios nowadays a much more financial investment and risk to produce a movie. My favorite movie, THX1138, was made for $777.777,77. It was new, it was original.
Warner Brothers didnt liek it, but could live with it. If today a 300 million movie fails, the studio is pretty much history.
But today people are spoiled. They only want to watch 300 million movies, because they are in HD, 3D and whatever-D…
So often when I propose a movie title for watching with friends, I get comments like “Jeez. this movie is from before 2010. I dont watch such old stuff. The effects suck.”
But that seems to be the style of the time…


This topic deserves more discussion as it’s one of the least understood but no doubt one of the most important aspects of game development but it’s difficult to get a general discussion going on the subject. It’s a little like trying to discuss the topic of “Art” which is quite a broad subject. If you would like to continue this perhaps we could narrow the scope of the discussion?

In the mean while, on the current general discussion:
One tool that I know of is the Mechanics-Dynamics-Aesthetics(MDA) framework. It’s strength is that it attempts to bridge the gap between the developer and the player by a chain of cause-and-effect-like definitions.

Right next to the developers point of view there are the Mechanics. These are the tangible rules that make up the game, what kind of commands the player has access too. In a platformer example a few of the mechanics can be Running, Jumping, Gravity and Platforms.

By looking at how different mechanics can work together you get Dynamics. By combining Running, Jumping, Gravity and Platforms you get something like a Puzzle or Challenge. You need some kind of coordination and timing to land each jump on each platform.

On the players side of the spectrum the dynamics will manifest them selves as Aesthetics. Aesthetics in this case is not a synonym to Visuals. It’s the Experience the game provides. If you land your jumps the aesthetics will be something like Accomplishment or Pride. If you fail to land your jumps the aesthetics will probably be something like Anger or Frustration.

The mechanics is what we actually create as developers. We don’t create Dynamics as much as we allow them to form because of what Mechanics we create. If a Dynamic turns out to be problematic we don’t alter the Dynamic itself, we alter the underlying Mechanics. You can think of the Mechanics as parameters we tweak in a simulation.

On the other side the Aesthetics is always what the player gets when they play a game. When you play a platformer it’s not important that you can jump onto platforms (or miss them and fall down). What’s important is whether or not you make that jump and the feeling you get when you do land it. The player does not care about the Mechanics or the Dynamics, only the Aesthetics.

It’s important to remember that this is a tool that you can use when you have to and not something that is supposed to be a silver bullet to good design or even a starting point to designing a game. One place where this may prove to be useful is to reverse engineer your own design to address problem areas. A good example would be the frustration that many players feel when losing in FPS or maybe MOBA games (frustration is certainly not limited to these genres but I think we can agree some of the worst cases can be found in games from these genres). Frustration is an Aesthetic. If we’ve encountered this Aesthetic in our game we can examine the situation to find what Dynamic caused the Frustration. The Dynamic is of course defined by a set of Mechanics that we then can go about tweaking to alter the Dynamic.