Redesign waffle coins

[Quintus]

Currently, our waffles still look too much like coins. We should redesign them.

See also this forum thread.

Current SVG file

Vale, Quintus

[datahead8888]

Official site discussion - http://secretmaryo.org/phpBB3/viewtopic.php?f=10&t=9959 Mr. Vertigo has already replied to this thread.

[Bugsbane]

Personally, I'd go with replacing the mushrooms with large, round rolling fruit (peaches, oranges, apples), and the coins with smaller fruit - possibly berries, like cherries for the yellow coin, and maybe a strawberry for the red coin.

[datahead8888]

I originally suggested coins instead of waffles, citing the game's roots as a reason, but I've since come to a different conclusion.

It's really a question about what core themes drive the game's story and gameplay. I was last playing around with the themes being the library, ancient ruins, monsters, and maybe wizards (based on the spell casting suggestions).

Having waffles (and potentially any food item) as the token sprawled through every level pushes a food theme for the story. With food themes you tend to end up with choices such as replacing the Rokko cannons with toasters (this was discussed in the forums) and chefs for enemies.

It really comes down to what themes we all want and what type of game. I'd like to see a game that has some bright and fun elements to attract children and some higher level themes like a librarian villain who quotes Shakespeare and armies of furballs walking across a field with dark, ominous clouds overhead. My thought is that introducing food tokens throughout the whole game will push the game more towards food themes that appeal more to children than adults as opposed to appealing to both age groups.

Thus my thought would be to introduce a new type of coin with a custom image such as ancient symbols as are used on the bookshelves graphics.

[Bugsbane]

I remember when this was being discussed years ago, that one of the other ideas that came up at the time was some type of gems. (Seems somehow fitting now that SMC uses Ruby...) They're still identifiable as valuable, used in many games to represent currency, but allow some extra colour.

One thing that I always enjoyed about the Mario games though, was their willingness to be a bit surreal and put things together you wouldn't normally see, such as a little guy in overalls running through pipes, collecting mushrooms and flowers and occasionally running into skeletons / lava monsters / turtles / Aztec crushing blocks etc. It was surreal in a way that too many games today wouldn't dare to be.

What held it all together was a very defined visual style, more than the actual objects depicted imo.

[datahead8888]

There's probably truth to both arguments. We'll just have to try new things and experiment with both the game assets and story.

[datahead8888]

I got to thinking again. Donkey Kong Country used bananas as the tokens, and this game fits the bill of appealing to both children and adults very well (by contrast I was disinterested in Donkey Kong Country 3 because of Kiddy Kong). In Donkey Kong Country I especially loved the environmental impact themes in Kremkroc industries, and even my parents talked about this game.

Given that fruit grows on its own, it's pretty easy to explain why pieces of fruit would be scattered all over the place. It doesn't necessarily require much of a story explanation.

Jewels are also an interesting possibility. I think I've seen them in some platformers, but I can't think of a widely popular one that uses them.

If there's an interest in a 3D version of this token (kind of like the 3D coins), I could maybe eventually look into creating a 3D version of whatever we decide to use rendered to sprites in Blender. I took a course on Maya modeling a year ago, though I have less experience with the open source equivalent of Blender. Given that it's been a while since I did 3D modeling and given my Blender experience, I can't promise anything. Even if we go 3D, we still will need concept sketches.

Given the number of possibilities and prominence of this item, I would like to keep the door open for trying new things for it going forward.

[Bugsbane]

I'm cool either way. I know Blender as well, and would highly recommend if you're going to give it a try to a) check Blendswap first just in case there's already something good there we could ask to use and b)Use the Freestyle renderer so we can get nice cell shading in a similar style to the current artwork.

[Quintus]

I can’t quote on which tools are best to use, because I’m barely familiar with any of them (I can do some little fiddling with Inkscape, but that’s about it). Use whatever you think is best, but please provide us with both the original files so other artists can pick the work up, and with rendered PNGs the dev team can put into the game (which are also useful for preview).

On the coins replacement topic, I tend to agree the fruits don’t really fit for them, even though Donkey Kong uses them... Jewels can also be designed to look bright and colorful, so I think they can appeal to children also. The Zelda series uses jewels as a currency btw, but this is a different type of game probably. Also, if we choose fruits as a replacement for the mushrooms, we get tuttifrutti if we also replace the coins with fruits :-)

I have long advocated to replace the mushrooms (and other powerups) with fruits. Rolling fruits are nice in the way that we would not have to alter the mechanics of the current powerups, but doing so is just fine. There is no need why the Ice mushroom should not just be some kind of stationary fruit. On their design, though, I would suggest to not color them too bright so they don’t fall off the library-and-ruins theme entirely. Don’t make them look as if they are the only interesting point all over the area. For the jewel-coins on the other this seems somehow apropriate as they fit the library theme better by their nature. Pfuh, hard to explain these theming nuances if you are not an English native :-)

Currently, I imagine larger, but not too colorful fruits for the powerups alongside with small, but brightly colored jewels for the coins.

Valete, Quintus

[Bugsbane]

"Currently, I imagine larger, but not too colorful fruits for the powerups alongside with small, but brightly colored jewels for the coins."

I think that sounds perfect. I also like that there is a thematic separation between coins and powerups (ie they're not all fruit)

[datahead8888]

The jewels should probably be smaller than power ups but not TOO small.

Changing mechanics of some power ups will actually help us diverge from Mario. This may break some levels and thus require us to put it in the 3.0 release. We could discuss the risks and advantages of each type of mechanics change, though. The rolling capability gives us a lot of options.

We also might think about creating a new sound effect for jewel collection. Having a coin jingling effect sounds like Mario, still. I could create a task if there is interest in this.

[Quintus]

@Bugsbane I would feel honoured if you could look into replacing our current coins with something like jewels. It would be really nice if we could have something in the 2.0.0 release that already makes a difference to original SMC and thus marks the direction we are heading into.

They don’t have to be exactly sized as the current ones are. Use whatever you find fitting.

Vale, Quintus

[datahead8888]

Long term I think a 3D rotating jewel might be interesting, but 2D might work for now. 2D probably is easier. Quintus is correct that the size can be different, but we will have to be careful not to be way too big or small. We'll have to evaluate their proportions subjectively.

[Bugsbane]

3D's not difficult. In some cases it can actually be easier, especially, when basic rotation/scale/position animation is concerned. Anyway, here's a rough 3d version I ran up (9 frames). The outline would look smoother in the game as animated gifs only have a 1 bit transparency and we use PNG's. I'm also not sure what size we're after, and would adjust the size of the outline (and render) accordingly:

[Bugsbane]

Just as a comparison, to see what the image looks like larger and with the smoother outline, here's a still png. Personally I think that it could use some lighting improvements so the red is a bit brighter, but you get the basic idea:

[datahead8888]

The 3D ones look really good, @Bugsbane.

With a large enough polygon count and a good choice of lighting model / lighting settings, we should be able to get it to look good if we choose to use a larger sized image.

@Quintus - I would assume we can set a scale (sizing) setting from TSC's configurations, correct? I know OpenGL has this, but I have not yet added an image to TSC myself.

If we use a little bit larger image with detail to support it, we can then shrink it to the desired size in the game. This would allow us to experiment in game to see what size works best and potentially change it later if needed.

I'd also be curious to try out some different colors and lighting settings to explore the possibilities. We'll at least need different gems to replace the yellow and red coins.

[Bugsbane]

For a shape like this, poly count isn't really relevant regardless of size. Real world gems are all a combination of a small number of flat surfaces. This model uses a grand total of only 17 faces, which is basically nothing. Lighting and materials do still need some adjustment, but they're not resolution dependent.

For smaller / larger versions typically the stroke width (for the black outline) need to be adjusted, but that's about the only thing that isn't resolution independent already.

I imagine that colourwise maybe instead of red and yellow coins, we could do red and green / blue gems (ie ruby and emerald / diamond).

[datahead8888]

Lighting and materials do still need some adjustment, but they're not resolution dependent.

I was thinking of gourad shading, which probably isn't what you were using. Gourad shading is probably a bit dated, now. Shading is usually done per fragment (pixel) now.

For smaller / larger versions typically the stroke width (for the black outline) need to be adjusted, but that's about the only thing that isn't resolution independent already.

Is it the svg files that scale without quality loss? I understand the png files will lose quality if you make them larger in-game, since they're raster based. I'm probably just not familiar with the workflow for putting svg's to use in the game.

imagine that colourwise maybe instead of red and yellow coins, we could do red and green / blue gems (ie ruby and emerald / diamond).

Rubies, emeralds, and diamonds is an interesting possibility. Long term, it wouldn't hurt to have more than two types of gems in our drafts repository. We can consider adding them to the game later if we think up rules we like for them. We could start our with just two for now to avoid changing the mechanics of the game for release 2.0.

[Bugsbane]

SVG files scale without quality loss, as do 3d files. That said, both often require some modifications for being output at very different sizes, just dues to the way human perception works. This is why icon designers typically create at least a 128x128, a 64x64, a 32 x 32 and a 16x16px svg file rather than just grabbing one and scaling it up / down. You won't get any technical problems just using scaling, but typically the images won't look their best either.

Bitmap formats like png, jpg, gif etc though, have qualitative defects introduced by scaling up (as the information isn't available to generate the extra pixels, unlike with 3d or vector files). Typically artwork in SMC (and other similar games) is made by the artist knowing roughly what size the final output will be and then designing a vector file for that. The vector file (Inkscape SVG's in our case) are used to output bitmaps (PNG's for us) at the size needed. If different sizes are needed, the "quick and dirty" solution is to just output new png's at a different size, however you'll get a higher quality if the vector is designed with the output resolutioni in mind, especially if the output resolution is very small.

[Quintus]

Very nice @Bugsbane! Thank you for your effort, this look nice already. However, I think it is a bit dark... You might want to lighten it up a bit? Do you think it may even be useful to make it a little transparent so one can see through it slightly?

I'm also not sure what size we're after, and would adjust the size of the outline (and render) accordingly:

I think the current coins are too large already, and with jewels this overlarge impression would probably strike out even more if they were as large as our coins currently are. I therefore suggest to use a size smaller than our current coins. That being said, here is the settings file from our current coin:

% cat yellow/1.settings 
width 38
height 38
col_rect 9 6 24 25
author Boder%

That is, the graphics are used at a size of 38x38 pixels, with the collision rectangle (the part you have to touch before the game grants the coin to you) being a bit smaller (col_rect syntax is X/Y/Width/Height).

You can find all information on the different coin graphics used in the game here in the repository.

@Quintus - I would assume we can set a scale (sizing) setting from TSC's configurations, correct? I know OpenGL has this, but I have not yet added an image to TSC myself.

TSC has the ability to rescale by specifying the target size in an image’s .settings file. However, scaling is done from the exported PNG (TSC does know nothing about SVGs, which would be hard due to Inkscape extensions anyway), hence it can only be scaled downwards. If you look at the current goldpiece graphics, you will find they have all been exported with a size of 256x256 to accomodate high resolutions also (SMC does not run everywhere with the same resolution, depending on your graphics card and monitor, and your configuration).

Valete, Quintus

[Bugsbane]

"However, I think it is a bit dark... You might want to lighten it up a bit?"

Yup. That's what I said above. ;P Just getting feedback on the overall concept, before playing around with the colour and lighting more. Everything I do tends to involve many drafts, tweaks and iterations. :)

[Bugsbane]

Is there any way of clearing cached settings files? If I do rebuild image cache from the options > video menu, it updates new png's I've added, but often doesn't seem to change the sizes when I've changed them in a .settings file.

[Quintus]

Is there any way of clearing cached settings files?

Force it.

$ rm -rf ~/.cache/smc

You can do that without being worried, that directory only contains the image cache. Next time you start SMC it will rebuild the image cache.

Vale, Quintus

[Bugsbane]

Thanks. So does that do something different to "refresh image cache"? Also, can we close this issue now?

[Quintus]

Actually I don’t know, but if it does, removing the cache directory will be the best way to force it to regenerate everything.

Do you really want me to close this issue while still experimenting with the jewel sizes as outlined in #210?

Vale, Quintus

[Bugsbane]

Ok, I've changed the size of the coins to a size I think looks good (and updated the settings files with the right colrect, too). From memory the blue ones were 18px, and now they're 23. What's everyone think of this? (Please look at the screenshot full size before commenting)

If everyone's happy with this I'll commit and do a pull request immediately.

[datahead8888]

It looks like you increased them in size slightly, if I saw correctly. It probably does make sense not to make them too large as Quintus said because otherwise [Maryo] would be picking up gems larger than his torso.

In full screen mode they seem fine; in the screenshot in github they seem small. This may be due to human perception as you hinted.

I'll look forward to trying these in-game later with the full rotation animation.

[Quintus]

I think the size is good now.

Vale, Quintus

[Bugsbane]

Ok, I'll commit them. The blue gems had some colrect issues, which I've fixed locally, too. I think there's possibly still an error with the falling colrect of the red gems (the standard settings file is fine), but I don't know that the red gems ever do actually fall, anyway.

[Quintus]

but I don't know that the red gems ever do actually fall, anyway.

I am not aware of any normal situation, but you can achieve that through scripting.

x = FallingGoldpiece.new
x.start_at(100, -100)
x.color = :red
x.show

Vale, Quintus

[datahead8888]

I noticed that when you destroy an enemy, the gems seem to float through the air. We may need to make them move a bit closer to the ground in this case. Flying gems are possible, but they'd need a lot more explanation...I'm not thinking we'd want to go that route.

We also could change it so that they move a little then stop. This would change the behavior as opposed to having them move like Super Mario World.

[Bugsbane]

when you destroy an enemy, the gems seem to float through the air.

That's an error in the settings file, due to the gems being smaller than the coins. I've already fixed it and will be putting in a PR shortly.

[Quintus]

We also could change it so that they move a little then stop. This would change the behavior as opposed to having them move like Super Mario World.

That sounds like a good idea. This is actually a mechanics change and would thus go into devel, but if we aren’t picky about such minor changes, we could do it in the release branch.

Vale, Quintus

[datahead8888]

That sounds like a good idea. This is actually a mechanics change and would thus go into devel , but if we aren’t picky about such minor changes, we could do it in the release branch.

As I said in another ticket, legal issues can potentially trump our feature freeze -- it's more of a question of how difficult the change is, if we agree on it, and if we are willing to go through a bit more beta testing. Obviously for this one we'd also have to decide if it's a legal issue in the first place (though it is the combination of many similarities to Mario games that add up to legal issues).

How tricky do you think getting this to work correctly might be?

We almost could add a "Legal" label in github, but one might argue the "Blocker" label serves the same purpose.

[BodhiPeace]

Playing with the rendering for the gem, for some ideas.

[Quintus]

We will need @Bugsbane’s comment on that :-)

Vale, Quintus

[Bugsbane]

Usually darker outlines make for faster player recognition due to how human perception works. The gems are not either the player or an enemy, so they don't qualify as the most critical for a player to instantly recognize (and thus the black outline). At the same time, they are a high importance item, being something the player actively interacts with, so they could benefit from some kind of darker coloured outline (as they have now).

An internal edge stroke, may increase recognition somewhat, however an internal edge stroke should never have as prominent outline as the external silhouette, as human perception uses outline to identify shapes first, so internal lines with the same level of emphasis just distract. What may work would be keeping a darker coloured outline, with perhaps thinner, white edge strokes.

[Quintus]

Superseded and resolved by #227.

Valete, Quintus