I realized that though I made this a while ago, when I first started working on my Pixie Game Engine, I never released it, so I thought I might as well do it now

It’s a simple little platform game, you play as Marvin Maggot, and you have to climb out of the well without falling into the water. Avoid being hit by the apples, as they will knock you down.

All the art by Patrik "Lord" Karvonen – he made it many years ago, on the Atari ST, when our demo group "Crystalic" was most active, but it was never used (mostly due to lazy coders ) but as they say, better late then never.

There’s a built-in editor in the game too – I think that you shouldn’t make a platform-game without a built in editor. At any time in the game, you may press F8, to enter editor mode, allowing you to place or adjust platforms, and then leave editor mode by pressing F8 again, making it very easy to try out jumps and experiment with the level layout.

Download Marvin Maggot here.

And as usual, the source code is available too:
The source code for Marvin Maggot

I’ve never been the biggest fan of Monopoly – it’s a nice game, but not a favorite – and I certainly don’t get the point of all these customized Monopoly games. You know, the ones with themes from popular movies, cartoons etc. So, I was a little bit wary about this game when I saw it in the store: Monopoly the Card Game ?!

As it turned out, it’s a great little game. Basically, the goal is to be the first player to reach £10,000 (yeah, it’s the british edition), and you gain money by collecting the best set of cards you can on each game round.

In the game, each player has 10 cards on the hand, and on each turn, he may choose to either draw a card from the draw pile, or trade cards from his own discard pile with another players discard pile. At the end of the turn, you need to discard any surplus cards, so you are left with only 10.

If you manage to get a full hand, you may, at the start of your turn, say "Monopoly", thereby ending the game. A full hand means that all your cards are part of a full set – you must have the full set of all the streets you have, and fill the rest of the hand with non-street cards.

When a player have said "Monopoly", the game immediately ends, and he gets to draw 5 extra cards and add them to his hand. A total sum of money is then calculated for each player, by adding up the amounts on the cards of their hand, and added to their total pool of money.

As with many great games, the basic principle is simple, and the fun comes from learning all the details – the monopoly card game have a bunch of special cards, like the Token (which can change value depending on the rest of your hand) and the Chance cards (which can count as any card you like, but if you’re not the first to say "Monopoly" at the end, it makes your entire hand worthless). There’s also quite a bit of strategy involved in how you draw, trade and discard, in order to get the best out of it for yourself while trying to mess things up for your opponent.

A great game, and I thoroughly recommed it (you can get it here).

Last time I wrote about the RetroBox, I talked about its internal components, and how they are connected. One of the more complex components is the VDC, or Video Display Controller, which is responsible for displaying things on the screen, and today I will go into more detail about this.

Have a look at the above figure. It shows the RetroBox screen layout – a 320×200 pixel area, surrounded by borders. You can control the color of the borders (by modifying color #0 in the color palette), but you won’t be able to display any art there; only the actual screen area (320×200) can display individual pixels.

If you look at the memory map from the last entry, you’ll see an entry named "Video RAM Address", which is located at address $1004. This means that if you set the contents of that address to a memory location, the VDC will read that location to determine the color of individual pixels on the screen. Consider the following example:

move.l $20000,$1004
move.b 1,$20000 

The first line will set the Video RAM Address to $20000 (just a arbitrary memory location which we’ve decided to use for the screen) and the second line will set the first pixels value to 1, which means the second palette index.

Now, being able to modify the screen is all we really need – we could make entire games using this. However, the RetroBox VDC have some built-in functionality to make it easier to do certain things. First, it’s got built-in support for Sprites, which are small bitmaps which can be positioned independently and will be displayed on top of the screen, making them ideal to use for things which move around, like the player, the enemies, bullets etc. You can have up to 64 sprites on the screen at the same time, and they can be in sizes up to 128×128 pixels. Any pixel with a color index of 0 will not be drawn, thus enabling transparent regions for your sprites.

In addition, there are 4 single color overlays and one full-color overlay. The single color overlays are 320×200 in size, covering the entire screen and with fixed position. All the pixels in a single color overlay are the same color, but different overlays may have different colors. The full-color overlay is like a second screen, displayed on top of everything else, with the only difference that pixels with a color index of 0 will not be displayed, making it possible to have parts of the other components showing through. The full-color overlay can be very useful for things like the user interface, which you want to show on top of the rest of the stuff.

When the VDC updates the displayed image, it starts by drawing the Screen, followed by the Sprites (starting with sprite #0, then #1 all the way to #63). Then it draws the 4 single color overlays in order, and finally the full-color overlay.

These different layers combine into the final image, which is displayed on the RetroBox screen. Having separate layers like this, means that it’s often not necessary to redraw that much stuff from frame to frame – usually, all you need to do is move the sprites around and update some UI information in the overlay. You could even change the Video RAM Address to scroll the background, while still having sprites and UI rendered correctly on top.

I hope this have given you some insight to how the RetroBox displays graphics, and how most aspects of it can be controlled by manipulating the reserved RAM locations.

Sometimes it’s fun to just work like crazy on something for a day or two and try to get as much done as you can, without worrying too much about the result. I used to make demos when I was young (demos are small programs showing off graphical effects, with nice art and music to go with it) and me and the guys used to get fuelled up on Jolt Cola and coffe, and spend whole weekends getting stuff together.

So a while back, when a forum I sometimes visit arranged a small competition where the objective was to create (or at least attempt) an RPG in only 48 hours, I decided to join in to see what I came up with. It was a very welcome break from the more serious things I was doing at the time. Also, it’s a great learning experience, as you have to really make quick decisions and stand by them, getting them to work any way you can. I started with nothing but my Pixie Game Engine.  I didn’t even have an idea of where to start or what the game would be about.

I started by browsing through some of the Poser stuff I have (Poser is the program I use to create most of my art, basically you can buy lots of pre-made 3d figures and put them together the way you want them), using the Poser Content Manager, which I now couldn’t live without I found stuff I could combine into the girl you see on the picture above, and decided to base my game on her. I named her Kassandra (actually, my mind drew a blank, so I browsed a mythology encyclopedia and picked a name I though sounded nice ) and put the cheesy "Amazing Adventures of" in front of it, and just took things from there.

I made the backgrounds by rendering some rocks in Poser, and then I assembled the screens in Photoshop. Basically, I created two fullscreen layers, one mud, the other grass, and then just used the eraser to "draw" the paths on the screen, and then just picking and placing some rocks on top of it.

I wanted a simple point-and-click interface for this, where the player can click anywhere on the screen, and the character should just walk there, automatically negotiating any obstacles. I wrote a simple A* pathfinder, and just paimted a grayscale image for each background, to use for determining where the player could move. The pure-white areas counts as blocked – the player won’t be able to move there (and the icon will change to indicate this), while the black area is the preferred route. The player can move onto the gray area if desired, but whenever possible, the character will try and stay to on the black path.

This makes for a nice system, where Kassandra will stay to the paths unless told otherwise.

I have a couple of enemies in the game too. They basically just move around at random, and if the player collides with an enemy, there will be a battle. I move the enemies by picking a random point on the screen, and then using the walk mask to determine if it is a valid location to move to, and then using the pathfinder to move the enemy there.

I didn’t really have much time left when I reached this point, so I did a quick and simple battle system, but which works fairly well… The player can choose to Attack or Retreat (though there’s always at least one round of Attack before the Retreat option is made available), and when you choose attack, the game will pick a random "Attack Modifier" value for the player and one for the enemy, which will be added to their Attack Values. The one with the highest attack score wins the round (draws favour the player) and deals his Damage Value to the other. It would have been nice to have had time to expand on this system, allowing the player to change weapons and use spells or items during battle, to affect the Total Attack Score of each round… but I ran out of time…

If you want to try it out, you can download The Amazing Adventures of Kassandra here.

As usual, the source code is available as well for those interested. It uses the Pixie Game Engine (included in the download) but it is somewhat messy, as I had to rush things for the deadline…

Download the source code (needs the game if you want to run it):
Kassandra Source Code – 938 KB

Hostages is a game I played a lot back in the days. The basic mechanics are quite simple, and the game is great fun. The story is this: Terrorists have taken control of an embassy, and you control a anti-terrorist force of six men.

First thing you need to do is place your men strategically: the three snipers goes on top of the buildings surrounding the embassy, and the other three goes on top of the embassy building (so they can enter through the windows).

When moving your guys into position, you need to dodge the search-lights, by hiding behind a wall, in a door entrance etc. If you’re ever caught in the light, you will be shot dead.

Once your guys are in place, you use the snipers to scan the buildings, checking for terrorists. You need to be careful though, so you don’t shoot any of the hostages.

When you’ve entered the building, you move around, room by room, in a first person view, killing terrorists as you see them, but again being careful not to kill hostages.

I think this is another example of where a game comes out more fun because it mixes three different games (positioning, sniping and walking around). Each part is simple in itself, but put together, it gives a real nice sense of variety, and makes the game very fun.

It’s time for the next piece on the indie 3D engine I’m working on. You should read throughthe one about Basic Concepts if you haven’t already, as this one builds on the concepts described in that one. This time, I will talk about instancing, which is the method we use to enable us to re-use the same models at multiple locations in the world, without needing duplicate copies of the model data.

As you remember, I defined a model as a Node, wich had a name/ID, Transformdescribing it’s position, and a hierarchy of child nodes, which could themselves be Nodes orMeshes. A Mesh contains a bunch of vertices and indices, and a reference to a Material. And the Material contains up to 3 texturmaps and a color.

Look at the figure above (click to enlarge it): it shows the relations between the different elements, and how a model may contain multiple meshes and even reference the same mesh more than once.

Now, imagine we have a game where we want lots of cars driving around. Let’s say we have three different car models, and five different texture maps, which have been created in such a way that they can be applied to any of the three car models. This would give us 15 different cars, just by using all the possible combinations. If we also consider that we can use different basic colors for the cars, we get even more variations. Just by combing the 15 different model-textur variations with a set of seven distinct color, we get over a hundred different cars.

In theory, we could create separate models for each of the 100+ cars, but that would just mean we would be wasting a lot of memory, which we could be putting to better use. And what if we want two (or more) cars in the world with the same appearence (maybe some police cars or similar)? We certainly wouldn’t want to duplicate data for them…

So the solution we’ll be using, is separating Definitions from Instances. In the contect of this 3D engine, a Definition is something that we typically load from an external source, and which stays constant throughout the game. It acts as a template, from which we can create working copies, or Instances, which we can modify, add to the world and manipulate. The key thing here, is that Definitions are typically large, heavy-weight structures, while Instances are very small and light-weight, containing just those elements of data which we need to modify per instance.

The figure above shows a Node Instance such as might have been created from the Node Definition shown in the entry on Basic Concepts. It doesn’t look much different – it doesn’t have a Name/ID field, but instead it’s got a reference to the Node Definition it was created from. Also, it contains referenced to Node Instance and Mesh Instance rather than to the corresponding definitions (which the Node Definition referenced). This is not a problem though – all these elements (except the transform) are just pointers to other elements, so each of them is just 4 bytes in size, so we don’t need to worry too much about the memory use of the Nodes.

The difference between Mesh Instance and Mesh Definition (as detailed in the entry on Basic Concepts) is a bit more interesting. As shown above, a Mesh Instance contains only a reference to a Mesh Definition (which is a lot less memory than storing a copy of all the vertices and indices) and a reference to a Material (so that we can use different materials for different instanes).

When we’re using a model in the engine, we do it by loading a Model Definition from file, and then we create as many Model Instances of that model for use in the game world. We are free to manipulate any data (Transform, Material or node structure) of each instance, to suit our games needs. The Model Definition might be big, with many vertices and indices taking up a lot of memory, while each Model Instance is tiny in comparison, containing only references to the large data.

We will be getting back to the topic of instancing later – there’s still plenty of details to get into when we come to implementing this… so stay tuned for the next update

A few years ago, some guys at work started playing "Magic the Gathering", a card game from Wizards of the Coast, and naturally, I joined in. I hadn’t played a collectible card game before, but I’m surprised how quickly I got hooked on it.

There’s lots of rules in Magic, and there’s lots of editions and lots of cards with their own special rule. But the core mechanics of the game are very simple. When I was new to the game, I got a starter pack which came with everything needed for two players to start playing, as well as a cheesy comic which described how to play in a way that was very easy to understand.

The picture above shows the 9th edition starter, but you can get the 10th edition starter here, if you want to give the game a go.

The basic objective in Magic is simple: kill your opponent, by damaging him such that his life points goes down to zero (from the starting 20). To do this, you make use of spells (the cards are your spells). Spells have all sorts of effects, and some can even damage your opponent directly, while others are used to summon creatures, which you can then use to attack your opponent, or defend yourself against his attacks. In order to cast spells, you need to draw magic energy (mana) from the lands you control (some cards are Lands rather than Spells, and the more Lands you play, the more (and more powerful) Spells you can cast.

Magic is an amazingly well balanced game, where you constantly have to think ahead and use your resources wisely. There’s also an element of chance, as you’re never sure what cards you’ll be getting next.

There’s two more things I’d like to mention about Magic – it’s a collectible card game, and it’s a constructible card game. Myself, I largely ignore the collectible aspect – I’m not interested in buying lots of "boosters" (packs of randomly selected cards) to get hold of some "rare" ones, but you can buy big lots of common cards online, which is what I tend to do.

The constructable aspect is more interesting – it means you can construct your deck of cards any way you like, by choosing which cards to include. This is a big part of the fun, as the way you construct the deck pretty much decided which strategy you need to use when playing it. Building, testing and tweaking your own decks is a lot of fun.

But sometimes it’s fun to play with pre-constructed decks, and there’s a lot "Theme Decks" available for Magic, which is simply a pre-built deck of cards, along with some information on recommended playing styles and strategies to use for it.

Magic the Gathering is a really good game, and I can wholeheartedly recommend it to anyone who likes board games, card games or strategy games.

When I got my Atari ST, it didn’t come with a good basic language, so I invested some (most) of my piggy-bank in a product called STOS – The Game Creator. It was a basic language specifically created for making games. It is my main source of inspiration for my RetroBox project, so I thought I’d take a trip down memory lane, to reexamine this great little language…

The box came with three discs (for the language, accessories and games, respectively), a language reference card and a printed user guide of approx. 300 pages, which explained the language and tools in details.

One of the really great things with STOS, was that it came with a bunch of specialized editors along with the basic language. It had a sprite editor, which was very easy to use, and an anination editor to go with it.

It also had a "room editor", which allowed you to build tilemaps, and a music editor which allowed for making chiptune music.

The fact that you had all these built-in tools made STOS an incredibly powerful development environment for its time. Even a minumum of previous experience, you could fire it up, doodle a few sprites, make a simple tilemap and start coding the sprite movement and animation using the specialized BASIC commands of the STOS language.

Mandarin Software (who was the publisher) also made a bunch of expansions for STOS, like a set of ready-to-use sprites and a compiler, which made it possible to create stand-alone executables from your Basic source codes, and which also made it run a lot faster.

There was even a sampler extension released, which included a sampling cartridge for digitizing sound, and software for simple manipulation of the sounds, as well as extensions to the STOS language to play sampled sound.

Here’s some old ads I came across from back in the days (click to enlarge):

All in all, I really enjoyed making things in STOS, and I’m hoping to be able to make my RetroBox into something similar – an integrated environment which lets anyone create simple games for fun

Time for another piece on my RetroBox. I’ve got it mostly working now, and will be releasing a first beta pretty soon, so I thought I’d talk a bit about how it works internally.

As you can see, there’s a bunch of different components in the RetroBox. I’ve already detailed the RBCPU processor, but there’s other things of interest too. We have the VDC, or Video Display Controller, which is the thing that is responsible for displaying stuff on the screen (and which deserves its own entry later on), the BIOS systems functions, which will provide things like file access and blitter functions, some Read-only memory (ROM), which holds boot code and things like a system font, the Input Controller, which handles input, and last, but not least, the Main Memory (RAM).

I will detail each of these components in due time, but first I want to focus a bit on the RAM. For the first release of the RetroBox, there won’t be any BIOS functions, and not much (if any) stuff in ROM, so the only way for us to do anything with the CPU is by means of the RAM. This is not that much of a limitation though: we can do all sorts of cool things by just poking around in the memory.

Here’s a full layout of the RetroBox’s memory, all 64 MB of it (click to enlarge):

As you can see, the first 64K (0000-FFFF) are reserved, and can’t be used for general storage. Instead, they are used to communicate with the VDC and the Input Controller. For example, if you set the LONG value at address $1000 (where the dollar sign indicates a hexadecimal number) to a memory address, the VDC will get its palette data from the memory at that address. If you modify the LONG value at $1004, you can set up the location of Video RAM, which is the area in RAM that the VDC reads when drawing things on the screen.

The keyboard can be read by looking at memory locations $1600 to $17FF, and the mouse by reading locations $1800 to $1805. The Input Controller constantly updates the values at those locations with input from the physical devices.

I will go into more detail on how this works when I describe the VDC and the Input Controller respectively, but I thought I’d mention the SysTimer now, as it is not part of either the VDC or the Input Controller. The LONG value at the SysTimer address ($100C) simply contains the number of milliseconds since the RetroBox was started, and is the easiest way to measure time.

That’s it for this time – a high level overview of the RB internals and its memory structure, but stay tuned for next time, when we’ll get in deep with the VDC.

Do you remember "X-Com: Terror from the Deep"? It was one of the best games of the time, and it still holds up to this day. Basically, it’s a strategy game where you defend the earth from an alien invasion, one that originates from the depths of the seas.

The main game screen shows Earth, indicating your bases and known enemy locations. It’s got options to bring up the various other game screens, and to speed up time while you’re waiting for enemy sightings.

The first thing you do is build your first base, but you can build more later on, assuming you have the necessary funding. You can keep adding modules to your base, giving it more capabilities. All types of modules are not available from the start – you need to research and develop them first.

You have control of a bunch of soldiers, which you can send on missions to known enemy locations. Early in the game, you mostly visit alien crash sites, to retrieve valuable tech which you can use for research, while later in the game you’ll be invading alien bases in order to defeat them.

The missions part of the game is quite complex, and it is important to equip your "Aquanauts" according to what you expect from the mission. The game is turn-based, and you have a limited number of time units available, which is used for everything from walking to firing weapons, and even moving items to the Aquanauts hands from other locations.

A lot of missions take place under water, but some are land-based missions, and the game mechanics in this area of the game works exceptionally well – you can tell they spent a lot of time on it.

In the game, there’s also a "Ufopedia", a type of encyklopedia which is constantly changing and expanding as you find new alien technology and perform research, providing invaluable information about everything in the game.

I think one of the reasons this game is so fun (apart from being extremely well executed), is that it successfully mix two different game styles: The turn-based squad-managing in the missions, and the high-level research and resource management.

I never played the later games of the series, but I don’t feel like I’ve missed out on anything. The sequal, X-Com Apocalypse, looks like this:

And… well… it’s more high-res, but looks pretty lame compared to the nice pixel-art of the previous games. I think what they’ve done is made pretty weak 3D models and rendered them out, which was probably quicker/easier, but made it look so bad that I don’t even want to play it.

Even the encyklopedia looks quite weak… A perfect example of a case where more advanced technology have made a game look worse rather than better.

And for the most recent addition, X-Com: Enforcer, they lost the plot alltogether:

I mean, this isn’t even the same type of game! I haven’t played it (and I certainly won’t either) but from what I’ve read, it’s a pretty generic shooter, with the strategy element gone completely.

Another proof that the games industry has been constantly regressing since the 90s, with games becoming worse and worse with every new advancement of technology…