MININIM 0.10

A free software implementation of Prince of Persia 1.

Moderator: English Moderator Team

User avatar
Norbert
The Prince of Persia
The Prince of Persia
Posts: 3169
Joined: April 9th, 2009, 10:58 pm
Contact:

Re: MININIM 0.10

Post by Norbert » December 22nd, 2016, 7:10 pm

oitofelix wrote:
Norbert wrote:I'll read through the specification.
Looking forward to your feedback.
Seems all right.
Will the document mention the assigned modifier/random/foreground/background combo (for backwards compatibility) for each standard item profile?
I think it's the right choice to not include aesthetics in the list of standard item profiles.

User avatar
oitofelix
Wise Scribe
Wise Scribe
Posts: 202
Joined: February 17th, 2016, 1:59 pm
Contact:

Re: MININIM 0.10

Post by oitofelix » December 22nd, 2016, 7:26 pm

Norbert wrote:Seems all right.
That's good. :)
Norbert wrote:Will the document mention the assigned modifier/random/foreground/background combo (for backwards compatibility) for each standard item profile?
I don't see why not. Those are closely related with the specification (motivation and purpose), furthermore, it's best to keep all that info together. It's useful info for everybody involved (modders and developers). The legacy format is in some sense a format everybody has to deal with.

We can put the assigned codes next to each reference standard item profile.

Code: Select all

 88888  FFFFF Bruno Félix Rezende Ribeiro (oitofelix) [0x28D618AF]
 8   8  F     http://oitofelix.freeshell.org/mininim/
 88888  FFFF  mailto:oitofelix@gnu.org
 8   8  F     irc://chat.freenode.org/oitofelix
 88888  F     Please, support my work: http://oitofelix.freeshell.org/funding.html

Falcury
Wise Scribe
Wise Scribe
Posts: 337
Joined: June 25th, 2009, 10:01 pm

Re: MININIM 0.10

Post by Falcury » December 22nd, 2016, 7:45 pm

oitofelix wrote:Falcury, instead of describing in detail what those potions do, as I've asked you to, please, read the specification (checking the "Reference standard item profiles" section) and in case those potions aren't exactly covered by it, tell me why.
It must have been quite some work to put that together.
I haven't yet read everything thoroughly... but yeah, looks quite OK. Regarding the potions for Secrets of the Citadel specifically:

BONUS_POTION
Seems good, except that REMAINING_TIME should maybe be an implementation-defined amount, rather than being fixed at 3600 ticks / 5 minutes?
It so happens that in my mod, I added a second functionality to this potion, and the potion now has a subtly different effect depending on the game mode:
(bit of a spoiler warning)
Spoiler: show
In the new version of the mod, unless players play in a special 'time attack' mode, the time limit for the levelset has essentially been removed. So, time will run 'forward' (with periodic messages like "5 MINUTES PASSED"). This makes the originally designed bonus potion effect somewhat less useful. Initially, the bonus potions would still decrease the amount of minutes that had passed, but in the end I decided that it would be more fun to just make them do something different. So I added a second functionality that makes them act as a kind of 'collectibles' that are accumulated throughout all of the levels, and could be used as a condition for triggering stuff at the end (e.g., special events). Note that the original behaviour of the potion is also retained in the mod; it's just that the bonus potions will only replenish time if there is actually a time limit in place.
CUSTOM_OPEN_POTION
Yeah, the way you defined ACTIVATE_ALTERNATIVE correctly describes how I'm using that potion to activate gates. (I didn't think about being able to close level doors though!)
However, ACTIVATE: (8,0,0) is not actually the effect in the mod. It so happens that there was another reason (not yet mentioned) why I decided I needed to add another open potion. So I think I should specify what I wanted to achieve a bit more:
Spoiler: show
I didn't just want to activate a single trigger at (8,0,0), but I wanted to create a way to have multiple potions in the same level open different gates. The way I did this was by coupling the trigger link ID with the room ID that the potion has been placed in. I made the mapping as follows: potion in room N triggers link (100 + N). (To avoid conflicts with already linked IDs, I didn't want to use the lower range of the link IDs; people would tend to use these the most extensively.) The only limitation of this would be that all potions in the same room would map to the same trigger link ID, but this was not a problem in my use case so I left it this way.
About using the random bits in combinations:
I still think that from a user's standpoint, tile ID + modifier is enough 'complexity' to be thinking about when placing tiles in an editor. The less mental overhead the better, right?
Of course the random bits wouldn't have to be disused entirely, but they might maybe be best used for specific states of tiles that a modder would not usually place (e.g. specific frames of an animation)?

User avatar
oitofelix
Wise Scribe
Wise Scribe
Posts: 202
Joined: February 17th, 2016, 1:59 pm
Contact:

Re: MININIM 0.10

Post by oitofelix » December 22nd, 2016, 11:34 pm

Falcury wrote:It must have been quite some work to put that together.
Indeed. Two days of work.
Falcury wrote: BONUS_POTION
Seems good, except that REMAINING_TIME should maybe be an implementation-defined amount, rather than being fixed at 3600 ticks / 5 minutes?
The profiles in the "Reference Standard Item Profiles" of the specification are meant to document exactly how reference implementation define their respective standard items. The idea is that it's more of a convention as you have suggested earlier in this thread. In principle the idea of implementation dependence doesn't apply there, because people doesn't need to implement those specific standard item profiles. The question of implementation dependence only arises in the abstract sense of not standardizing aesthetics (there are no problems with conventions, though) and for fully compliant implementations in the sense of requiring them to implement all possible standard items. Perhaps this should be clarified on the specification. Thus, the remaining question is: what's the true value of TIME_COUNT (see below) for the "Secrets of the Citadel" mod?
Falcury wrote:It so happens that in my mod, I added a second functionality to this potion, and the potion now has a subtly different effect depending on the game mode:
(bit of a spoiler warning)
Spoiler: show
In the new version of the mod, unless players play in a special 'time attack' mode, the time limit for the levelset has essentially been removed. So, time will run 'forward' (with periodic messages like "5 MINUTES PASSED"). This makes the originally designed bonus potion effect somewhat less useful. Initially, the bonus potions would still decrease the amount of minutes that had passed, but in the end I decided that it would be more fun to just make them do something different. So I added a second functionality that makes them act as a kind of 'collectibles' that are accumulated throughout all of the levels, and could be used as a condition for triggering stuff at the end (e.g., special events). Note that the original behaviour of the potion is also retained in the mod; it's just that the bonus potions will only replenish time if there is actually a time limit in place.
I have a proposal to make that potion a legitimate standard item. First we remove the attribute REMAINING_TIME. Then we add these three immediate effect attributes to the specification:
  • TIME_COUNT: integer N. Subject to TIME_COUNT_MODE.
    • N > 0: adds (subtracts, resp.) N frames to (from, resp.) time count, in case the current time count mode is limited (unlimited, resp.).
    • N < 0: subtracts (adds, resp.) abs(N) frames from (to, resp.) time count, in case the current time count mode is limited (unlimited, resp.)
    • N == INT_MAX: enables time count.
    • N == INT_MIN: disables time count.
    • N == 0: does nothing on this regard.
  • TIME_COUNT_MODE: enumeration.
    • LIMITED: If true, and the current time count mode is unlimited, TIME_COUNT is ignored, otherwise does nothing on this regard.
    • UNLIMITED: If true, and the current time count mode is limited, TIME_COUNT is ignored, otherwise does nothing on this regard.
    • BOTH: does nothing on this regard.
  • COLLECTIBLE: boolean. If true, increments collectible counter, otherwise does nothing on this regard.
Then the BONUS_POTION (which we should really call SC_BONUS_POTION, or something less generic because it has a quite specific meaning) standard item profile becomes:
  • LIFE_POINT: -1
  • TIME_COUNT: (value I've asked you for)
  • TIME_COUNT_MODE: LIMITED
  • COLLECTIBLE: true
By the way, I'm not sure if the attribute LIFE_POINT is right. Does the kid die if he drinks that potion with only one life point? I'm wondering this because you originally used the term: "trading in 1 max life point" which to me sounds like it might have some connotative meaning.

Notice that with these modification we are implicitly requiring fully compliant implementations to implement both notions of time count and an collectible item counter: limited and unlimited. I personally think that is a good thing, since it feels to me quite natural to expect these feature. In particular, as Norbert said, it's the right choice for aesthetics to be implementation-dependent, because this way implementations may choose more meaningful graphics for collectibles.

What do you think about these modifications? Do they now fully express the item you've defined?
Falcury wrote: CUSTOM_OPEN_POTION
Yeah, the way you defined ACTIVATE_ALTERNATIVE correctly describes how I'm using that potion to activate gates. (I didn't think about being able to close level doors though!)
(emphasis mine)

Interestingly enough, we are discussing exactly this here. What do you think about standardizing construction semantics?
Falcury wrote:However, ACTIVATE: (8,0,0) is not actually the effect in the mod. It so happens that there was another reason (not yet mentioned) why I decided I needed to add another open potion. So I think I should specify what I wanted to achieve a bit more:
Spoiler: show
I didn't just want to activate a single trigger at (8,0,0), but I wanted to create a way to have multiple potions in the same level open different gates. The way I did this was by coupling the trigger link ID with the room ID that the potion has been placed in. I made the mapping as follows: potion in room N triggers link (100 + N). (To avoid conflicts with already linked IDs, I didn't want to use the lower range of the link IDs; people would tend to use these the most extensively.) The only limitation of this would be that all potions in the same room would map to the same trigger link ID, but this was not a problem in my use case so I left it this way.
You did make a smart hack there! :P However, I propose a more general way of solving this problem. We can add the following immediate attribute to the standard item profile specification:
  • EVENT: integer N.
    • N > 0: triggers open event N-1.
    • N < 0: triggers close event abs(N)-1.
    • N == 0: does nothing regarding this.
What do you think?
Falcury wrote: About using the random bits in combinations:
I still think that from a user's standpoint, tile ID + modifier is enough 'complexity' to be thinking about when placing tiles in an editor. The less mental overhead the better, right? Of course the random bits wouldn't have to be disused entirely, but they might maybe be best used for specific states of tiles that a modder would not usually place (e.g. specific frames of an animation)?
Regarding the codes assignment for the legacy level file format, as I said before, I think I'm not in a rightful position of claiming that I know what's best. My opinion is that provided I present the situation and my concerns clearly enough, thereafter I should trust your and Norbert's judgment. What do you think about this issue, Norbert?

Code: Select all

 88888  FFFFF Bruno Félix Rezende Ribeiro (oitofelix) [0x28D618AF]
 8   8  F     http://oitofelix.freeshell.org/mininim/
 88888  FFFF  mailto:oitofelix@gnu.org
 8   8  F     irc://chat.freenode.org/oitofelix
 88888  F     Please, support my work: http://oitofelix.freeshell.org/funding.html

User avatar
Norbert
The Prince of Persia
The Prince of Persia
Posts: 3169
Joined: April 9th, 2009, 10:58 pm
Contact:

Re: MININIM 0.10

Post by Norbert » December 23rd, 2016, 2:29 am

We have:

foretable * backtable =
rr * m * ccccc * backtable =
random * toggle * group * modifier =
4 * 2 * 32 * 256

As I understand it, we can use 64 groups (2 * 32).
Of those, at least(*) 33 are already taken, namely:
- toggle = 0, with 32 groups (example: 0 with 0x0A = potion)
- toggle = 1, with 1 group (just: 1 with 0x0B = stuck loose tile)
(*) The original game randomly sets the toggle to 1 all over the place. I/we would have to run a script/program to see if any groups with toggle set to 1 are truly unused. Mods can always be modified, but we should not try to work around (any version of) the original game.

Then we have the modifier (256) to come up with variations within these groups.

This leaves random (4) to specify something that impacts all things in the accompanied 'toggle * group * modifier': random * 1 * 32 * 256
So far, random is only used by MININIM with 'toggle * 1 * modifier', to create floors that become visible when touched.

Given the scarcity of available combos, and the ability of level editors to hide what's happening under the hood, as I see it, the user's standpoint should be irrelevant. Nevertheless, unless something applies to all group+modifier combos, the random bits should not be used.

By the way, there are probably some tiles that are part of the legacy format, and that are used in some mods, that are not yet included in MININIM. They are documented in this PDF. To summarize, ignoring the weird-looking tiles:
- The wall group with modifiers 0x00 and 0x01 (included in level editors)
- The free group has the additional modifier 0x02 (included in level editors)
- The chomp group has several additional modifiers (not included in level editors)
- The exit left group has several modifiers (not included in level editors)

However, most of the stuff above doesn't matter.
Because all we need to do is, if someone complements the legacy format, agree on a suitable combo.
And we're already mostly there, I think.

Probably start with a wiki page, to list all legacy tiles and what we've added to it so far.
Then if we think it's complete, we'll just release it as a document.
After that, all we need to do is keep it up to date.

User avatar
oitofelix
Wise Scribe
Wise Scribe
Posts: 202
Joined: February 17th, 2016, 1:59 pm
Contact:

Re: MININIM 0.10

Post by oitofelix » December 23rd, 2016, 4:39 am

Norbert wrote:By the way, there are probably some tiles that are part of the legacy format, and that are used in some mods, that are not yet included in MININIM.
Why do you say that? I came across that document before releasing the first version of MININIM. If I recall correctly, I've implemented all of them, except for the "weird looking" tiles. (which in my opinion don't deserve the title of "tile").

Code: Select all

 88888  FFFFF Bruno Félix Rezende Ribeiro (oitofelix) [0x28D618AF]
 8   8  F     http://oitofelix.freeshell.org/mininim/
 88888  FFFF  mailto:oitofelix@gnu.org
 8   8  F     irc://chat.freenode.org/oitofelix
 88888  F     Please, support my work: http://oitofelix.freeshell.org/funding.html

User avatar
Norbert
The Prince of Persia
The Prince of Persia
Posts: 3169
Joined: April 9th, 2009, 10:58 pm
Contact:

Re: MININIM 0.10

Post by Norbert » December 23rd, 2016, 11:16 am

oitofelix wrote:
Norbert wrote:By the way, there are probably some tiles that are part of the legacy format, and that are used in some mods, that are not yet included in MININIM.
Why do you say that? I came across that document before releasing the first version of MININIM. If I recall correctly, I've implemented all of them, except for the "weird looking" tiles. (which in my opinion don't deserve the title of "tile").
Oh, nice. :) Perhaps my statement came across as me underestimating your thoroughness, which was not my intention. The word "probably" wasn't the right pick, I should have used "possibly" or, even better, have checked (playtested with) MININIM. Yes, it makes sense to ignore the 'weird' tiles.

David
The Prince of Persia
The Prince of Persia
Posts: 1511
Joined: December 11th, 2008, 9:48 pm
Location: Hungary

Re: MININIM 0.10

Post by David » December 23rd, 2016, 6:11 pm

Norbert wrote: Of those, at least(*) 33 are already taken, namely:
- toggle = 0, with 32 groups (example: 0 with 0x0A = potion)
- toggle = 1, with 1 group (just: 1 with 0x0B = stuck loose tile)
(*) The original game randomly sets the toggle to 1 all over the place. I/we would have to run a script/program to see if any groups with toggle set to 1 are truly unused. Mods can always be modified, but we should not try to work around (any version of) the original game.
Those are not really random.
The bit was set to 1 by Mechner's level editor for those tile(position)s where the tile(type) below requires floor/wall above.

I think I wrote about this, but I can't find where...

User avatar
Norbert
The Prince of Persia
The Prince of Persia
Posts: 3169
Joined: April 9th, 2009, 10:58 pm
Contact:

Re: MININIM 0.10

Post by Norbert » January 1st, 2017, 7:56 pm

David wrote:Those are not really random.
The bit was set to 1 by Mechner's level editor for those tile(position)s where the tile(type) below requires floor/wall above.

I think I wrote about this, but I can't find where...
Ah, yes; here.

User avatar
Norbert
The Prince of Persia
The Prince of Persia
Posts: 3169
Joined: April 9th, 2009, 10:58 pm
Contact:

Re: MININIM 0.10

Post by Norbert » January 2nd, 2017, 6:31 pm

Norbert wrote:Probably start with a wiki page, to list all legacy tiles and what we've added to it so far.
I've created a first, rough draft:
http://www.princed.org/wiki/Legacy_combos

I still need to search for all the combos where Mechner set the bit mentioned in the post above.
When I'm done with that, I'll edit the wiki article and post about it.
[Edit: modifier bit info here. I've added it as a possible TODO in the "General information" section of the wiki article.]

Post Reply