Turn frequently-used “special level objects” to core objects

[Wuzzy2]

A couple of customized objects seen in levels are used repeatedly in levels and I think they should be made into core objects (=directly addable in editor, no or almost no modifications required). Reasons:

• Unified names
• Unified collision polygons
• Unified tooltips
• Unified/default properties
• Default size (instead of each level probably using a different size xD)
• Less redundancy
• Easier to add in editor

Objects in question:

• [x] Flower*
• [x] Toy chest
• [x] Goal
• [x] Cola crate
• [x] Crates and boxes
• [x] Styrofoam blocks
• [x] Peg (aka “Something weird”, seen in Petanque level). Not used very often, but can be useful

* = Problem: Scenery or RectObject? Butterfly Race uses Scenery because I didn't know then that other levels use RectObject.

[kaa-ching]

I did the toychest. The Goal needs to follow a similar approach. Cola Crate, the other crates and boxes and the styrofoam are just plain RectObjects and should be easy to add to that file.

I need to think about flower. It's actually two objects and I've used the daffodil as illustration in a few levels as well.

[Wuzzy2]

Thanks for that. Is it intentional that the new toy chest is movable now? In Bouncing Balls the chest seems to be pushed around pretty easily; the bowling balls can even topple it over. xD

Edit: Yes, the chest needs more tweaking. The collision polygon also looks somewhat crude to me. Probably not a big deal for large levels but could be noticable in smaller levels like Bouncing Balls. Also, its default ZValue is 2. :-( As the chest is now, I honestly prefer the scenery + invisible RectObject hack. ;-)

[kaa-ching]

Haven't changed the zvalue yet - that requires a code change that I need to do for the upcoming seesaw changes anyway. But to answer your other question: yes, my intention it to make it movable. as you can see in the above commit, fixing it to the world is easy :smile:

[Wuzzy2]

Okay, I can wait. I don't want to rush you. :-)

[Wuzzy2]

I'm not really happy about the chest being movable by default. Its only (!) purpose in levels so far is to mark the goal area and the goal is like “put stuff in chest”. For those levels which use the chest as a container/goal marker, it almost certainly breaks the level design if the chest can be moved by just an inch. If it is possible to push the chest around, things get very confusing. If the player moved the chest, and still puts all stuff into it, its no victory anymore, because the goal area did not move along with the chest. And “moving targets” are not a thing in TBE. I also don't like the idea of “fixing it in the level” because this creates object inconsistency (in some levels you could move the chest, in some levels you can't, that's confusing as there is no visual distinction).

I also think it looks kinda lame to see the chest being toppled over because of the static hatch.

On the other hand: Do you have any use case (i.e. level idea, even just a vague one) for a movable chest? Right now, the dominant (and only) use case I see so far is as goal marker.

Same goes for the goal, because it is also used as a goal marker exclusively.

[kaa-ching]

Hi Wuzzy, I would be really dumb if I wouldn't listen to my number one level designer. Interestingly, it is even worse - I haven't been thinking it through. While it is true that I have a level with a moving chest in mind, it doesn't matter. Any object without mass is automatic stationary, any object with mass is subject to gravity. So we can both have what we want :wink:

[kaa-ching]

Once @Wuzzy2 has signed up as an organization member, I'm going to assign this ticket to him/her :smile:

[kaa-ching]

enjoy :smile:

[Wuzzy2]

Well, I don't know if I could handle all this, but I can do a part of this issue at least. The RectObject things are certainly possible for me, but I am not so sure about the PolyObjects. Although I managed to make CardboardBox and made the polygon for it, I more or less got it right with lots of trial and error, to be honest. I did not fully understand how the Polygon attribute works, the coordinate system seems to be very WTF. Like, I make little changes to just one point, then the collision polygon moves in a weird way. Want to say hello in IRC? (#tbe on irc.freenode.net)

Flower still needs discussion.

[Wuzzy2]

I tried to implement the cola crate as ColaCrate with this definition in src/model/RectObject.cpp:

static AbstractRectObjectFactory theColaCrateFactory("ColaCrate",
        QT_TRANSLATE_NOOP("AbstractRectObjectFactory", "Cola Crate"),
        QT_TRANSLATE_NOOP("AbstractRectObjectFactory", "A crate of 12 filled cola bottles.\nIt's very heavy and hard to push around."),
        "cola-crate", 0.85, 0.6, 18.0, 0.1,
        "Friction:0.1/");

The numeric values are taken from Coconut instead of Cola. However, this ColaCrate does not behave like the cola crate RectObjects in that level. ColaCrate seems to use the default bounciness rather than 0.1. Also, friction does not seem to be used either. This may be related to #169.

[Wuzzy2]

Done.