Trying to develop XOR for RnD

All about creating levels and level sets, custom elements and custom artwork.

Moderators: Flumminator, Zomis

Post Reply
r0lZ
Posts: 93
Joined: Sat Oct 20, 2007 6:24 pm

Post by r0lZ »

Your solution is very interesting, but it doesn't work well! :(

You have already noted the synchronization problem that permits to the player to survive in some cases.
But there is also an unpleasant pause in the move of the zeppelins, and their overall movements are also slowed down.
I could live with those problems, but the most important problem is that the player is killed when he should not.

In your level, remove the zeppelin that you have added to the right of the player. Then play the level. Enter the cave at the left of the player, and take the diamond that is in the row below the player. To escape, you have to move up. The whole row of zeppelins start to move, and as soon as the first zeppelin hits the wall, the player is killed because he is touched to his bottom side by another moving zeppelin. Of course, that's unacceptable.

There might be a solution for this problem. In the original game, only ONE element moves at a time. So, in the example above, when you move up, the first zeppelin of the row starts to move, and it's only when it reaches the wall that the second zeppelin starts to move. The third starts when the second has hit the first, and so on.
In this case, the player should never be touched by a moving zeppelin when, at the same time, another zeppelin hits something.

I remember that I have tried to simulate exactly this behaviour, but I had several problems.
For example, imagine that there is a rock over the second zeppelin in the row. When that zeppelin moves, the next one doesn't follow it immediately. Therefore, the second zeppelin leaves a gap during its movement, the rock falls in the gap and block the other zeppelins of the raw. That's not what I need. When a row or column of elements starts to move, all moving elements in that row or column must move before freeing the adjacent elements. BTW, this is why the moving elements leave an invisible tail of CEs behind them, to prevent the adjacent elements to take precedence.
So, I guess that programming that original behaviour is not easy, and maybe even impossible, and that would require a complete rewrite of many CEs anyway.
Furthermore, the current method has the advantage that the movements take place as soon as possible, and the game is less static than the original version. I would like to preserve that.

Note also that I will have to modify the atoms like you did for the zeppelins. There are no atoms in level 2, but they behave exactly like the zeppelins, except that they explode when they are hit by something (except by the dolly.) I suppose that I can use your method here also, but the risk of problems will be greater.

It would be much more simple to use one of the game engine modification I have suggested above. Holger, are you there? ;)
Oh, yeah, could you add also an option "Collectible but not snappable" in the CEs? Just kidding ;) ...but that would be nice!
Last edited by r0lZ on Sat Nov 03, 2007 9:48 pm, edited 1 time in total.
Daniel H.
Posts: 535
Joined: Sun Apr 02, 2006 7:13 pm
Location: USA

Post by Daniel H. »

r0lZ wrote:Oh, yeah, could you add also an option "Collectible but not snappable" in the CEs? Just kidding ;) ...but that would be nice!
Well, if you look at mushrooms in Snake Bite, you can see how to make an item collectible but not snappable, but it's not perfectly cheater-proof.
The H. World levelset can be downloaded from http://www.bd-fans.com/RnD.html -- search The H. World on that page.
r0lZ
Posts: 93
Joined: Sat Oct 20, 2007 6:24 pm

Post by r0lZ »

I see. The mushroom is defined as not collectible, but it changes to a collectible mushroom when it is pressed by the player. Interesting idea! It's simple and it has the advantage to preserve the standard behaviour of collectible elements (sound, animation...) Thanks!
How can we cheat with that?
r0lZ
Posts: 93
Joined: Sat Oct 20, 2007 6:24 pm

Post by r0lZ »

The diamonds can now be picked but not snapped, as they should, and the animation and original sound is still present. Thanks again for this excellent method, Daniel.


I have also been able to modify the sounds of some elements.

However, I am still stuck with the sounds of the dolly, zeppelins and atoms when they hit something. Using "custom_#.impact" doesn't work. I have tried almost everything, still without luck. The only thing that works almost is to use Custom_#.changing, because the CE changes to another one when it hits something. But it changes also to another CE when it is touched by the player, and therefore the sound is played also when it should not.

There might be a solution. For example, if I change the dolly to a new CE when it hits something, and then I change that element immediately to the dolly again, I could assign the sound to that new element. But IMO it's a bit too complex to do that just to be able to add a sound to a specific action. Is it a better method?


And I still have no working solution for the big "kill player" problem...
Zomis
Posts: 1502
Joined: Mon Jun 21, 2004 1:27 pm
Location: Sweden
Contact:

Post by Zomis »

Try with Custom_#.hitting
I think .impact is only when an element falls.

I suspected there'd be more bugs in my approach, I guess the best is indeed to modify the game engine.
r0lZ
Posts: 93
Joined: Sat Oct 20, 2007 6:24 pm

Post by r0lZ »

I have tried the .hitting property too, but without luck so far. But I have now modified the CEs to create an additional temp CE that triggers the sound when it changes, and that works fine.

Therefore, as far as I know, everything is working well now, except that the player is not killed when he is hit by a zeppelin or an atom.
Zomis
Posts: 1502
Joined: Mon Jun 21, 2004 1:27 pm
Location: Sweden
Contact:

Post by Zomis »

r0lZ wrote:Therefore, as far as I know, everything is working well now, except that the player is not killed when he is hit by a zeppelin or an atom.
I am not the one who gives up!

I just made a new attempt, using another approach ("change when touching empty space" can be useful sometimes...), let's see if you find any bugs in this one!
http://www.zomis.net/rnd/download.php?id=695

I haven't tested it completely, so there might be some bugs... But I hope not.
r0lZ
Posts: 93
Joined: Sat Oct 20, 2007 6:24 pm

Post by r0lZ »

Yeah! Seems it's *almost* perfect! :)

I don't understand yet how you did this magic, but currently I have noticed only one problem, and it should be possible to avoid it.

In the GE7, I suppose you need to have everything that is solid (not empty.) Right? You forgot some elements, like the exit door. Therefore, CE39 doesn't change to the zeppelin when it hits one of those missing elements. And the player dies if it touches CE39. No problem, I have added the missing elements in the GE, and that works. But there is one element that I cannot add in the GE: the external border. I suppose that it is not a regular indestructible wall, as it is impossible to pick it with a control-click. So, when the zeppelin hits the external border, it stays deadly forever. Dead end? I don't think so.

In the worst case, it should be possible to add a second border, made of regular indestructible bricks, so that the external border can be added in the GE and detected. I don't like that too much, but I'm sure it will work.

Also, I have tried to change the condition in the change page of CE39 from "hitting element GE7" to "hitting something" and apparently, that works fine, including with the external wall. So, I wonder why you did that with a GE. Is it a problem with "hitting something"?

Oh, could you also explain the logic behind your trick? I must admit that I am completely lost!

Anyway, it's a great job! Thanks a lot!
r0lZ
Posts: 93
Joined: Sat Oct 20, 2007 6:24 pm

Post by r0lZ »

Zomis, I have finally made something that works almost perfectly. Using "hitting something" works fine, so forget my previous post. Also, I have understood your method. Not really simple, but very smart! Thanks again!

I thought I was ready for a new beta, but I noticed that some tapes were broken, probably because there are small timing differences. So, I replayed some levels. And I've found another problem! :(

In this situation, , if the player takes the gems, he should die. But he is not killed by the zeppelin! He is killed only when he reaches the empty space. Same thing if I replace the gems by horizontal tubes, or the zeppelin by an atom.
(There are several diamonds only because it's easier to test, but the problem occurs also with a single diamond.)

I have also tested the same situation vertically, with a rock or a bomb, just to be sure, and the same problem was present! However, in this case, I don't use your method, since I can use "can fall" and "can smash player".

Then, I had the idea to check with a collectible diamond, and that worked fine, for the vertical and horizontal situations. So, I suppose that the collectible diamond is removed from the board immediately when it is collected, but a walkable diamond that changes to the empty space is removed a little bit later, and the check for the collision finds the gem instead of an empty space occupied by the player.

Since I can't get your method to work correctly with collectible diamonds, I have changed again the property of the diamond to walkable. Strangely, this time, that worked fine in the vertical situation. Although I have removed the checkmark of the "collectible" property, I forgot to change the property itself to the default, "diggable". It's the only thing that is different! And if I quit RnD and then reload the level, the property displayed in the editor is again diggable, but that continues to work fine! I don't understand. It's probably a RnD bug, but I can use it to solve the problem with the rocks and bombs. However, the same trick doesn't work with your method, in the horizontal situation with the zeppelins and atoms.

I have tried to adapt your method so that it works with collectible diamonds (using the "mushroom method" given by Daniel above so that the diamonds cannot be snapped), but unfortunately without success. And I don't know how I could solve the problem with the tubes (although it is perhaps possible to define them as collectible too but I haven't tried that yet.)

Any idea?

BTW, I have changed a lot of things since beta 1, as there were several problems. (Especially, there was a problem with your method when the player is touched by a zeppelin and the user uses the drop key to swap the players. But it's OK now.) Let me know if you need a template level or a new beta to check the problem with the almost-definitive version.
Zomis
Posts: 1502
Joined: Mon Jun 21, 2004 1:27 pm
Location: Sweden
Contact:

Post by Zomis »

I have a small idea about how it could be solved, but I'm not sure.

A new beta-level would be good to test with.
Or a simple level that shows more of your different solution attempts would be good.

I'll check it out later today.
r0lZ
Posts: 93
Joined: Sat Oct 20, 2007 6:24 pm

Post by r0lZ »

OK. Here is beta2: http://home.tele2allin.be/vt6328799/files/XOR_v0.2.zip
[EDIT] File removed. Please use the latest beta! [/EDIT]

I haven't kept my different attempts to solve the problems, sorry. But level 3 of the last levelset is a level that I use to test. Currently, it has exactly the same CEs than in the other levels.

I'm very busy today, but I will try again this evening. In the meantime, good luck! ;)
Last edited by r0lZ on Sat Dec 08, 2007 4:29 pm, edited 1 time in total.
User avatar
Holger
Site Admin
Posts: 4071
Joined: Fri Jun 18, 2004 4:13 pm
Location: Germany
Contact:

Post by Holger »

> Try with Custom_#.hitting

Unfortunately, this does not exist. :-(

> The only thing that works almost is to use Custom_#.changing, because
> the CE changes to another one when it hits something. But it changes also
> to another CE when it is touched by the player, and therefore the sound is
> played also when it should not.

That's right. To solve this, you can use a sound effect for each change page, like this:

> custom_134.page[3]: jingle_animal.wav

For more examples on advanced sound definitions, have a look at the "soundsinfo.conf" of Zelda 2.
r0lZ
Posts: 93
Joined: Sat Oct 20, 2007 6:24 pm

Post by r0lZ »

Holger wrote:> To solve this, you can use a sound effect for each change page, like this:
>
>> custom_134.page[3]: jingle_animal.wav
Great! I was hoping that something like that existed! It's much more easy now! Thanks!
r0lZ
Posts: 93
Joined: Sat Oct 20, 2007 6:24 pm

Post by r0lZ »

Zomis wrote:I have a small idea about how it could be solved, but I'm not sure.
Don't worry! I've found a solution (using the "pickable mushroom" method.) I think it's exactly what I need. But unfortunately, most of the tapes are now broken again, so I have to play several levels again to be sure that everything works as expected.

I have also fixed another problem that caused level 9 to be unplayable.

I will release a new beta as soon as possible...
User avatar
Holger
Site Admin
Posts: 4071
Joined: Fri Jun 18, 2004 4:13 pm
Location: Germany
Contact:

Post by Holger »

About the problem of being unable to use a "horizontal impact" (hitting horizontally):

> 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.

I think this option is indeed missing! Currently, there are the two obvious options "deadly when touching" and "deadly when running into", and the not-so-obvious "deadly when colliding with". The third option includes two different conditions: A player reaches a tile where he would "hit" the next tile with this condition, and the CE tries to move to a tile which is occupied by a player. Especially the second case is currently also true when the CE was never moving, but *would* move to the player's tile. It is debatable if this should really count as a "collision", as the CE was never moving at all before.

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.

> 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.

That's right! And I think that a concept of "can fall <up/down/left/right>" would really be useful!

> 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.

I also agree here! Selecting "can smash" could be used for all actions that result in an "impact" action/condition, not only those related to "falling", but also those related to "moving".

> 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.

Finally, also this should work, to make things more orthogonal. I still have to check if this would be easy to add or if it might need more effort.

> 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!

Adding change pages to the player element(s) would certainly result in a lot of extra work both for the game engine and for the level editor GUI, so I think we should use one (or more) of the other four solutions first. :-)

> There might be other solutions as well.

No, I think you have made a quite complete list of possible solutions to handle the problem you described! And I think I should add at least one, if not more than one of these suggestions to solve that problem, as I can see that certain tasks could not easily be done without these changes.

Unfortunately, I cannot give an "estimated time of arrival" for one of these fixes, but I'll try to work on this as soon as possible!
Post Reply