//long term goals

Yesterday I went to an interview for a job in which I’d be writing embedded-C programs for an engineering company. I think the interviews went pretty well, and I’m hopeful, though not expecting to get this job. Maybe a 60% chance? Always hard to say.

But one of the interviewers asked about my process and we started talking about how we structure goals. He mentioned how optimistic he tended to be, which sometimes meant that a project was a lot more difficult than he imagined. I told him how I break tasks into the smallest components possible, which made it easy to start work and get things done.

It did, however, expose one of my weaknesses: long-term planning. Though I’m very focused when demo nights get announced, my long-term goals tend to be much hazier. And that’s led to the project getting pushed back and delayed. Even now, when I feel the game “should” be in beta, it sits in alpha. I think having some harder deadlines would be good.

So I’m setting them. Big goals to hold myself to. Of course, if I get this job, those goals might have to be moved somewhat as I get situated and learn some new skills. But regardless, it’s important to set them.

Let’s see what happens. Perhaps this will be the thing that gets the game finished.



//Kana Master work

Aside from the bigger games I’m working on, I’ve also been making the smaller game Kana Master. It’s a simple-ish game to help learners of the Japanese language master read and recognize kana, the Japanese syllabary.

Basically, this thing.

While I didn’t struggle too long learning the kana, I know others that did. As a Japanese tutor during university, I saw countless students coming in needing help with the kana. What makes language so difficult is that everything builds on everything else. In our university, Japanese classes phased out the use of romaji, the English-character-equivalent of the kana, after the first few weeks. If you didn’t have it, you’re basically left behind.

Even forgetting university students for a moment, lots of language learners are self-taught. Having more good tools available is never a bad thing.

So I decided to start working on a game to help teach the kana, Kana Master.


Kana Master is a game to help Japanese learners learn and apply the kana. In the beginner levels they’ll learn about what each Kana looks like and play small games to reinforce their understanding.

A basic learning screen. Each character, when moused over, will have their own explanation and some mnemonic device to help people remember it, as well as its pronunciation, obviously. 

After the beginner levels, intermediate and advanced levels focus on recognizing words and sentences, respectively. So while beginner might teach み and ず, intermediate teaches みず (water) and advanced teaches みずをのむ (drink water).

In this game you have to type out the character to shoot the enemies on the right.

And then, in the story mode, players will have access to a mini text adventure in which they have to deal with enemy encounters by typing out actions. When you see a businessman, you could attack him like a standard RPG or you could negotiate (こうしょう) or maybe even go out for a drink (びーるをのみにいく).

The game is coming along, but the more I delve into it, the bigger it becomes. Feature-creep. Am I happy with having 3 games to test knowledge? No! I’m looking for 10-15, minimum, but each one requires making a new, separate game, essentially. And while I want the text-adventure to be fun and help give people practical experience with Japanese, it also seems like it’s going to be more than I can handle by myself. It’s one thing to write out everything. It’s another to implement. Doing one or the other could take a lot of time. To do both is going to be… difficult.

That said, I think it’s worth it. Not only is it a game to help others learn, but it’s also forcing me to experiment and consider new ways of doing things. Not to mention that if it’s successful, it could be a chance to earn a living.

As it is, I’m expecting the game won’t be done for another few months, minimum. All my estimates push its release into the winter, but for the first time, I’m considering this for Early Access. While The Many Sides of Ball isn’t a good game to release before it has everything, Kana Master seems like it might be a good fit.

But, before even that, it needs to get into a good state. It still isn’t quite there.

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


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