Its Good to Rewrite

Here are 5 reasons you SHOULD rewrite your projects:

• You’ll have a better design the second time around
• It’ll take you less time to come up with something much better (from a developers point of view, anyway)
• Contrary to popular belief, you can keep most of the good code when you rewrite
• Rewrites can make your project less frustrating to code, less frustration == more productivity
• You may even have less intrinsic bugs!

Game Showcase: Beatboy

Today I will review Beatboy, a game made with Ruby.

Beatboy is a game made with the SFII90 engine. This game allows you to make your own beats with samples provide by the game or samples you provide yourself.

Its more of a toy than a game, but that didn’t stop me from spending a while playing it
Try it out for yourself and tell me what you think in the comments!

Screenshot:

Beatboy Screenshot

Note:

To play this game you may have to install a few things..
1. Download a newer version of “opengl32.dll” from:
http://sfii90.googlecode.com/files/opengl32.dll

2. Move the new “opengl32.dll” to beatboy’s “bin” directory.  This will
probably be “C:\Program Files\beatboy\bin”.  It should overwrite the old
“opengl32.dll” file.

3. Also, if you don’t hear any sound from the game, try installing the
OpenAL drivers from: http://sfii90.googlecode.com/files/oalinst.exe

Thanks Phillip for the fixes!

If you would like your game reviewed, go to the Making a Game with Ruby? and post a comment.

Ruby Tower Defense Status Update

Ruby Tower Defence (rbtd) has had 46 version control commits. It contains:

• The main game loop
• A GameObject class
• A Box class for prototyping
• A Text class for a HUD
• An event hook system (instead of using rubygame’s, so I could tweak it more and for compatibility with the most current Windows releases (2.3.0 instead of 2.5.0) )
• Game States

This is all done on the back end and no actual game development has been done. I’m doing this in the hopes that having a nicely structured engine for the game before I start development will make the addition of new features easier and less painful.

Things I still need:

• Sound
• Sprites/Pictures
• Better game state management (it works,, but I think it could be better)
• Collision detection
• And maybe the basics of a GUI framework (but that may be part of the game, and not the engine)

Besides me wanting a nice framework before I started, I also had no idea how the hell the game was actually going to play. So I used the engine to make my free time more productive.

As you may have noticed by the previously posted design document, I came up with a bunch of design ideas last night. The ones for Ruby Tower Defence are only half formed, and need to be prototyped.

As always, a link to the project: Ruby Tower Defence on Launchpad

Survive in the City

You are captured by enemies. Your play styles are:

1. Escape the city
2. Hold out for as long as possible
3. Take over as much of the city as you can
4. Penetrate as deep into enemy territory as possible
   1. Take down the enemies main command station (could involve a huge fight of every enemy left after you destroy it)

You are a high profile target, everyone is trying to kill you. The game could either infer the type of game style you are playing, provide options to let the player track his progress in a play style, or chosen explicitly from the menu.

If the choice of play style is not explicit, it could be possible to play all play styles in one game. For example:

A player could fight his way into the city and take the enemy’s base (play style #4). The remaining enemies would then focus their efforts on their old base (now your base). You would hold out until there was an opening to escape (sort of play style #2). You could then fight your way out of the city because you have gained some important info from the enemy’s base (play style #1). Then when you were safe you could recruit some people from your side and try to completely take the enemy’s city (play style #3).

If the player keeps track of his progress:

pros:

• He can do whatever he wants with less constraints

cons:

• There is no explicit reward system, no “Good Job!” or “Game Complete” or riveting cut scene.
• Or any other type of reward since the game would be unaware of when something is accomplished.
• Also with no game regulated play style, the AI’s strategy could suffer.

If the game infers what play style the player is using:

cons:

• The system could be wrong because of misinterpretation or a play style that is not recognized, leading to very frustrating situations.

If you explicitly choose the play style from the menu:

pros:

• In game bonuses, win-screens, etc.
• experience could be better tailored to the play style
• impossible wrongness (because that’s what the player picked!)

cons:

• possibly too restricting.
• If the player decides to switch it up half way through, he could become frustrated.
• The play style could become too tailored, and end up being 4 different games.

Play styles explained in detail:

1. You are a high profile target so you have to be careful and stealthy. You have to get out of the city and away from your enemies until you are in a safe location (over the border, at the pick up point, etc.) You may be using stealth or may gun your way through as fast and as obvious as possible.
2. You build a base and:
   1. Barricade it up
   2. Stockpile supplies
   3. Keep enemies away
   4. This mode would either be:
      1. survive as long as possible against an endless horde
      2. fight the enemy until the go all out on you/you have killed everyone
3. You build a base and:
   1. Barricade it up
   2. Stockpile supplies
   3. Keep enemies away
   4. Connect to other possible base locations and expand your territory
   5. Recruit/Smuggle in people from your side or persuade enemies to fight for you
   6. Try and take over as much of the city as possible until:
      1. You have it all
      2. You are killed/your base falls (could you base/recruits fight on without you? (and you just watch?))
4. Fight your way into the city, you don’t have time to hold down a permanent base, but may need to set one up from time to time to regroup, rest, etc. This has two play style possibilities:
   1. The goal is to get as far as possible. With your battles getting harder as you go further.
   2. Or if we have a city of finite size: To get to the center of the city and destroy the enemies main base and their leader. Which then has the following possibilities:
      1. You use the enemies main base as your own and fight the remaining enemies in the style of play style #2
      2. The game ends with the players mission successful

Tower Defense!

After my decision to stop working on Block Bounce. I have decided on what I will make next: a Tower Defence game . I have named it (rather uncreatively) Ruby Tower Defence, or rbtd for short.

More than that, I also want to try out the VCS, bazaar (bzr). I plan on writing a review of bzr, and a comparison of bzr vs git.

I’ve decided to write a nice backend to the game first, before I start on the actual gameplay. You can find the work I’ve done so far on Ruby Tower Defense’s Launchpad page.

Block Bounce Is Over

I’m no longer going to develop Block Bounce any more. I’ve lost interest and feel that the alpha5 release is Good Enough™. As much as I wanted a completely finished game to add to my portfolio, I am not one to force myself to do things. If I ever get a random burst of desire to code, I wont stop myself. But I’m not going to be actively coding. I may yet write a post-mortem as to what went right and what went wrong, but alas, I may not even to that.

Bye!

Block Bounce Alpha 5 Released!

Yep, it’s true, only been 11 days and I’ve made another release. I’m starting to think my goals are too easy to achieve… Shouldn’t releases take longer?

I hit no major roadblocks code-wise this week. I did, however, get sick during the development cycle… That was no fun. But I’m better now!

We now have:

• A Title Screen
• Pause
• Easier to load levels (via the title screen)
• “Are you sure you want to quit?”
• You go back to the title screen when you win or lose

Alpha 6 might actually be part of alpha7, because it only has one goal and will probably be very easy (I hope!)

Block Bounce on GitHub

Block Bounce Alpha 5 Download (Source)

Bye!

Block Bounce Title Screen

Threw this together in a couple of minutes. Not too bad for programmer art (if I do say so myself).

Block Bounce Title Screen

Its going to be the background for the title screen.

What do you think of it?

Block Bounce Alpha 4 Released!

After what is the shortest time between releases (6 days!), and with a list of things I thought would take a long time to do. I released alpha 4!

Here’s the TODO list I had for this release:

• Blocks take 2 hits to die (Start of level properties)
• Win condition (all tiles destroyed)
• Be able to lose balls to the bottom of the screen
• Fail condition (3 balls lost)
• Have a “Click To Start” message
• Level Properties Editor
• Fix all bugs found up to this point

I thought the creation of level properties would add on another week, I was wrong… (I hope no one finds out I can finish tasks in half the time I estimate)

Block Bounce on GitHub

Block Bounce Alpha 4 Download (Source)

Lesson Learned: There is Always a Simple Solution

As I was working on my game Block Bounce, I ran into many problems that I couldn’t wrap my head around. The solutions started off very complex, spanning many lines. These complex solutions would often fail, or only half work. As it turns out, every single time I had to do something like this, I could always find a simpler solution later on (that worked consistently too!).

Here are my tips for getting the simplest solution:

• If your implementing an effect, try faking it. Even though it may not be implemented in complete realism, it still looks just fine
• Approach the problem from as many angles as possible.
• Take a break. Sometimes just walking away, or just leaning back and closing your eyes can help you solve the problem faster.
• Never develop tired. You can’t think completely clearly and obvious solutions always seem to evade when you are tired.