Archive for August, 2008

RetroBox – The Processor

Saturday, August 30th, 2008

Time for the next piece on the RetroBox. If you don’t know what that is, start here, then go read this. This entry will be quite technical, so if you’re not the programmer type, you might want to skip it.

The RetroBox Processor

So, I’ve decided what sort of things the RetroBox processor (RBCPU for short) will be capable of. Basically, it will be able to operate on bytes (8-bit), words (16-bit), longwords (32-bit) and floats (32-bit).

When it comes to registers, the RetroBox will have 32 integer data registers, named d0to d31, each 32 bits,  and 32 integer address registers, named a0 to a31, also 32 bits each. There’s no real difference between the data and address registers, other than the name, and they can be used in the same way (I just find it handy to make a distinction between data and address values when writing assembler). In addition to these integer registers, there will be 32 floating point registers, named f0 to f31.

Also, there will be a 32 bit instruction pointer named IP, and a 32 bit stack pointernamed SP. Those shouldn’t be used for general purpose stuff, but can be useful to implement some tricks, I’m sure :-)


The Instruction Set

Here’s a list of the machine code instructions which will be available on the RBCPU. There’s only 38 of them, but I think that’s all it’s going to need. And as you’ll see, each instruction will be quite powerful in regards to what it can operate on.

NOP – no operation
JSR – jump to subroutine
JMP – unconditional jump
RET – return from subroutine
SYS – make a system call (used for things like sprites and the blitter operations)
MOVE – move values between memory/registers
ADD – addition
SUB – subtraction
NEG – change the sign
MULS – signed integer multiplication
MULU – unsigned integer multiplication
MUL – floating point multiplication
DIVS – signed division
DIVU – unsigned division
DIV – floating point division
ITOF – convert integer to float
FTOI – convert float to integer
CMP – compare two values
JE – jump if the last compared values were equal
JNE – jump if the last compared values were not equal
JGE – jump if the first of the last compared values were greater than or equal to the second
JLE – jump if the first of the last compared values were less than or equal to the second
JG – jump if the first of the last compared values were greater than the second
JL – jump if the first of the last compared values were less than the second
TST – test a value for zero
JZ – jump if the last tested value were zero
JNZ – jump if the last tested value were non-zero
PUSH – push value onto the top of the stack
POP – pop a value off the top of the stack
AND – bitwise and
OR – bitwise or
XOR – bitwise xor
NOT – bitwise not
BSET – set specified bit
BCLR – clear specified bit
BTST – test specified bit
ROL – bitwise shift left
ROR – bitwise shift right

The assembler will be strongly typed, so most of the instructions above will have a suffix of.b, .w, .l or .f to signify which type to operate on. Also, the operands for most operations can be either a memory adress or a register (so no need to always shuffle things into registers before doing anything). For example, all of these variations are possible when using the move operation on the byte datatype:

  • move.b d0,d1    ; Move the content of register d0 into the register d1
  • move.b @a0,d0   ; Move the content of the memory address pointed to by register a0 into the register d0
  • move.b 42,d0    ; Move the literal value 42 into the register d0
  • move.b @$30000,d0     ; Move the content of the hexadecimal memory address 30000 into the register d0
  • move.b d0,@a0   ; Move the content of register d0 into the location of the memory address pointed to by register a0
  • move.b @a0,@a1   ; Move the content of the memory address pointed to by register a0 into the location of the memory address pointed to by register a1
  • move.b %101010,@a0    ; Move the literal value 42 (expressed in binary) into the location of the memory address pointed to by register a0
  • move.b @$30000,@a0   ; Move the content of the hexadecimal memory address 30000 into the location of the memory address pointed to by register a0
  • move.b d0,@$20000    ; Move the content of register d0 into the location of the hexadecimal memory address 20000
  • move.b @a0,@$20000    ; Move the content of the memory address pointed to by register a0  into the location of the hexadecimal memory address 20000
  • move.b $2a,@$20000   ; Move the literal value 42 (expressed in hex) into the location of the hexadecimal memory address 20000
  • move.b @$30000,@$20000   ;  Move the content of the hexadecimal memory address 30000 into the location of the hexadecimal memory address 20000

And the same goes for most other instructions as well, and for all the other datatypes. So as you can see, the instructions are quite powerful, and allows for the low-level control you need.

I wanted to keep the RBCPU relatively simple, but at the same time make assembler programming for the RetroBox a viable option, and I’m hoping that this instruction set will enable that. There will of course be a high level language as well, but for raw speed, you’ll want to use ASM.

Ok, a bit technical this time, but sometimes it has to be :-)

A First Person Shooter Worth Playing

Saturday, August 30th, 2008

Remember when FPS games was a new thing? Wolfenstein had been out for a while, DOOM had just made a huge impact, and Duke Nukem was the latest thing… I never really got into DOOM, but I really liked playing multiplayer Duke Nukem 3D.


But there was another game, that came out at around the same time. It was called Blood, and it was sort of a horror-style 3D shooter. Now, it had some pretty generic things, like the double-barrelled shotgun and zombies, and was based on the same technique (raycasting) as DOOM and Duke Nukem 3D. But it also had some amazingly fun weapons, which worked great for multiplayer games.


One of them was the flare gun, pictured above. Now, most of the weapon had two different firing modes – the shotgun could be fired normally, one barrel at a time, or with the special fire, which would fire both barrel at once. The tommy gun would automatically sway from left to right and back again if you used the special firing mode. And so on.

The flare gun would fire a flare which flared up on impact, if you used the normal firing mode. But if you used the special mode, it would fire off a flare, and if you hit an opponent, it would stick to him, and ignite several seconds later. If your opponent wasn’t alert, you could easily put 4-5 flares on him, before he realized what was going on, and by then it would most likely be too late for him to do anything about it…


Another great weapon was the voodoo doll, with which you could hurt a nearby opponent without even hitting them – you would just jab a needle into the doll, and their health would just drop. It was great for using when you were being chased, as you could hurt your opponent while running away from him…


And a favorite weapon was the magical staff with a human skull on the top. When you hit an opponent with it, all the health points he lost, would be added to your own health, making it a great way to recover. But not only that, it was also a weapon that you could continue to use after you’ve run out of ammo, and in that case, it would use your health points as ammo. That meant that you could easily kill yourself by firing too much, but it also meant that as long as you hit with your shots, you would get back the health it cost you to fire it! What a great way to build a tradeoff mechanic into a FPS weapon.

I sort of stopped playing FPS games after that. The later ones all seemed to be going in the wrong direction, striving for realism rather than fun – and that can spoil the best of genres.

It’s quite interesting to see the impact that Portal had when it was released – and that was a small step in the same direction as the early FPS games, but not nearly enough for my liking.

I wish FPS games would focus on fun again, on interesting weapons and traps, focusing on fun rather than realism and technology. If they did, I might start playing them again.

More Miniatures – Superheroes

Saturday, August 30th, 2008

As I’ve mentioned before, I like painting miniatures. This time, I’m showing some super hero miniatures from the HeroClix collectibles strategy game. I’ll talk more about the game (which is amazingly good) in a later entry, but for now, have a look at this:


The HeroClix miniatures come pre-painted, but as the paint job is quite poor, and I enjoy painting them myself, I cover them in a layer of black and do a repaint from scratch. On some of these, I’ve not only painted them, but also done some customization of the actual model (by using green stuff putty to add details, and an exacto blade to remove stuff I don’t like. For example, the Doc Samson figure (the green haired guy, if you don’t know your comics) was way off – appearently based on some newer version of the character, while I prefer the classic one with long hair and different custume, so I changed the belt and boots, added hair, removed the gloves and gave him the T-shirt with the flash on it. Just the way he should be :-)

You can also see how I’ve equipped Sabretooth with jeans and boots, to replace that ugly jump-suit… and turned a shield agent into the Punisher 😀 It’s good fun, and I’ll be writing more about this sort of stuff later on.

North & South – Strategy AND Action

Saturday, August 30th, 2008

A while back, I talked about Defender of the Crown, and about games which incorporated different types of gameplay. This time, I’ll talk about another one of my old favorites which share that characteristic: North & South.


At the core, this is also a territory acquisition game – you move your troops around, attacking your opponent, with the goal of owning all territories.


When you do attack an opponent though, you’ll get this battle screen, where you control your artillery, cavalry and infantry. It’s quite tricky at first, but after a while you get the hang of it, and it truly becomes a matter of skill whether you win or lose.


Some territories have a fortress (the red dots on the map) and if you attack one of them, you get yet another play mode: a side scrolling plaform-style game, where you have to fight soldiers and dodge dogs, to reach the end before time runs out.


There’s a bunch of other elements to it as well. You can get reinforcements by ship if you own a specific territory (one of the ones on the right hand side) or by getting enough gold, which you get when the train pass from one fortress to another (though your opponent can try to rob the train, in a game mode similar to invading a fortress). There’s also a cloud moving across the map, and whenever it goes across one of your territories, you are unable to move those troops. On the left hand side, there’s an indian chief and a mexican, and occasionally they will attack and obliterate ome of the troops in adjacent territories.

I think this game is another fine example of a game where they have combined a few different types of game modes in a way which works really well. I have’t seen much in terms of strategy games which incorporate arcade action in recent years, which is a bit of a shame – it’s such a nice concept.

3D Engine – Basic Concepts

Friday, August 29th, 2008

As you probably know by now, I’m making an indie 3D engine, and last time I talked aboutthe abstraction layer for accessing the 3D hardware. This time, I’m going to talk a bit about the basic concepts of the higher level engine, touching on things like meshes, materials and the scene graph.

It’s always difficult to judge what level to start at when discussing these matters. Some people know a lot about 3D already, others might be beginners… and considering how poorly defined the terminology is in the field of game development, misunderstandings are not uncommon. So, I’ll skim through the very basic stuff as well, just to make sure we’re on the same page.


This figure shows a triangle and part of a mesh. A triangle is made up of three points (called vertices), and if you draw a line from one vertex to another, you get what is called an edge. The area contained by three connected edges is the actual triangle. In a 3D engine, everything is made up of triangles, and if you need more complex shapes, you always build them by combining triangles. This is because 3D hardware works with triangles, and all a 3D graphics card really does, is provide a way of drawing lots and lots of triangles really really fast (the more modern cards can do it in a very flexible way, usingprogrammable shaders, but it still comes down to drawing triangles).

There’s no definitive name for a collection of triangles, but I’ve chosen to call it a mesh. In the above figure, you can see that a mesh is made up of a bunch of vertices and triangles connecting them. It would be possible to define a mesh in terms of a long list of vertex triplets, but as some vertices are shared between several triangles, that would mean that we waste a lot of memory by duplicating data (as you will see later on, a vertex can be quite large, as it contains not only a position, but also color, normal  and texture coordinate information). The common solution for this is to specify all the vertices in one big list (called a vertex buffer) and when specifying the triangles, to use the index of a vertex instead of the full vertex. So a triangle would be defined with three simple index values rather than three complex vertex structures. If you look at the platform abstraction layer I defined last time, you’ll see that there’s functionality for creating vertex and index buffers, as well as a Render method which allows us to specify which vertices and indices to use from the specified buffers.


So, the way I define a mesh, is as a collection of vertices and indices, along with a material,as pictured in the above figure. This means that all the triangles in a mesh are rendered using the same material, and it also means that it’s not possible to move one part of a mesh in relation to the other parts (for example, spinning the wheels on a car). This means that some models will need to be made up of several meshes, but that’s fine – we can deal with that. But it also means that a mesh can be rendered in one go.

Few models are simple enough to be made up of only one mesh. You often want to use different textures on different parts of the character, or you might want parts of the model to be able to move independently of the others (like the wheels on the car). The way we’ll be making that possibile, is to create a hierarchy, or tree structure, of nodes.


In the above figure, you will see the contents of a node. Each node has a name, which will be useful to identify the different parts of a model, and it also has a transform, which is a description of the nodes position and rotation relative to its parent node. A node might have any number of child nodes, which can be either nodes themselves, or meshes (as defined earlier).

There are some nice things about structuring things this way, as we will see later on. A model will be defined as just a node, and the entire scene (everything we render) will also be just a node. To add a model to the scene, we just add the models node as a child to the scene node. If we have a model of a car, and a model of a driver we want to attach to it, we would just add the driver model as a child node to the car model, and the car model as a child node to the scene.

More on this next time, when I will talk a bit more about how we go from these basic concepts to actually rendering it using the platform abstraction layer. And if anything is a bit unclear, just post your questions as a comment and I’ll do my best to clarify.

RetroBox – The Specification

Thursday, August 28th, 2008

Ok, so like I was saying last time, I’m working on something I call the RetroBox, which is kind of like a virtual oldschool computer.

I’ve decided on an initial specification for it now. That’s basically just a bunch of arbitrary limitations I’ve decided I want to apply to the RetroBox, which might seem weird, but keep in mind that: 1) I want the RetroBox to be very much like an oldschool computer like the Commodore 64 or Atari ST and 2) I believe that having fixed limitations to work within can actually help you focus on making your game, rather than just focusing on things like technology or compatibility.

Ok, so here goes… I will go through the central aspects of the RetroBox, and my reasoning behind it. These things are all preliminary at the moment, but I’ll have them locked down within the next few weeks, as I implement the whole thing.

Colors: 80 concurrent from 4096 available

The RetroBox will have a palette of 80 colors at a time, out of a total colorset of 4096 available colors (12-bit colors). Of those 80 colors, 24 are fixed and cannot be changed (these are the System Colors) and 56 colors which can be chosen from the available colorset (those are the Custom Colors) .

System Palette:

The default settings for the custom palette:

I think this is quite generous compared to the C64 with 16 fixed colors, and the AtariST with 16 custom colors out of a colorset of 512 colors. The NES had 56 fixed colors. So all in all, it’s not so many colors that you can totally go crazy with it, and it’s not so few that you’ll have to struggle every step of the way. The fact that there’s 4096 available color, means that the R, G and B components of a color can each be described with one character when using hex (0-F), so for example, hot pink would be $F0F, and medium gray would be $777. Which is a quite neat way of describing colors :-)

Having a fixed set of system colors can be real nice, as you’ll always know they will be there, which means they’re ideal for things like UI or when making editors etc.

Resolution: 320×200

The resolution of the RetroBox is 320 pixels wide by 200 pixels high. However, the whole screen will be 400×300 pixels, which means there will be a border around the screen, just like in the good old days :-) I’ll also provide some sort of mechanic to change the border color for each scanline, independent of the palette, so you could create that "raster color" effect from the old days…

Sound: 8 channels (6 chip channels, 2 channels for digitized sound)

Of course there will be sound support as well. I haven’t given this too much thought yet, as I know I’ll need to learn a bit more about how soundchips used to work, but I’m thinking it would be nice to support WAV sound, and 2 simultaneous sounds would be about right. In addition, I want some sort of soundchip as well, like the SID chip of the C64 or the YM chip of the Atari ST, for that nice, solid retro feel. So I was thinking 6 channels of chip sound in addition to the 2 digital channels.

This would allow you to, for example, have a music track with 3 chip channels and one digi-drum channel, while still having 3 chip and one digitized channel left for ingame sounds. Which certainly should be enough…

Sprites & Blitter

There will be built-in support for Sprites, just like there was on the C64. I’m thinking 64 sprites, each with a maximum size of 128×128. The width and height must be a power of two value of eight or higher, so 8, 16, 32, 64 and 128 are valid width or height values for a sprite. All 80 colors may be used freely in a sprite.

I’m also thinking that it would be nice to have a built-in "blitter", functionality that allows you to really quickly copy data with lots of different options, making it ideal for implementing fast drawing of bitmaps.

Using a TV as monitor

Ok, so I’ve saved the more unusual thing for last… Have you ever noticed how, when running old games in an emulator, they often don’t look as nice as you remember them… That’s not just your mind playing tricks on you, it’s because the old machines was usually running on old TV’s, which made the colors on the screen bleed and blend quite a bit, making things look better than they really should…

The RetroBox will emulate that look, and I’m happy to say I think it will emulate it pretty well. More on this in a later entry :-)

So, that’s what I have in mind. Stay tuned for the next update, when I will go over the RetroBox CPU and its instruction set…

RetroBox – My New Retro Project

Wednesday, August 27th, 2008

Ok, so I’ve been moving recently (going back to university, so I’m now a student again for the first time in a looong while), and while carrying boxes and furniture, my mind wandered, and I got an idea that can probably be described as just plain weird. Or really nice. I’ll let you judge, bear with me :-)

Basically, I was thinking of how things used to be back in the 80’s & early 90’s, when I was making games and demos for the Commodore 64 and the Atari ST. Development environments wasn’t all that evolved back then, and you had to make do with whatever tools you could find… but, and here’s the thing, in some ways things was a lot simpler, and it was in many ways easier to get started making stuff for those machines.

So, I got to thinking that it would be fun to make a virtual retro computer. Not an emulator, there’s plenty of those, but a brand new home computer which runs in a window on your PC. It would have quite strict technical limitations, its own flavour of assembler language, and some sort of high-level (and preferably a bit more modern) language built on top, and a couple of sprite/image/sound/music editors thrown in, to enable people to make their own stuff for it straight out the box.


So, it’s a crazy idea, but I’m doing it anyway. I’m in the initial planning phase now, which I really enjoy: cup of coffe, couple of books, a notepad and some imagination :-) I’m defining the technical specification of my made-up machine, and also designing the instruction set for its made-up CPU :-)

I’m calling the thing RetroBox for now. More on this later…

Simon the Sorcerer – More frustrating than fun

Monday, August 25th, 2008

I’ve been playing an old adventure game lately – Simon the Sorcerer, and it is nowhere near as good as I remembered it. The experience is still sort of enjoyable, but there’s ahuge element of frustration, which sort of spoils it…


The first thing that strikes you when playing the game, is the stunning visuals. Simon the Sorcerer has some of the nicest pixel art I’ve seen in this type of game, it’s amazingly detailed and some of the scenes are really beautiful.

That being said, there’s way too many scenes in the game that are just "transportation": there’s nothing to do there, and they really serve no purpose in the game. This means that you are spending a huge amount of time in the game just walking around exploring things.


You do have access to a map though, which allows you to teleport to known locations, once you’ve found them by walking around.


I think that having this many locations, with so few of them being used for puzzles, was a big mistake. And adding a map was not the solution – they should have dropped about 70% of the locations, and the game would have been much better for it.


Another thing that adds to the frustration, is the number of possible actions you can perform. Some of them (like Wear and Consume) are only used once or twice in the entire game – and it’s never a good idea to include mechanics in a game which are used only once or twice. If you ever find yourself doing so, you’ve found an area which needs redesigning.

I think that a lot of these specialized verbs could have been replaced with just a general Use action, and that would have worked wonders to reduce the frustration. Also, requiring you to at one time (and at one time only) combine two inventory items (the rope and the magnet) by "Use"-ing one with the other, is also an amazingly poor mechanic…


The last big cause of frustration is that inventory items stay in your inventory even after you have used them. This is just really, really stupid, as it leaves you with a lot of objects at all times, and you don’t know if you’re done with them or if you’re meant to use them again.

It gets quite bad towards the end, but at one point (when you’ve shrunk yourself down to the size of a mouse), the game totally clears out your inventory, leaving it all in a pile next to you. It’s good in a way, because you have less things getting in the way for the last few scenes of the game, but wouldn’t it have been better to lose items after they’re used, leaving you with a smaller inventory at all times?

All in all, Simon the Sorcerer is not a good game, as it highlights some of the worst flaws of the genre. And the stunning visuals doesn’t make up for that.

3D Engine Abstraction Layer

Sunday, August 24th, 2008

So, as I mentioned the other day, I’ll be making a 3D engine specifically suited to technically simpler 3D games, such as indie developers might want to make. I’ve started working on this now, and there’s two major lessons I’ve learned over the years: 1) keep it simple, and 2) don’t add features you don’t need yet (also known as the KISS and YAGNI rules).

Many are the times when I’ve tried to keep things simple, but failed somewhere along the way – it’s so damn easy to overcomplicate things, and I’ve found that keeping it simple can at times be really hard.

There’s also been plenty of occasions when I have thought I’ve been keeping features at a minumum, while in reality I’ve been thinking too far ahead, and kept adding things I’ve anticipated that I’ll need further down the line. Only to end up with lots of bloat, and code I don’t really enjoy working with.

When I made the Pixie game engine, I managed to avoid most of those mistakes from the past, and I’ve ended up with a really nice, well structured engine, which is a joy to work with, so I’m determined to apply the same principles to the 3D engine.

In fact, Pixie is such a great codebase to work with, that I will build the 3D engine on top of it, which will allow me to use the same nice, clean infrastructure and platform abstraction layers.

So, my first task in making this 3D engine, is to add an abstraction layer for 3D hardware. It would certainly be possible to work with DirectX or OpenGL directly, but that has some serious disadvantages.  As I said in the previous post about this engine, I want it to be suitable for indie developers, and that means it should work on both Windows and OsX (as many self-publishing indies report a similar number of sales on OsX as they see on Windows, even though the Windows userbase is much larger).

I wouldn’t want to use OpenGL for a Windows game – that’s just asking for trouble, as many potential customers wouldn’t have suitable drivers to get OpenGL to work, and in that case would probably not even bother trying to get the demo to work. And you’d obviously not use DirectX on the Mac. Note that I won’t be supporting any fancy stuff such as Shaders – this will be strictly a Fixed Function engine, for ease-of-use, performance and, most importantly, compatibility.

Here’s the full abstraction layer for accessing 3D hardware, such as it is at the moment. I’ve only added functionality I actually need, not stuff I anticipate that I will need later on. When that time comes, I can decide whether it’s a must to have it, and then add it, or if it’s something I can live without, and just leave it.


As you can see, there’s not much in there. Functionality to create Vertex/Index buffers and Textures, set transformation matrices, specify dynamic lights, toggle a couple of renderstates and rendering indexed or non-indexed triangles.

The goal here have been to streamline the whole rendering API, to just a handfull of methods that I actually use, and to specify them in such a way that I would like to work with them, without attempting to conform to a specific API. At this point in time, anything outside of this would just be distracting and add bloat. I suspect though, that I will be adding a few more things to this down the line. Time will tell.

In the main abstraction interface above, there’s methods to create vertex/index buffers and textures. I’d like to show you what the interface for the index buffer itself looks like:


Now, this one is actually very simple: you can "Bind" the indexbuffer, which essentially makes it the indexbuffer that will be used in the next calls to the Render method used for indexed primitives. The rest of the methods are used to fill the index buffer with index data values.

The vertex buffer is essentially the same, but with more accessors for the different components. Which components are available are specified by passing a combination of VertexFormat flags to the CreateVertexBuffer method (and are similar to the Flexible Vertex Format of DirectX, though not identical).


And last, for completeness, the interface for textures:


Which again is similar, but here we pass an additional parameter to the Bind method, to indicate at which texture stage we want to use it.

The idea is to use these concepts in my higher level 3D engine code, so that it is independent of the actual rendering API used. I’m making a D3D9 implementation of this to start with, but will extend it to a DirectX3 version as well, for compatibility (to be used as a fallback on systems which doesn’t have a recent version of DirectX installed – means I have to get reacquainted with Execute Buffers… argh!), as well as an OpenGL version and a basic Software renderer (as the ultimate fallback for when there’s no 3D hardware).

Keeping the function set limited should make the work on the different versions a bit easier, which is a good thing :-)

3D Engine for Indie Games?

Wednesday, August 20th, 2008

I’ve been working on games for a while. Worked with a few commercial 3D engines, made a couple myself… I’ve been around the indie-scene for quite some time too. Most indie games that make money are 2D games (though some make use of 3D graphics cards to render their sprites faster), and that makes sense: the customer don’t care, and it’s a more cost-effective way to produce games.

My opinion on games in general, is that very few game types benefit from 3D – they make better games if done in 2D (and at this point, someone always goes "but what about FPS games, they require 3D", failing to realize that the game type is, of course, shooter, and that there’s plenty of great 2D shooters. Which are also generally better than the first person ones).

But there’s one specific genre which I think lends itself better to 3D: the racing games (and in my previous post on racing games, I tell you what a fun racing game is). Sure, there’s 2D racing games too, but they tend to not work as well. Even on the early computers and consoles, the good racing games were 3D, although a simplistic, primitive form of 3D.

I like the kind of whacky, casual types of racing games, a la Mario Karts. Would be fun to make one at some point. But as a hobbyist developer (as for most indies), my technology options are limited. The commercial engines are too expensive. The free ones are usually developed to make use of the latest and greatest shader technology with fancy lighting and realtime shadows. They are (for this very reason, I bet) quite unstable, and won’t run (or will run way too slow to be usable) on a large number of computers. They will also, in some cases, require a greater effort in terms of the artwork (normal maps, shadow volumes etc to be created, which takes time). Some of them are difficult to use. It’s clear that their developers favors working on new features over making the basic technology stable, reliable and easy to use.

The fact of the matter is, that for indie developers, there’s no point using fancy modern 3D technology, like the latest shaders. It will incurr a cost to the indie, in the form of time spent and more expensive art resources, as well as in reduced sales (given higher hardware requirements).

You might think that there are benefits to using fancy effects – but the truth is, by doing so, you’re starting to compete with the AAA retail games – and you won’t ever win that battle, as you’re outnumbered to start with. If you focus on your gameplay and mechanics though, you have a chance of delivering something that the AAA games industry can’t – A great game.

Though most games are better in 2D, considering that some (like racing games) can actually work better in 3D, I think that what’s missing today, is a good, basic 3D engine, free to use for indies and hobbyist, which focus on stability and ease of use, and leaves out the fancy shader effects. One which supports models and animations, basic particle systems and billboards, basic decals, simple lighting (with something like lightmaps to efficiently add static lighting to a scene). And not much more. But, in a way that is simple, straightforward, easy to use and modify, at which works just about everywhere.

I don’t think there is an engine like that out there. Yet. I’m planning to make one, and as with other tech I write, it will be released into the public domain. That means that there’s no license for using the engine: anyone can use it for any purpose, without restrictions and without paying anything. It probably won’t see widespread use though, as most indies who do 3D stuff seems to want to compete with the latest and greatest AAA games in terms of visual quality – meaning they will fail doubly: they won’t get it as nice as the AAA games they are imitating, and they won’t make a fun game either.

But for those rare indies that see a need for 3D as a gameplay mechanic rather than a visual effects fest, I’m hoping this 3D addition to my Pixie game engine will be a welcome and useful one.

I’ll keep you posted…