Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Diarandor

Pages: [1] 2 3 ... 45
1
General discussion / Re: Design of graphs of dungeons
« on: April 19, 2017, 08:42:36 am »
An example to explain what I mentioned would be a dungeon with only 1 red key and only 1 blue key, but several red locks and several blue locks. This is a weird example of dungeon with more locks than keys (completionists may not like the idea of having locks that cannot be opened, though). There would be multiple solutions, which also adds more replayability to the game. Buth this is also a double-edged sword for the devs since they are forced to check that all choices allow to solve the dungeon, without "breaking" the game, heheh.

2
General discussion / Re: Design of graphs of dungeons
« on: April 19, 2017, 08:16:01 am »
An interesting remark is that when you have a key and a multiple choice of doors to unlock, the graph may become different depending on that choice (that is not completely the case in key cavern of LA, though). This is easier to see if we allow to have color keys and one color key gives such a choice; with color keys the graph thing could even become much more complex, depending on the choices.

3
General discussion / Re: Design of graphs of dungeons
« on: April 17, 2017, 11:23:03 pm »
This video (about Link's awakening) is really nice too:
https://www.youtube.com/watch?v=AezAN2RcO8Y

This guy has made analysis of the dungeons for most of the Zelda games; I think these are worth it to see if you are developping a Zelda game.

4
Development / Re: About color text dialogs
« on: April 17, 2017, 09:48:09 pm »
@wrightmat: Yes, I modified Christopho's script to allow displaying a sprite and choosing its animation.
Your idea that allows passing the name of the NPC is really good too; it is a nice feature to add to the scripts.

5
Development / Re: About color text dialogs
« on: April 17, 2017, 07:05:49 pm »
What do you think would be better of these options for the dialog box script? (I mean, for a new script that I will make.)
Non-nested properties (as the ones you use)? Or nested ones (like the ones of the end of my last comment)?

6
General discussion / Design of graphs of dungeons
« on: April 17, 2017, 05:58:19 pm »
This video explains a bit how to make a dungeon graph, which is useful to design a dungeon. It is not exactly a tutorial, but it is interesting.
https://youtu.be/fqKGl6exyyY

7
Development / Re: About color text dialogs
« on: April 17, 2017, 04:44:21 pm »
I agree with @llamazing and @MetalZelda that putting names to new text surfaces in the dialog_box is really unnecessary. The idea I had in mind when I coded that was to allow to go back to the previous text surface if needed, to reduce the number of surfaces, but since the dialog box is small we should not worry about this kind of things. Better to reduce the syntax as the ones you use.

A good idea, and probably a better syntax, would be allowing to call functions in dialogs. So I propose a slight modification of the same syntax, which is even shorter:
Code: [Select]
$function_identifier
The functions associated to each "function_identifier" would be defined in the dialog box as usual: "dialog_box:function_name()".

To avoid using long function names in the dialog box (the syntax would be too long) and at the same time keep the long name in the definition of the functions of the form "dialog_box:function_name()" (which is clearer), we could use a short identifier after the dollar symbol "$" instead of the name of the function. For this purpose, another function "dialog_box:start_function(short_id, parameters)" would be needed, just to start the convenient function assotiated to that "short id" used in the syntax.

Furthermore, to keep the dialog as clean as possible, the parameters of each function should better be given as properties of the dialog and not in the middle of the text. For instance, if the color is changed 3 times in a dialog, we would define an array of color properties, and each time $c is called, the next color of the array would be applied.

Remark: $c could be used to call a function "dialog_box:set_color(color)". This function should be overloaded to be compatible too with this other useful syntax: "dialog_box:set_color(r, g, b)", whose parameters would be sent as strings and then "dialog_box:set_color(r, g, b)" would first convert the three strings into integers and then make the color change.

An example to change color and a shaking effect:
dialog{
  id = "_cannot_lift_too_heavy",
  skip = "all",
  color = {"red", "white", {200, 0, 100}},
  movement = {{"horizontal", "fast"}, nil, {"vertical", "slow"}, nil},
  text = [[
Oh là là, c'est l'$camour$c !

$cWe will $mshake$m and $mbounce$m !
]]
}

I propose some short function ids (i.e., for the dialog syntax):

$0, $1, $2, $3, etc: as usual, for the "text speed"
$c: change color; allows color_id_string  or (r, g, b) as parameters
$s: change the size of the text; integer parameter
$f: change the font type; font_id_string parameter
$m: movements and shaking effects; parameters: movement_type_string, and other optional_parameters
$d: "dynamic" (i.e., continuous) color changes (rainbow color-shift, etc). parameters: effect_id_string, and others
$b: change the "beeping" sounds, which may be different for different NPCs, etc; parameter: sound_id_string
$i: draw image/icon (the width may be given as parameter if necessary). parameters: image_id_string, etc

If you have more ideas for other different effects that we may implement, or a suggestion for a different syntax, we can discuss it.

A different syntax, much clearer for translators and easier to read, but harder to code (because there could be a "nested" use), would be to use "{", "}" symbols (these could be optional) to indicate where the effects will be applied. For instance:
blablabla this $c{word} and $c{this} are in red.
Another example:
dialog{
  id = "_cannot_lift_too_heavy",
  skip = "all",
  color = {"red", {200, 0, 100}},
  movement = {{"horizontal", "fast"}, {"vertical", "slow"}},
  text = [[
Oh là là, c'est l'$c{amour} !

We will $c{$m{shake} and $m{bounce}} !
]]
}

8
Game art & music / Re: Original art
« on: April 16, 2017, 01:24:09 am »
Let's go on-topic again: I made some new (original) soldier sprites!!!
These will be used for normal soldiers in the project "Children of Solarus". Testing video here:
https://youtu.be/WbGFNsvQwLs

9
Game art & music / Re: Original art
« on: April 15, 2017, 07:03:04 pm »
I agree. Seiken Densetsu 3 is an awesome game, but as you say there is an annoying small delay before the attacks, and the most annoying thing is the difficulty (you have to spend too many hours grinding to level up, which is probably the worst about this game). The graphics, story and OST are probably the best of this game. I finished this game 15 years ago, but I used cheats with the ZSNES emulator because I was underleveled and I got bored of grinding.

Another thing that I loved of SD3 is that depending on the main hero you choose, you start in a different place with a different story, and each hero has a different ending too (the bad thing is that you need to complete the game at least twice to get the endings of all 6 heroes). There are other games using similar mechanics of several heroes, like "Live A Live" and "Treasure of the Rudras", both of them masterpieces too; in these two games you first complete several main stories, and in the end all heroes join for the last part of the game; that is one of the ideas that I wanted to include in the hybrid game of my dreams that I want to make (with more complex mechanics due to the puzzle part of Zelda games), but that will be after we finish Children of Solarus, which is my main priority.

EDIT: if by "sword of mana" you mean the GBA game, I did started to play it, but I never got motivated to finish it. Maybe I had already played too many RPGs, or maybe I was getting "old", XD.

10
Development / Re: About color text dialogs
« on: April 15, 2017, 05:22:30 pm »
It would be very useful too to add a feature that manages the change of line of the dialog box if the max lenght of one line is given. I don't have time these days to work on this, though.

11
Game art & music / Re: Original art
« on: April 14, 2017, 02:07:33 pm »
@Zefk: Thanks a lot for valuing so much this work! Your appreciations are very appreciated ;D
It has been a lot of effort (and time) to draw the improved animations of the hero, and there is still quite a bit to do.
When this is finished I will go back to the work on the overworld tileset, to finish its final version.

Indeed, the sleeping animation for Eldran is highly (and mainly) inspired from the animations of Seiken Densetsu 3 (aka Secret of Mana 2), as you noticed.

12
Game art & music / Re: Original art
« on: April 14, 2017, 10:55:08 am »
A few more animations are finished for the remastered Eldran. These include "sword_loading_stopped", "sword_loading_walking" and "sword_brandish". Link here:
https://youtu.be/ar3OJIuHJac

13
Development / Re: About color text dialogs
« on: April 14, 2017, 02:21:23 am »
Thanks a lot @llamazing!
I'm sure your scripts will be useful to others to program similar features.

14
Development / Re: About color text dialogs
« on: April 13, 2017, 06:32:45 pm »
Hi! Due to the fact that there was a lot of discussions about the color features of the dialog box (bugs and improvements), we can continue talking about this in this topic.

@llamazing: You said that you made a script that allows to change colors for any type of font (even non-monospaced fonts) and also working with special characters (multi-byte characters, like accents, Japanese characters, etc). Would it be possible for you to share it here? It may help others, including me, to improve our dialog box scripts.

@wrightmat: I think that your syntax is ok for your game, but it is not so good for other games if we plan to add more features that are combined with the color feature; for instance, we could allow to change the font type or size in the middle of a dialog, or even allow to code several "shaking" effects for part of a dialog, so the approach of changing surfaces (and give names to them) may be better in my opinion.

The only think one has to be careful, when using your syntax, is that when you change color before of a word, your syntax may be concatenated in a weird way sometimes. For instance, if the first word of a phrase (say, "Hello world") is in red and the rest in white color, you would have to write "$rHello$w world" without a space between the "r" and "H" because spaces are not ignored (unless we change the code). With my syntax it would be something like this: "${red_surface}$[color_name]Hello ${default}world", which makes slightly easier for translators to detect where the color syntax ends, I think. It is also good to allow choosing color with the "$[(r,g,b)]" syntax too, just in case we don't want to define a color name for a color that is used just once; for colors that are used a lot it is probably better to use the other syntax, "$[color_name]", so allowing both syntaxes seems a good idea to me.

Note that if we try to expand the features of the dialog box, for instance to add a shaking effect, it would be usefult too the change of surface. If we use a LaTeX-like command for the shaking effect, say "$\{shake}text to shake", an example for a shaking word would be: "This ${shaking_surface}$\{shake}word ${default}is shaking". I was thinking that it could be more intuitive if we use a math mode like in LaTeX, where dollar symbols $ are used to start and to end math mode in a way like this "blablabla $\command_name{optional_parameters}$ blablabla", and enviroinments can be started or finished in the same way (maybe we could omit the dollars, or just use the dollars as if they were the "\" symbol as I already did in my syntax).

@everybody: Well, we all should discuss which syntax for the dialog box could be more intuitive, but also versatile for all kind of general purposes, and it would be nice to fix a standard notation compatible between all games. (It could even be added to the Quest Editor if Christopho or someone else programs the Editor to display the text with that kind of features (colors, shaking effects, change of fonts or size, etc), but I guess that this would be too specific and is probably a bad idea for the Editor.)

Our main purpose in this topic would be then to fix an "official" syntax for dialog box features that produces no limitations (i.e., that allows to add more commands and as many of them as we want) and is intended to be used in most games of the community (for compatibility reasons). We could share the code here or in some github repo. We could even open some poll in the forum, if necessary, to make some decissions.

15
Your projects / Re: Zelda: Book of Mudora
« on: April 13, 2017, 05:47:23 pm »
Maybe we can continue in this old topic where this discussion began:
http://forum.solarus-games.org/index.php/topic,312.msg1201.html#msg1201

Pages: [1] 2 3 ... 45