Git tip: Fix a mistake in a previous commit

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!

Continue reading Git tip: Fix a mistake in a previous commit

Revision numbers considered harmful

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.

Rubyweekend Post-mortem

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.

Election Year: Zombies vs. Pirates!

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!

Screenshot

Download the game!

Requires Rubygame 2.3.

Screenshot (vertical meters)

I added a VerticalMeter class, a subclass of Meter with a vertical orientation. I’m using it for the volume level, as you can see here:

Vertical meters

I’m also going to add a “Moderator Annoyance” meter – the ninja moderator gets more and more annoyed over time, and especially fast if the players are loud! When the ninja loses his patience, the game is over, and whoever has the highest rating wins.

Start of day 3

About 10 hours and 40 minutes left as I write this. It’s starting to turn into an actual game now; you can mash the space bar to shout and increase your volume meter, and the computer player “AI” does the same (random chance per frame to shout; it looks pretty good, actually). There’s exponential decay on the volume meter too, so you have to mash harder to keep it high.

Now I just need to make volume affect your rating, and add win/lose conditions, and it’ll be a game.

Meter Bars

I generalized the DemaMeter class into a Meter class, which implements behavior for drawing a progress meter / health bar / etc. widget. It takes a player and can track any attribute (given a symbol with the name). It can also take two colors, the background color and fill color. Then I made RatingMeter and VolumeMeter subclasses, which show the audience rating and volume level of the player. The small green bar is volume.

Meter Bars

Game loop

I’ve got a proper game loop now, with event handling. It even goes through rounds and phases and stuff, although they’re not very interesting yet. The game looks the same as it did before, so I won’t bother with a screenshot. The internals have changed a ton, though:

  • Implemented Game class, which sets up and runs the game.
  • Implemented Phase class, which defines game behavior for each phase. Right now there’s only ShoutingPhase, which enabled “shout mode” for both players, and starts to pass them keyboard events.
  • The players can now “shout”, if shout mode is enabled. All shouting does is raise the player’s “volume”, which isn’t displayed yet.
  • You can bind a keyboard key to a player to make them shout.
  • You can enable AI for a player (where “AI” means “a random chance to shout each frame”…)

The deadline is about 24 hours away, now. It turns out that Venut meant to end on Monday 04:00 GMT, not Sunday, so we have a whole 24 hours more than we thought. (So, the 36 hours I thought we had is now 60 hours. Woot.)

Next I’m adding a volume bar, and making the player’s rating increase at a rate depending on their volume.