Blog


Week Three: Back At It

April 11, 2016, 6:20am

April 11, 2016, 3:20am

Week three game is posted here!

If you look closely at my right forearm, you'll notice two rather large scars. One came from my first attempt at mountain biking — I was riding over some rocky moguls when a bug flew in my face. As I turned my head to shake it off, my front wheel hit a rock and I flew over the handlebars and scraped the heck out of my arm. I didn't ride another mountain biking trail for about a year, but I resolved not to be discouraged by my failure and got back on the bike. This time, I was riding fast down a sandy trail, took a turn too fast and my bike skidded out from under me and I again scraped the heck out of the same arm.

Not getting discouraged by failure is one thing, but around this time I decided that I should probably find another hobby.

I spent most of this week in Los Angeles spending time with family and friends so this was a short work week. I was pretty down last week when the game turned out so badly so I decided to give it another shot. This time I went for a basic shooting mechanic and tried to emphasize functionality and simplicity. The game turned out much better this week (actually being playable helps) but really, D3 is very far from ideal for making games.

I'm glad that I built a satisfactory D3 game so I can cross this off my project list. The smooth zoom scaling is pretty sweet but mixing SVG transformations and css positioning is needlessly complicated.

Next week is another short week (I'll be in Boston and Cleveland starting Thursday) but I'm pretty excited about the next game! Trying something pretty different.


Post-mortem of Week Two

April 05, 2016, 7:20pm

It’s Monday afternoon and I’ve had a chance to get some sleep after finishing the game for week two. If you’ve played it, you might notice that due to bugs, it’s practically unplayable. If you are fortunate enough to be able to play for a bit before it bugs out, you might come to the unfortunate conclusion that the game isn’t even fun.

So what went wrong?

That’s a question I’ve been asking myself all day. I’ve narrowed it down to three issues:

1. The design was too ambitious.

2. The technology was too ambitious.

3. Not enough time.

Let’s tackle them one by one.

1. The design was too ambitious.

I’ve been toying around with the idea of a game based around a gun that is aimed via algebra equations for a while. My buddy Greg flies jets for the Navy and has spent the past few months on an aircraft carrier in the middle of the Pacific Ocean which provided the inspiration for this game.

There’s a pretty great anecdote from George Fan, creator of the fantastic Plants vs. Zombies franchise about how he chose plants and zombies as the characters for his tower defense game. You might think that he chose two popular character types at random (it could just as well have been cats vs. ninjas) but there’s actually a lot more thought put into it. You see, the enemies in tower defense games have to be slow and numerous and the protagonists have to be rooted to the ground. It so happens that plants and zombies fit that description perfectly and the charming puns and descriptions followed naturally.

I had the same sort of idea with this game. Aliens are attacking your ship, which lies at the origin of a cartesian plane, and it must be defended with a laser that aims via y=mx+b equations and a missile which finds its targets with cartesian coordinates.

On paper, it actually sounds pretty simple. Much simpler than week one’s crazy tamagotchi/MOBA hybrid. In practice, it was pretty difficult to make the enemies spawn and attack slow enough to allow the player adequate time to calculate and enter the algebra equations while still eliciting exciting gameplay.

When I set out to build a new game every week, I decided that the minimum requirement is that each game explores an idea, concept or technology. Being fun is NOT a requirement, nor is being 100% functional and bug free. So technically, I’m still on track.

One of the problems with building a game in such a short timeframe is that it allows no room for iteration. The first couple of days are usually spent coming up with a concept and design and the later days are spent coding, but when design issues come up during the coding phase there is no slack time to revisit the design. I learned that a bad design can have adverse effects on engineering as well.

2. The technology was too ambitious.

While at EdSurge (where I was most recently employed until two weeks ago), I got a chance to work with D3 which is a pretty awesome javascript framework for data visualization. It’s sort of tricky to use but you can create some pretty amazing data visualizations with just a few lines of code.

I wanted to do a project in D3 while it was still fresh in my mind and this algebra shooting mechanic seemed like the perfect candidate: D3 makes things like dynamic axes and plotting points easy!

Well, it turns out that it wasn’t quite so simple. Plotting data points is easy enough, but D3 transitions tend to happen very periodically, instead of multiple times per second so it’s hard to create dynamic AI. It’s also tricky to be moving back and forth between pixels and graph units (even though D3 does have built in xScale and yScale functions). It’s also hard to make changes to the data mid-transition: for example, when destroying an alien mid-transition, it will throw an error when it tries to reference that alien again.

I think all of these obstacles could be overcome with enough time and effort, but it’s hard to make that extra push late on Sunday night when the payoff isn’t there. Put another way, no engineer wants to kill themselves to implement a mediocre design.

3. Not enough time.

When I say not enough time, I don’t mean I should have taken more time to work on this particular game. What I really mean is I should have aimed for a less ambitious design. I have a ton of game ideas, and the goal of this game-a-week mission is to test as many of them as possible. Starting out of course, the ideas are bursting out of the seams and there is a tendency to want to squeeze as many ideas into each game. This is a marathon, not a sprint, and there will be plenty of opportunities to explore all of my crazy ideas. And a few months (or years?) from now when that bursting torrent of ideas becomes a slow trickle and inspiration becomes scarce, I will be grateful for having kept a few of these ideas in storage.

In the meantime, it’s on to week 3 with these lessons learned.


Week Two: Early Stumbles

April 04, 2016, 5:13am

April 4, 2016, 2:13am

Week two game is posted here.

Last week, I had a pretty ambitious idea and it ended up working out. This week, not so much. It's super buggy and not very fun. I drove down to LA this week to spend time with family and friends I hadn't seen in a while, and between the hectic schedule, I just couldn't work out a lot of the problems that this game was having.

Week three will be better.


Week One: Hello World!

March 28, 2016, 6:13am

Hello! My name is Brady Fukumoto. I was most recently a full-stack web developer at edsurge.com and an educational game designer and writer.

A week ago (March 18, 2016 to be exact) was my last day at EdSurge. It was a great experience and I learned a lot.

What am I doing now, you ask?

Why, I'm making games, of course!

A new one every week.

You can play the first one here.

If you've got any questions, send me an email (no robots allowed). More to come soon!

- Brady