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. This is important, as with the “feature creep” of the mechanical side of development, micro-detail falls to the wayside when a player is actively engaged.
I started off gaming in the early 90’s when I was around 3 years old. My dad had just purchased a 486, and along with it, some shareware floppies of Doom, Duke Nukem, and Rise of the Triad. First person shooters were my bread and butter, and using the BFG for the first time in Quake was honestly a magical moment. A couple years passed, and I moved onto Quake 3, and I had another magical moment with the rocket launcher. Blasting myself into the air to meet an opponent as they descend, blowing them into tiny bits… I get teary eyed thinking of it as a grown ass man.
I like arena shooters; I like how fast paced they are, how dying is sometimes the quickest way to getting the upperhand, and how frequently knowing what to do isn’t as important as knowing when to do it. I’ve been developing games for most of my life, mostly as a form of self expression, an outlet for my creativity. I’ve used UDK for some time, but since Unreal Engine 4 was announced, I’ve been developing a great deal with it. It’s easy to use, and as an IDE, I don’t think there is anything better at the moment that can give you the same results.
A lot of back end work has been done since these screenshots were taken, though, I’ve lost a bit of steam overall in its development. I typically develop something until it is no longer fun, and move onto something else. More than anything, this has been an exercise in the ground up basics of developing a first person shooter, animating models, rigging them, and optimizing performance for lower end rigs. Realistically, I’ll need to start over to be happy with Mages Acension going forward; hindsight might be 20/20, but I must have been blind going into this — I did some stupid, hacky, short term things to get the game working half decently, and these hacks are what really limited the game from progressing.
In total, I had about 15 working spells, a blink mechanic, and multiplayer working. The game aspect was a little lacking, since scoreboards, timers, and re-spawning never saw the light of day in any public / alpha release.
Tables. RPG’s need tables. Lots and lots of tables, and lots and lots of planning.
The idea here was to use the smallest pallet possible, and create a game where all you do is walk. It was intended to be cyclical, meaning that you ended the game as the story began. The man in the red cloak entered the wastes of gloom to find the deathly oak, the source of the gloom, and the blight that came with it. It’s an idea I might pursue at some point in time, but I’ve realized that many people will be let down by using games as a medium for storytelling, which is unfortunate in my mind, as some of the best stories I’ve encountered have come from games.
I’ve got the source laying around here somewhere, but for all intents and purposes, this was the entirety of the game that would later be known as “that one time I tried to make a sequel to a crappy game”.
This had less to do with mechanics, and more to do with atmosphere and story. That being the case, I quickly lost interest as I realized my time was spent on other projects, such as Book of Leaves 3: The Book Strikes Back!
The book of leaves started as an exercise in game development. Many times developers, especially indie developers, will gave an awesome story, great characters, and lots of cool unique ways of combining the two. Unfortunately, this leaves them with a huge gaping hole where gameplay should be. I set out to create a game, in it’s simplest form, and create a story around that gameplay. Around this same time, FlappyBird was just picking up steam; I liked the concept of simple mechanics with a steep learning curve.
To ensure that only the most hard core players would actually play my damn game, I created my opening title to reflect that this game means business. No options. No control configuration. One size fits all.
You play as Harold, a simple boy, who became lost on his way home from school. During his walk through the forest, he finds a strange book. And then is immediately attacked by a monster. The name of the game is simple; manage your stamina. If you run for too long, you become winded, and cannot move. The monster can then reach, and ultimately, kill you. If you do no run enough, the monsters random bursts of speed will close whatever gap you’ve created, and again, you die. It’s about finding balance!
This game is pretty terrible, but it was a lot of fun to develop!
Book of Leaves: Windows | Android
A world for a dungeons and dragons 5th edition campaign I’ve started working on. I’m not new to world building, as I’ve done it before with Ultima Online modifications and conversions; I used some of the general locations and lore from previous maps and combined them here. Without going too far into it, I’ve decided that Altherra, the world this map reflects, is a super earth. The main continent, for now known as The North, is about half the size of the united states. This kind of scale allows other players in my group to add locations and their own lore without necessarily interfering with the lore I am establishing here.
This is still very much a work in progress, but its nice to see it coming together.