Droplet Post-Mortem

This is a look back at last weekend’s RubyWeekend #3 game contest and the process of developing my entry, Droplet. You can read more post-mortems from the contest in the Rubygame forums.

What went right:

  • I’m really happy with how the plants grow and change and move. I think I got the rustling to be pretty convincing, almost like it’s using a physics engine, even though it’s just some sine waves.
  • I think the overall polish level is high, even if the “gameplay” is a bit limited.
  • I’m glad I settled on the concept I did. I love making stuff like this, and the competition was a great motivator.

What went wrong:

  • It took me the whole first day (8 hours) to come up with a concept. (This is typical for me, actually.)
  • I spent the next two days just making the plant system…
  • I didn’t manage to work in any real gameplay. It could probably be a pretty cool puzzle game if I invested some more time.
  • Nobody likes my toy. Boo hoo hoo! … Just kidding. :P

What I learned:

  • I learned a bit of how to use Gamebox. But I didn’t learn it very well or thoroughly, because I was in a hurry.
  • I discovered how cool Garage Band is, although I didn’t end up using it.
  • After the contest, I learned how to record video and audio in Linux using the aptly-named RecordMyDesktop, so that I could record a video of Droplet in action. I need to figure out how to convert it to a format that YouTube supports, though.
  • I learned how utterly irresponsible I can be, participating in a game contest on a whim when I had work deadlines coming up… but it all turned out well in the end, so that’s okay! I have yet again avoided needing to learn a life lesson about personal responsibility. \o/

What I would do differently:

  • Use a different system for drawing the plants. Probably image-based sprites that are scaled and rotated, instead of using drawing primitives. Then I could have gotten more visually interesting trees with less time-consuming coding.
  • Use OpenGL. I think this game could have benefited quite a bit from OpenGL (or even better, OpenVG). The graphics would have been a lot smoother, I could have had more separate branches per tree, and the code would have been simpler to write, even without an image-based sprite approach.
  • Probably not use Gamebox. I’m not saying Gamebox is bad, but it felt a bit restrictive and limited, and trying to learn a new framework while I was in a hurry wasn’t the best idea. More about Gamebox below.

On working with Gamebox:

Gamebox is interesting, and much more mature than its version number (0.0.6 as of this writing) might lead you to believe. The game contest helped flush out several bugs and shortcomings, but Shawn has been super-fast to fix them. I’m sure it will polish up very nicely as he gets feedback from more people.

In general, I am wary of frameworks. Certainly, Rails puts a bad taste in my mouth these days (despite my positive initial reactions two years ago). I tend to find frameworks restrictive, and would much rather be handed a set of building blocks to assemble. For one thing, a framework makes assumptions about what shape I want the final result to have. And I find that many frameworks assume more than they should, and make it too difficult to do things the framework creator didn’t anticipate.

Gamebox suffers from this a little bit, but not nearly as much as Rails does. This is evidenced by the fact that even an unorthodox game like Droplet could be made with it. For instance, a more rigid flamework would not have been able to handle the game objects being arranged radially or having no set appearance. There were some things that I had to work around, though:

  • At the time I wrote Droplet, Levels did not have access to the InputManager, so I had to attach the event hooks to an actor instead. Shawn fixed the issue a day or two after Droplet was finished, though.
  • Gamebox did not support the MouseMotion event type. Shawn fixed this during the contest, though, so I was able to use it. (Thanks, Shawn!)
  • There is no clean way to set the window title. I had to work around this by setting it in Level#draw.
  • Gamebox’s sound support is geared towards fire-and-forget playback, whereas Droplet required the ability to play a sound in a loop and constantly adjust the volume level. Shawn will probably have this fixed within 5 minutes of reading this, though. ;)

There were a few other things that felt like work-arounds to me, but which I think I could have done better if I were more familiar with Gamebox, especially its Behaviors system.

Would I use Gamebox again? Sure! Especially for more conventional games, Gamebox is a great way to get a head start on your game. Even weird stuff like Droplet can be accomodated without a great deal of trouble. And at the rate Shawn is improving it, I’m certain Gamebox will soon be one of the most kickass game frameworks around.

… at least until Rebirth comes out. >;)

Droplet

Screenshot

I’m pleased to present my entry to the RubyWeekend #3 game competition: Droplet. From the README:

Droplet is a small musical toy created by John Croisant in 72 hours over the weekend of June 26-28, 2009 for the third RubyWeekend game creation competition.

The theme of the competition was “A Tiny World”. The inspiration for Droplet comes from photographs that people have commonly described as “tiny worlds”: droplets of water, and the small plants and fungi that grow underfoot.

Initially, Droplet was going to feature both plants and creatures interacting in their tiny droplet world, but I abandoned plans for the creatures due to time constraints. So, what’s left is abstract, rainbow colored plants that sing when you tickle them!

Enjoy!

The controls are simple:

  • Left click anywhere on the edge of the droplet (the large circle) to plant a seed. The seed will gradually grow into a tree-like plant of a random color.
  • Move the mouse cursor around near a grown plant to tickle it and make it sing. The faster and longer you tickle, the louder it sings. The sound each plant produces is randomly chosen from the “data/sounds/” directory.
  • Right click the trunk of a plant to remove it.
  • Click “Help / Credits” to view controls help and game credits.
  • Press Escape to quit the game.

To run Droplet, you will need Ruby 1.8.6 (1.9 might work), Rubygame 2.5.2 (with SDL_gfx, SDL_image, and SDL_mixer support), and Gamebox 0.0.4.

Droplet – End of Day 3

Screenshot

What’s working:

  • Plants have a limited number of generations, so they don’t start to slow everything down.
  • Plant colors, branch length, and various other attributes are randomized per plant for more variety.
  • You can rustle the plants by moving your mouse cursor around them. This makes them wave back and forth for a while, and will eventually make them “sing” louder.
  • I made a custom method for drawing branches, which is a bit faster than draw_line_s, and anti-aliased, but not as roundy at the ends.

What’s not:

  • The algorithm for calculating how much you rustled a plant is a bit dodgy.
  • Still no sound. I’m definitely adding that tomorrow, though. I’ve got a few chime sound loops prepared, and I’ll make some wind/pad loops too.
  • I decided not to use Garage Band due to time constraints and because I wasn’t sure about licensing (since I’d just be making short samples). I’m using some nice chimes and pads from freesound.org instead.
  • I need to a title and instructions and credits in the side bar.
  • Maybe add a way to kill plants that you don’t want anymore?

All in all, though, it’s coming together well. 16 hours left.

Droplet – End of Day 2

A quickie progress update and screenshot of my RubyWeekend game, Droplet.

Screenshot

What’s working:

  • You can click to make a new plant at the nearest point on the circle.
  • The plants grow a bit when you press spacebar.
  • The plants grow and create new branches based on rules.

What’s not:

  • The plants are ignoring their color rules.
  • The plants are “leaning”.
  • The plants are jaggy and slow to draw (when complex). I’ll probably have to stop using Gamebox’s “thick line” method (draw_line_s), and either use regular lines (maybe antialiased) or roll my own code to draw branches. OpenGL would be really nice right now…
  • The plant rules are a bit simplistic and rigid.
  • No sound yet.

The contest period is nearly half over (39:30 hours left as of this writing). I’m going to try to fix the color and leaning issues, then head to bed. The focus tomorrow will be on sound/music.

Update 03:52: Fixed the color and leaning issues. Both were just stupid little mistakes. Here’s an updated screenshot:

Screenshot

Droplet Thoughts (Day 2)

I’m calling my RubyWeekend #3 game “Droplet”. I will not proceed to ramble about it to help my planning. And you get to read the results, you lucky person you!

  • I’m setting aside the animals/people aspect for the competition. It’s just going to be about the plants.
  • I’m going to use Garage Band’s built-in instruments to create the music sound effects for the game. I am in love with Garage Band.
  • I’ll be using Gamebox. It seems pretty cool so far.
  • Since the game takes place on the inside surface of a circle, I’ll need to do some trigonometry to calculate the positions and angles of plants around that circle. After a bit of thought on this, I’ve decided I’ll make a PivotActor that represents the center of the circle and contains the math code to calculate the positions of plants given an angle, and also calculate the point on the circle nearest to the mouse cursor.

I’ll update this post with more thoughts as I have them.

RubyWeekend #3 Game Concept

RubyWeekend #3 kicked off about 8 hours ago, and I’ve been pondering game ideas since then. The theme is “A Tiny World”. I was having trouble coming up with something, but I think I’ve finally got a solid base for a game. It’s still a bit vague, and I haven’t figured out how I’ll turn it into a proper game, with an objective and challenge and such. Right now it’s just kind of a neat idea for a toy. (Which, to be honest, I find more interesting to create, but I should at least try to make it somewhat game-ish for the competition.)

Continue reading RubyWeekend #3 Game Concept

Solunaria

Here’s my entry for RubyWeekend #2: Opposites. You can read my progress logs in the rubyweekend section if you’re interested in reading about how I got the idea and the process involved in making the game.

In Solunaria, you control a giant, glowing, magical moth. It’s your job to round up the smaller moths, but there’s a problem: the smaller moths come in two varieties: solar moths (orange) and lunar moths (blue), and they’ll only follow something of the same color as them!

Fortunately, since you’re a magical moth, you can change color (left click) to attract each color of moth. The catch is that there are also colored glowbugs flying around, and the small moths have a tendency to follow the glowbugs if they get too close. Silly moths!

Solunaria Screenshot Thumbnail

Download the game! (Requires Rubygame 2.3.)

I didn’t completely finish the game (there’s no winning or losing conditions), but it’s still kinda fun to fly around and guide the moths. And it was a lot of fun to make the game in the first place!

Be sure to check out the other entries to the RubyWeekend #2 contest. There will be voting starting tomorrow, so check the contest forum then.

Also tomorrow, I’ll write up a post-mortem about making the game, just like I did for the previous contest.

New Solunaria Screenshot

Here’s a crappy JPEG screenshot of the current progress of my game.

Screenshot with small moths and background

As you can see, I’ve added smaller moths of different colors. The small moths follow the big moth, although if there was anything else around they’d follow it if they got too close. Next I’m going to make them act differently based on their color compared to your color.

I’ve also added a starfield background image which I threw together in 5 minutes in the GIMP.

(2:30 hours left!)

Up and at ’em

Getting started for the day. Had a little bit of work stuff to take care of, but it’s all done for now. Next up is to work on the LilMoth class and make it respond to the BigMoth. Then I’ll generalize that to make it respond to any “light sources”. Then I’ll add some static lights around the level and a goal light that registers how many moths are following it. And then, my victory will be complete!