Feb 17 2010

NXT RPG – an introduction

Category: NXT RPGSpiller @ 16:32

I thought the last post was pretty bad, and since most people wouldn’t know what NXT RPG even is, I thought I should say a little about it.



This is a Role Playing Game engine for the Lego Mindstorms NXT I’m developing in my spare time. The RPG type is highly inspired by the Pokemon games for Gameboy.


The first thought of making a RPG was back in the late spring/early summer of 2009. I hadn’t touched programming so much for some time and I simply wanted to start a new project. I have played the Pokemon games quite a bit and liked the gameplay, but there is also big issues with the actual gameplay. It is just a bit too easy, so I thought of making a RPG of something like Cat Mario.

Then megamindstorms101 started the NXTasy Challenge #7, I thought why not as started work so I could enter it in the challenge.

Why NXT?

A lot of my friends have asked this, it is just some toy some kids and a few geeks have after all, so why?

The NXTasy Challenge was just what finally got me started. I had recently moved to C++ instead of using Borland Pascal, but I only really knew how to make console programs in C++ I found quite limiting. With the NXT there is some easy commands to draw on the screen, so it would be easier to get started.

But the most important reason is that the NXT “is just a toy”. It is not a highend computer with amazing 3D graphics, it is just a small minicomputer with 32KB RAM.

Now you might ask, why is this a good thing? As weird as it might sound, I like limitations. Not because they are limiting, but that they wouldn’t necessarily allow you to use the first and easiest solution, you are forced to come up with other (and hopefully better) solutions. Every piece of code I write needs to be efficient because I don’t have a 3,6GHz CPU which wouldn’t even care. The NXT only have 32KB RAM, I can’t just waste too much memory. Secondly, there is only about 100KB memory back after the Firmware is installed, so program and game files must not become too big either. The 100x64px single color display is also fun.

These limitations might mean that I can’t have all kinds of advanced features in the game. But they force me to select those which are actually important and not just bloat it with something most people wouldn’t even notice. And I need to implement those features as efficiently as possible.

As I’m self-taught this is great practice to learn programming correctly and not just use whatever that seems to work.

The game (or something)

This didn’t exactly become a Cat Mario clone. I thought that should wait for a real game for PC if I still want to make another one after this project. Instead this became more like a Game engine, mostly because of my lack of inspiration. But also because I wanted to try to make something that will work for a multitude of games and not just one specific.

The goal became that you could create a whole new game by just changing the data files without having to do anything with actual code.


You move in a strict quadratic grid, up down, left and right. Each step move to the next point in the grid, there are no middle positions. (There is some animation though.)

Events happen only on steps. If you don’t move, nothing will happen.

Battles are turn-based,  if you don’t make a move, nothing happens.


In order to make this game run properly you need:

  • nbc/nxc enhanced firmware 1.28
  • 4 touch sensors

Tools used for developing

  • NXC
  • XML
  • XSLT
  • C++

NXC is used for coding NXT RPG.

The data files are stored in XML.

XSLT is used to “preview” the  data files in a web-browser.

An application written in C++ is used to convert the data files to binary data (since directly using the XML files would simply use too much space on the NXT). Right now XSLT is used as a middle step for converting the data files. (It creates a simple text code that is easier to convert.)

2 Responses to “NXT RPG – an introduction”

  1. 2Tie says:

    Just a quick question…

    for .ric files, when you GraphicOutEX them, does it displays the whole image (as shown in nxtRICeditV2 as the PreView), with the white space potentially clearing black pixels set from an earlier GraphicOutEX? or does it just turn on the black pixels, with the white pixels left untouched?

    • Spiller says:

      GraphicOutEx behaves exactly just like GraphicOut(), it just allows you to modify the parameters.

      I haven’t messed with the NXT for a long time now, so this is by memory:
      By default, they do not clear the previous pixels and writes on top of them. If you use a Line operation, it will just draw that line on top of the image. However the CopyBits operation replaces the area with the pixels as specified in the Sprite, so previously black areas will be cleared.

      On the extended firmware, you can use extra options to control the behavior of the operations: (click on each one to see a description)

      This means that if you want to clear all the pixels in an area, you can use the Rectangle operation. Start it on 0,0 and make it the size you want. Then set its drawing options to: DRAW_OPT_FILL_SHAPE | DRAW_OPT_INVERT . This makes it draw a filled white rectangle, removing anything below.

      If you want to keep black pixels already on the screen with the CopyBits operation, you can use the DRAW_OPT_LOGICAL_OR drawing option on the CopyBits. This applies the Or operation between the on-screen pixel and the one which is about to be draw. The result will thus be black if either the pixel on the screen or the one to draw is black.

      Check out RICcreator if you haven’t tried it yet, I created it partially just to make it easier to use Drawing options in RIC files.

Leave a Reply