New equipment system finished, ZSDX is the priority in 2011

Hi everyone,

During the last months of 2010, I worked hard to move all the equipment stuff from the C++ engine to the data files. This work is finished now! The quests now specify their list of equipment items (e.g. bombs, bow & arrow, swords, bottles, rupees…) as explained in a previous post, and they provide Lua scripts to manage them. Each item has a Lua script that defines its behavior when the player uses it or receives it. In other words, you can make your own quest with other items than the ones of Zelda Mystery of Solarus DX.  This new equipment system works great and it is an important step towards my bigger, long-term goal: making a generic Zelda-like 2D game engine.

From now on, I decided to focus more on developping the quest (Zelda Mystery of Solarus DX), and make less improvements to the C++ engine (Solarus). There will still be some necessary improvements though, like making scriptable enemies and bosses because for now, the behavior of enemies is hardcoded in the the C++ engine. But my priority for 2011 is the quest. Zelda Mystery of Solarus DX did not make much progress in 2010 because I had to improve the engine first.

In fact, I made some new maps during the Christmas break and I will make much more in the near future. And then, I may be able to start thinking about a release date for the full game…

Solarus moves to Git and GitHub

I have just switched the source code from Subversion to Git. The code can now be accessed on github, which provides a nicer interface for the history of commits and many more features.

Your svn local copy should be replaced by a local fork of the git repository. Everything is explained on the Solarus github page, but to be short, use the following command to download the code (obviously, git needs to be installed):

git clone git://

You now have a local fork of the repository, including the full history of commits. You may modify the code and even do your own local commits since git is a distributed versioning system. Then, if you want me to include your modifications into the official repository, you can make a request with git. Feel free to contribute!

Note: the SVN repository is still available but is now obsolete. New commits are only made on the Git repository. The SVN repository remains at revision 1443.

Making the equipment independent of the engine

Up to now, the equipment is hardcoded in the C++ engine. If you are developping your own quest with the Solarus engine, you cannot add new items or remove the ones you don’t want, unless you modify the C++ code. By “items”, I refer here to everything that the player can find: a sword, a shield, a boomerang, some bombs, some rupees, a piece of heart, a bottle, a key, etc. The list of items is defined in the C++ code, as well as their behavior.

I am currently working on making items independent of the engine. This is an important step for making the engine not specific to a particular game. The ultimate objective is to have a configuration file that describes each item of your quest. Such a file might have an ini-like syntax where each item is described in a group.

The hookshot would be described like this:

name = Hookshot
savegame_variable = 1105
can_be_assigned = true

Here we have declared an item with the id “hookshot” and the human-readable name “Hookshot”, useful for the editor. Its possession state (0 or 1) is saved in the variable #1105. It can be assigned, i.e. the player can associate it to an item key and use it explicitely by pressing this key.

A Lua script gives the behavior of the item. It defines what happens when the player uses it explicitely (for items that can be assigned to an item key). It can also define what ability the simple fact to have the item gives (for example, the flippers give the ability to swim and the player does not need to assign them to an item key).

Some items have several variants. For such items, the possession state may have a value greater than one. For example, we can imagine that the sword has four variants:

name = Sword
nb_variants = 4
ability = sword

Some items have a counter associated to them:

name = Bombs
savegame_variable = 1101
can_be_assigned = true
counter = 1024

Here, the savegame variable #1024 stores the current number of bombs of the player (whereas the variable #1101 indicates whether he has the bombs). The number of bombs may be limited by a fixed number, or even by another item:

name = Bomb bag
savegame_variable = 1032
limit_for_counter = bombs
nb_variants = 3
amount_1 = 10
amount_2 = 30
amount_3 = 99

A third item can update the number of bombs (note that this one is not saved):

name = Bombs refill
changes_counter = bombs
nb_variants = 3
amount_1 = 1
amount_2 = 5
amount_3 = 10
brandish_when_picked = false
can_disappear = true

I agree with you: describing all items of your quest like this would be great. This is what I am working on. The treasures, the pickable items, the inventory items and the dungeon items will depend on this file. None of them will be hardcoded anymore. It requires a lot of work in many parts of the engine (not only the items) : the savegames, the Lua API, the HUD, the pause subscreens, etc. The format of maps is also changing because some entities rely on the item system: the chests, the shop items, the pickable items and the entities that hold pickable items (enemies and destructible items).

When this work is finished, your existing maps, scripts and savegames will not be compatible anymore (of course, I will provide some documentation to explain how to upgrade them).

The map editor

Several people have contacted me to know if I use a map editor for Zelda: Mystery of Solarus DX. The answer is yes, and its source code is available on the Subversion repository. Even if there is no official release yet because some essential features are missing, I have just published a page that explains how to run the development version of this editor to edit a quest.

Quest editor

A screenshot of the quest editor

Quest files specification

The project is making good progress these days, though it was hard for me during the last few months to find much time to work on Solarus, for professional reasons (I am finishing my phd thesis) and personal ones (I just got married!).

If you are interested in how a quest is built, I just published some detailed documentation about the different data files that compose a quest. This documentation specifies the format of each file:

Zelda: Mystery of Solarus DX new trailer

We have just released a new trailer of Zelda: Mystery of Solarus DX. It contains various elements of the beginning of the game, including small details (such as walking on stairs and tapping against a wall with the sword), the fight with the boss of the first dungeon, and a sequence of the second dungeon (which is not present in the demo version). The music of this trailer is an original creation of our team!


I hope you will enjoy it!

Technical documentation

Hi everyone,

The blog is under construction and new pages may become available at any time. Today I am starting the technical documentation section of the engine (Solarus), which will provide a detailed specification of the engine and the quests management. Many subsections will come soon with the specification of each component of a quest (maps, tilesets, sprites, scripts, etc.). For now, you can browse the Doxygen documentation of the C++ code if you are interested in how the engine source code is designed.


Welcome to the development blog of Solarus, the open-source Zelda-like 2D game engine. Solarus is the engine developed for the game Zelda: Mystery of Solarus DX. This blog has several purposes:

  • Provide access to the source code of the engine (Solarus) and the game(s), including the development version
  • Give news about the development and some technical information about how the engine works
  • Encourage contributions for translations, ports to new systems, development tools, and new quests

Some pages are already available and others will come soon. For now, you can get the source code and see the Zelda Mystery of Solarus DX section. You can also contact me for any suggestion.