Recent Posts

Pages: [1] 2 3 ... 10
1
Your projects / Re: Tech Demo using Cythera style interactive dialogs
« Last post by llamazing on Today at 04:03:43 pm »
Just curious, was anyone able to finish this quest (i.e. complete both objectives)?

I was intending to post some hints, but I don't see any way to do a spoiler tag on these forums (except perhaps making the font color the same color as the background). Any ideas?
Spoiler Test
2
Development / Re: About color text dialogs
« Last post by Neovyse on April 22, 2017, 12:33:36 pm »
Instead of rechoosing whiteafter changing color, you could choose default. So that, if the default color of the text is black (for example) it will become black again. For portabilty, it may be easier.
3
Development / Re: About color text dialogs
« Last post by llamazing on April 22, 2017, 04:58:49 am »
I also suggest adding a horizontal text alignment thing like $vertical{"center"}

An example more in-line with what I posted earlier would be something more like the following, using $a for horizontal alignment:
Code: [Select]
$a{center}centered text$a0
Although horizontal alignment is a tricky one because it doesn't really make sense to have more than one alignment style per line. Maybe alignment settings should be ignored unless specified at the beginning of a line/paragraph?

Also, horizontal alignment is very doable, but I'm not sure how vertical alignment would work, since isn't each line sized vertically to fit the text anyway? Maybe if you were using multiple font sizes on a single line? Or perhaps you mean to vertically align an entire paragraph of text relative to the text box?



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.

My Cythera dialog script does this.



There is still the spacing problem if you use a special characters such as é, è, ç, à and Asian type characters

My Cythera dialog script seemed to work just fine with the European accents. I didn't try Asian characters, but that would only be a problem if the characters exceeded the bounds specified by text_surface:get_size().



Also, another cool feature you could add to your dialogbox script is savegame value parsing.

In keeping with the other notation, I'd suggest $g for savegame variables, e.g.:
Code: [Select]
assignez l'arc grâce aux touches $c{red}$g{item_1}$c{white}
ou $c{red}$g{item_2}$c{white}.

Also, there's no reason the dialog has to be limited to only one instance of $v. I allowed multiple in my Cythera dialog script.



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)?

I can't say I'm a fan of the nested notation. It would be burdensome with lots of different values in a single dialog and potentially confusing to translators.

Another advantage to using the non-nested notation is that it works better with dynamic text. For example, say the player is selling their items at an item shop. A dialog may be something like "You sold the Hero Shield for 15g", which could be coded like:
Code: [Select]
"You sold the $v for $c{yellow}$vg$c0"
Then you could have strings.dat entries defining item names like so:
Code: [Select]
text{ key="item_hero_shield", value="$c{green}Hero Shield$c0"}
text{ key="item_ice_rod", "value="$c{blue}Ice Rod$c0"}

In this example, different items have different colors, so the color to use is dynamic and depends on which item the player sells. Also note that the color gets defined by the strings.dat entry rather than the dialogs.dat text.

As for the functions calls idea, it could work with the shorthand notation, but the parsing full function names becomes much trickier and is error prone if the function name is typo'ed, for example.
4
Game art & music / Mouhitotsu no Takarajima
« Last post by ffomega on April 21, 2017, 10:11:19 pm »
Hey guys! I just found out something really interesting that might benefit Solarus in terms of sprites.

This game,

Mouhitotsu no Takarajima, was originally directed by Eiji Aonuma, and shares a very similar art-style to A Link to the Past.

Here are some screens:



It would appear this game's sprites and tiles may look at home in Solarus.  What do you guys think?
5
Game art & music / Re: Building a Library of Images for Everyone
« Last post by Eric Matyas on April 20, 2017, 02:21:02 pm »
Hi everyone,

I've uploaded about 50 new metal texture images. Feel free to edit them as needed. You'll find them here:

http://soundimage.org/txr-metal/

I hope some of them are helpful!
6
Your projects / Re: Id like to create book to help beginners about solarus editor
« Last post by Zefk on April 20, 2017, 08:53:22 am »
Stable book in progress: Here

18/19 chapters are mostly done for the book. Only the chain quest chapter (chapter 16) is left.
7
General discussion / Re: Design of graphs of dungeons
« Last post by Diarandor 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.
8
General discussion / Re: Design of graphs of dungeons
« Last post by Diarandor 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.
9
General discussion / Re: Design of graphs of dungeons
« Last post by Zefk on April 19, 2017, 07:54:51 am »
I am gonna take notes on these videos. I think information like this would be very useful in the game development section of the book I am working on. Also, I could add more ideas to the brainstorm post.
10
General discussion / Re: Design of graphs of dungeons
« Last post by Renkineko on April 19, 2017, 07:42:08 am »
In Breath of the Wild, there is a lot of "Find your path" in the dungeons. There is no main item because you get them all at the start of the game, but there is still a condition to unlock new passages.

Very interesting channel. I watch a lot of video yesterday, not only the Boss Keys one. I love how he draws the graphs in the end, very clear and smooth. I'm wondering what he'd think of the Mystery of Solarus DX (and XD) games :) clearly, the 6th and 7th dungeons are a lot of find your path, while others are just follow the path. Maybe these games are too close to ALTTP to really break the formula he establised for this one.
Pages: [1] 2 3 ... 10