Ice, low walls and other improvements about grounds

Two new types of grounds (or terrains) are now implemented in Solarus 1.1, as well as improvements in the detection of the ground.

  • Ice ground: tiles that make the hero slide, with some sort of inertia.
  • Low walls: obstacles that can only be traversed by projectiles like thrown items, the boomerang, arrows and flying enemies.

I also improved the code that detects the kind of ground of a point. Before, it only worked with the hero, and did not always correctly take into account dynamic entities that may change the ground, like dynamic tiles. (And the code was too complex!)

Now, the ground is correctly detected, including when it gets changed by dynamic tiles (even with moving dynamic tiles). Last but not least, this new detection algorithm works for any coordinates (not only the hero). Therefore, enemies and thrown items can now fall into holes and drown into water or lava!

These improvements and the two new kinds of tiles were demanded for a long time. I hope you will enjoy them!

Solarus Forums

Since the Solarus 1.0 release, several people suggested that we create a forum.

Here it is!

We hope that the forum will be very useful for people who use the Solarus engine. You will be able to talk about developing your own games, get help, share knowledge, scripts and game resources. It will also be a place to present your projects to the community. We are open to any suggestion!

New entity type: separators

I have finished another new feature for Solarus 1.1: you can now separate a map in different regions. When you are in a region, you cannot see adjacent regions. And when you touch the limit of the region, the camera scrolls to the region on the other side.

You can use this feature to visually separate rooms that are in the same map. In ZSDX, when you are in a room of a dungeon, you can also see parts of the adjacent rooms. If you want to only show the current map (like in Zelda ALTTP), it is possible now. With the quest editor, you create a separator, which is a vertical or horizontal bar that you place on your map.

Separators implictly define regions on your map. Thus, you can also use this feature to make a minimap that shows the visited rooms of the dungeon.

Customizable dialogs!

This is a very important new feature of Solarus 1.1. The dialog box system is now fully scriptable using the Lua API! It means that you can now make any feature you want to your dialogs, like changing the font, the color, the text alignment, adding images or sprites, making questions with multiple possible choices…

The syntax of the dialog files does not change, expect that any custom property is allowed in a dialog. Actually, only the dialog id and the text are mandatory. Everything else (the icon, whether there is a question, whether the dialog can be skipped…) is now seen as additional, custom properties of your quest.

If you don’t make a scripted dialog box in Lua, the engine shows a minimal dialog box without decoration. But it is recommended to make your own one!

Here is an example of a small map script with a non-playing character that shows a simple dialog when the hero talks to him:

local map = ...

function some_npc:on_interaction()
  -- Remember that you specify a dialog id, not directly the text to show.
  -- The text is defined in the dialogs.dat file of the current language.

Here is a more complex example, with an NPC that asks a question. This example assumes that your dialog box system can ask questions to the player, and returns the answer as a boolean value.

local map = ...
local game = map:get_game()

function another_npc:on_interaction()
  game:start_dialog("give_me_100_rupees_please", function(answer)
    if answer then
      if game:get_money() >= 100 then

The new dialog API is very flexible. When you show a dialog, you can pass a parameter to your custom dialog box system (this feature is not used in this example), and symmetrically, your custom dialog box system can return a result (like the answer selected by the player in this example).

Fore more details, see the documentation of game:start_dialog() in the Solarus Lua API.

New format of project_db.dat

Since Solarus 0.9.0, the format of most data files is being changed to be more readable, easier to parse and more homogeneous.

In Solarus 1.0, good progress has been made in this direction, especially with the new format of maps. Three formats of data files remain to be changed: the strings.dat language file, the sprite sheet files and the quest resource list file. I plan to change them all in Solarus 1.1.

And the work is now finished for the quest resource list file (project_db.dat). This file defines the list of resources (maps, tilesets, sprites, musics, sounds, enemies…) and allows the quest editor to show them and edit them. The new format looks like this:

map{     id = "outside",      description = "Outside World" }
map{     id = "hero_house",   description = "House of the hero" }
map{     id = "shop",         description = "Shop" }
map{     id = "dungeon_1_1f", description = "Dungeon 1 - First floor" }
map{     id = "dungeon_1_2f", description = "Dungeon 1 - Second floor" }

tileset{ id = "overworld",    description = "Overworld" }
tileset{ id = "house",        description = "House" }
tileset{ id = "dungeon",      description = "Dungeon" }

sound{   id = "door_closed",  description = "Door closing" }
sound{   id = "door_open",    description = "Door opening" }
sound{   id = "enemy_hurt",   description = "Enemy hurt" }
sound{   id = "jump",         description = "Jumping" }
sound{   id = "treasure",     description = "Treasure" }

item{    id = "sword",        description = "Sword" }
item{    id = "bow",          description = "Bow" }
item{    id = "arrow",        description = "Arrows (x1 / x5 / x10)" }

enemy{   id = "soldier",      description = "Soldier" }
enemy{   id = "dragon",       description = "Dragon" }

Note that the quest editor fully supports the modification of this file since Solarus 1.0.2. More information about this quest resource list file is available on the documentation pages.

More importantly, I added to the quest editor a system to upgrade automatically your data files when their format changes. Whenever a new version Solarus is released, if the format of data files has changed, the quest editor will upgrade them for you.

Maps have now a default destination entity

Here is a small improvement that will ease the life of quest creators in Solarus 1.1, the future version of the engine.

You will be able to set a destination entity as the default one of the map. It means that whenever a teletransporter (or some Lua code) sends the hero to a map without specifying a destination entity, the hero will arrive on the default destination. If no destination was explicitly set as the default one, then the first one of the map is the default one.

Many maps are very small in a game (like a house in a village) and contain only one destination. In these cases, you no longer have to give a name to the destination and to link a teletransporter to this destination name. In the map of the village, you can make a teletransporter that goes to that map and leave its destination parameter unspecified.

When you create a new savegame, the starting map and the starting destination on that map also become optional in Solarus 1.1. If you don’t call game:set_starting_location(), the game starts on the first map declared in the resource list and with the default destination entity of that map.

This change is not the most important new feature of Solarus 1.1, but it will reduce the risk of errors and improve flexibility!

Controlling the quest size to obtain maximum portability

Many new features are planned for Solarus 1.1. I will talk about the important ones whenever I implement them.

The one I have been working on for the last few days is an important improvement for quest makers, for players and also for people who compile the engine on various systems.

In Solarus 1.0, the size of the visible space that appears on the screen (we call this the “quest size”) is a constant defined at compile time: by default, 320×240.  This “quest size” is how much content of the map you can see when playing. It should not be confused with the video mode of the screen: the video mode just defines how this 320×240 quest space is rendered on the screen: directly in a window, stretched or scaled to 640×480, in fullscreen or not, etc.

The main problem of this approach is that everything is decided at compilation time. As the creator of a quest, you have no control over the screen size and your game is just supposed to adapt itself with any size. Which is just not possible. You don’t want a game area of 1000×1000 because the player could see way too much content of your maps! Still, you may want to allow different sizes (like 400×240) so that the game fills the entire space of wide screens, using square pixels and without vertical black bars.

To solve the problem, in Solarus 1.1, you will be able to set the range of sizes that your quest allows.

If you are okay to allow people with a wide screen to see more content that others, you can set a range of sizes in your quest properties file (quest.dat):

 solarus_version = "1.1",
 write_dir = "my_quest",
 title_bar = "My incredible quest",
 normal_quest_size = "320x240", -- Works on most configurations.
 min_quest_size = "320x200",    -- Might make fullscreen compatible with more systems.
 max_quest_size = "400x240",    -- Suited for wide screens, including mobile devices like Pandora.

Of course, your maps and your menus will have to adapt correctly to any value inside this range. So it requires more work, but your game will be more portable. There is a new Lua function to help you with that.

At runtime, the user can choose his quest size with a command-line option. A default quest size can also be set at compilation time. If the size requested is not in the range allowed by your quest, then normal_quest_size is used instead.

Then, Solarus does the complicated work for you :). It automatically detects the appropriate resolutions to render this size at best for each video mode (fullscreen, with scaling, etc.). So you don’t have to worry about that part. Besides, the Lua API of video modes does not change at all.

If you prefer that all people play your quest with the exact same visible area, set all three sizes to the same value, or just define normal_quest_size (by default, min and max take the normal value):

 solarus_version = "1.1",
 write_dir = "my_quest",
 title_bar = "My incredible quest",
 normal_quest_size = "320x240", -- Only one allowed quest size.

Solarus 1.0.4 released, fixed crashes in ZSXD

And… Solarus 1.0.4 is out!

Two crashes in ZSXD remained despite all my tests, and the customization screen of joypad commands was also broken.

Changes in Solarus 1.0.4

  • Don’t die if a script tries so show a missing string (#237).
  • Don’t die if a treasure has a variant unexistent in the item sprite.
  • Fix customization of joypad commands.

Changes in Zelda Mystery of Solarus DX 1.6.2

  •  Fix two line errors in English dialogs.

Changes in Zelda Mystery of Solarus XD 1.6.2

  • Fix a crash due to a missing text in the French options pause menu.
  • Fix a crash due to an invalid treasure in a pot of crazy house 1F.
  • Fix a typo in the French inventory pause menu.

Please continue to report any bugs. I expect more bugs to be found because this upgrade of both quest to Solarus 1.0 is really a heavy change for them.

Solarus 1.0.3 released, no more blocked blocks

Due to Murphy’s law, I introduced an important bug at the very end of my tests, just before releasing Solarus 1.0.2. This bug made you fail to push blocks completely (the last pixel of the movement was not done). So here is a new patch release (1.0.3) that just fixes this bug. You really want to upgrade.

There are no changes in our games (ZSDX and ZSXD) but they get a new version number (1.6.1) because on some systems, the engine is included with the game.

Changes in Solarus 1.0.3

  • Fix blocks not completely moved since 1.0.2.

Sorry about that and thanks for your feedback.

(I really should make unit tests one day!)

Solarus 1.0.2 released, ZSDX and ZSXD upgraded to the new engine

An update of Solarus 1.0, Zelda Mystery of Solarus DX and Zelda Mystery of Solarus XD is available!

This update fixes a bunch of bugs of previous versions. It is recommended to upgrade.

Because it is a patch release (1.0.1 to 1.0.2), there is no change in the format of data files or in the Lua API, everything remains compatible.

And our games Zelda Mystery of Solarus DX and Zelda Mystery of Solarus XD are now fully working with Solarus 1.0. They are both released in a new version 1.6. There is also a new title screen from Neovyse (thanks!) and the English translation of both games has been greatly improved (thanks ibara!).

We have worked hard to upgrade both games to the new Lua API (thanks for your help pdewacht!). This does not change much things for the players, but if you are developping a quest with Solarus, you might be interested in reusing and modifying some of our scripts, like the HUD, the pause menu, the title screen or some enemies. The Lua scripting API of Solarus 1.0 allows to customize all of this!

Changes in Solarus 1.0.2

  • Fix a crash when a treasure callback changes the hero’s state (#224).
  • Fix a crash when a victory callback changes the hero’s state.
  • Fix a crash due to invalid sprite frame when animation is changed (#26).
  • Fix an assertion error with FollowMovement of pickables.
  • Fix the fullscreen mode not working on Mac OS X 10.7+ (#213, #220).
  • Fix pickable treasures that could be obtained twice sometimes.
  • Fix fade-in/fade-out effects on sprites that did not work (#221).
  • Fix that failed with “none” or “same” (#201).
  • Fix item:set_sound_when_brandish() that did not work.
  • Fix diagonal movement that could bypass sensors since Solarus 1.0.1.
  • Fix circle movement not working after entity:set_enabled(true).
  • Fix detection of movement finished for NPCs.
  • Fix memory issues with menus (#210).
  • Fix handling of nil parameter in boolean setters (#225).
  • Fix hangling the default language.
  • Correctly suspend timers when set_suspended_with_map is called.
  • When a sprite is suspended, suspend its transitions (#226).
  • Don’t die if a music or a sound cannot be found.
  • Don’t die if an image cannot be found.
  • Don’t die if running a savegame without starting location specified.
  • Don’t die if a script refers to a non-existing equipment item.
  • Don’t die if the self parameter is missing when calling a method (#219).
  • Fix dangling pointers after removing some kind of entities.

Changes in Solarus Quest Editor 1.0.2

  • Allow to create map entities from the quest tree (#208).
  • Fix a typo in the bomb flower sprite (#214).
  • Fix a possible NullPointerException when opening an invalid map.

Documentation changes

  • Add the syntax specification of maps and tilesets.

Changes in Zelda Mystery of Solarus DX 1.6

  • Improve the English translation.
  • New title screen from Neovyse (#45).
  • Fix a typo in French dialogs.
  • Fix a door bug that could get the hero stuck in empty rooms.
  • Fix saving the state of Billy’s door.
  • Dungeon 1: keep the final door open when coming back in the boss room.
  • Dungeon 7 2F: save the nort-west torches.
  • Savegames menu: the joypad was not working to delete a savegame.
  • Dungeon 10 B1: fix a cauldron the hero could walk on (#20).
  • Rupee house: don’t let the player to get the piece of heart with the sword.
  • Dungeon 6 2F: move crystal blocks to avoid a possible breach.
  • Outside world B3: fix a minor tile error (#12).
  • Dungeon 8 B1: fix a minor tile error (#2).
  • Dungeon 8 B3: fix a minor tile error.

Changes in Zelda Mystery of Solarus XD 1.6

  • Improve the English translation.
  • Fix the hero stuck after jumping on a block in dungeon 2.
  • Fix all missing empty lines in dialogs.
  • Add the Solarus engine logo at startup.