talpa wrote:I just subscribed because I wanted to share a levelset I originally built in 2004 and never put online.

Congratulations on your level set! I do very much like your levels design. :-) Well constructed, clean, and challenging, without resorting to the use of obscure bugs.

I found however a problem while playing it in MININIM. The video below demonstrates the problem.

The issue is that a closer floor is used to open a level door. This semantic is not expected by MININIM, where level doors, like normal doors, are closed by them.

This is a symptom of a more general problem: the lack of standardization on the semantic of constructions. Until now I wasn't aware of this specific instance of the problem, and believe me, I should have been.

I'd like to start a discussion with the modding community, specially implementation[0] developers (David, Falcury, Norbert,...) about how we can tackle this problem.

I was intrigued by the prince's ability (shown in the video) of flip in the air and grab, because it would frustrate my efforts to start the level losing a life
But I think that's a feature of MININIM too... I tried it in the DOSBox and doesn't work, while in MININIM clearly so.

As for the "original" choice of using a closing button for the level door, it was because the idea behind that room was that 2 of the 3 buttons should entrap you, and you shouldn't be able to distinguish which based on graphic appearances...

Norbert wrote:The default close button construction can open level doors, which MININIM does not yet account for.

What are the exact conditions in which a closer floor opens or closes a level door in legacy code?

Norbert wrote:Tackling this problem in the short term involves a (hopefully) simple modification of MININIM.

Except for the fact that I'd like to avoid losing the adequate semantics of a closer floor, closing a level door.

I'm more inclined to consider the "medium" and "long" term solutions. What about testing MININIM against existing mods and collecting all semantic deviations strong enough to render existing mods unfinishable? (Or even potentially unfinishable, given the situation at hand is reasonably realistic.) Then we can find a middle ground and agree on the correct semantics, hopefully for the majority of cases. In the potential cases we come to an irreducible disagreement, we can document them and make a guide for writing portable mods. What do you think?

Last edited by oitofelix on December 22nd, 2016, 7:57 pm, edited 1 time in total.

talpa wrote:As for the "original" choice of using a closing button for the level door, it was because the idea behind that room was that 2 of the 3 buttons should entrap you, and you shouldn't be able to distinguish which based on graphic appearances...

In MININIM that calls for a feature called (generalized) fake constructions, where you can make any construction (tile) look like any other. Then, you could have disguised an opener as a closer floor. The video below demonstrates how it works.

By the way, I found another difference in semantics regarding the automatic closing of level doors when starting a level.

By a quick inspection of SDLPoP's code, it seems that it searches the room of kid's start position, top to bottom, left to right, for the first level door it can find and assume that to be the level door the kid came from, and then closes it.

MININIM, on the other hand, expects the level door to be located at the kid's start position, because after all he's supposed to be coming from there since he starts there.

This makes no difference for the original level set, where both methods coincide. However in this mod (Twisted Ideas) the difference is noticeably at the start of the second level.

This surely isn't a fatal difference, because it cannot render a level unfinishable, as far as I can see. But these are the sort of thing that would benefit from discussion and standardization of a common semantics.

[David, maybe some posts should be moved away from this thread. I can imagine the mod's author might prefer discussions about standardization and MININIM take place elsewhere.]

oitofelix, SDLPoP replicates the original game's behavior. The original game's behavior is set in stone. SDLPoP isn't pursuing the same thing as MININIM is. This means trying to mold or standardize things until all mods play in all implementations is a futile exercise. Since it is your implementation that is moving away from the original game, and mods are currently primarily being created and playtested with DOSBox, you are bound to run into more semantical differences. Things that complement the legacy behavior and format, such as replay files and new constructions can be standardized. Other things, in my opinion, can not.

As a newbie, my first thought is that mininim is interesting because it allows new things, but for the same reason, it requires ad hoc levelset.
For example, since mininim changes the behaviour of movements, from one hand you can think of rooms that you can pass only with mininim, but on the other hand, you can think of rooms that probably you can't pass with mininim. For example, my mod requires the "jump up" to adjust a little bit your position for the following movement, while in mininim I understand jump up whitout grab doesn't move.
You can think of other movements, combat situations, etc where the behaviour will be too different.

It's interesting but it almost feels like a different variation of the game.

And, for sure, in this topic I would prefer to hear your comments on my levelset, what you like, what you don't, if it's easy or you have troubles...

Norbert wrote:oitofelix, SDLPoP replicates the original game's behavior. The original game's behavior is set in stone. SDLPoP isn't pursuing the same thing as MININIM is. This means trying to mold or standardize things until all mods play in all implementations is a futile exercise. Since it is your implementation that is moving away from the original game, and mods are currently primarily being created and playtested with DOSBox, you are bound to run into more semantical differences. Things that complement the legacy behavior and format, such as replay files and new constructions can be standardized. Other things, in my opinion, can not.

Norbert, I think I was misinterpreted by you, or didn't express myself clearly enough. I have no intent or hope to change SDLPoP. I've already stated that I clearly see how MININIM and SDLPoP differ in their philosophies, and that's all fine: different philosophies, noble goals. For instance, I have no problem with the idea of implementing a "--legacy-semantics" switch to make all legacy mods work as intended on MININIM. That would be a very good thing. I think people would like it. I, myself, would enjoy it pretty much. Your, David's, Falcury's expertise on the legacy code would be a source of invaluable help for me in doing so. Please, don't get me wrong.

Said that, what I'm calling for is standardization of semantics for non-legacy implementations and standardization of semantics for the legacy implementation, so it's easy for developers to implement both behaviors, which can and must coexist. I want to avoid a future where each non-legacy implementation diverges so much, to the point of not being possible to meaningfully share level sets. On the other hand, I want a future with a richer and powerful semantics, free from the constraints of the legacy one.

PS:

talpa wrote:And, for sure, in this topic I would prefer to hear your comments on my levelset, what you like, what you don't, if it's easy or you have troubles...

Oitofelix, for my general knowledge, how can you show 4 rooms? (haven't found it described in pdf).

Seeing your solutions, definetely I think that playing with mininim alters fundamentally the functioning of my levelset. I think it is worth of levels made ad hoc, but if you want to experience the true feel for which my Twisted Ideas was born, you should instead play with something that reproduces legacy features exactly. For example:

Level 1, room 1, you shouldn't be able to avoid losing the first life.
Level 2, first guard: you shouldn't be able to jump through him
Level 2, the guard that gives the name "jump into my arm", if you make the action described in your video in a traditional emulator (like DosBox) the guard will kill you. Instead, you should find the exact positioning for the jump via the "jump high" adjustments that your player has disabled as a "bugged" feature.
Finally, level 2 you skipped an extra life; then again, you were able to run through the last guard, that I couldn't in a traditional emulator.

I'm not (no longer) a forum moderator and I certainly don't want to come across as playing down the interestingness of some posts here, but would like to suggest posting walkthrough videos on the "Walkthrough Videos" board, and, as I suggested, I do think it would be a good idea to move several posts related to MININIM away from this thread. Also, the post made at 6:46 pm, 6 minutes after the previous post, which was by the same author, embeds the complete video that explains how to create fake tiles in MININIM. I think editing that previous post and including just a link would've been sufficient, but this is just my personal opinion.

talpa wrote:Level 1, room 1, you shouldn't be able to avoid losing the first life.

For those who doesn't like MININIM's special movements, I've implemented the "--movements=LEGACY" switch, which disables them. I'll continue to use them for my walkthroughs and encourage people to do the same, though.

talpa wrote:Level 2, first guard: you shouldn't be able to jump through him

Indeed. I thought about it and I considered it a general MININIM bug. It has been fixed. Trying to jump through a guard puts the kid in fight mode.

talpa wrote:Level 2, the guard that gives the name "jump into my arm", if you make the action described in your video in a traditional emulator (like DosBox) the guard will kill you. Instead, you should find the exact positioning for the jump via the "jump high" adjustments that your player has disabled as a "bugged" feature.

I don't consider the use of such obscure side effect good level design. Furthermore, it doesn't prevent the player from progressing. Thus, in my opinion, MININIM does it better.

talpa wrote:Finally, level 2 you skipped an extra life

That's because MININIM's traditional running jump momentum wasn't enough to get there. I considered this another general MININIM bug and fixed it.

Besides the general fixes described above, in order for level 3 to be finishable in MININIM, I've expanded the legacy semantics to include:

No cross-room guard sights

Constrained running turn

Infinite life for level 3 guards

By the way, I improved the jump and running jump hang animations which often missed 1 frame when used against walls, resulting in a jumpy animation.

Norbert wrote:I'm not (no longer) a forum moderator and I certainly don't want to come across as playing down the interestingness of some posts here, but would like to suggest posting walkthrough videos on the "Walkthrough Videos" board, and, as I suggested, I do think it would be a good idea to move several posts related to MININIM away from this thread.

That was good suggestion. Thanks.

Norbert wrote:Also, the post made at 6:46 pm, 6 minutes after the previous post, which was by the same author, embeds the complete video that explains how to create fake tiles in MININIM. I think editing that previous post and including just a link would've been sufficient, but this is just my personal opinion.