We had a death in the family this week. I didn’t get much work done.

I think death is often dealt with poorly in games. To those that experience loss, it can feel trivial. And for those who haven’t experienced it, sometimes the way the characters handle it seems like an overreaction.

Part of it, like with other kinds of media, is that death is used as a writer’s tool. Usually to move the plot forward or help another character grow. In books like Slaughterhouse-5, death is trivialized to aid the theme that all life is fleeting. In A Song of Ice and Fire (Game of Thrones), death is there to lend character to the world, give it a realism that isn’t as common in fantasy, and promote the sense of real danger that comes with any interaction.

Video games have another tool that helps. Where books deal more with emotions of the characters, video games let you actually feel the help another character gives. When a capable party member like Gremio (Suikoden) or Aerith (Final Fantasy VII) dies in an RPG, or someone that’s aided you during the entire playthough like Agro in Shadow of the Colossus or Estelle in Tales of Vesperia temporarily goes away, you feel that real sense of loss. You’re weaker without them.

But video games are much worse at dealing with non-useful figures. People that are with you, that provide moments of joy, but are largely just there and occasionally make your goals more difficult to complete. The real experience.

I don’t have a solution, per se. These are just idle thoughts.

But it’s important to be aware of any medium’s strengths and weaknesses. With video games, story death is better handled when mixed with gameplay. When you want a character’s death to be felt, make sure that character was very useful. Make sure that no other character can easily or perfectly replace them.

This is what made the deaths in The Legend of Dragoon so laughable. Although I enjoyed the game, whenever you lost a party member, you’d immediately gain a new party member that had all of the same skills. The spear-wielding knight dies. He was a great party member. You feel that sense of loss for all of two minutes before the king strolls up and says he’ll help and, don’t worry, he trained under the knight so he has all the same skills. When your healer leaves later in the game, another character just pops on by with the same skills. It’s a re-skin. Aside from a little change in dialogue, there is no loss.

Books (and words in general) deal with mental emotion and inner thoughts. Movies deal with facial emotion and that sense of believability that comes with seeing real people moving around.

Games deal with interaction. Loss, and all emotions you want a player to experience, need to be tied to that interaction to be felt as completely as possible.

But how to deal with the death of a character that had no use? Either it’s a problem waiting to be solved, or just simply better left to other media.


//side project: Hakai

Finally back to a game with a better scope!

“Hakai”, meaning “destruction” in Japanese, was based largely on the game breakout. It’s a short arcade-style action game with over 20 levels and a little story to guide it along.


You can download Hakai on itch.io here (for PC and Mac)

The game supports keyboard, mouse, and gamepad control. Which, until this point, none of the games I’ve made had such variety in user control. Chalk that up to the simple gameplay. Perhaps I’ll include touch controls in a future update. Depends on the interest I get.

The game, like Tetris Fighter before it, has a few glaring bugs that remain, including levels where sometimes the ball stretches and a few levels where the ball can go through the enemy even before the enemy is dead. I have ways to fix these problems, but ultimately, I think I have more to gain by working on the next project.

For two busy weeks, I’m pretty happy with where I ended up. But this is definitely a game I could come back to in the future and potentially make a sequel to.

We’ll see! For now, go on over to ichi.io and enjoy it!

P.S. Consider purchasing the game if you’d like to support my game development efforts.

//team effort

The hardest thing about working solo is, tautologically, being solo. That lack of a team.

It’s not the lack of bouncing ideas off of. I’ve ample friends and family with whom I can carry on hours long conversations about minutia. Certainly, talking with experts has been enlightening, but not in a grand, earth-shattering way. It’s the +1 on a Bronze Longsword. Helpful, but there are better things out there.

No, the lack of a team rears its head most in the time-management aspects of game development. Though managing a large team can be complicated, and keeping everyone on a clear schedule while trying to keep creative and open can be rough, having a one-man show means that if I want 3D models, I need to not be writing, or coding, or building, or marketing, or any other aspect of game creation.

If I want models, I need to make models.

And that’s tough. Because, as is often the case, I want to polish something to a satisfactory level. I want the game to work well. I want there to be that proverbial “zing” when everything snaps together perfectly. And sometimes that also means leaving something half-baked in order to focus on some other aspect of the game.

What all this often boils down to is that everything is the bare minimum. The graphics are simple. The coding is basic. There is no polish. But it’s done.

In the world of writing, most beginning writers are given the advice to just “finish their book”. Don’t endlessly rewrite the first chapter. Get to the end. One way to do this is to write short stories. Another way is to just never edit, and free-write all the time. In the end, the act of writing all parts to the story–beginning, middle, and end–will improve the writer’s craft.

But there are aspects that aren’t covered in that process. Editing. Polish. The ways in which a book, or game, goes from being “good” to “great”.

As I work to make a portfolio, and even with The Many Sides of Ball, I sometimes get caught up on the things that don’t make sense to do. Very dynamic cameras. Interesting little puzzle components that aren’t reusable. Hand-crafting nice 3D models. All of those take time that could be spent actually finishing the game.

Sometimes, however, I need to remember that most people don’t care about the basics. They care about the polish. The little scene that was really hard to make and only shows up for 5 minutes.

What may be the case is that all my polishing is on the writing side, making something I’m really proud of. Still, even the writing is hampered by the delivery, since code dictates how and under what conditions I display it.

All that said, I’m not entirely alone, however. I shouldn’t seem like I am. With The Many Sides of Ball, I have a dedicated composer. The music that’s coming in for the game is solid, and I’m excited for that. Perhaps because, aside from the writing, I think it will be the other aspect of the game that’s above par. A standout feature.

I look forward to the day I can work on a team of experts, focusing on either writing, or game design, or programming. When I can put in 110% because there is no other aspect of the game that needs attention.

Also, it’ll be nice to work on a team with a dedicated marketing person. That’s the indie messiah.

//sunk cost thoughts

It’s hard to change focus when you’ve spent hours every day thinking about something nonstop. When you really finish a project, there’s a certain part of the mind that turns off.

“We’re done. Let’s move on.”

But when you just decide to abandon a project, unfinished, it lingers. It takes effort to not have that abandoned project crawl back into your space. There’s only one thing to do.

Like a recovering addict, it’s important to replace one habit with another. To avoid thinking about the old project, you start working on something new. Completely immerse yourself in the new project.

That’s one way to help solve the problem. The other way is to make sure your new project incorporates elements from the old project. This way, it feels like a continuation of the older project. A way to trick your mind into saying, “That was all just leading to this.”

And it’s not wrong. Whenever you make something new, you tend to bring elements into it of everything that came before. Nobody invented the car or wagon without knowing about the wheel, and it shouldn’t surprise anyone that the leading rocket scientists of the first space missions were really into missiles beforehand.

So I made the decision Wednesday to just work on something new. A breakout clone. But, never satisfied with making the same thing as something I’ve seen before, and with RPGs on my mind, I decided to make it RPG-like. At the least, stats and an upgrade menu. I’m toying with a storyline, but that dangers the scope. So, we’ll see. Definitely won’t commit to that until I have the rest of the game effectively done.

In terms of avoiding thinking about the old game, it’s actually been super effective. I’ve spent the past couple days only thinking about the new one, which I’ve dubbed “Hakai” (破壊), which is Japanese for “break” or “destroy”. I’m excited to unveil it within the next week or so.

For now, here are some of my basic test screenshots:


//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!