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

level13.png

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.

failure.png

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:

20160923_150856.jpg
This was the first level for “The Many Sides of Ball” I actually planned out. 
canyon
This is how it ultimately ended up.
20161115_084317.jpg
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. 
20161123_092450.jpg
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. 
20170109_125630.jpg
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.
20170110_123456.jpg
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.
20170130_121251
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.
20170428_204357.jpg
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.
20170324_120057.jpg
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.

Hakai1Hakai2Hakai4Hakai5Hakai3

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:

HakaiTitleHakaiTestLevelHakaiUpgrade

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

PrettyConcise.png

“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:

PC_current_world.png

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.