This is an important question related to the game at large, what will be the size of a normal map in the game?
Large
If all of the game world was placed in one map, with perhaps additional dungeon maps, we would have a large open ended world. Many modern western RPG's are like this. Oblivion and Fallout most notably. It's a good choise for real 3D worlds as you need to see farther than you can walk anyway. But to me there's usually always too much walking around, too much nothing in between things. I'm envisioning Driftmoon a little more tight packed. Technically it would require a lot of changes to get everything to play smoothly on one map, so I'll have to rule this one out by lack of development time.Medium
A medium sized map could have one town and various open areas- a lot of quests to play with a reasonable amount of enemies. Something you could spend an hour or two playing. This was my original plan for Driftmoon, and each map would have been an island. You would have played the islands sequentially, and within the island would have been an open area for you to play as you like.But the more I think about it, the more I would like to play in even smaller areas. Even on a medium sized map there would be a lot of boring walking around, fighting filler enemies. Basically all RPG's tell you at some point that here's somewhere you need to go, look it up on your map and get there. That forces you to leave areas unexplored, or if you decide to explore everything in your current location before going to the new place, you'll likely forget the plot, why you were even going there. That happenens to me often, I decide to explore the current area completely before going on, and then I drop out of the main plot and quit.
Small
What I've been hatching is bite sized maps. They have one main quest, maybe one optional quest, and a couple of enemies to kill. Each area can be as unique as I like, they don't have to be connected to each other by filler terrain or filler enemies. When you're done playing the area you really know that you've played it through, you don't have to spend 10 minutes looking for important people you've missed, main quests you're missed. You can play it in one go so you're less likely get interrupted and forget what you were doing. And even if you do get interrupted, the map is small enough for you to find out what's going on.And if you're anything like the people who've test played Driftmoon when I've been looking, you'll be very glad that a smaller map is easier to navigate. All my testers got lost at some point in the preview maps. And those maps were pretty small to begin with!
What do you say? Which map size do you prefer?
It's been slow replacing the whole graphics engine, but I'm nearly finished now. I've found dozens of additional bugs in the process, so everything will be running even more smoothly in the future. Plus the rendering speed is now a bit faster in several key areas, particle rendering and floor rendering in particular.
Sadly I couldn't find a good alternative for the text box used in Irrlicht. I resorted to using the default DirectX text box, which doesn't have multi-lining - I'm going to have to come up with some ideas for the conversation editor which was the only place where multi-line editing is a requirement.
Oh, and I don't remember showing you this fancy automatic shadow system I implemented! It's an on/off toggle button in each object's graphics edit screen, it renders the same sprites in transparent black.
Since working on the low level code is so boring I've been thinking about the actual world and the framework for the gameplay. Anne says I've got to sleep today, so I'll talk about that next time. 
For the past couple of weeks I've been removing our graphics engine Irrlicht and replacing it with DirectX 9. Well actually for the past week I've been too sick to really code, but nevermind that, I'm back in the wheel!
Here's a shot of the menu, it's the part I've been working on most and it looks pretty much the same as before.
The difficult part is coming next, replacing the text edit box. These are a notorious bane of all programmers who cannot use the default operating system edit boxes. A simple multiline box where you can write can be suprisingly complex to program. Most users have already used some windows text editor, so they're expecting the same functionality. If any of you know of a good edit box I can drop into Driftmoon, do tell.
So this Pharaoh from Egypt comes to me and says: "Love your Bikez 2 game, but I have a kinda stupid question - was there any Bikez 1 game? It bugs me and my friends " Well, Ramzes and friends, you're in luck, because it's time for part 2 of our oldies list.
Bikez 1 was a GTA 1/2 style top-down deathmatch for two players split screen style. There was a level editor, a shop for choosing from a dozen or so weapons, and more importantly, you could shoot the civilians.
Sadly time has not been so kind on Bikez 1, as the transparency function doesn't work on any modern hardware. You can download it, but be warned, it's in Finnish! And if you see the pink borders on everything, it's not playable. 
I somehow managed to make Magebane 1 without ever learning to use things like arrays, for loops, while loops, or even any kind of structures. This time I had used actual DirectX, and most of the code that actually worked came from DirectDraw example code. I still have no idea how the whole thing took 7000 lines of code, whereas the simplistic game I do at work goes well into 200 000 and counting.
Bikez 1 was probably my least downloaded game. At first I released it as shareware, but sadly I really didn't know how to use the internet to sell it. Later on in 2004 I released it as freeware, but I could never really get it working with modern hardware. Surprisingly it seems to work fine on my Windows 7 right now.
I'm still hoping to do another split screen game someday. Now that I have a wife I can force to play with me, it should be much easier than in 1999, when I had to wait for my brother to come and play with me.
I'm really hoping someone asks of The Forge next, so we can do this chronologically.
This is a technical rant, so be warned. I'm reinventing the wheel. I'm systematically replacing all of other people's code with code of my own. Here's why:
In 2005 I wanted to make a cutting edge indie game engine for my next game. I wanted to compose my engine of different parts, thinking that somehow that would speed things up. I didn't want to reinvent the wheel, obviously. I chose Irrlicht for graphics, Newton Dynamics for physics, RakNet for networking, Angelscript for scripting, and Audiere for sound.
Choosing to use good existing libraries was a good choise wasn't it? It would speed up development, I could start using those sounds and physics and whatnot straight out of the box. As the libraries were updated, my code would become better with no effort on my part. All I had to do was combine the well designed interfaces. Naive thinking.
No library is perfectly suited for the task you have. You're better off writing the code yourself.
- The library doesn't have all the features you need, and it never will. If the library you want to use is missing a feature, it will never be there. The maintainer's may tell they're hard at work implementing it. But it will never get in there. If you really need that feature you can't depend on promises. Real life can get in the way, other features can get in the way. It's a risk you don't want to take if you really need a feature. I waited four years for Vertex Buffer support in Irrlicht. It got there in the end, but not the way I wanted.
- The library won't suit your needs after all. Newton Dynamics couldn't support the amount of physics objects Driftmoon deals with, mainly because it was a 3D physics library. Turns out I wanted a 2D physics library instead of 3D.
- Updating the library will break your software. In the beginning Angelscript had a lot of bugs, it was just getting started after all. But each time it was updated, some of the interface changed, requiring extensive code changes. There's no telling what an update of a library does, maybe it fixes something and adds features, maybe it adds some very clever bugs, requires a complete rewrite of your own code, and removes just the feature you needed.
- There will be hard to track crashes and bugs. Audiere crashed the whole game at random intervals (see earlier post about sound libraries). The reality is that a library will have bugs in it, and you may never know whether the problem is in the way you're using the library or within the library. Right now my Irrlicht text rendering becomes crawling slow at some random point in the game. I have no idea what's causing it, maybe it's a bug in Irrlicht, maybe I've done something wrong.
- The library interface will suck. Newton Dynamics wanted you to build your code around it. You didn't tell it that your object had this physics representation, it told you that I've got your physics right here, you can add your object to that. You shouldn't be forced to structure your code to suit a library, but that's often the way it goes.
- The library will be bloated. So maybe the library has all the features you need, and then some. I wanted to use OGRE graphics library at some point, but turns out the library would have taken ten times the space my code did. The space is less of a problem these days, but you'll have to think forward to the day you need to debug the library. Can you find the code paths you're using in the mess of code? Can you add the feature you need if you can't understand what the thousands of source files do?
- The library maintainer will abandon the project. You find a huge bug in the library, what do you do? Fix it? No, you point it out to the library maintainer. Maybe he's lost his interest, got fired, or maybe the company is bankrupt even though you've got paid support. So what do you do? If you're lucky you've got the code so you can fix it yourself, which brings me to the next point.
- You will not be able to fix any of the bugs in the library. Chances are the maintainer isn't interested in your bug reports, and you're the only person on the planet still using the library - you'll have to fix the bugs yourself. But you can't understand advanced physics/networking/graphics, that's the whole reason you used the library in the first place!
Get our newsletter!