Rocks'n'Diamonds

Well, I had a quick look, and indeed it works. However, I have still some problems. IMO, they can be avoided by using other CEs when appropriate, but that's not as easy as it sounds.

1. If I define the dolly to be able to dig the tubes, it digs the horizontal tube also when it is pushed vertically, and vice-versa. It should, for instance, dig the horizontal tube only when it is pressed horizontally. I can probably change that using a "main dolly" that cannot dig anything, and by changing it to another CE that can dig the horizontal tube only when it pressed horizontally, but, as I said, it's not as simple as it sounds.

2. I am unable to stop the dolly by changing it to itself when it hits a tube, as you have suggested. It digs all tubes until it hits another element. Seems that the diggable elements are not considered as "something". Again, I can probably use a dolly that cannot dig anything during the free moves, and replace it by a "digging dolly" when it is pressed.

3. Mainly a cosmetic problem, but currently, the tube disappears when the dolly is pushed for a very short duration (in fact it disappears as soon as the dolly is pressed.) So, if the player releases the key quickly, the tube is gone, but the dolly and the player have not moved. That's not what I need for XOR. I can easily change that by setting the push delays to 0, but that implies that the user must press the keys carefully. The push delay is a good thing to avoid mistakes. So, if it's easy to do, I would like to have the diggable element disappear only at the end of the push delay, when the pushed element moves really.

Anyway, that's already really simpler for me, so I can live with those limitations. Thanks again!

I will try to re-program the elements using the new features, and report later if I find other problems. But I need some time...

ad 1:

This sounds indeed a bit tricky. My first thought was "just change the dolly CE when it touches the appropriate tube type, but of course it's not that simple as the dolly can touch tubes at the left and bottom, for example, so it seems that this can indeed only be applied when actually trying to push in a certain direction.

ad 2:

> Seems that the diggable elements are not considered as "something".

They are! And it should work that way. I have a test level like this:



And the following things work fine:
- push the dolly
- dolly moves until it hits the first tube, _without_ digging it, but it just stops at it
- push the dolly again
- the dolly digs the first tube and stops, if the player stops pushing
- push the dolly again
- the dolly digs the next tube, and so on
- after digging the last tube, the dolly continues moving until it hits something

My test CEs work like this:
- tube CE: Just a vanilla CE that looks like a tube
- dolly CE: another vanilla CE with only the following modifications:
1. CE is "[x] [pushable]" (I haven't changed the push delay)
2. CE "[x] can move [when pushed]"
3. CE "can dig: <tube CE>"
4. CE "[x] element changes to: <self> after/when" "[x] [hitting something]"

(At point "4.", you can also use <dolly CE> instead of <self>.)

This works for me as you described it (if I did not miss anything).

ad 3:

Ouch! This is a nasty bug! Of course the element that "can dig" should not dig anything when it does not move at all! Fixed! Please try this updated binary:

http://www.artsoft.org/RELEASES/win32/r ... 071031.zip

(2) and (3) should work now, and (1) is hopefully solvable by some clever CE programming, too! :-)

1. Yes, I agree. It's what I've tried to do. That should work. Will try again.

2. Indeed, it works. I'm not sure why I haven't been able to do it, as I think I have done exactly what you describe. Maybe I forgot to change something, like the tube being defined as diggable. Sorry.

3. Yeah! Your new version does exactly what I need. Thanks!

OK. Back to CE programming! I think it will work fine now...


I have still the other important problem with the player not being recognized as a standard element. Without that, it is impossible to kill him when he is hit by a zeppelin or an atom (atom = bomb falling from right to left.) It is easy to do what I need for the rocks and the bombs with the "can fall" and "can smash [player]" options, but they work only for falling objects. I need something like "can smash [player] when hit at his [right side]". (Or at any side, as those elements can not hit the player in another direction, except when they are pushed.) Another approach would be to add change page to the player elements, but I'm not sure it's easy to do. Anyway, this is the last important problem to solve for XOR.


BTW, I would like also to define sounds when the zeppelins and atoms hit something at the right side, like the bombs and rocks for the top side. Currently, they are completely silent. I have tried to modify the soundsinfo.conf file, but I don't know how to define sounds for specific CEs. Is it possible to associate a sound with a change page of a CE? Can I just copy the standard soundsinfo.conf file in the levels directory and use the classic sounds, with some additions, or should I create a completely new sounds scheme?
Of course, that's not very important, as that has no impact on the playability of the game.

OK. I have been able to program the dolly with only 3 CEs and 2 change pages per CEs. Previously, I needed 12 CEs with up to 8 change pages per CEs, and the result was not satisfactory. Great!!!

I will now reprogram the rocks, bombs, zeppelins and atoms, as they can also be pushed in the tubes. I will certainly have something much more simple and easy to understand and modify.

BTW, I've found a little bug. I think it has already been reported.
If I use a "+3" ref (or similar) in the "can dig" field, it is not taken into account. I have to use an absolute reference.
Also, when swapping two CEs (the two tubes) the "+/-N" refs are not updated accordingly in the other CEs.
Not a big deal.

OK, I have finally a first working version of XOR.

You can download XOR v0.1 beta here.
[EDIT] File removed. Please use the latest beta! [/EDIT]

And don't forget that you need RnD version 20071031 or more to play XOR! You can download the beta I have used to built the XOR world here: http://www.artsoft.org/RELEASES/win32/r ... 071031.zip


There are 3 levelsets in the package. The first two levelsets (15 levels each) are official levels, converted from the Amiga version of the game.
The third levelset contains only two levels. The first one has been created by an user, and the second one is a modified version of the last level of the first levelset, called "The Decoder". When you will have played the original level, you will understand why I have modified that level.

I think all levels are playable, but I have played only eight of them. (The solution tapes are included.) I can't be sure that everything can be played exactly like in the original game, so, if you are stuck in a level, please let me know. I'm also interested by your solution tapes, and by your comments and suggestions. (BTW, I still don't know how to define sounds for the CEs. Is it possible?)

IMPORTANT:
There is still the annoying problem of the zeppelins and atoms that are still harmless when they hit the player. I can't find a workaround for this problem. Therefore, it is possible to "cheat" and to continue to play when you have been hit by a zeppelin or an atom. I have added a little demo level to explain this bug. See level 3 of the last titleset. If someone can find a workaround for this problem, please let me know. Thanks!


Holger, can I hope a solution in a forthcoming RnD beta?
IMO, there are several solutions possible, but they require some modifications or additions in the game engine.

1. You could add an option "Deadly when [hitting player]". IMO, it's the best solution, but I don't know if it is easy to implement.

2. The problem doesn't exist for the rocks and the bombs, because they are falling down, and I can use the "Can fall" and "Can smash [player]" options to do exactly what I need. So, another solution could be to define an optional direction for the falling elements. If I could have an option like "Can fall [left]", I could use "Can smash player" when the CE smashes the player at his right side. If the default direction is "down", the compatibility with existing levels is probably assured.

3. A variant of the previous solutions could be to enable the "Can smash player" option even if the "Can fall" option is not enabled. Currently, in this case, "Can smash" is ignored. If "Can smash player" is ticked but not "Can fall", you could assume that the CE can smash the player from any direction.

4. As previously suggested, recognizing the player in the change page conditions will certainly be sufficient to program what I need. But you have explained that it's not easy to do.

5. I'm not sure if it's possible, but adding change pages to the player elements is also a possible solution. This way, I could add a change page to detect that the player has been hit by a deadly CE, and kill him. But it's probably not the easiest solution to implement!

There might be other solutions as well. Holger, could you envisage to implement one of them? Thanks in advance!

Nice to see a beta, r0lZ

r0lZ wrote:BTW, I would like also to define sounds when the zeppelins and atoms hit something at the right side, like the bombs and rocks for the top side. Currently, they are completely silent. I have tried to modify the soundsinfo.conf file, but I don't know how to define sounds for specific CEs. Is it possible to associate a sound with a change page of a CE? Can I just copy the standard soundsinfo.conf file in the levels directory and use the classic sounds, with some additions, or should I create a completely new sounds scheme?
Of course, that's not very important, as that has no impact on the playability of the game.

Yes, this is possible. I'm not a soundsinfo.conf expert, but take a look at levelsets such as BD2K3, see how that soundsinfo.conf looks like. You can also use Alan's great tool ConfEdit to write your soundsinfo.conf file.

I've started playing the XOR levels now, and I've got some questions.

1. Will there be specific XOR graphics later on?

2. If you push a zeppelin, and there's a zeppelin to the right of the zeppelin you've pushed, should the player die?



--->




I really hope Holger will implement one of your solutions to the Zeppelin kills-player-problem so that you can continue to work on these CEs!

3. How to solve this area of the second map (without being hit by a Zeppelin)?
Or are all gems not needed?
I don't know how to get the lower left one here without being hit by the Zeppelin on that row.








By the way, I guess the answer to question number 2 is "No".


4. Is snapping allowed in XOR?
If not, there is actually a way to prevent snapping with CEs.

Thanks for your help. I will have a look at the BD2K3 soundinfo.conf file.
I have just installed ConfEdit yesterday, but honestly I think it's an enormous work to understand how to use it just to add some sounds. Maybe I'll use it if I decide to design new worlds...

I have currently not the intention to make new graphics for XOR, as the current graphics are good enough. But I agree that new graphics are good to inform the user that the behaviour of the elements is different than the original one. Maybe I'll do that later, if I have some time, and if the game has some success. (BTW, IMO, XOR is one of the best logic game concepts I know. There are very few elements, and they are extremely simple, but the difficulty of some levels is astonishing!)

Zomis wrote:2. If you push a zeppelin, and there's a zeppelin to the right of the zeppelin you've pushed, should the player die?

No. The zeppelins, atoms, rocks and bombs have all the same behaviour. They kill the player and his friend when they hit them, but they are harmless when they touch them. Therefore, it is always harmless to push something to take its place. But take care at the chain reactions, as pushing an element can free another one, and that element could be dangerous.

Just remember that you cannot move left when you are touched at your right side by a zeppelin or by an atom, as this element will follow you and (theoretically) kill you (unless there is a rock or a bomb on your head that will fall down before the zeppelin or atom and prevents it to follow you.)

Zomis wrote:3. How to solve this area of the second map (without being hit by a Zeppelin)?
Or are all gems not needed?

You have to take all gems.

You can have a look at the solution tape. I have played this level.
But you have to take the gem at the right side first, then the one at the bottom left, then the bottom right and move up. Finally, you can enter the tube at the top left to take the last gem.

Zomis wrote:4. Is snapping allowed in XOR?
If not, there is actually a way to prevent snapping with CEs.

Oops! No, you can't snap in XOR! I forgot to change that.

How do you inhibit snapping? You have to modify the properties of the player element, or of the gem CE?

I really think that some graphics should be added to make it more comprehensive what the elements do. But of course, it's easy to learn just after a few minutes of playing. How do the original XOR graphics look like? I'm sure it's not equal to the RnD graphics, right?

r0lZ wrote:How do you inhibit snapping? You have to modify the properties of the player element, or of the gem CE?

There is no easy option for this. So you'll have to change the Diamond CE.
It should NOT be collectible (since this allows snapping)
And then a CE page:
- Element changes to Empty space
- when entered by player
- CE Action: Set needed gems - 1

I think that should be enough to make it work.


By the way, believe it or not... I think I'm close to a solution on the "hitting player" problem. I'm trying to implement it in a XOR level right now.

Zomis wrote:I really think that some graphics should be added to make it more comprehensive what the elements do. But of course, it's easy to learn just after a few minutes of playing. How do the original XOR graphics look like? I'm sure it's not equal to the RnD graphics, right?

Well, the original version has odd graphics, and, of course, they are really outdated. But the Amiga version is not so bad. However, the graphics are embedded in the executable, and I don't know how to retrieve them (especially without losing the animation.)

Zomis wrote:There is no easy option for this. So you'll have to change the Diamond CE.
It should NOT be collectible (since this allows snapping)
And then a CE page:
- Element changes to Empty space
- when entered by player
- CE Action: Set needed gems - 1

I think that should be enough to make it work.

Well, I've just tried that solution, and it works, byt there are several drawbacks. No sound (again! but that's certainly possible), and the score is not incremented. I suppose that the score can be incremented by using another change page that is triggered by change of page 1 of the same element. Anyway, that's not very important, as you don't gain score points when collecting the gems in the original XOR game (but I like that feature, as the number of points during the game shows you how many gems you have collected so far.)

Zomis wrote:By the way, believe it or not... I think I'm close to a solution on the "hitting player" problem. I'm trying to implement it in a XOR level right now.

Wow! What's the idea? I thought I've tried everything possible, without success...

>Well, the original version has odd graphics, and, of course, they are
>really outdated. But the Amiga version is not so bad. However, the
>graphics are embedded in the executable, and I don't know how to
>retrieve them (especially without losing the animation.)

It should be possible somehow... is it possible to play on PC? Then there's probably some graphics grab functionality which either can extract the graphics from the executable directly, or which can record the graphics from the screen.

>Well, I've just tried that solution, and it works, byt there are several
>drawbacks. No sound (again! but that's certainly possible), and the
>score is not incremented. I suppose that the score can be incremented
>by using another change page that is triggered by change of page 1 of
>the same element. Anyway, that's not very important, as you don't gain
>score points when collecting the gems in the original XOR game (but I
>like that feature, as the number of points during the game shows you
>how many gems you have collected so far.)

Yes, there's drawbacks. The graphics is also looking a little odd (before, it was an animation which changed the diamond from big to smaller and made it disappear, now it's just from diamond to nothing).
You can add score by copying the first page and then just change the CE Action on the other page.
And I forgot one thing, the CE has to be walkable for this to work.

>Wow! What's the idea? I thought I've tried everything possible, without
>success...

The idea is to use a loooong workaround. But as long as it's possible, it works I haven't finished the implementation yet though.

Ok, here's the workaround:
CEs react on "Hitting something" also when they're hitting Player.
So then use "Hitting something" to check if we're hitting something, and then check if we are hitting everything we should NOT kill player for. If we haven't found something for 6 frames, then kill player.
This forces everything else to change to itself each 4 frames or so, so that the CE can use "Touching element <x>" to check if it should NOT kill player.

However, this implementation has a small bug, if you move with the exact same timing, the Zeppelin has just changed to itself and then it does not react on the "Hitting something" condition.

Here is the idea in use:
http://www.zomis.net/rnd/download.php?id=695

Maybe it's possible to improve it somehow, to prevent that little timing-bug.

OK, I have modified the way the diamonds and lights are "collected", and the score is now correctly updated as well.

But I have still a little problem with the "fuel" element. As you know, you have to take it as soon as possible to be able to swap the two players when you drop the fuel. So, the fuel must be collectible AND droppable. However, with your method, an element can be picked without being really collectible, but it cannot be dropped. Right?

Anyway, that's not very important, as this FUEL CE is an element that I have been forced to add in the game to manage the two players, but that is not present in the original game. So, snapping it should have no impact on the playability of the game. But it has a tiny impact on the final score, as the bonus points depend of the number of moves, and, with the current method, the player who knows that he can snap the fuel can gain one or two moves. Not a big deal, but if there is an easy solution for this problem, please let me know.


About the Amiga graphics now. I can run the game in the WinUAE emulator. I guess I can grab the screen, but it will be very difficult to grab all images of the animations.
I'm not sure I will be able to use a Windows program to extract the graphics of the executable. Remember that it's not a Windows .EXE file, but an Amiga program running in an emulator. But I have never used those grabbing tools, and maybe they can grab everything that is displayed in a window.
But there are still some other difficulties. The players, for instance, are not displayed over a black background like in R'n'D. So, I will have to remove the background image. Also, I suppose that the size of the image is not exactly what I need. Resizing the image could have some odd effects.
Anyway, let's finish the game world with the standard graphics first!


I'm waiting your "killer solution" with great impatience!
[EDIT] I've just noticed your previous post. I will try your level immediately! Thanks!

r0lZ wrote:But I have still a little problem with the "fuel" element. As you know, you have to take it as soon as possible to be able to swap the two players when you drop the fuel. So, the fuel must be collectible AND droppable. However, with your method, an element can be picked without being really collectible, but it cannot be dropped. Right?

Anyway, that's not very important, as this FUEL CE is an element that I have been forced to add in the game to manage the two players, but that is not present in the original game. So, snapping it should have no impact on the playability of the game. But it has a tiny impact on the final score, as the bonus points depend of the number of moves, and, with the current method, the player who knows that he can snap the fuel can gain one or two moves. Not a big deal, but if there is an easy solution for this problem, please let me know.

Hmm... No, I see no solution for this so I suggest that you let the FUEL be collectible, so that it can be dropped too. (Why is there no 'Snappable' option for the CEs?).

r0lZ wrote:About the Amiga graphics now. I can run the game in the WinUAE emulator. I guess I can grab the screen, but it will be very difficult to grab all images of the animations.
I'm not sure I will be able to use a Windows program to extract the graphics of the executable. Remember that it's not a Windows .EXE file, but an Amiga program running in an emulator. But I have never used those grabbing tools, and maybe they can grab everything that is displayed in a window.
But there are still some other difficulties. The players, for instance, are not displayed over a black background like in R'n'D. So, I will have to remove the background image. Also, I suppose that the size of the image is not exactly what I need. Resizing the image could have some odd effects.
Anyway, let's finish the game world with the standard graphics first!

There are video recording programs which records all activity on screen as well. I'm not sure that it has enough frames per second. But it could be worth a try.. But of course, it should be playable first of all (I'm also a person who takes care of the gameplay first and leaves the graphics for later on... )

r0lZ wrote:I'm waiting your "killer solution" with great impatience!

Look at the post above (which I hope you just did, when you noticed that I wrote that before you finished yours).