I wish I could say I’ve gotten much game work done in the past few weeks, but I’ve actually gotten a job and started it, and with family visiting and visiting family (took my visiting grandparents on a trip to see my aunt in Virginia), I haven’t had the time or energy to get a new post up.
But! I’ll do my best to write something in the coming days or weeks, especially about how my indie dev cycle is affected by working a 9-5 job.
Until then, all the best in your own efforts!
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.
I sometimes think the way I work right now is similar to what I’d be doing if I were retired. Wake up leisurely and get out of bed by 7:30 or 8:00. Have a nice morning chat. Work casually, with goals but also occasional breaks, from 9:00-6:00. Have dinner. Relax in the evenings, if there isn’t a meetup or other event to go to.
Rinse and repeat.
I like doing things. I can’t imagine a life without movement of some kind. Even if I didn’t make money, I’d still do things like write books and blog posts. But perhaps I’d also do tasks that have almost 0% chance of turning a profit, like stamp collecting or gardening.
If I’m being honest with myself, my independent games probably won’t turn a big profit. I’ll be happy if they make the equivalent of working on minimum wage. It would be nice to end this year of self-employment with $15,000 or so. Unlikely, but one can dream.
Dreaming aside, I don’t really want to ever retire. And as a 20-something, maybe that makes sense. I haven’t had the time to be beaten down. This is probably one of those statements I’ll look back at in 30 years and say, “how naive you were, young one”. But then, maybe not.
Still, it would be nice to be financially independent, and to spend a lot of time with my family. To the extent that work takes you away from those you love, well, I do want to do away with that aspect.
Okay, back to work. Let’s achieve some level of financial freedom!
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.
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.
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).
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. 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.
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.
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:
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.
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.
Beginner Friendly 