Trying to develop XOR for RnD

[r0lZ]

It's the problem with the game speed that is not restored for player 2 after it has been frozen. See this post.
There might be other similar problems as well, but I haven't really tried to implement XOR with two real players yet, so I'm not sure.

BTW, Holger, I have also noticed a problem with the tapes when playing regular Emerald Mine levels by two human players over a network. It is possible to record a tape, but if you try to reload it with F2, RnD issues an error message and the level is stopped. It would be nice to allow restarting a level with F2 in network mode. (But I don't need that for XOR!)

[r0lZ]

Beta 5 is available here.
[EDIT] File removed. Please use the latest beta! [/EDIT]

I have now played all levels of the Original XOR Mazes set, the two additional mazes, and the first ten levels of the Proscion's Mazes, and all levels are playable, except level 14 of the Original XOR mazes, with the problem reported above about the gem that cannot be collected without dying. I have modified slightly that level so that it can now be played. I will play the last 5 levels as soon as possible...
BTW, I have also modified the priority of the levelsets, as the Proscion set is globally much more easy than the Original set.

But although all levels I have tried are playable, there is still one important bug. Again, it is caused by the complexity of the elements moving horizontally and the way the player is killed. Therefore, this bug will probably be easy to fix with the next release of RnD. Anyway, I would like to fix it in the current version if it's possible. Here it is:

If the player pushes the dolly to the left, the zeppelin moves and should kill him. But the player is not killed during the push operation. So, the result is:

and the player is still alive! Now, if he continues to move to the left, he dies normally.

Note that the same problem occurs if the dolly is replaced by another element that can be pushed horizontally (rock or bomb) and/or if the zeppelin is replaced by an atom, like in this example:



I have tried to introduce yet another intermediate CE, but I have been unable to fix that bug yet.

A similar problem was present in the vertical direction too, but it was easy to fix. IIRC, that fix is the only difference since beta 4 (with the order of the levelsets.)

Zomis?

[r0lZ]

Well, finally I've found a way to avoid the problem reported in the previous post. I had to introduce two new elements amd a lot of new change pages, but it works!

The idea is to create a new invisible element behind the player when he presses an element that can be pushed horizontally (dolly, rock or bomb) from right to left. That invisible element is changed to the empty space as soon as the player leaves it. Therefore, when the player pushes, say, a rock from right to left, he is temporally "protected" by the invisible element that prevents any zeppelin or atom at his right side to move. When the push is done, the player has moved to the left, and the invisible element disappears. The zeppelin or atom is now able to move, and it kills the player. Previously, the zeppelin or atom started to move immediately during the push operation (or at least during the same screen scan, I don't know exactly) and there was still something to its left side that prevented the kill method to work correctly.
I had to create also a new dolly element, as I have now to treat the dolly pushed from left and the dolly pushed from right differently.

I really hope I've found and fixed the last bug. But I thought that already many times!
Unfortunately, 12 tapes are again broken by the timing changes, and I need to record them again.
I will release beta 6 as soon as possible...

[r0lZ]

Unfortunately, my method is incompatible with the way the player and the friend are swapped.

Suppose that the player presses the dolly from the right during a short moment, shorter than the push delay. The invisible element is created under the player, but the player doesn't move. Now, if the player uses the drop key to swap the players, the fuel element is not dropped because there is already something in the player location. The player has to move and come back, and be careful to not press the dolly to be able to swap the players again. This is difficult to accept, and I just came across a case where it's simply impossible.

I suppose that there is no way to drop something in a place already occupied by another element, or to replace the existing element with the dropped element. Right? I have tried to change the "can dig" property, but unfortunately, when an element is dropped, it cannot dig.

I begin to be tired by those problems, so I think I will wait the next beta of RnD to continue the development of XOR. That should be much more simple...

[Zomis]

I suppose that there is no way to drop something in a place already occupied by another element, or to replace the existing element with the dropped element. Right? I have tried to change the "can dig" property, but unfortunately, when an element is dropped, it cannot dig.

No, unfortunately not (at least not yet, maybe in a far distant RnD version this could be possible.
However, I think I've got a much easier solution to your problem, which I hope won't create any more bugs (but who knows?).
The idea I have right now is to simply change the zeppelin/atom to a temporary "Freezed" zeppelin/atom with the same properties, but which can not move. And then just release this zeppelin/atom when the push is finished (which probably would be after 8 frames, or if you can detect it in another way).

I begin to be tired by those problems, so I think I will wait the next beta of RnD to continue the development of XOR. That should be much more simple...

I can understand that, but you're so close now. As I'm saying to my cousin who's starting to learn programming: It takes time. But it's so nice to see the result. You're a programmer yourself, so you know, right?

[r0lZ]

I thought also at a similar method. However, I'm not sure it is possible to detect easily when the push begins and when it ends. Especially, if I detect that an element is pressed, I can not assume that it's the beginning of a push and freeze the zeppelins and atoms, as if the player releases the left key immediately, the push will not occur, and the zeppelins and atoms will stay frozen forever. But it is true that I haven't tested this method yet.

Thanks to your words of encouragement. The fun part in the programmer's job is precisely to find the good way to solve a specific problem. But with a real language, there is usually many ways to obtain the result, and currently I have the feeling that with RnD, there is (perhaps) one way to do the things correctly, but it is very difficult to find it. Maybe it's only because I'm a beginner in RnD's editor programming. Anyway, if you have played some difficult caves in XOR, you know that there is often only one correct way to pick a gem. I really like this kind of challenge, so, yes, I am decided to try again.

[Zomis]

I thought also at a similar method. However, I'm not sure it is possible to detect easily when the push begins and when it ends. Especially, if I detect that an element is pressed, I can not assume that it's the beginning of a push and freeze the zeppelins and atoms, as if the player releases the left key immediately, the push will not occur, and the zeppelins and atoms will stay frozen forever. But it is true that I haven't tested this method yet.

Not if you use simple delays to make the frozen objects return to normal. But then the zeppelin/atom must detect if there's empty space or a player when they return to normal, but I think that's possible (or maybe it's already solved just the way the normal zeppelin/atom work).

Thanks to your words of encouragement. The fun part in the programmer's job is precisely to find the good way to solve a specific problem. But with a real language, there is usually many ways to obtain the result, and currently I have the feeling that with RnD, there is (perhaps) one way to do the things correctly, but it is very difficult to find it. Maybe it's only because I'm a beginner in RnD's editor programming. Anyway, if you have played some difficult caves in XOR, you know that there is often only one correct way to pick a gem. I really like this kind of challenge, so, yes, I am decided to try again.

Yes, this is true. In normal programming, there are many many ways. But in RnD, if you're lucky then there's many ways, sometimes it's one way, and sometimes there's no ways at all. But this is what I think makes "programming" in RnD much more exciting!

[r0lZ]

Well, I have already modified the dolly and spaceship elements to implement your method, and I have good results so far. I have still to modify the rocks, bombs and atoms... and to try the method in real circumstances.

Of course, I had to add again several new CEs, GEs and change pages, as I have to treat the dolly pressed from left and right differently, and I need a new "frozen zeppelin" element. There are so many elements now that my big fear is that I will not be able to understand why I did this or that this way if I need to modify something in the future. So, Holger, a new version of RnD will still be much appreciated, even if I can solve all problems with the current beta!

Now, back to work!

[Zomis]

Of course, I had to add again several new CEs, GEs and change pages, as I have to treat the dolly pressed from left and right differently, and I need a new "frozen zeppelin" element. There are so many elements now that my big fear is that I will not be able to understand why I did this or that this way if I need to modify something in the future. So, Holger, a new version of RnD will still be much appreciated, even if I can solve all problems with the current beta!

CEs, GEs and change pages are just like programming code. You keep on adding, deleting and removing like there's no end of it. Unfortunately, there's no way of commenting your CEs, GEs and change pages.

Hmm...
Change pages are like peices of code
CEs are like functions
And GEs are like arrays

And I'm like off-topic


Looking forward to see if it's actually possible this way, or if you discover any new bugs.

[r0lZ]

Yes, I agree.

I have finally something that seems to work, but as I thought there were also many other things to change to control the rest, as currently, things are so interconnected with each other than changing "a coma in a line of code" has important repercussion in another module!

And again, almost all tapes are broken, so I have to check all levels again. And I'm almost sure that I will again find something that doesn't work as it should. But I should be able to release a new beta soon, and that's the most important...

[r0lZ]

I thought I had finally fixed all problems, so I have re-recorded all tapes, without any hiss. However, I have also tried to solve a level that I haven't played before. And I found another bug!

It is caused by the combination of the method to kill the player when he is hit by an object falling horizontally, the method to freeze the objects when the player presses an object to its top or bottom side (the last problem explained in this thread), and a bizarre behaviour of the player when the game speed is frozen.

Here is the situation:





The player pushes the atom through the tube. As soon as the atom has replaced the tube, the player is frozen, the atom is free to move to the left, and the zeppelin follows it, like that:





Finally, the atom should hit the wall, and it should be hit by the zeppelin:





The atom and the zeppelin explode, and the player can pass through the hole to take the gem:






That works fine if the player releases the down key as soon as the atom starts to move. But if he presses the down key a little bit too longer, he is still pressing it when the zeppelin touches him to his bottom side, like in the second illustration. Although the player is frozen during the move of the elements, he can still press the zeppelin when it passes below him! IMO, that's abnormal. If the player is frozen, he should not be able to do anything, especially with a moving object. Anyway, he can press the zeppelin, and therefore the atom is changed to another CE that cannot move. (I did that this way to solve the problem reported above.) Therefore, the zeppelin continues to move, and hits the frozen atom immediately, causing the explosion too early.





Finally, the hole is not at the right place, and the player cannot continue:






Note that the same problem occurs also if I replace the zeppelin by another atom.

This level demonstrates the problem. It uses the latest CEs.

Currently, I need 12 CEs and 33 change pages to control the behaviour of the atom, and almost the same thing for the zeppelin, plus a lot of change pages in the other elements also to control the atoms and zeppelins! That's really too much! I need only two elements for the bombs and the rocks, because I can use Can Fall and Can Smash Player, and I have no problem with those elements.

I have tried to change the zeppelin to another CE when it is moving. That new element does not trigger the freeze of the atom when it is pressed. But since I need already to change the moving atom to another CE (to kill the player when he is touched by an atom to his right side and then he moves left) my attempt cannot work.

Therefore, I must either:
1. Find another way to kill the player when he is hit by an atom or zeppelin,
2. Find a way to prevent the player to press an element when the game speed is frozen,
3. Find a way to prevent the player to press a moving element,
4. Wait a new version of RnD with some kind of support for "Can Fall Left".

I'm now convinced that the last solution is the only one that can work without problem! I can't spend all my free time on those problems. Furthermore, there are some other minor problems (such as a too long push delay due to too many CE changes when the user pushes an atom or zeppelin) that will be fixed also if I can use a simpler method, similar to the method currently used for the rocks and bombs.

Holger, any hope to have a new beta relatively soon?

[Holger]

> Holger, any hope to have a new beta relatively soon?

Oh well. I better don't promise anything at the moment. :-o

Currently I have nearly no free time due to my new born son! I'm happy when I don't miss too much sleep (better to say that I'm happy when I get any sleep at all). Not to think about programming! I hope (and think) this will get better with time, but I don't dare to do any forecast... :-o

I'll try to get at least a new beta version out that contains some of your requested changes before christmas... :-/

[r0lZ]

Thanks, and congratulations!

BTW, maybe I've found a new way to kill the player.

Since, when a zeppelin or atom can move left, there is an empty space to its left, I have added a change page in those elements that creates a non-walkable invisible CE to the left side of the element each time it hits an empty space. The zeppelin or atom can dig that invisible element, therefore it is not blocked. And the new element is placed with an extended change target, replaced when walkable. Since the player is considered as walkable (!), if the zeppelin or atom hits the player, the new element is created under the player, and the player dies. That was somewhat more complex, as I have to treat things differently when the player pushes an element to the left, but it works!

Of course, the method can work only because there are no walkable element in XOR (except the player), therefore this method is not universal at all, but it works in this case.

I have still to modify some things, but with the new method, I have suppressed 9 CEs, 1 GE and a lot of change pages! And I don't need any more to freeze the element when the player pushes something to the left, and most of the last problems reported in this thread are solved!

Of course, I will have to play all levels again to be sure that everything works as expected, but I'm more or less confident. Anyway, things are much more simple now, and I can again understand what I do! I have again the feeling that I can improve things instead of creating more and more complex and interrelated change pages, impossible to manage correctly! I'm happy!

[Zomis]

Gratulations, r0lZ!

Are there any news about XOR for RnD? Any new beta?

[r0lZ]

Yes! I have probably a bug-free version now! I'm just finishing to replay some levels, and I haven't noticed any problem yet. The method explained in my previous message was a good idea, although it was more difficult to control everything than I thought.

I will probably post a new beta tomorrow...