“Mashing” means you mix the crushed malt with water and heat it up to a specific temperature so the enzymes that convert starch to sugar are activated. You have to keep a series of temperatures for a specific amount of time, because there are different enzymes that all work at different temperatures. This process is the starting point and determines for a large part the final taste. You can start with the exact same materials and end up with something entirely different if you change the mashing scheme.

A major difference was also that after boiling, there was lots and lots of stuff in my wort (the unfermented beer) that needed to be filtered out. This stuff is mostly proteins from the malt. When I used malt extract, this wasn’t so much of an issue. Getting the stuff out was not so easy, because it immediately clogs every filter. I have to think of a better way to do this next time. It was quite messy!

So right now, the beer is fermenting in my boiler room, where it’s a nice 25°C. The fermentation seems to go very well, and I expect it to be finished in a few days. After that, it’s two weeks of secondary fermentation in the basement, then bottling and finally, two months waiting until it’s ready to drink.

• Player graphics are done. This means the ship, weapon animation, rockets, cannon shells, flames and explosions. Interesting detail: the rocket flames are animated sprites and not particle effects. Moving particle effects are a bitch to make. The cannon also ejects empty shell casings.
• The camera tracking has been improved. The camera follows the player, but the connection between the player and camera is a bit elastic, so the movement is smooth. The disadvantage is that the camera always trails behind, so the player is too close to the wrong side of the screen and you don’t even see your target until you’re too close. I have solved this by mounting an invisible object to the player and positioning it in front of the player. The camera follows this object instead of the player, so you always have a perfect view in front of the player.
• I have implemented a zoom functions. You can now zoom in and out, wich can sometimes come in handy if you want a better overview of the battlefield.
• Explosions! The projectiles you fire explode when they hit.

The next step are decent graphics for the player launch platform, and the level building blocks. When these things are done, I hope to get rid of the prototype look so I can finally publish some actual screenshots.

• The game design process; An excellent article from Gamedev.net describing the different elements of the game design process.
• A showcase of astonisihing spaceship concepts; Almost every idea I have in mind involves spaceships, so this would be an excellent source of inspiration.
• Quad tree design; A core technique for high performance collision checking. I don’t need this at the moment since I use Torque Game Builder, wich has built-in collision checking, but it will come in handy once I start using XNA. Also very usefull: the Wikipedia entry for quad trees.
• Program like a Quake developer; A free book by Michael Abrash, one of the developers of Quake. The book is quite outdated, of course, but it’s still a very interesting read.
• Anatomy of an MMORPG; Unless you’re very experienced, very rich and very crazy, don’t even think about developing an MMORPG. This article should do a fine job of explaining why.

The scanned drawing was then imported into Inkscape for tracing. I imported it as a bitmap image and used it as a background for drawing the ship. You can’t see it here, but this image contains about ten layers!

The biggest difference, however, is th way the image is colored. Previously, I used Inkscape for this as well. I found this a bit difficult, though. Smooth gradients and solid colors are no problem, but effects like inner shadows or anything that uses blurred lines or fills. Blur effects slow the program down like no other! So this time, I imported the line art into Gimp and used that to color everything. The colors are all separate layers, so the final image contained about twenty layers!

This looks already pretty sweet, but it’s not the final image just yet. First of all, the player will be a lot smaller than this, of course. And I’m gonna try to add some surface textures to the ship. Yep, I think this is a pretty good method!

Oh, and for the weekly link roundup: I haven’t found anything worth mentioning this week.

• What every programmer needs to know about game networking; An explanation of peer-to-peer and client-server networking. Adresses the main issues of both methods and a solution named client side prediction, wich eliminates input lag.
• Con Artist Games; A developer that’s working on a cool zombie game. And who doesn’t like to shoot zombies?
• Rokon; An OpenGL-based 2D engine for Android. I bought an Android phone myself a while ago (an HTC Hero), and I might give game development on it a try.
• Android Game Development resources; A short list of Android development resources, including a Quake clone for Android!
• Procedural Content Generation; Techniques for generating game content, such as maps and levels, through automated algoritms. Perhaps the most famous game that used this was Diablo II.

Like I said before, no more narrow corridors and grid-based movement. Omega Arena features large, open levels and lots of freedom of movement. The gameplay is, essentially, like Asteroids. You pilot a craft you have to rotate and fly using rocket thrusters. The ship is equipped with two weapons: a grenade launcher and rockets. The rockets are very potent, but you have only a limited supply and are slower than grenades. The grenade launcher has a larger capacity, but has one hell of a recoil.
I have decided to limit the weaponry to these two main weapons, but there will be lots of upgrades you can pick up during the game. This is something I was gonna put in Gridblaster II and I decided to keep it. The same goes for the enemies. The game will have spawners that launch the next enemy when one is destroyed. The enemies in Gridblaster II were the main reason I cancelled it. The collisions between enemies were insanely difficult to handle and kept messing everything up. In this game, they will just bounce off each other and the walls using the built-in physics engine of Torque. Besides the regular enemies, the game will also have static weapons, such as gun and rocket turrets. And lots of booby traps.
You might also wonder where I got the name Omega Arena. The very first game I played when I got a C64 (I was 8 at the time, wich was in 1986) was called Omega Race and followed a similar concept. I had been thinking about a cool name for this project for a while. I had already decided it would have to be something with “arena” in it, so it became Omega Arena.

Okay, done? Great! So, here are my plans for Wintereenmas. One of my WoW characters is about to enter Outland and I want to celebrate Wintereenmas by kicking ass in Hellfire Ramparts. Also, I hope to get some more work on my upcoming game done so I can finally post an announcement next weekend. So everybody have fun and game on!

• The 7 commandments all video games should obey; A nice list of things no game developer should ever put in a game again. My number one pet pieve: escort quests! They are frustrating, boring and most of the time the AI of the character you’re supposed to guard is as dumb as a brick.
• Indie Game Music; No game should be without a soundtrack. This website has a nice selection of game soundtracks in various formats, and most of them can be used for free in freeware games.
• Game GUI; If you need some inspiration when designing a user interface.
• Game Textures; Perhaps not very usefull for 2D games, but the textures look damned nice!
• RB Whitaker’s XNA tutorials; An impressive collection of XNA tutorials. I’m still working on C#, but I hope to use XNA for one of my next projects.

That’s all for this week!

1. World of level design; Level design tutorials, interviews, level building tools and a forum. Aimed more at the modding community.
2. The Doom Wiki; A collection of everything related to Doom and games powered by the Doom engines.
3. Game programming patterns; A work-in-progress, still in the early stage. Not much content at the moment, let’s wait and see.
4. Steering behaviours for autonomous characters; All about steering behaviours.
5. Open Game Art; A directory of free game art. Includes sprites, animations, 3D models, textures and audio.

So that’s everything for this week. More stuff coming next week!

The game follows the classical approach. Notes drop down the fretboard and you have to press the right buttons at the right time. It is played with four buttons. You can choose between ASDF, HJKL or 1234. I prefer HJKL for one simple reason: Belgium is one of the few countries that use the azerty keyboard layout instead of qwerty. I have no idea why this is, but it can cause serious headaches at times, especially with games that have the keyboard input hard coded in them and don’t allow you to customize it.

The game is quite short but very addictive. It contains six songs and has four difficulty levels: easy, normal, hard and geek. On easy, you never have to play more than one note at a time, on geek you often meet three note chords and fast solos. The songs are all instrumental rock songs and sound quite good. Some of them include Kirk Hammet-style guitar solos. The gameplay is only about hitting notes. You don’t have to strum or sustain notes. Even though it’s a bit short, it’s a very cool game. The animated guitar player during the game is hilarious.