Jar Of Eyeballs

Okay, here’s the deal. It’s been a while since I worked on this game. For the past weeks, I’ve been mainly busy playing WoW and doing stuff with friends. Almost a year ago I joined an organisation for single people and that’s been taking quite a bite out of my free time for the last few months. I’ve been elected into the organisation’s administration, meaning I have to attend several meetings each month and work a few evenings in a row once in a while. This also means the game is progressing slowly and I don’t have a lot to show off at the moment. Here’s what I got so far:

I know, not too impressive. I’ve created graphics for the enemy spawner and the first stage of the enemies. These graphics will remain the same in all levels; the main difference between the levels will be the maze look and feel.

Okay, here’s another short update on Gridblaster II. No new graphics to show off, but some major advances in code. Here are the features I added:

• Enemies fire at the player, and detect if there’s a wall between them and the player. They only fire if they have an open line of fire.
• Player and enemies can collide with each other and explode. You don’t get points for destroying an enemy that way.
• Projectiles of player and enemies can collide with each other. This means you can actually shoot down anything the enemy fires at you.
• Cheat mode can be enabled, giving you unlimited hitpoints, lives and ammo. Not that you would ever use this, would you?

And here’s a list of new bugs I ran into:

• The wall-detection doesn’t work 100% of the time, and I have no idea why.
• When two enemies collide with each other while one is exiting a spawner, very unpredictable things happen.
• I still haven’t found a way to solve the wheel animation issue.

These bugs aren’t really critical, though, except maybe the second one. From time to time, this causes an enemy to move out of the maze and start moving around at random! I hope to solve this issue soon. In the meantime, I’m working on some more graphics. I’ve got enough working code now to build a fully functional level, meaning it’s time to start replacing the dummy graphics. Expect more screenshots soon!

I’ve mentionedI was working on some player graphics a few times in my tweets and in a previous post, and here’s the result. This is what the player looks like. Took me quite a bit of effort, but the result looks good (at least, that’s what I think). The main problem was drawing something that wouldn’t get messed up too much when scaled down. The original drawing was much, much bigger than this (about ten times bigger). I added all sorts of details, but when scaled down most of them simply disappeared while others looked horrible. I removed most of them and experimented a bit with line width to get a decent looking scaled down image.

The entire player object consists of not less than 14 different sprites! A bit of a problem was keeping the 3D-look of spherical objects. For example, the wheels. They turn in the direction you’re driving, but I couldn’t just turn the entire sprite. The highlight is on the top right part, and turning the wheel would also move the highlight around, ruining the entire effect. I solved this by using two sprites. One is opaque, has the highlight and shading and doesn’t turn. A semi-transparent sprite without any shading is placed on top of that, blending together with the bottom sprite. This sprite is turned, while the bottom sprite doesn’t, thus preserving the 3D effect.

There’s still one problem. The wheels are animated so they appear to be rotating. Of course, when the player stops, the wheels also have to stop. The only problem is, this isn’t as easy as it sounds! Torque can’t stop or start a cyclic animation, it’s always running. I tried making it non-cyclic and then restarting it every time it ends, so I can make it stop when the player stops. This doesn’t really work, since it makes the animation skip frames from time to time. I have a few ideas in mind I can try and I will probably solve the problem, but this isn’t very high on the priority list right now.

So what’s planned next? The next big step is making the enemies shoot at the player. This will be quite tricky, since I don’t want them to fire when there’s a wall between the player and the enemy. I’ll have to work out a way to determine if there’s an unobstructed line of fire. When that’s done, I’m gonna start working on the graphics so I can start building a complete level.

A while ago I said I was gonna work on a few prototypes first before announcing my next project. Well, here it is (or at least one of them): Gridblaster II! The game concept is similar to the first Gridblaster, but this one will have more variation and be much bigger. The first Gridblaster was more or less a clone of the C64 game Crossfire. Also, it was the first game I made with Torque Game Builder. Everything was very new to me and I had to experiment a lot. This, however, won’t be another clone!

When I talked about “prototyping” earlier, this is what I meant. When I got started on the game, I used all dummy graphics. In fact, I didn’t even have the slightest clue about what everything was gonna look like. By using dummy graphics I could focus better on coding. I’ll continue using lots of dummy graphics for a while; only the most important objects will get complete graphics for now. I’m working on some cool graphics as well already, but they won’t show up for now.

So what will be new in the sequel? Quite a lot! Instead of a simple grid layout, the levels will be real mazes, complete with dead ends and junctions. It will also be bigger, spanning multiple screens. The player and enemies will spawn from bunkers within the maze, not starting positions outside the maze. I’m also gonna use a savegame system and player statistics, wich will be a first for me. And the weapons will be completely different. In the first Gridblaster, you fired plasma balls. In this game, the player will be a tank with a rotating turret, a cannon and rocket launchers. Ammo won’t be infinite; to reload, there will be ammo stations at various locations throughout the maze.

A bit of explanation about what you see in the über-ugly screenshot. The gray squares are the building blocks of the maze; you can clearly see it will have a tile-based setup. In the middle of the screen is the player. It’s already got wheels that turn in the correct direction and a rotating turret. The red thingies with the green doors are the enemy spawners; enemies come out of these things. For now, this enemy is a yellow circle. It doesn’t fire or take hits yet, I’m focusing on the navigation right now. The green cross-shaped thing in the upper right corner is an element of the user interface. It doesn’t do anything, I just put it there to check if it adapts properly to different screen resolutions and aspect ratios. The blue bar on top, finally, is the debug bar, a feature in TGB. Don’t pay any attention to that.

As with my previous games, I will do regular updates about the progress. Right now I’m focusing purely on code and doing some draft graphics. I’m not gonna go ahead and promise a release date already since I probably won’t be able to keep my promise anyway. By the way, I also found a great code editor today, so expect a review about that in a few days.