//scope issues

I came across this Tweet the other day:

It seemed to resonate with everyone, the comments being large agreement that scoping was difficult. And I couldn’t help but think how much it related to my current side project.

For the uninitiated, “scope” in project terms refers to how large a project is, in terms of content and systems. Open world games like Grand Theft Auto and The Elder Scrolls tend to have a large scope: a very realized world with thousands of NPCs, items, and hand-crafted narratives. Games like Splatoon and The Witness have a pretty modest scope, focused around a few features and never straying too far from that. And games like THOTH or my own Tetris Fighter have a tiny scope, with short completion times for both the game and the project.

Games with large scope require large teams, while games with small scope don’t require nearly as much, naturally. In fact, having the wrong scope for the wrong team size is problematic. 5 people trying to make Breath of the Wild? Not going to happen. 300 people sitting down to make Super Hexagon? Waste of resources. The problem always comes down to a mismatch in resources.

And one of those resources is time.

My goal was to make a game a week, with an extra week of buffer time if things got too crazy. That means two weeks from game realization to completion. With such a short amount of time, scope needs to be small. No original music. Simple systems. Not a lot of hand-authored content.

So why did I choose to make an RPG?


“Pretty Concise” was an attempt to make a very simple RPG. Abstract a lot of the systems out. Few stats. No combat. Story handled by little blurbs of text. English-only.

But RPGs, by nature, are not small scope games. Even this one, with a tiny scope, ended up needing a lot of work. After all, there were locations to hand-craft. 3D models to make. And, more than anything else, formulas and balancing to do. And those take time.

I wasn’t originally going to make 3D models. I was going to have everything be cubes. Nor was I going to have money or side areas. But, here we are:


And still there’s a lot of work that needs to be done.

But all that said, I’m becoming more and more proud of this little game each day. While it still has a bit to go before it’s actually fun, I think it’s a good start.

So maybe instead of making 3 games, I’ll just make one semi-big one.

Next game, however! That’ll have a better scope. Hopefully.

Haphazard Vs. Intentional Level Design

This is Part 2 of the level design series. Click here for Part 1, “Questions to Consider with Level Design”.

In spite of going into area creation with some idea of the final result, many novice level designers approach the actual formation with little concrete thought. Why does this level exist? What does it add? How long should it be? Any of those questions from before are asked often in retrospect rather than prior to actual creation. In other words, a beginner will just start to make something.

Just going to see what happens.

In writing, there are two kind of writers: freewriters and outliners. Freewriters will just write until nothing more comes out, letting the story “tell itself” and the character’s “move in their own directions”. Outliners will make an in-depth overview of the whole plot, and then find it hard to deviate at all, even when the characters and situations call for it.

Of course, these two extremes are not meant to be a binary. In fact, all writers find themselves somewhere on a line between the two, one more outliner than freewriter, and another more freewriter than outliner. Knowing about the two ends of the spectrum helps a writer understand the areas they lack: an outliner should try to focus on their ability to create unbridled, while a freewriter should give some more time thinking about and outlining major points in a plot.

Game designers, like writers, often find themselves somewhere on the line between haphazardly creating (freewriting) and intentionally crafting (outlining). And truthfully, though a lot of bad has been said about haphazardly building a level, neither one of these ends is all completely good and bad.

Haphazard Level Design

There are many reasons why a level designer might just start making something without direction, without it being a mark of inexperience.

Take a cave area in an RPG. The story basically dictates that the main characters are going to hide away from the empire in a cave, get lost and split into two groups, and then reconvene having bonded with the people they got lost with. It’s a powerful story moment. It lends itself to some interesting mechanics too: puzzles dealing with lighting, enemies taking advantage of the lack of party members, and rock-moving puzzles.

Everyone loves rock-moving puzzles.

How will our heroes solve this one!?

The point is, when working on a team, some things are going to be decided for you. Out of your hands. Other times, you’ll make an area based off of concept art and need to “place down” a level on top of the area. Even working solo, sometimes your own inner writer will be getting to areas of the game before your inner level designer is.

The benefits to haphazard level design:

-Area almost certainly introduces a player to an aspect of the world. When an area is built before the challenges are added into it, the level can feel more real and lived in.

-New ideas can spring up naturally. Like with freewriting, sometimes a level wants to tell its own story. Maybe a mechanic that wasn’t planned for makes an appearance because, when making the level, it just “fits”.

-Designers don’t have to feel restricted. Although great pieces of art often do arise from restriction, there is value in the untethered mind.

-You can often create more in a limited amount of time. Without much thought, levels can flow like water. In many open worlds, a large portion of the game is made haphazardly because, well, there’s not enough time to plan everything out.

The problems:

-Levels are sometimes truly bad and need to be scrapped. This can be a real source of wasted time.

-Levels might throw too many new concepts at a player at once. Without thought, each element could make an area feel confusing.

-Haphazardly designed levels often forget to connect to levels past and future. Built “in the now”, they might not utilize past skills or foster new ones. At worst, they might just exist without purpose.

What does this level even mean? Where does it connect to anything else?

With that said, haphazard design is truly a better fit for an experienced level designer, who intuitively knows how a level should be paced, and what kind of challenges need to appear.

Those aspects of level design, when handled by beginners, are often best done intentionally.

Intentional Level Design

I’m going to go out on a limb and say that most of the best levels are made intentionally.

That doesn’t mean that every inch of a level was done with precise focus, but rather when a level was being added, there was real thought being put into it.

“Ah, this is going to be the first level you go to after being granted the double jump skill. The very first section needs to let the player play around with it, and understand the timing. The first jump will be vertical, requiring the double jump. So if the player fails it, they don’t have to do any kind of backtracking.

“The second jump will be over a small pit, so that if they do fail, they have to backtrack to a small ladder and restart the jump. This adds some consequence, but not too much. On the other side of the pit will be some basic reward.

“Then we’ll get them feeling confident again with some ground enemies they have to kill. You know, ‘differences of kind’ and all that. But now we’ll pepper in a few flying enemies that can be hit more easily with a double jump. Show the versatility of the double jump.

“Okay, toss another pit like that second one. Maybe throw an enemy in it that shoots fireballs up. If the player doesn’t time their jump well, they might get hit by the fireball and fall in the put. But then they can just kill the fireball spraying thing and make the challenge easier.

“Now, we don’t want to focus entirely on double jumping. That’ll feel too gimmicky. So let’s slow things down with a little puzzle. Gotta light all these lamps in this cave. Oh yeah, I forgot to mention, this is in a cave. Okay, so there’s this lamp lighting puzzle. Definitely don’t need to jump, but hey, feel free to. Maybe it’ll make this puzzle feel better.”

“What kind of puzzle, chief?”

“Eh, just make it. Doesn’t really matter. Haphazard, or whatever. Something simple.

“Okay, next up, a big pit. In fact, a couple big pits. Each jump is from one nice crystal path to another. Give the player a little spectacle. If the player falls, they die. This will ratchet up the tension a bit. But the checkpoint will be right before, so no big deal.

“Then we end on some simple jumps, a few challenging enemies, some nice reward, and the level end. The difficult jumps will be all behind us, and the challenging enemies will provide a satisfactory end to the level, but without testing any really new skills.”

This kind of a level will almost certainly be better than something made without thought. Things are being placed with order, and there’s very few pacing problems. The level is built to intentionally teach a skill and reward the successful learning of it. The big con is that the level will probably feel less “lived-in”. Like a Mario level, it will be mechanically interesting, but obviously designed. Art added to the level after the fact will attempt to hide some of this design, but cannot mask it entirely.

I think we can all agree that this doesn’t seem like a real, living place. It does seem interesting, however, and looks fun to play.

The benefits of intentional level design:

-Planning out a level will make a level feel better to play, 99% of the time. Everything will be placed with thought as to how it can build player skills and reward them.

-Thinking about a level and writing down how the level will play allows feedback before a level is made. It tends to be a lot faster to design a level on paper than within the game engine itself.

-Intentionally building a level often focuses on the core experience. While haphazard design can lead to things being added for no reason, intentional levels tend to not get bogged down in unimportant details.

The problems:

-Thinking about a level for too long, especially on a small team, leads to games that are never finished. Sometimes you just need to make something.

-Intentional levels often feel built. It can take away from the believably of the world.

-If your design experience is limited, level designs will often all take similar form. Your typical “Introduction–>Expansion–>Twist–>Conclusion” doesn’t work and shouldn’t be used for every level. There needs to be enough to distinguish one level from another.

Regardless, my general feeling is this:

As a beginner, focus on intentionally designing levels. After you have enough experience under your belt, feel free to let instinct take the wheel.


If you find your levels are not working, take a look at them again and ask: why aren’t they working? Was there not enough thought placed? Too much?

The ultimate truth is that all design requires thought. It doesn’t just happen one way or another. Ask questions. Get the opinions of others. Be critical. Look at your creation from afar and see what it does well and what it does poorly. And from then on, reevaluate the methods that brought you to making that level.

At the end of the day, find what works for you. And go from there.

//side project: Tetris Fighter

Hey guys. Over the course of the past week, mostly in my off time, I made this short Tetris-platformer hybrid. The game is short and simple, but I think you’ll be able to find something to love.

TetrisFighterV1 2017-04-21 10-12-05-91.png

The game is available on itch.io here.

If you like it, please tell your friends!

The reason I’ve made this game and will probably make 2-3 others over the next month is because I’m looking to build up a portfolio of simple games that show off my range of game design abilities. Certainly, they aren’t quite as thought out and rigorous as usual, but if this was any indication, they’ll be fun to make.

And, honestly, sometimes people prefer the simple games.

TetrisFighterV1 2017-04-21 10-17-34-13TetrisFighterV1 2017-04-21 10-12-19-75TetrisFighterV1 2017-04-21 10-17-39-14

We all dream of making the next Fez or Undertale or The Stanley Parable. But there’s value in these little endeavors as well. Especially as a means to broaden personal horizons.

Anywho, enough blathering. Go check it out!

Questions to Consider with Level Design

Perhaps one of the biggest hurdles to making a good game on a good schedule is making sure that everything that is made for the game ends up in the game. Many times, assets aren’t used for one reason or another. Maybe an asset fits an earlier idea for the game but not some later version. Or, plainly, it could be a placeholder. At the worst end of the scale, something might not be used in the end because it was ultimately without any redeeming quality.

In spite of FFXIII being rightly criticized for its level design, the areas were still fine to look at aesthetically. And they did fit into the world itself. While someone might look at FFXIII as a poster child for bad level design, I’d argue it’s biggest failing was in a lack of “differences of kind”. But that’s a story for another day.

In platformers, hand-made dungeon-crawlers, action adventure games, and RPGs, among others, level design can be one area in which lots of time can be consumed and yet poor quality assets result. What factors make or break level design? Why can be it so costly?

When approaching level design in any game, a few factors need to be considered prior to putting anything in the game.

  1. What is the purpose of this level?
  2. How does it relate to every other level?

Each of these questions still needs to be broken down further, to their more specific components.

    1. Does this level teach a mechanic?
    2. Does this level introduce the player to an aspect of the world?
    3. Does this level attempt to challenge a player’s current skills?
    1. How difficult is this level compared with the ones around it?
    2. Does it use mechanics previously learned?
    3. Does it fit in thematically with the areas around it?

There’s a lot to consider when looking at a level. Over time, game designers come to understand the process on an intuitive level, but the factors are all there. Beginner game designers might want to take a more focused approach, and actively think about what they’re adding into the game? Can you answer all the above questions?

Instead of going with Mario 1-1 or another common first level, let’s look at Route 1 in the first Pokemon games and see if we can answer the questions. I’ll put down my thoughts, but first see what you come up with.


Does this level teach a mechanic?

Yes. Rather explicitly, because it’s the first game in the series, it tells you (and then you subsequently experience) the fact that wild Pokemon only appear in tall grass. Shallow grass and roads are totally safe. It also teaches the player about ledges they can go down, not up.

Does this level introduce the player to an aspect of the world?

The towns are all separated by these routes with wild Pokemon. While towns are safe, these areas are somewhat dangerous. Notably, the patches of random wild grass are most heavily concentrated close to the town. They get easier to manage the closer the player gets to the end, which could trick the player into feeling like they’ve already mastered some element of the wilderness.

Does this level attempt to challenge a player’s current skills?

As a first testing ground, an introduction to a mechanic is already challenging a player’s skills. While they’ve had the chance to move in relative peace in the first town, the combination of ledges and wild grass additionally challenge the player’s ability to move around the space itself. However, it doesn’t last so long as to completely frustrate the player.

How difficult is this level compared with the ones around it?

This level is much harder than the town, which had only one story battle, but with the player’s control of a level 5 Pokemon compared with the surrounding level 2-3 Pokemon, it shouldn’t provide too much difficulty. Even if the player gets tired, they can jump over ledges all the way back to the beginning, with the only bit of grass on the return route the patch right in front of the town.


Does it use mechanics previously learned?

Combat is taught in the first town, and here it is on display. A direct connection with the information the player was previously taught. However, elemental weaknesses don’t have to be considered here. Just raw HP and damage matters most.

Does it fit in thematically with the areas around it?

This is the first introduction to the wild, right after it was previously discussed with the player. Artistically, it doesn’t look too different than the first town. Aside from it being a little short, and like many Pokemon areas, focused on design over realism, it feels plausible that this stretch of land exists. Like many RPGs, it does seem odd that someone raised in this world still needs someone to explain to them the dangers around the corner, but it’s a minor complaint.

Overall, the area succeeds. It’s a solid introductory zone. Likely, this area underwent some of the most intensive testing as first sections of any game are often the most scrutinized.

While I don’t know the personal development of this game in particular, many games and books will do much of their final editing on the first section once the whole game is in place to ensure that the initial bits reflect on the game as a whole.

As for why level design can be so costly? Well, that’s the result of imagination; of Haphazard vs. Intentional level design. And that’s a topic I’ll discuss next week.

This is Part 1 of the level design series. Click here for Part 2, “Haphazard Vs. Intentional Level Design”.

//starting on polish

This week saw the end of work on the final level. That doesn’t mean that the level is completely done, but that for all intents and purposes, the basic structure of it is in place.

With the levels all done, in their most basic implementation, there remains only 3 aspects to finishing the game:

  1. Add in the final voice overs to each level, including the extra dialogue (stuff you hear when waiting around in certain spaces)
  2. Polish each level, based largely on tester feedback
  3. Fully implement the save system, and potentially the upgrade system

This doesn’t take into account the fact that I need to finish working on the dialogue, officially record the final voice overs, wait for all the music to be finished, wait for cutscene art to be finished, as well as the decision whether or not to include bonus areas or how the level select should be implemented (world map, or big screen with each level as a button).

Regardless, getting the final level basically done certainly gives an air of finality to the project being completed.

I’m working on getting a video ready for submission to the Boston Festival of Indie Games. And this weekend I’ll hopefully get some decent playtesting information. That’s going to be exciting.

Even though I’m close, that April 15th deadline still scares me. Gotta get this done!

//testing, music, and randomization

This week saw more work get done on the final area. With all my additions, I gave it a nice playthrough and I’m generally happy with the results.

Often in development, more time goes into working on the game rather than playing it. In some ways, this comes from a trust in yourself that the things you’re doing make sense and fit into the game. And, that for every week you put into a game, you get about 10 minutes of actual additional playtime in the game. From that perspective, testing might as well be every month, so you have almost an hour you can play. Gives you a nice macro look at how the game is coming.

But, really, best practice says that testing should be happening often.

One of the best things that happened this week was getting the final version of music for the first area from the composer. It’s so good. SO good. I may be overselling it, but it really does sound good in the game. Accompanied by a slightly updated sound system that keeps a song playing between scenes and the game feels a lot more like a real game.

Getting all the music and voice overs, will, I hope, make the game feel done.

Aside from that, I added some randomization to the jump sound so that it doesn’t get too repetitive. Although the real key might be to have two or three different jumping sound clips and randomly choose between those. The game isn’t too long, so hopefully the sound isn’t too annoying, but there is a lot of jumping in the game.

All in all, a good week. Could have been better, but I feel accomplished.

//BFIG, cutscenes, and decent work

It’s been exactly a month since my last update. Too long. I actually couldn’t believe it when I saw the date.

I’ve been working, of course. The final area is coming along, and I’m happy with how the game is fitting together. It definitely needs more work, but I’m sure every developer feels like that even after release.

It was a rookie mistake to go into this narrative-focused game with a whole outline of where the main character would go and then build that world exactly. The openness of most of the world has led to some difficulties, specifically in camera movement and player direction. The focus was on making a big world over a detailed world, and while that was part of the entire feel for the game, I definitely think it ended up making this a lot harder for a single person to complete.

But, this isn’t a postmortem. The game’s not even out. There’s still time to fix some of the problems.

On the other hand, I was happy to add pictures to my opening cutscene.


None of them are good, but they work as placeholders. Immediately, people started paying attention to the opening of the game, where they traditionally had not. That’s good. Now to hope I can get an actual artist to make some final versions of these.

April 15th is the deadline for submission to the Boston Festival of Indie Games (FIG). That means I have to make a short video explaining the game and send in a demo, among other things. Can’t say I’m super confident that it’ll get there, but I’ll do my best.