//demo night

Demo night. Those words bring me untold joy. Nervousness, sure, but joy too.

I had actually given up a little hope. In Boston, Demo Nights often come around once every 3 months. Different groups often have their own demo nights, but again, if you miss one, you’re stuck waiting 3 months. The Boston Unity Group had their demo night early this month, right before I’d returned to the states. Somehow I’d gotten it in my mind that the Boston Indie group had also had theirs.

So it was a great relief when I saw a new message in my mailbox, that the Boston Indies were in fact having their demo night on 6/19. Also great fear, realizing that day was only a few days away.

I had been working on Kana Master, a game to learn Japanese, but realized that I needed more feedback on The Many Sides of Ball. So I sat down with TMSOB and got to work.


Before the demo, I managed to get a bunch done, fueled by the thought of putting it in front of people’s faces. I worked a bit late on Monday, making sure the upgrades were in, NPCs were roaming with their own text, the pause screen worked perfectly, and that the demo end screen got people excited for the full release of the game.

Then came the demo night. I got there a bit late but still snagged a decent location. People came to play. Some people left before finishing. Others, like these two kids, blew through it and loved it. Made me feel a little guilty, actually, because it included words like “hell” and “fuckup”.

The worst mistake that was left in the game: the camera had a basic problem. I didn’t realize it during the testing prior to the demo night, but the changes I’d made to the camera meant that, with some odd camera movement in the 3rd person view, it could become sluggish and hard to control the player. Basically, the player usually matches the camera’s y rotation. But one of my changes made the player match the camera’s x rotation too, which made things odd when messing with the camera. More concretely, by putting the camera above the player, looking down, it was like the player was pointed towards the ground, so forward movement would inch them forward and backward movement would make them “jump backwards” into the air. Stupid mistake, but I knew what I’d done wrong.

Ultimately, I was left with some good feedback. I knew to fix the camera. Other minor things, like players getting stuck in small crevices, were fixed by making certain objects bigger or smaller. I lowered some of the large walls, to make it easier for players to move around. I edited some of the dialogue, changing “hell” to “heck” and “fuckup” to “failure”, for instance.


But that focus on the game persisted into this week. I gave the script a full once-over again. I rerecorded some of the voice overs in the game.

And I think, ultimately, the game is a lot better than it was a week ago.

Demo nights are amazing. Sometimes people love the game. Sometimes people could care less. But it always focuses you. It makes you notice what’s good and bad about it. Testing is good, but testing with random people is even better.

That’s not to mention the good people I met that night. Always fun talking to fellow game developers.

All to say, bring on the next demo night!

…in 3 months or so.

//getting ready to demo

So I got back to America and decided to restart work on a game to learn Kana, the Japanese “alphabet”, which had been delayed by my odd final week in Japan. No sooner had I got it half set-up before I find out there’s a demo night for the Boston Indies group next Monday. And what does that mean: Time to go get work done for The Many Sides of Ball.

Having been working on my portfolio for the past couple months, TMSOB has really been on the backburner. And when work isn’t getting done for it, it slowly feels worse and worse. Like a cold that doesn’t go away. Not so bad when nothing changes for a week. Awful when you’ve had the same cold for two months.

But since learning about the demo night, I’ve gotten a boatload of work done for TMSOB. Almost perfecting the 3rd person camera. Putting in a cutscene skip button. Adding NPCs with little speech blurbs. Getting the same system in order (including making multiple save slots, have collectibles stay collected). Making the world map work. Updating the pause menu. All over the course of two days. A very productive two days.

For the first time in a long time, I’ve felt really good about TMSOB. Still, a lot more work needs to be done before it’s ready for the general public. But it finally feels like that’s possible again.

//weakness of doing everything on a whiteboard

I love whiteboards. I don’t think it’s a secret.

In college, I had a large one I could use for teaching or other community projects, like club advertising. After college, in order to get my daily goals worked out, I’d often write everything down on a whiteboard and erase each thing as I got it done. Whiteboards helped me stay organized and make connections between things in a way that typing things in a word document never allowed.

And then I got into game development. My whiteboard addiction unabated, I wrote all my ideas for levels down and erased them as they were completed. I planned things out, daily, and organized my thoughts. Sometimes I’d make a sketch for something I’d go and make in Blender later.

The problem was: I always erased. Never kept anything. And now that I want to show my thought-process, it’s gone. All that potential concept art, gone.

That’s not entirely true, though. I do have some sketches, mostly from times I sent someone else an example of what I was doing. So, without further ado:

This was the first level for “The Many Sides of Ball” I actually planned out. 
This is how it ultimately ended up.
This was one of my daily organizational outlines. The big task was to record some scratch voice overs. But, there’s also some ideas for how I want the levels to look. 1-1 is simple, 1-2 is a bit of a maze, 2-1 has a big open area, 2-2 has a climbing thing going on, 3-1 is a fast-moving downhill windy level, 3-2 is a lot of hills, 4-1 is a very vertical platforming level, 4-2 is super vertical, 5-1 has a lot of floating platforms, 5-2 is floating around one central building, and 6-1 and 6-2 deal with platforming around a moving ocean. 
This happened after I determined that there would be multiple camera / gameplay perspectives to the levels, and I wanted to see how often the different perspectives were used, as well as how they were sandwiched between other perspectives. The line is 2D side scrolling, the square is top-down, and the cube is full 3D. Some of these are totally different than how the final game is ending up. 
This was a simple concept I had for the world map. Wanted to remember it in case I could use it in the future, but I really needed to use the board for other purposes. In fact, the final world map does look similar to this sketch.
When I was debating what the final level should entail, I started planning it out on the board. Not too intense, but sometimes just writing something down helps out, similar to just putting some writing on paper to get started on that blog post / essay you need to start.
Thought about having the narrators have faces. Probably won’t go this route.
20161204_172143 (1).jpg
This was level planning for a strategy RPG I’m working on. Ultimately, the number of enemy units ended up being too many and the final map had them pared down.
This was the general world map for Pretty Concise, the simple RPG that I’ll hopefully get back to sometime. At the time of drawing this, the two blacked out areas were complete. At this point, four more of those blocks should be blacked out. Still have a ways to go.
Working on the final area of The Many Sides of Ball, I needed a way to visualize what was needed for the final area. It’s a little abstract, but it made sense to me. The three groups of blocks are different sections of the map. The 3 and 4 dotted-line areas take place vertically above the section. The 4 vert and 6 horiz(ontal) are about whether or not the platforming has more of an upward focus or simple sideways flow to it.

But that’s it. Nothing more that I can find. Hard to make a portfolio of past design choices and the thought processes when so much of it has been poorly preserved.

In any case, there’s only one direction–forward. Onward. Time to keep better documentation.

Still going to use the whiteboard though.



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: