Replace the powerup graphics

[Bugsbane]

With something not from the Mario games. This includes:

The red "size" mushroom The green "1 up" mushroom The poison mushroom The Blue "ice" mushroom The grey "ghost" mushroom The fireflower The invincibility star item The moon item

Not sure if each of these should be their own issue or not. Feel free to split it up if so.

Side note: We're not releasing 2.0 until we've gotten rid of the items copied from the SMB games, right? If so, then could we get bugs that deal with replacing these assets (like this one) labled as blockers to make it easier to see what to work on next? Thanks.

[Bugsbane]

Current work on replacing mushrooms with fruit, as per previous discussions.

"Size" mushroom replacement:

"Ice" mushroom replacement:

Fire flower replacement:

They look a bit weird sliding around at the moment. Code to make them roll instead (similar to Army) would be appreciated. :)

[datahead8888]

I really liked the "Flamey cherry berries" from #103 -- it just seemed like something I've never seen before in a game.

If we use these, my suggestion would be to add some sort of flame to the fire flower replacement and some kind of frost or ice to the ice mushroom replacement.

We also could stylize the blossoms on the top of the ice plant a bit more (making them look like they have a layer of ice or something like that) if we keep them on the plant.

[Bugsbane]

I'd like to see flames especially on the fire fruit. I'd just need someone to add the code and tell me what to name the files. I held off on this because the code wasn't there, so I couldn't see how it looked and tweak accordingly.

[datahead8888]

It certainly is possible to write code for fire. I could look into this later if there's interest. I had assumed we'd use sprites for the fire, but something using particle systems or a similar technique actually might be better. Sprites might work for now, though.

Unfortunately, we cannot write code for fire (or any graphics effects) until issue #105 is resolved. Otherwise we will be adding to our OpenGL conversion workload. We also will have to put new graphics effects like this in a different release, since the code is frozen for release 2.0 (with respect to features).

[Quintus]

Side note: We're not releasing 2.0 until we've gotten rid of the items copied from the SMB games, right? If so, then could we get bugs that deal with replacing these assets (like this one) labled as blockers to make it easier to see what to work on next? Thanks.

Yes.

t certainly is possible to write code for fire. I could look into this later if there's interest. I had assumed we'd use sprites for the fire, but something using particle systems or a similar technique actually might be better. Sprites might work for now, though.

The fireflower is animated already by using fire particles on it. The code generally employs a particle emitter for doing such things. We can easily do the same for these yummy berries. Therefore,

Unfortunately, we cannot write code for fire (or any graphics effects) until issue #105 is resolved.

doesn’t hold true.

Vale, Quintus

[Bugsbane]

The fireflower is animated already by using fire particles on it.

Soo... do we need >1 frames for the firefruit or not? I have just the one now, but can do more if needed. The current fireflower already has 3 frames: standard, looking left and looking right. Not sure under which conditions those frames are shown though.

[Quintus]

The frames are just played in order slowly to make it look animated. As the current fireflower doesn’t move as the mushrooms do, you could add frames to make the berry look as if shifted slightly by the wind. It could then be hung on those bushes we already have in the game, and it would look quite natural I guess.

We might want to discuss something similar for the other berries also, though that of course is a mechanics change and thus something for later versions.

Vale, Quintus

[Bugsbane]

Latest draft, from left to right, top to bottom: 1 up, poison, gost, size ice, fire 1, fire 2, fire 3

[Quintus]

They look great. The fire berry looks really cool.

Am I right in that apart from the fire berry, these are all intended to be rolling fruits? @datahead8888, what do you think in changing at least the mechanics of a few of them so that they don’t move but rather just stay in place so you can hang them somewhere? Or wait... I have an IDEA... We could have both variations! There is nothing to stop us from creating a variant that rolls, and another one that can be hung somewhere. The rolling one is the one we will do in the 2.0.0 release (no mechanics change), and the other one can be added in devel.

The fire berry looks basically ready I think. I would like to test it in-game, can you post the SVG(s)?

For the other berries: It would be nice if you provided a few more frames so that we don’t have to use "programmer art" to make them roll by just rotating the image. I am sure it would look weird when the leafs do not react to being pushed to the bottom...

Vale, Quintus

[datahead8888]

Do we still want to apply the existing in-game fire code effect @Quintus mentioned to the fire berry, or do we want to do it with sprites?

There isn't an in-game ice code effect, is there?

It would be cool if we implemented transparency and/or used the Ghost [Maryo] graphics code effects on the ghost berry.

@datahead8888, what do you think in changing at least the mechanics of a few of them so that they don’t move but rather just stay in place so you can hang them somewhere?

There are exceptions to all rules, including our feature freeze. Legal issues potentially trump it. It's just a question of how difficult it is to code things like this, if everyone is in agreement, and if we're willing to go through a bit more beta testing for it. We at least need something different than always having the size power up moving towards you and the fire power up staying still --- that is what will make people accuse us of being a Mario-clone.

[Quintus]

There isn't an in-game ice code effect, is there?

Employing the particle emitters in code, it can easily be added. Really, particle emitters are very nice to use from the C++ code.

Vale, Quintus

[datahead8888]

My other feedback is to stylize the purple flowers on the ice berry a bit more (more shading and/or an ice layer, etc). Other than that I think they look good (though if we use in code ice/fire effects we may have to change the sprites again).

[Bugsbane]

Ok, I've just done a pull request with them basically as they are in the image above, just to get them out to you all. Then we can look at any modifications from there. At the moment, my thinking is that all of them except the fireberry roll, to keep level gameplay working with the current levels. I like the idea of having still, hanging versions later, but after we've gotten 2.0.0 out.

I will add shading to the ice flower. The iceberry itself already seems to have some particle effects on it (it trails some grey crosses).

[datahead8888]

There are exceptions to all rules, including our feature freeze. Legal issues potentially trump it. It's just a question of how difficult it is to code things like this, if everyone is in agreement, and if we're willing to go through a bit more beta testing for it. We at least need something different than always having the size power up moving towards you and the fire power up staying still --- that is what will make people accuse us of being a Mario-clone.

It just occurred to me that changing when power ups move and doesn't move "may" have a chance for breaking level designs. For example, if someone built a level that required you to have a mushroom move towards you and fall down from a higher area, you may be unable to retrieve it. A mushroom may let you jump a little higher. We had discussed only doing level breaking changes in 3.X releases, but the question is how likely this actually is to break levels.

Other than that, I would lean towards introducing a few small mechanics changes so as to support @Bugsbane's graphics swaps. I just want to put an end to the Mario clone accusations. Big changes such as the life system for [Maryo] taking damage obviously should not go in version 2.0. Adding small mechanics changes probably will delay the 2.0 release date, so we should all consider this carefully.

[Bugsbane]

Right now I think we need to just get 2.0.0 out as quickly as possible, with all of the mario assets replaced, but keeping the current mechanics in place. After that, we can take a bit more time to examine changes in the mechanics more carefully to see where they may cause breakage.

All my current graphics were designed, assuming the current mechanics (ie firefruit isn't really designed to roll, the other fruit more or less are, just as the fireflower is still but the mushrooms move). I've been careful to make sure that my graphics don't actually require any changes in code or mechanics (although rolling animation would be nice).

[datahead8888]

Someone on a forum once said, "If you want to get attention, release early and release often." I think it was a Super Tux forum - they have been going for even longer than we have without a release (and we have waited about 5 years). Releases are the bloodline of a project and what draw new people to it.

I agree we should forget the small mechanics changes in this release, suggest we only include graphics changes that eliminate Mario-isms, and suggest we follow Quintus's advice of deciding which bug fixes are actually high-priority for making the game seem functional to users.

The decision that I think should be made more carefully is when to move from the 2.X series of releases to the 3.X series because that is when old levels become unusable. That is a discussion for another day, though.

[Bugsbane]

Agreed.

If we're going to make old levels unusable for 3.0.0 though, then we'll really need to look at making the level editor easier to use to encourage people to use it before then. What we have now isn't too bad, but it has a couple of issues, like not giving people any guidance on the controls (even a hint when starting it saying "Push F1 to see the keyboard shortcuts." would help). It could also really use snapping to help align things, and a draw mode to let people quickly fill in areas. Also changing the wording from massive / semi-massive / passive / front-passive etc to something like solid / semi solid / background / foreground would help new users understand the concepts quicker.

You know what, I'll put this in an issue, and we can discuss it later for 3.0.0.

[datahead8888]

We probably need to have a discussion in the mailing list, forum, and/or a github ticket to decide which tasks are needed for release 2.0. This would include Mario music swaps and deletion, Mario graphics swaps and deletion, bug fixes, and of course set up for the new web site. We could then make sure only tasks that are actually needed show the release 2.0 milestone. github will then show us exactly how close we are to a release. Some new tasks may get added if we find new critical bugs or Mario assets we missed, but it will be a good metric.

[Bugsbane]

Sure. My suggestion above was for somewhere between 2.1.0 and 3.0.0, not for now.

[Quintus]

Superseded and resolved by #227.

Valete, Quintus

[SonOfBowser]

There's still some old powerup images in https://github.com/Secretchronicles/TSC/tree/devel/tsc/data/pixmaps/ground/castle_1/statue/objects

[Quintus]

There's still some old powerup images in https://github.com/Secretchronicles/TSC/tree/devel/tsc/data/pixmaps/ground/castle_1/statue/objects

Yeah. @Bugsbane suggested to determine an Inkscape filter to easily convert regular objects into statues. After that has been done, we could replace the statue objects also.

Vale, Quintus