Rocks'n'Diamonds

Thanks for your positive answer, Holger!

As you have certainly read, I've modified the genial solution of Zomis so that it works in *almost* all cases I need. But when I think I have finally found THE method, something gets broken somewhere else. And the complexity of the current method makes it difficult to find why something doesn't work. So, I would be very grateful if you can implement one of the solutions above (and even more grateful if you can implement several solutions!)

> Adding a "deadly when hitting player" option (that includes that the CE was
> moving before hitting the player) would be very, very useful, and would
> add to the existing "deadly when" options in an orthogonal manner.
About that first solution, please note that I need to kill the player only when he is hit by a moving element, exactly like the "can smash" option. The option will be useless for me if the player is killed as soon as he is touched by an immobile zeppelin or atom.


Another thing. I suppose that you have already noticed the problem, but I prefer to report it anyway.
When you play a tape and pause it (either with the "pause before end" or manually) and then you start to record from that point, there are often synchronizations problems at the joint and when you replay the final tape, it doesn't replay the things exactly like at record time, and the tape is often broken. I have noticed that, at least with XOR, that problem does not occur when the pause is exactly between two moves of the player (in other words, just before a new cycle of 30 frames.) Maybe delaying the pause until all frames of the current cycle are played is sufficient to solve the problem. Is it possible to test that in a beta? Currently, I have to replay the same levels again and again to test my modifications, and I cannot use the pause+record safely. I'm becoming crazy! Thanks in advance for looking at this problem as well.

> So, I would be very grateful if you can implement one of the solutions
> above (and even more grateful if you can implement several solutions!)

I'll try to add as much as possible!

> About that first solution, please note that I need to kill the player only when
> he is hit by a moving element, exactly like the "can smash" option. The
> option will be useless for me if the player is killed as soon as he is touched
> by an immobile zeppelin or atom.

Of course, yes! What you described is more or less what "deadly when colliding with" does for such elements, which is certainly not what is desired in many cases. So such a "deadly when hitting" should indeed work just like getting smashed from above by a falling object, but from any direction.

> Another thing. I suppose that you have already noticed the problem, but I
> prefer to report it anyway.
[tape appending problem]

Many others also had/have this problem, and I was able to reproduce this once or twice (I think). So far, I wasn't able to find (or fix) the cause for this sporadic problem. :-O

It seems to me that this problem only occurs when you *manually* append to tapes (using the tape recorder buttons for recording, pausing, playing and forwarding), but *not* when using the key shortcuts F1 (quick tape save) and F2 (quick tape load), which also use appending (but don't work for some cases like yours, where you want to replay, say, the second half of a tape due to changes in the level or CE definitions that only occur in the second part of the level).

Can anybody acknowledge or disprove this observation?

I think you're right. Appending to the end of the tape seems to work always. I use F2 very often and IIRC I never had problems. But using features such as pause before end to truncate an existing tape is dangerous.

XOR v0.3 beta is available.
[EDIT] File removed. Please use the latest beta! [/EDIT]

I think I have fixed most problems now, but I'm still not sure.

Anyway, I will now wait the next RnD beta to continue, as it should be really simpler to program exactly what I need.

Possible bug found in level 3, Original XOR Mazes





In this puzzle, walk down and then right to get the two diamonds.




Walking up from here causes the two Zeppelins to move left, and then the rock falls down.




Here the Zeppelin starts to move left, hitting the player. But the player does not die.

Maybe this bug is already known to you, and related to the <element hitting player> change condition?

What is the intended XOR Behavior in this situation?

Yes, I have noticed that bug recently, in level 10. It happens in very precise circumstances, difficult to describe.

In XOR, the behaviour or the elements is related to the direction of the moves of the player. For example, when the player moves down, the zeppelins and atoms have precedence over the rocks and the bombs. So, in a situation like this one



the zeppelin protects the player when he moves down, and in this situation:



the rock protects the player when he moves left!

To simulate the same behaviour in RnD, I have to use the normal or reverse scan mode. Since I can't check the direction of the moves of the player, I have to use a trick to understand how he can move and set the scan mode accordingly. I do that by checking if the player touches on his left or bottom side an element that he cannot push, collect or dig (like the wall in my examples above.) That elements sets the scan mode as it should be.
That works fine, I think.

However, note that in this case:



the precedence is unpredictable (or, more precisely, it depends of the last "solid" element that the player has touched.) But that's not a problem, as in this case, the player must die anyway, as there is no way to escape without being hit by one of the two moving elements.

The default scan mode is reverse, but in your example, it is changed to normal because the player touches the wall with his foots, and the rock has to fall before the zeppelin. And in this case ONLY, the player is not killed by the zeppelin. I haven't understood why yet, but as you have noticed, the problem is related to the way the player is detected with your (slightly modified) method.

I have not tried really to fix this bug, as it should disappear anyway when I will be able to smash the player in a more standard way, with the next beta of RnD (hopefully to be released soon.)


Note also that I have fixed two little problems in the latest version, not released yet. When the player uses a teleport, the number of moves should be increased by one, but that was not the case. Similarly, when the player is swapped with his friend, two moves were counted instead of one. That was easy to fix.

BTW, I'm already very happy with the current version of the game. I think that the bug you have reported is the only one that persists, and there are less problems than in the Windows version of XOR. There are also tapes available on the net for that game, and I use them to verify if the behaviour of my version is identical. In some cases, I've found important differences! But strangely, playing the Windows version is mush more easy, and you don't need to use a lot of elements. Strange! So, I have verified the behaviour of the game in those strange situations with the Amiga version, and indeed the players who have recorded the tapes have exploited some important bugs of the Windows version. My version is much more compatible with the original... and much more difficult to play, as it should!

r0lZ wrote:To simulate the same behaviour in RnD, I have to use the normal or reverse scan mode. Since I can't check the direction of the moves of the player, I have to use a trick to understand how he can move and set the scan mode accordingly. I do that by checking if the player touches on his left or bottom side an element that he cannot push, collect or dig (like the wall in my examples above.) That elements sets the scan mode as it should be.
That works fine, I think.

Actually, it IS possible to detect in which direction the player moves. Use a CE with the change condition "Change when Move of <player 1> at left side", then it will ONLY trigger the change when the player moves left. "Move of" is one of the rare cases where it actually works to have a player element as the condition element.

Anyway, I managed to fix the bug that I encountered, it wasn't really that hard at all... just adding another temporary CE (like there isn't enough of them already...) solved the situation. Take a look at this updated file: http://www.zomis.net/rnd/download.php?id=695

r0lZ wrote:BTW, I'm already very happy with the current version of the game. I think that the bug you have reported is the only one that persists, and there are less problems than in the Windows version of XOR. There are also tapes available on the net for that game, and I use them to verify if the behaviour of my version is identical. In some cases, I've found important differences! But strangely, playing the Windows version is mush more easy, and you don't need to use a lot of elements. Strange! So, I have verified the behaviour of the game in those strange situations with the Amiga version, and indeed the players who have recorded the tapes have exploited some important bugs of the Windows version. My version is much more compatible with the original... and much more difficult to play, as it should!

Well, you really should be happy about it I must say that I'm impressed in how fast this development has went.

Zomis wrote:Actually, it IS possible to detect in which direction the player moves. Use a CE with the change condition "Change when Move of <player 1> at left side", then it will ONLY trigger the change when the player moves left. "Move of" is one of the rare cases where it actually works to have a player element as the condition element.

I haven't noticed that yet! Thanks!
However, I'm not sure it will work as expected, because the right scan mode must be set as soon as the player moves. I have read that the scan mode is updated only after a complete scan of the whole playfield, and I understand that it's necessary. So, maybe the old scan mode will be used when the player starts to move. My method changes the scan mode before the move of the player takes place. But I will try also the "Change when Move of <player 1> at left side" condition. If it works, that will be safer than the current method.

Zomis wrote:Anyway, I managed to fix the bug that I encountered, it wasn't really that hard at all... just adding another temporary CE (like there isn't enough of them already...) solved the situation. Take a look at this updated file: http://www.zomis.net/rnd/download.php?id=695

Thanks! I will have a look...

Zomis wrote:I must say that I'm impressed in how fast this development has went.

With your help!
I have learn a lot of things, and without you, Holger and the other guys who have helped, I would probably still be wondering if adapting XOR to RnD is possible!

OK, XOR beta 4 is available here.
[EDIT] File removed. Please use the latest beta! [/EDIT]

I have used your new zeppelin element and created a similar atom element to kill the player. I had to modify the delay (from 4 frames to 1 frame) as the original delay caused some problems in some cases. The explosion of the atoms and bombs hit by the zeppelin in some circumstances was not working any more. But now everything seems to work fine, and I think it's the first time that a new element with a delay did not break some tapes!

I have also modified slightly some things.

I use now another element to display the walls. The current version looks less similar to Emerald Mine.

Also, I have replaced the diamonds by emeralds (just because the GUI shows the number of emeralds, and not the number of diamonds.)

There are however still some diamonds (max 4 per level.) They are not like regular emeralds. You have to take all emeralds, but you don't have to take the diamonds to complete the level, but they give you a bonus of 10 points. The reason for the presence of the diamonds is that, in the original game, there are 4 map elements that I haven't implemented. When you collect a map, a quarter of the maze is displayed in a little window. This is very useful in the original game, as the visible portion of the playfield is very small (8x8), and you have to touch the border to scroll the playfield. Therefore, without the maps, it is very difficult to know where you are in the maze. Since I cannot implement the little window with the map in RnD, I cannot create those map elements. But I cannot simply ignore them, as they are often necessary to stop a moving element, for example. So, in the previous version, I have replaced them by gems and that worked fine. But I have played a level where one of those maps cannot be collected! (It's because you have to do a quarter of that level in the dark, and they don't want to help you with the map.) Therefore, it was not possible to complete that level, as one gem was missing to open the door. Now, if you can't take a map/diamond, you lose a bonus, but you can open the door.
Note that, if you play one of your tape, the final score is not identical than in the previous versions, as collecting a diamond gives you 10 points instead of 1.

I have also tried to use the "Change when Move of <player 1> at left side" condition to change the scan mode. However, that doesn't work. As I suspected, the change takes place only during the next screen scan, and the elements touching the player start to move immediately, using the old scan mode. I have also tried to anticipate the necessity to change the scan mode, as, usually, when the player has to move down to escape, that means that he has moved up just before. Therefore, I thought that inverting the left/right and top/bottom directions could be sufficient, but again that doesn't work well.
I think that it might be possible to use the method if we can force the moving elements to start moving only at the next screen scan, but that would require the addition of new elements and conditions, and they will probably break something else.
Since my current method works (almost) correctly, I'm not going to change it, at least for now. Maybe, with the next beta of RnD, if it is possible to dramatically reduce the number of CEs and conditions, I will try again. I would like to be able to implement it, as currently, there are still some problems with my method. For example, if you replace the walls in the examples I have given above with gems, my method doesn't work (as I cannot consider the gems as "solid" elements, and the player can decide to escape by the way he took to come, or by collecting a gem.)

I have also tried to grab the original graphics of the Amiga, but unfortunately, they are too small (24x24 pixels instead of 32x32) and scaling the images gives an horrible result. So, I think I will not change the graphics.

BTW, I have still a little problem with the sounds. I have created a soundsinfo.conf file to add sounds to some events, and that works fine. The original classic sounds are still used when I have not redefined them, and that's fine. But I had to copy some sounds file in the folder containing the soundsinfo.conf file, or RnD cannot use them. Since there are 3 different levelsets in XOR, I have to copy the whole directory with the sound files 3 times. And the sound scheme appear 3 times in the custom artwork menu. Not a big deal, but I wonder if it is possible to define the sound scheme only once, and reference it in the two other levelsets. I know that it's possible if I install the sounds in the RnD installation folder, but I would like to leave them in the levels folder, as it is easier to install them. Someone can help?

I will now try to play the 20 levels I haven't played yet (and that's a lot of work!) And if I can play them without problem, and if Holger can release a new official version of RnD, I will probably release the first final version of XOR. I'm still interested in your tapes if you can beat my scores...

Unfortunately, I have still two important problems.

In level 14, this is the end of the way followed by one player:





It is easy to take the emerald at the right side, but it is impossible to take the other emerald without dying!
It's not really a problem in the original game, as, when a player dies, the other can continue, and only one player must escape by the exit door.
But in my implementation, the game ends as soon as one of the two players is killed. I did that this way simply because I have been unable to transfer the control to the other player (the "friend") when the real player dies. Changing the "friend" by the real player is possible when the explosion of the real player occurs, but unfortunately the game is stopped anyway, as the game engine detects that the only real player has been killed, and apparently assumes that it's the end of the world!
Is it a way to force the player to reappear somewhere after his dead?

The other problem is probably possible to fix, but in my implementation, I will have to change a lot of things.
The problem occurs when the "friend" explodes:




Move down to take the fuel, and stay at that place. Then swap the players with the drop key. Now, move left. The rock falls on the bomb, the bomb explodes and kills the friend. So far so good. But the main player should die also (or continue to live but without being able to swap the players again, as explained in the previous post.)

However, the player continues to live, but he cannot move any more (because the game speed, controlled by the friend element, is not restored to normal.) OK, that's not really smart, but that's not so important, as the player cannot continue to play. However, if you use the drop key, the friend reappear beneath the player, the player can move again, and there are again two players alive on the playfield. That's unacceptable.

I haven't found a way to fix this problem yet.
Any idea?

OK, I've found a solution for the second problem. Now, when the friend explodes, the main player is also killed. That's better than nothing.

But I have still the first problem. I can, of course, modify the level 14 so that it is possible to take the last emerald without dying, but I would like to try to implement exactly the same behaviour than in the original game.

1. Currently, when the friend dies, the player dies also, and the game is over. Normally, the player should not be killed, and the game should continue normally with one player only.

2. Similarly, currently, when the main player dies, the game is over. Normally, in this case, the main player should die, but the friend should be replaced by the player so that, again, the game can continue with one player.

I have two problems to do that.

1. When the friend dies, I can easily avoid to kill the player. But the player has still the fuel element, and he can drop it to recreate the friend. Therefore, I need to remove the fuel element that is in possession of the player so that he cannot swap the players any more. (Replacing it by another element doesn't work. Only the elements that are in the playfield are replaced, and not the elements in the possession of the player.) Since the fuel is the only thing that is collectible and droppable, I would like to know if it is possible to empty the collection of objects that the player owns, or if I can force the player to drop his fuel element so that I can change it to the empty space when it is on the playfield.

2. When the main player dies, I am unable to transfer the control to the friend. I can replace the friend by the player, but he is inactive because the game engine has detected that the only real player in the playfield has been killed. It is perhaps possible to swap the players just before killing him so that it's the friend that is killed instead of the real player, but in this case I am back with the first problem.

If I can't find a solution for those problems, it's not very important. In this case, I'll modify level 14. (Anyway, the Amiga version of this level seems to have a bug. One element is different than in the original CBM64 version, and apparently it's sufficient to make the level unplayable. Therefore, I have to modify it anyway.)
But if a better solution exists, I would like to implement it. Thanks in advance for any help!


[EDIT] I've found an inelegant method to avoid problem 1. Since, when the friend has been killed and the remaining player drops the fuel, the friend appears beneath the player, I can add a change page in the friend CE with "Element changes to [empty space] when [player leaves] element [friend]". The friend effectively disappears when the player moves, but it disappears only when the player has completed his move, and the friend is therefore visible during the move of the player. Not a good solution at all, but it works... almost!
That method introduces another problem. For example, when the friend has been killed and the player is under a rock and presses the drop key, the friend appears beneath him. When the player moves down, he should be killed by the falling rock, but the presence of the friend during his move blocks the rock. Therefore, that method is not good.

r0lZ wrote:Is it a way to force the player to reappear somewhere after his dead?

I thought this was possible:
CE changes to Player 1
When explosion of Player 1

However, it seems like this wasn't possible. I think it was possible in an earlier version though Holger?

I think it's possible to avoid the second problem (not being able to switch players after second players death) by using a temporary CE (with graphics like "empty space") which detects if friend is alive somewhere, if it is alive then it changes to the friend. If not, then it changes to empty space.

Thanks for the tip. I will try that.
I suppose that detecting if friend is alive must be done by detecting if he touches something? Right? But I think that detecting if an element touches something works only when something changes. And I suppose also that I will need to test also if he touches an empty space, as the empty space is not considered as "something". Right?

Anyway, without a fix for problem 1, implementing the solution for problem 2 is useless...

Oh, yeah, Holger! I would like also to do a version for two human players. However, with the current behaviour of player 1 only being usable in some conditions (as reported earlier), I can't do that. Can you also have a look at that problem?

r0lZ wrote:I suppose that detecting if friend is alive must be done by detecting if he touches something?

Nope, you can make the friend element change to itself every 0 frames. And then using two pages on another CE: 1. Change to self when change by page of <friend ce>. 2. Explode when delay 1 frames.

When that other CE explodes, friend is not alive anymore.

r0lZ wrote:Oh, yeah, Holger! I would like also to do a version for two human players. However, with the current behaviour of player 1 only being usable in some conditions (as reported earlier), I can't do that. Can you also have a look at that problem?

Could you tell me/us which problems appear when having 2 players?