Messages

I;d say a window menu, is a must, with the following minimum options:

Configure Input
Main Sound Volume
Sound Effects Volume
Default Size
(Possible nest those in a Prefs menu)
Default Keys -> Displays all the keys for adjusting the window, such as F5, F10, so that a player can have a reminder.
Pause
Quit -> On separate menu list, with 'Are you sure?' dialogue.

Clicking anywhere in the window, could also work to pause the game

A separate commit function, when adding tile selections to the tile selection pane, in the PNG viewer. i.e When you select an area, and make it a tile, you can click commit to store it, and get a verbose dialogue. Because there's no internal response to making the object, it's hard to tell starting out, if what you're doing is working.

An internal PNG loader would, of course, be of higher value.

Hmm... the faerie could use a sound effect then, as it gives no response. Either way, if the player has no empty bottle, adjusting it so that it acts accordingly should be rather straightforward.

I have no objection to puzzles. I managed all the puzzles up to that point essentially blind, but that one last block, because it can misalign, and there is no way to fix it, can ruin the completion, and waste a great deal of player time to realise that it's become impossible to solve.

Moving the crystal switch, and the two switch tiles, down 8 pixels might be enough to prevent that; unless it was intentional.  (I would have literally had it on my first attempt, if not for that.)

I'd also say, that  updating to correct any kind of game design problem, would roll into bugs. Then again, I update my projects regularly, no-matter what I change, and always keep older versions available.

More of an 'unintended consequence', but:

If you have a faerie in a bottle, and pick up another one, and choose 'store it', you get an error that you don;t have empty bottles, but the faerie isn't released. It's just wasted. You may want to fix that for future releases, especially if a player isn't closely monitoring his bottles. All you need do, is change it so that if it can't put it in the bottle, it re-spawns it close to the player.

That, or run a check to see if there are any full bottles, before offering the choice.

--

In the L1 block puzzle, it's possible to misalign the block in the small room with the crystal switch. Again, I'm not sure if that's intentional, but it took me half-an-hour to realise that I botched it, with a misalign. Once I realised that, I reset the room and solved it quickly. The puzzle itself isn;t hard, just tedious; but that misalign potential has no recovery possible.

Rather than having game options (Volume, Music Volume) only available at the start of a game, it would be nice if the Solarus viewer itself had a menubar, with options to change behaviour, including volume, controller mapping, and the elsewhere mentioned 'pause' option.

I expect that you could add the options inside a game, but I always feel it the duty of the host programme to offer this, in the event that a game creator fails to do it.

I'm not sure if this was intended, but when sending a PM, the default destination is the recipient's profile, not the user's inbox. I think a dialogue 'Message Sent' would be good, no-matter where you forward the user, as the way it is, it doesn't appear that the message was dispatched, and the messages box doesn't show an outgoing messages folder.

I also run SMF, but I stick to the classic 1.x version, because I have too much committed to customisation with it; but I know that in 1.x, the behaviour for this was easy to change.

(For all I know, PMs are broken at present.)

This one sounds straightforward: Add a PNG resource file, for use with sprites/tiles, from inside the Solarus editor.

Place a button 'add' in the sprites editors, select a file from anywhere on the local volume. Then, Solarus copies it into the required directory, and assigns it a name matching the resource ID a user provides.

That would be simpler than manually going to the resource directory, copying, renaming it, and ensuring that it matches.

Also, a 'commit' button, for editing the tile/sprite page, would be nice, so that changes occur only after pressing a button; and a verbose response ('change committed') would be good too. I would make both of these latter two, options enabled by default, that a user could disable in prefs.

Well, as I said, I already fetched the DX quest pack from GitHub,  but you either need to bundle that, or make it easily available (as in, put a direct link to it, as a ZIP archive, on the Solarus download page) so that people aren't entirely lost.

I can understand wanting to avoid IP complaints, but let's face it you designed this to make Z3-inspired games, and you already distribute both the DX and the XD games under GPL 3, so putting them on the site directly, wouldn't change much.

I'm personally not an avid fan of GPL3, and I distribute under GPL and LGPL v2, but that's me. (I'm guessing that you were forced to use v3 because of Lua anyway.)

I also doubt that the GPL community will come down at you in flames for bundling Nintendo graphics, and sound samples with a binary. Binary distribution, primarily requires that sources are made available; and you do exactly that. External infringement isn't a clear breaker for GPL, only for those who own the IP, and ZC has been around for 16 years with no complaints whatsoever.

Most of these fan projects, from what I can see, Nintendo look at as free advertising.

At present, all aspects of enemies, and items, must be hardcoded. I would suggest that you consider using templated format enemies, where the sprite, hp, movement, and other parameters can be passed as arguments through an editor pane. This would, be in addition to the present mechanic, and if you would like to see this implemented elsewhere, have a 30-minute walk through ZQuest.

If you pre-load a quest template with enemies, items, and map objects, and allow easy customisation of the enemies, and items, users would be far more ready to adapt, or shift to the Solarus programme.

A bug that I, and several mates have noticed (on different hardware), is that during area transitions that do not have a cross-fade, there is about a 1.5 second delay, while Solarus loads the map for the next screen area, in which the game jitters, and the music halts briefly.

We suspect, this to be caused by the Solarus engine, not pre-fetching the next map area, and I have a suggestion for how to fix this: Find the closest map area to where the player is at all times, and keep that loaded in memory, so that the game engine can instantly transition to it. This is relevant only to map areas, where there are screen region transitions.

Clearly, you would only need to pre-fetch touching map areas, and probably only those to which the player is close. Maybe within X pixels of a boundary, to avoid that lag.

Otherwise, I'm quite impressed with the engine itself, although I won;t be giving up ZQuest anytime soon, and in particular, the 50,000 lines of ZScript code that I've created to run with it. I do look forward to learning the Lua language for Solarus; although I think it will take me a while to adjust to the lack of a simple enemy, and item editor.

One thing that most gamers love to hate, is when a game has absolutely no way to pause it, and pause the music with it. ...

I'm one of those blokes who has been using ZC for years; and one of the nice features in ZC, is that the programme will pause when you click in the window, or when you defocus the window. This means that you can do things, like take a break, or use Skype, or watch an LP to aid in figuring out a stubborn puzzle; and not have the game continue running, and playing the in-game music.

I have pressed every key, toggled everything that I can find, and short of exiting the viewer, nothing will stop the game running.

Unless I've missed something, it seems there's no way to pause, defocus, or anything of the sort, to have a moment's silence. Aye, I could turn the speakers off; and then, I can't do anything else with the system that's running Solarus viewer, which is to say the least, a big greedy; yes?

Please add a method of fully pausing the game, or at least, disabling sound with a menu of some kind in the Solaris view itself. Pretty please...

I've been a long-time user of ZC/ZQuest, and the idea behind this game engine is interesting, however...

It would be nice if there was a sample quest file, that contained all of the items, enemies, and other game objects that are actually in Solarus DX. You know, like the screenshot on the main page at http://www.solarus-games.org/ displays...

Did I miss something?

Is there a way to import all of that into the editor, or a download link for the quest package for the Solarus game?

A default quest, with all of the goodies used in the Solarus game, should be attached to this, IMO, in future builds.

P.S. I should note, that I did manage to merge all the material from the GitHub sources, but I still feel that should be included with the editor as an example quest, rather than a one-room thing. People who want to make all their items from scratch, can do that, but people who want a drag-and-drop Z3 engine, will want something with which to build that.

I need to read the docs for all of this, as I'm trying to figure out how item sprites are linked to the items, as there's nothing seemingly in the item code that determines its sprite. It's all quite interesting, although it'll mean learning yet another language, and specific syntax; so it may be a while before I can get around to doing more than making a quick and dirty test game.

Otherwise, the end-user is stuck creating all of the game objects from scratch, which is essentially saying 'make the whole game engine, again'. I would appreciate some information on this matter, and some example quest files, if possible. Thank you, and cheers.