Jar Of Eyeballs

Me and my brother are addicted to World of Wracraft. He was into it from the start and managed to drag me in last year. Besides videogames, we also play boardgames a lot, so this was actually inevitable: he bought the World of Warcraft boardgame!

This is obviously not something for the occasional boardgame player. As you can see, we filled the entire table. He got the main game and the Burning Crusade expansion. The playing area consists of the northern part of the Eastern Kingdoms, and the Burning Crusade has the entire Outland map.

So how does the game work? We each played with two characters. It’s pretty similar to the videogame. You choose a class, buy skills and equipment and gain levels by doing quests. The goal is to defeat a boss, wich is hard as hell even at maximum level with very impressive gear. Combat is done with 8-sided dice, of wich you need a lot. Towards the end of the game you’ll often find yourself rolling over 20 dice!

Here’s a closeup view of my warrior, in the early stage of the game. The card at the bottom is my first talent. The other cards on the character sheet are skills and items. What most of these do is adding dice to your dice pool (the more dice you can roll, the better), giving you reroll values (so you can roll dice again if the outcome is too low) and allow you to change dice values to higher values.

Playing with two characters each took way too long, though. We got started at 10am and played until midnight! At the end it got a bit annoying because each turn took way too long. Luckily, the game can also be played with only one character each. This is a lot faster, but requires you to work together on certain quests. Also, the final boss is impossible to defeat on your own, no matter how epic you are. You only get one try at defeating him, so you’ll either both win or both lose.

Until now, I had been using JEdit for writing my Torque Game Builder scripts. Even though it worked pretty good, it had one major drawback: it can open only one document at a time. Since I usually had at least three source files open, there were at least three JEdit windows open. What I needed was an editor with syntax highlighting, a multi-document interface and, preferably, an easy way to browse project files. And here’s a good one, one that’s been written especially for Torque: TorqueDev.

I have opened the Gridblaster II source files to demonstrate the capabilities of Torquedev. You can import the entire game directory into a project file, so you get all source files structured the same way they are on your drive. By default, it imports only Torque files, but you can use it for any other text-baded file type as wel. I use XML files for storing configuration settings, wich I can edit directly in Torquedev. Besides the syntax highlighting, it also has collapse capabilities. It automatically collapses anything between curly brackets (very convenient for large files, JEdit didn’t have this feature), but you can also define your own collapsable regions, wich comes in very handy sometimes. As you can see in the screenshot, I have put the input functions in a separate region.

And now the bad stuff. It crashes from time to time. Adding a new source file is buggy. It generates an error message, followed by a crash. The only method that seems to work is creating a blank textfile in Windows Explorer, changing the file extension into a Torque file and importing it into the project. Not the most elegant way to do things. Debugging is something else that didn’t quite work. It relies on an external debugger, and simply selecting it as the default debugger made the program crash. I don’t know if anyone has gotten this to work in some way, but if you do, please let me know! I want real debugging features, not the improvised methods I use now.

Despite the few shortcomings, this tool will definitely replace JEdit from now on. The built-in file browser and code collapsing are a huge advantage. At the same time, it isn’t bloated with useless features and it has a very intuitive interface, making it very easy to get started with. Some other text editors I have seen are loaded with toolbars you simply never use.

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.

I search for free or cheap game engines from time to time, just to see what’s available. Something I keep running into all the time are these “build your own MMO” toolkits. Sounds fun, right? Who doesn’t dream about writing their own MMO, and with these tools it seems easy as hell. Unfortunately, I think these games are doomed from the very beginning, and here’s why.

The first M in MMO stands for “Massive”. This means both a massive amount of players and a massive world. An MMO that has hardly any players and a world you can explore in an hour sucks. Nobody will play such a game. Perhaps it will draw a bit of attention initially, but this will fade away soon enough, leaving your online world to gather dust. Second, RPG’s rely heavily on a storyline. Even a single player RPG needs a story the size of a small novel to support it, and most good ones are based on an already-existing story. For example, Baldur’s Gate had the Forgotten Realms from Dungeons and Dragons, while World of Warcraft is built on the story set out in the RTS games.

Creating an MMO is probably the most epic and daunting game development project one can think of. Even a small world requires more content than most single player games. There’s simply no way a small team can build a decent MMO world in their spare time without superhuman abilities. And besides, most games are more or less finished after release, except the occasional patch and bugfix. MMO’s aren’t, however. These games remain under development for years after the initial release. Players expect this. They expect the game to grow and expend, and if it doesn’t they won’t keep playing.

And let’s not forget the server infrastructure to run an MMO! Even if you manage to build a good world and attract players, you need enough servers to keep the game running. If the game starts lagging or players can’t login because the realms are full, they won’t keep playing. I can’t even begin to imagine how many servers it takes to keep World of Warcraft up and running!

So, to recap everything: building an MMO requires the most skilled developers you can think of and epic amounts of time and money, two things indie developers don’t have. Even if you manage to pull it off, the chances it will succeed are slim. Tools that claim to make building an MMO easy won’t change this. Therefore, it’s best to stay away from these games and leave them to the really big guys.