Skip to content
An open-source Zelda-like game engine

English translation in progress

Jan 5
News

Happy new year everyone :)

As you may know, Zelda: Mystery of Solarus DX is now finished. The French version was released on December 16th, 2011.

The English and German translation of  the game are in progress. People from the OpenPandora community are working on the English translation (thanks!) and we are helping them. I have modified the syntax of the dialog file so that writing and translating dialogs is much less painful and error-prone.

And the dialog file is now in Lua. All data files will eventually be converted to Lua, which is great for describing data. The Lua parser is lightweight and fast, including for big data files (it was initially designed for them). Lua is extensible and it is now trivial to write, for example, Lua scripts that check the validity of Lua data files. I am currently working on a tool that checks the dialog files and their translations. One day, we will be able to check the validity of an entire Solarus game and detect errors such as missing data files, invalid sprites specifications, untranslated dialogs, etc, and this tool will be integrated to the quest editor.

Zelda Mystery of Solarus DX is almost finished

Dec 10
News

The completed version of Zelda Mystery of Solarus DX will be available soon. Here is recent trailer showing a lot of game sequences!

YouTube Preview Image

The French version will be released on December 16th. There is no release date (yet) for the English version, but I hope it will be ready in few weeks. Any help is welcome for other translations. Feel free to contact me. If you already contacted me for a translation between the demo release and now, it’s possible that I did not answer you… Sorry about that. That’s because I didn’t know what I wanted (translate the old demo? make a new demo? wait for the completed game?). Finally, I chose the third option. So please accept my apologies and try again, the game is ready for translations now :)

Because releasing ZSDX was the priority in 2011, I’ve been working a lot on this quest in the last months, and there was no important changes in the engine or the quest editor since the scripted enemies. New big changes in the engine and the quest editor were not necessary for our team to finish games like ZSDX and ZSXD. But after the release, I intend to improve the format of quest files and stabilize the quest editor so that you can also make your own quests with Solarus. I have plans about that, and I will update this development blog to keep you informed.

Download ZSXD now!

Aug 12
News

Our parodic creation Zelda Mystery of Solarus XD is now available in English, as announced in my previous post. You can find it on the download page of ZSXD on Zelda Solarus (the website is in French but the download page exists in English). You can also download it directly with one of the links below:

Have fun! But don’t forget: this game is essentially a big April 1st joke ;)

Coming soon: Zelda Mystery of Solarus XD

Aug 8
News

Yes, the title is correct: Zelda Mystery of Solarus XD, not DX! DX is in progress too, but this is not what I’m talking about today!

Zelda Mystery of Solarus XD (or ZSXD for short) is one of our creations. It’s a small parodic game that we released on April 1st, 2011. I did not talk about it earlier on this blog because the game was only available in French. However, people from the Caanoo French-speaking community are currently working on a Caanoo port of this parodic game ZSXD. And they decided to translate it in English. We helped them for the translation, and it’s almost done! It still needs some final verifications.

Once it’s done, we will be able to make a release of ZSXD in English! Though it’s a parodic mini-game (initially a big April 1st joke), it’s a real, full game with two huge dungeons and 5-10 hours of playing.

Here are some screenshots:




Stay tuned ;)

Enemy scripts… finished!

Jan 18
News

Last week, I was thinking about the enemies system because one of the things I have to implement these days is the boss of the second dungeon. Then, I don’t know what happened. My fingers must have slipped. I did not really realize it, but I wrote everything to manage enemies with scripts. And here we are: enemies are officially scripted now!

So far, each type of enemy was implemented as a C++ class (hardcoded into the engine). Creating a new type of enemy required to write a new C++ class that inherit the Enemy class. Even if  the API was easy to use, implementing new enemy types was a quite heavy task. And the editor’s source code also had to be updated to support the new type of enemy… So this is was annoying. The other reason to make scripted enemies is that it will allow you to make your own enemies for your own quest. What you want when creating new types of enemy is to specify  them as data files (a Lua script and some sprites), not to change the C++ engine.

So it’s done. I took 3 months to make scripted items, and 7 days to make scripted enemies. I’m surprised it is finished so soon. I was afraid it would be very hard, but thanks to the scripted items system, things were much easier that I thought. Most of the work was already done: for example, providing to Lua scripts some functions to manage sprites and movements. I started by writing the Lua script of each existing type of enemy. Then I deduced a list of 80 functions I needed to provide to Lua enemy scripts, and I implemented all of them. And that’s it! It just works!

And why it this so nice? It changes a lot. You want to write your own enemy (say, a spider)? Just create a file spider.lua that describes its properties and behavior:

spider.lua:


function event_appear()
  -- The enemy appears: set its properties
  sol.enemy.set_life(1)
  sol.enemy.create_sprite("enemies/spider")
  sol.enemy.set_size(16, 16)
  movement = sol.main.path_finding_movement_create(32)
  sol.enemy.start_movement(movement)
end

The sol.module.something() functions are functions of the engine that a Lua script can call. sol.enemy represents the current enemy and provides some functions to set their properties and their dynamic behavior. The engine can also call some functions of your scripts (the ones prefixed by event_): the function event_appear() is called by the engine when a new instance of the enemy arrives on the map. Here, we set this spider’s initial properties: its life, its sprite (the corresponding sprite file must exist, and contain a small set of predetermined animations like “stopped”, “walking”, “hurt”, etc.), its size and its movement. sol.main.path_finding_movement_create() creates a movement that calculates a path to the hero. That’s it, you have a new type of enemy. You can now add spiders to maps with the quest editor.

There are lots of functions like this. event_appear() is called by the engine to notify your enemy that it was just created on the map. Other useful callback functions are event_obstacle_reached(), event_movement_finished(), event_sprite_animation_finished(), event_dead(), etc… After the release of ZSDX, I want to make some tutorials to show the elements of making a Solarus quest: maps, enemies, items, sprites, NPCs…. In the meantime, you can have a look at the (updated) documentation.

New equipment system finished, ZSDX is the priority in 2011

Jan 10
News

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

Sep 22
News

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://github.com/christopho/solarus.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

Sep 9
News

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:

[item.hookshot]
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:

[item.sword]
name = Sword
nb_variants = 4
ability = sword

Some items have a counter associated to them:

[item.bombs]
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:

[item.bomb_bag]
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):

[item.bombs_refill]
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

Aug 18
News

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

Aug 6
News

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: