blog.jacius.info

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.

• Download Droplet 1.0!

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.

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

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:

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

In my recent adventures in Haskell and Scheme, I was immersed in the concept of functional programming. Haskell in particular has a strong relation with the notion of pure functions, i.e. functions without side effects. A pure function does nothing except calculate and return some value based on the input parameters.

I like pure functions, and I try to write them where I can. But Haskell is billed as a “purely functional programming language”. This perplexed me. How could there be an entire programming language that was purely functional? Or, rather, how could you use such a language to actually do anything useful?

Consider this: if you’re restricting yourself to absolutely no side effects, you’re not allowed to write to files, send data over a network, print text to the console, draw images on the screen, or anything like that. (So much for any ideas of writing a game in a purely functional language!) A program with no side effects is a sort of black hole: parameters can go in, but nothing comes out (except the program exit status code, which is the “return value” of the program). The user doesn’t see anything, no files are changed, no packets sent over the network. The program leaves behind no legacy: the system is in much the same state after the program has run as it was before the program ran.

And yet, at least one useful bit of software has been written in Haskell: the darcs revision control system. So what’s the secret? How did they do it?

Well, it’s simple: Haskell isn’t entirely pure. It’s “tainted” with some functions that do have side effects, such as writing to files and printing text.

Granted, it’s noteworthy that Haskell can get by without many other common side effects, like editing strings or lists in-place, modifying object state, or keeping global variables. It does force you to think in a functional way, and to break many bad habits. And striving for functional programming, regardless of the language you are using, often results in cleaner, less buggy, and easier to maintain code.

But at the end of the day, if you want to accomplish anything, you have to make some concessions to imperative programming. There has to be a side effect somewhere.

Lately I’ve been poking around at some new-to-me programming languages, Haskell and Scheme. I don’t expect to use either of them in a serious, practal project (except maybe Scheme for scripting GIMP), but they are both “weird” enough that it’s fun to learn them and expand my horizons.

For Haskell, I’ve been following along with the brilliant and funny Learn You a Haskel for Great Good. It’s in a similar spirit to Why’s (Poignant) Guide to Ruby, but more instructive and less nonsensical, without being any less funny. In addition to being a highly readable and excellent learning resource, it’s also home to golden quotes like this:

You also can’t set a variable to something and then set it to something else later. If you say that a is 5, you can’t say it’s something else later because you just said it was 5. What are you, some kind of liar?

And totally irrelevant but highly amusing illustrations like this:

I therefore assert that Learn You a Haskell is the most awesome guide to any programming language, ever.

Even with a great guide, though, Haskell is a lot to wrap your head around. Partly because of its functional nature, and partly because of its outlandish concepts like curried functions, partial application, and folding, Haskell busted my brain halfway through chapter 6. (Okay, in my defense, it was also 4 AM.)

But it seems like a really interesting language once you grasp it, so I plan to revisit it later.

I also dabbled in Scheme a little bit, following Teach Yourself Scheme in Fixnum Days. Unfortunately, Teach Yourself Scheme isn’t nearly as entertaining or thorough as Learn You a Haskell. It’s very dry reading, and unless analyzing macro expansions gets you off, you probably won’t find it too enjoyable.

But, I was already familiar with Lisp, so most of the concepts weren’t terribly foreign, and I didn’t need as much handholding. For the most part, I just needed an introduction to the terms and function syntaxes peculiar to Scheme. But therein lies a problem: there are lots of Scheme implementations, and they are all peculiar.

SchemeWiki.org lists some 70 different implementations of Scheme, and none of them are authoritative. Perhaps in an attempt to remain apolitical, very few of the lists I’ve found give any sort of indication of which ones are any good. Which are stable, efficient, easy to install and use? Which ones have the most users? What features do they support? Are they still actively developed? Which (if any) of the 6 or 7 Scheme standards are they compliant with? What quirks or extra behavior do they have?

Am I expected to download and try every implementation, devise tests and benchmarks to determine compliance, efficiency, and feature set, and then decide which one I want to use to learn the language? Not gonna happen. Even reading the web sites for every implementation is more effort than I’m willing to spend. If there were 2 or 3 to choose from, sure, but not 70.

In the end, I just said “screw it” and installed Gambit on the highly scientific basis that it has a cool name. But, I might use MzScheme for learning, since that’s what Teach Yourself Scheme uses, and I wouldn’t know the difference.

I’m still interested in learning more Scheme (at least enough to find out what’s so great about call/cc), but the learning experience so far has not been nearly as rewarding or entertaining as it has been with Haskell.

Maybe Scheme needs a tutorial with a sense of humor and an octopus playing Guitar Hero?

It couldn’t hurt.

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!

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.

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

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!)

Here’s an expanded/refined concept for my RubyWeekend #2 game. Like last time, I’m not going to put all the posts about it on the home page, so it won’t spam your RSS readers. I’ll put up the announcements and big stuff, but if you want to follow everything, you should check the rubyweekend section.

The game is called Solunaria (solar / lunar + ia for fanciness). You control a large, magical, glowing moth. On one side of the moth’s wings is the sun, and on the other side is the moon. For some reason (maybe bats are coming?), you have to guide your smaller, non-magical moth friends into a box.

When your wings are showing the sun side, it glows very brightly, and the moths fly away from it to hide. When you’re showing the moon side, it glows softly, and the moths are attracted to it. Using your two opposite abilities, you have to push and pull the moths to get them into the box!

I think the solunar moth will be moved with the mouse. Left clicking will switch to the sun side, and right clicking will switch to the moon side. I’m not sure yet how I’ll avoid the obvious strategy of sitting in the box and using the moon side to pull all the moths in; that would be a pretty easy game! Maybe you can’t get within a certain distance of the box, or it’s too small of a box to fit you?

Probably there will be a timer; either you’re being timed to see how long it takes you to get all the moths into the box, or you have a certain amount of time before the end games (bats come and eat everything?).

That’s the idea! A little crazy, a little arty, small enough scale that it might be achievable (even given the slow start). Off I go!

A quick blog post with my crazy game idea for the RubyWeekend #2 contest.

The idea is a half-sun half-moon guy (kinda like this). You move him around with the mouse, and switch between sun and moon to make moths go into a box. (The moths don’t like the light, so if you are sun they will fly away from you.)

Okay, it’s a silly and daft idea, but it’s the best I’ve got, 7 hours into the contest!

Here’s a handy tip that shows off one of the little conveniences that makes me love Git.

In Subversion, if you made a mistake in one of your commits – too bad. At best, you might be able to edit the revision log, if your repository was configured to allow that (Sourceforge repositories aren’t).

In Git, as long as you haven’t pushed upstream yet, it’s trivial to change the commit log, or even the actual commit contents!

When using Subversion for vertion control, I was always conscious of revision numbers when committing. It was as if there was a limited supply of revision numbers, and I didn’t want to waste them making tiny commits. So, I’d often bend over backwards to make sure the change was significant enough to be “commit-worthy”.

It’s an awful habit, to be sure, but I know I’m not the only one. I recently had one of the programmers I manage (a very bright kid, if still a bit green) apologize to me for committing 20 revisions in a single day, as if it was wasteful or inconsiderate to make frequent commits! I think you become less concerned about “wasting” commits as you get more experienced, but it was still always in the back of my mind.

Not so with Git. The reason is simple: Git doesn’t use incremental revision numbers. Instead, it uses a long string of digits and letters which is totally meaningless to a human being. (Getting technical, it’s based on a SHA1 hash of this commit and previous commit(s), or some such thing. But it’s non-obvious to a human what the connection between 2499051dca30def85f5433c08519adea56a12a14 and its parent aaaa83fc4e9737b41a5c52b16e946b34dab63ede is.)

Since the commit identifier is totally meaningless to me, I don’t pay attention to it (except in the rare cases where I need it, such as checking the diff for that commit). And because it’s not a number that gets larger the more I commit, I don’t feel like I’m “wasting” numbers by commiting often – sometimes several times per minute.

Yet another way Git and other distributed version control systems assuage our obsessive-compulsive tendencies and promote good habits.

What went right:

• The character art came out well.
• I was really happy with my original game concept, even though the actual game didn’t live up to it.
• The code is pretty clean, IMO.
• I got it to a playable state (altho not very fun).

What went wrong:

• I spent too much time on the character art, and not enough on the coding.
• I hit several periods of coder’s block that hurt my productivity.
• The gameplay is pretty dull.

What I learned:

• More familiarity with using Git, especially good merging practices.
• How to set up a publicly-accessible Git repository on my web site.
• The fact that hanging out in IRC is a huge productivity sink. … Oh wait, I already knew that one. : P

What I’d do differently:

• Less time on art, more time on code.
• Instead the boring spacebar mashing gameplay, implement the more interesting gameplay concept of strategic answers and rebuttals, like I wrote about in the original concept, and showed in my concept screenshot.
• Use Gosu. Gosu is so cool. ; )

You can also read more post-mortems by many of the other competition participants.

Done! Here’s my entry for RubyWeekend #1! You can follow my previous entries in the zombies-vs-pirates rubyweekend section (they didn’t appear on the home page or in RSS feeds).

Here’s the premise of the game:

It’s another election year, and the two major political parties, the Zombie Party and the Pirate Party, have chosen their candidates!

You are Senator Rrghhnn from the Zombies; your opponent is Senator Birdbeard from the Pirates.

Oh, look, it’s time for the Presidental Debates!

You and Senator Birdbeard disagree on a number of important issues, including what to do with the nation’s brains, and where to bury the tons of gold that used to back the value of the U.S. dollar.

But the issues aren’t important to the voters – this debate is going to be decided by shouting! Loudly!

The game is simple – mash the space bar to shout louder than Senator Birdbeard!

Download the game!

Requires Rubygame 2.3.