Tuesday, February 05, 2013

One down, 11 to go

January OneGameAMonth post-mortem

January is over, and I'm done working on Rocks! (for now, at least), and it's time to go over what worked, what didn't, and what I'll do differently for February.

First, here's a link to the current version:

And here's the Github repository with the source code:

What I was trying to do:
This was the first month of the One Game A Month challenge, and I really wanted to make sure I finished something, so I'd get started off on the right foot. To that end, I tried to shrink the scale of what I was trying to do for January to something I was sure I'd be able to finish. Rather than design a game from scratch, I started with a well-known design, and implemented it on an unknown (to me) technology stack. So, I decided to do a clone of Asteroids, running in the web browser, using the canvas element for graphics, and the Web Audio API for sound.

I wanted to produce something with a retro feel, true to the spirit of the original, even if it wasn't exactly the same in execution. And I decided to do the whole thing without the use of any frameworks or libraries, both because I thought that the game was simple enough that I could just bang it out without much help, and because I wanted to actually learn the browser APIs, not some third-party library.

What went right:
Got something working very fast, then iterated
By the end of the first week, I had a playable game, if not a very interesting one. That took a lot of the pressure off, knowing that even if I ran out of time, I'd have *something* to show for it.

Scope creep (mostly) avoided
Although lots of really great ideas came to me while working on Rocks!, I managed to avoid the temptation to add in a bunch of extra features. I feel especially good about this given that I didn't quite meet the initial goals - I'd have felt a lot worse if I didn't manage to make a complete game, because I'd gotten distracted by doing something cool, but not part of the core gameplay.

Proper "retro-twitch" feel
I spent a fair amount of time tweaking the controls, to get ship movement that felt "right". I think this is something that really distinguishes my game from the other Asteroids-like games that were submitted to OneGameAMonth last month. My ship is very responsive, it turns and accelerates quickly enough to get out of trouble, which makes the player feel like they're in control of their own fate.

No Art
I didn't want to spend a lot of time drawing terrible art that I then hated. I figured that going with the vector approach would encourage (enforce?) a simple graphical design, and save me from spending hours tweaking art trying to make it look less goofy. My inability to draw well is going to be an ongoing issue for the next 11 games, too.

I "Finished" on time
Actually a bit ahead of time. Which is good, because a bunch of "real world" stuff came up in the last few weeks of January.

What went wrong:
Spent much more time on art & sound than expected
Despite the fact that I went with a totally minimalist look & sound, I still had to do a fair amount of tweaking. But with everything defined in code (see next item), it was pure tedium to make any changes in the graphics or sound.

No creative tools
I ended up doing the entire art design by sketching things out on graph paper and manually copying down the coordinates into my code. This wasn't *terrible*, but it was tedious and error-prone. I didn't produce an editor for shapes and sounds because that sounded like more work than actually finishing the game. For *this* game, that was arguably true - but a couple of features got left out, rather than going through the process of manually designing graphics & sound for them. I'm planning on using the same technologies in future games, so I'll be able to amortize the effort to produce the tools over several projects. Conveniently enough, the optional theme element for OneGameAMonth February is "sound", so I'll have good incentive to build (or find) at least a rudimentary sound editor.

What ended up on the cutting-room floor:
* High score board
* Touch browser controls
* Enemies
* Hyperspace

These are all things I intended to do, but just didn't get around to. Technically, there is a high-score board, it just doesn't allow you to put in your initials. This is because I didn't feel like I could implement it without needing to make some major changes somewhere else.

I didn't do touch controls for keyboard-less tablets and phones because I wanted to do the controls on a kind of virtual arcade cabinet presentation. I never did get any designs for that panel that I liked, so you still can't play the game out your iPad,

Enemies were going to be UFOs like in Asteroids, with an occasional power-up coming from each enemy shot down. I think I could get a fairly rudimentary version of alien AI done in a couple of days, but I just ran out of time.

What about February?
February will be crazy busy for me, so I'll be setting my sights low for this month as well. The massively-multiplayer infinite-world Sci-Fi adventure game will have to wait a month or two.

Amongst other things, I will be adopting some helpful libraries and/or frameworks, rather than trying to do everything myself. In particular, it'd be an interesting exercise to build a videogame using the Enyo.js framework, since we've never really pushed that particular use case, Enyo being more focused toward native-equivalent mobile productivity apps.

Friday, January 11, 2013

Rocks! Update #2 - it's a game

It's an actual game now!

So, first things first - here's the current version of Rocks!

Rocks!

New features include:

  • updated graphics - random rock shapes, and a progression of sizes
  • on-screen instructions
  • better sounds
  • proper collision detection
  • particle effects when things are destroyed
  • more than one level
  • a "shield" that will prevent rocks from running into you

It's looking a lot more like a real game now.

Sound design is hard

Oddly enough, the hardest thing for me so far has been making those decidedly "retro", simple sound effects. The Web Audio API is very powerful, but it's also very much focused on doing sophisticated manipulation of sampled sound. I certainly could have grabbed appropriate sampled sounds, or built some in Audacity, but I wanted to push the "classic" feel of the thing, and I thought - "I've done this sort of thing before, how hard can it be"? Besides, attaching a couple of huge sample files to a game that's currently under 20kb total in size felt a bit like the tail wagging the dog.

Of course, the last time I tried to create synthesized sounds from scratch was probably 30 years ago, on an 8-bit home computer with a fixed-voice synthesizer chip. There's something to be said for the existence of fewer choices helping to focus your efforts. When you're faced with an API that supports multi-channel surround sound, arbitrary frequency- and time-domain manipulation, 3-D positional audio, dynamics compression, and all the rest, it's a little difficult to figure out how to just make a simple "beep".

Here's what I've learned so far about using the Web Audio API:

Web Audio is based on a connected graph of nodes, leading from one or more sources through the graph to the ultimate audio output
This is enormously-flexible, and each of the individual node types is jut about as simple as it can be to do the thing it's designed for. There's a "gain" node that just multiplies the input by a constant and feeds it to the output, for instance. The source nodes don't have individual volume controls (because there's the gain node for that).

There's one weird quirk to my old-school sensibilities, which is that every note requires making another source node and connecting it to the node graph. When a note stops playing, the source node is automatically removed and garbage collected. If you want to play the same sound over and over, you're continuously creating and destroying nodes and connecting them to the graph.

There's a simple oscillator source node that's very flexible
You can easily create an oscillator that uses an arbitrary waveform (square, triangle, sine, on user-defined), plays at a specific frequency, and starts and stops at a specific time. This is about 80% of what you need to make a "beep", but:

Oddly, there's no built-in ADSR envelope support
Back in the day, we'd set up ADSR (attack, decay, sustain, release) parameters for a sound, which would control how quickly it came up to full volume, how loud it was as the note progressed, and how quickly it faded. There are probably about 10 different ways to do the same thing in Web Audio, but nothing with the same simplicity.

There's no simple white-noise source
This is a bit of a weird omission, in that noise sources are the basic building blocks of a lot of useful effects, including explosions, hissing, and roaring noises. And again, there's probably 10 different ways to solve this with the existing building blocks, each with their own limitations and quirks. I ended up using Javascript to create a buffer of random samples, which I could then feed through filters to get the appropriate noises for thrust and explosions.

The API is very much a work in progress
Despite the fact I wasn't trying to anything particularly sophisticated, I ran into a few bugs in both Safari and Chrome. I imagine a certain amount of this is to be expected with an in-development API that hasn't been standardized yet.


Next Up: Enemies!

The next big feature for Rocks! is to have some enemies to chase you around and shoot at you.

Saturday, January 05, 2013

One Game a Month, One Blog a Month?

A New Year Brings a Fresh Start

I swear, I'm not going to start this post out with how disappointed I am at my lack of writing output over the last year. Oops...


The Problem

No matter how much I promise myself I'm going to update my blog more often, it tends to languish. I have a bunch of half-written articles waiting to be published, but in the absence of any compelling deadline, I can continue to look at them as "not quite ready for public view" for forever.


A possible solution

Something I've seen work really well for other people who struggle with producing consistent output are what I think of as "creative challenges". Things like the "take a picture every day for a year" challenge that a lot of people are doing to improve their photography.

I just can't face the idea of a "blog a day" challenge, though - I like the idea of something a little more long-form, and a daily deadline would force me to cut corners to an extent I'm not ready for yet.

So instead, I signed up for the OneGameAMonth challenge. Game design is one of my non-programming passions, so I feel like I'll be able to stay motivated and really try to see this through. A month is a long-enough deadline that I feel like I can produce something worth examining, and the practical problems and "stuff I learned along the way" should provide ample material for *at least* one blog entry a month.


The Plan

I haven't planned the whole 12 months out yet, but here's what I do know my plans:
  • I will create a variety of games in different formats, including video games, board games, and card games
  • I will explore different genres in each format
  • Everything I do will be open-source on my Github account
  • I will write at least one blog entry every month, about the current game
  • If I don't finish a game in a particular month, I will not give up - I'll just do something less ambitious for the next month


The Proof

And to prove that I'm not completely full of it, here's the in-progress game for January, after two days of after-hours hacking:

It's named Rocks!

And here's the GitHub repository for it.

This is an HTML5 Canvas & WebAudio version of the old Asteroids arcade game. Because it uses some cutting-edge web features, it only runs properly in recent WebKit-based browsers. That's Google Chrome and Safari. Future games will likely be more cross-platform, but I wanted to learn a bit about the Web Audio API.


What I've learned on this project so far

This first version is very limited, and frankly pretty buggy:
  • There's no proper collision detection - it's hard to die, unless you try to hit a rock with the ship
  • The asteroids don't start larger and break up into smaller ones
  • There's no level progression, and no game-over when you die 3 times
  • No enemy UFOs yet
  • There are missing sound & visual effects
And the code is, frankly, a mess. But on the other side, there's a lot I've learned over the last two days:
  • All of the rendering is done using the Canvas line-drawing primitives
  • The sounds are synthesized on-the-fly using Web Audio units instead of sampled sounds
  • The animation is driven using requestAnimationFrame, so it should throttle back when in the background
  • The whole thing is less than 11k in size, and there's about 400 lines of Javascript in the main game file. That's smaller than a typical iOS app icon...

Friday, February 10, 2012

The simplest possible computer

The simplest possible computer

So, if we were going to build a model of the simplest possible computer, where would we start? As it turns out, you probably have such a model in your home already.


Many homes have what's known as a "three-way" switch, which is a light switch that you can turn on and off from two different locations. This circuit can be used as a simple digital computer.





By properly labeling the switch positions and the light bulb, we can use them to solve a logic problem.


Let's say that you need a system to tell you whether to have dessert with your lunch, but you have some specific rules to follow:

1. If you have a salad for lunch, you'll have dessert.

2. If you have soup for lunch, you'll have dessert.

3. If you have both soup and salad for lunch, you'll skip dessert (since you'll be over-full).

4. If you haven't had anything for lunch, you won't have dessert (because dessert on an empty stomach will make you sick).


Here's how to solve this problem with the three-way switch:


If necessary, flip one of the switches so that the light is off. Label the positions that the switches are currently in. Label one "had soup", and the other "had salad". Label the other two positions "no soup" and "no salad", respectively. Hang a sign on the light bulb that reads "have dessert".


Congratulations! You now have a computer that will tell you, based on whether you've had soup and/or salad, whether you should have dessert. Try it out, and you'll find that it follows the rules given above, and the light will only come on if you've had either soup or salad (but not both).


This isn't all that exciting by itself, but this same circuit can be used to solve an entire family of related logic problems, just by changing the labels on the switches and the light bulb. This ability to use the same logic to solve many different problems is the source of the flexibility of computers, and is what enables them to be useful for so many different things.


A new project!

I'm working on a "book" in my spare time. I put book in quotes there, because I don't know that it'll actually get to the level of being published on dead trees. Due to the subject matter, it would make more sense to publish it online (or perhaps, via something like iBooks) in any case.

It's intended to be an introduction to Computer Science for non-nerds (and/or younger folk), which I'm sure is well-covered ground, but the unique direction I'm planning on taking is to start "at the bottom" with the most basic principles and work my way up.

This is based on conversations I've had with family and friends over the last few decades, at family gatherings, at parties, and on road trips. I get the impression that a lot of folks think that there's this mysterious "other level" beneath what they understand about their computer that requires a lot of formal training to understand. I want to show that things aren't really that complicated at the lower level, and that all of the complexity is layered on top of a very simple foundation.

And, I find the subject really interesting, so I enjoy writing about it. I'm going to set up a website for he new project soon, but in the meantime, I'll put an excerpt up here to see what people think.

Update: Here it is - The Simplest Possible Computer

Wednesday, June 08, 2011

Time for a reboot...

Okay, it's now been more than a year and a half since I updated this blog. I need to get back on the horse. Stay tuned for an update soon (really)!

Sunday, January 24, 2010

JavaScript by example: functions and function objects

I've been working in JavaScript a lot these last couple of months, and I feel like I've learned a lot. I wanted to show some of the more interesting aspects of JavaScript that I've had the opportunity to bump into. I'll use some simple examples along the way to illustrate my points.

Note: If you want to follow along with the examples in this blog post (and the followup posts), you'll probably want to use an interactive JavaScript environment. I tend to use Firebug with Firefox when I'm trying stuff out, but there shouldn't be anything in these examples that won't work in the WebKit console in Safari or Chrome, or in Rhino, for that matter.

Functions

A simple function is defined and used in JavaScript thusly:

function add(x, y) {
return x + y;
}
console.log(add(3, 5)); // this prints "8" to the console

This does just about what it looks like it does. There's no trickery here (the trickery comes later on). Let's say that we want a version of this function that takes a single argument, and always adds 5 to it. You could do that like this:

function add5(a) {
return add(a, 5);
}

console.log(add5(3)); // prints "8"

But what if you're going to need a bunch of these one-argument variants on the add function? Well, since functions are first-class objects in JavaScript, you can do this:

function make_adder(v) {
var f = function(x) {
return add(x, v);
};
return f;
}

var add7 = make_adder(7); //create a function
console.log(add7(3)); // prints "10"

This is only slightly more complicated than the original example. One possibly subtle point here is that the returned function "captures" the value of v that was passed into make_adder. In a more formal discussion, you'd call this a closure.

Sunday, June 07, 2009

PuzzleTwist is now available!

My latest creation is now up on the iTunes App Store. It's called PuzzleTwist, and it's a puzzle game where you unscramble a picture by rotating the pieces.  As each piece is rotated into place, others will rotate as well - some in the same direction, some in the opposite direction. The key to solving the puzzle is to figure out what order to move the pieces in.

One unique feature is that the rules for each puzzle are different - some are simple, some are more complex. A few are so difficult that I can't solve them without looking at the solution.

Once you've solved a puzzle, you can save the resulting picture in the Photo Library on your iPhone, and then use it as the wallpaper image for the phone, or assign it to one of your contacts.

PuzzleTwist also keeps track of the best reported scores, so you can compare your scores versus the rest of the world.

If you're a puzzle fan, you should check it out. Here's the iTunes store link.

On a side note, this application was approved much faster than the previous applications I submitted. Perhaps the App Store review team is coming out from under their backlog.