This site requires JavaScript, please enable it in your browser!
Greenfoot back
WhitePorpoise
WhitePorpoise wrote ...

2016/3/10

Make certain condition for ice block to fall

WhitePorpoise WhitePorpoise

2016/3/10

#
Currently, I'm re-making a NES game called Fire 'N' Ice. Here are some of the game's machanism: 1. The game's actors are wall (as block or ground) and ice block 2. Player only can create ice block at their bottom-right diagonal or bottom-left diagonal (by pressing D) (the player cannot jump, and can only create ice when they stand on something (in this game, the player can stand on either ice block or block), so it is guaranteed that when player create an ice block, there's already a wall or another ice block beside the created ice block If there's any block or ice block under the player, the ice block will stick to it and can't fall 3. If there's an obstacle (wall) at player's bottom-right / bottom-left diagonal, and the player press D, the ice cannot be created 4. If there's an ice block at player's bottom-right / bottom-left diagonal, and the player press D, the ice in that place will disappear (player can re-create and remove ice block at the same place without limit) 5. Once the player pushes ice block, the ice block won't stop unless it hits another ice block or wall or fall 6. Player can only push one ice block at a time. If there's a space beside the ice block 7. If there's not space beside the ice block and no other object on the iceblock, the player will climb it 8.After player create the ice block, and it's beside the wall, then ice block will stick to it. But if player move onto the created ice block, and create another ice block beside it, then it will merge (it becomes a long ice block). As long as one of the ends of the long ice block stick to a wall it won't fall Here are the game's mechanism that I'm still trying to solve 1. After player create the ice block, and it's beside the wall, then ice block will stick to it. But if player move onto the created ice block, and create another ice block beside it, then it will merge (it becomes a long ice block). As long as one of the ends of the long ice block stick to a wall it won't fall Note: in my greenfoot, instead of making a new actor for merged iceblock, i use a code so it won't fall as iceblock won't fall if it's summoned beside another iceblock, it will fall if it lose its grip on both ends of the long ice block Here's my code for it: This code is in IceBlock class
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
public void act()
{
        if(!(onIce()))
        {
            if(!(squeezed()))
            {
                checkFall();
            }
        }
}
public boolean squeezed()
{
      if(!(onGround()))
        {
        Actor ice = getOneObjectAtOffset(32, 0, Blocks.class);
        Actor wall2 = getOneObjectAtOffset(32, 0, Wall.class);
        if(ice==null && wall2==null)
        {
            return false;
        }
        else
        {
            return true;
        }
      }
      if(!(onGround()))
        {
        Actor wall = getOneObjectAtOffset(-32, 0, Wall.class);
       
        Actor ice2 = getOneObjectAtOffset(-32, 0, Blocks.class);
        if(wall==null && ice2==null)
        {
            return false;
        }
        else
        {
            return true;
        }
      }
       
       
       
      return true;
    }
If I use the code above, the result: 1. When I create ice block on my left wall, it will stick (success) 2. When I create another ice block beside the created ice block, it will stick to each other (success) 3. When I'm on the right side of the map and remove an ice block, the long iceblock on the left side falls (success) 4. Even if the long iceblock falls, it won fall entirely, some iceblock will stuck (failure) 5. After I create the long ice block to the other side of the wall (it's supposed to stick), I'm on the left side of the map and remove an ice block, all iceblock falls (failure) I'm really sorry for my bad English, and it's really hard to explain the game's rules in words. Here's the link for the gameplay I'm terribly sorry for the inconvenience
danpost danpost

2016/3/10

#
First, there seems to be a problem with where you are placing some of your ice blocks. The one on the ground (lowest one) does not appear to aligned properly with the rest. All objects (even the player) should not be allowed to stop anywhere but at a "cell" location. If you fill your world with wall objects, starting at the top-left corner, placing them side by side and one above another, the location of each one would be a "cell" location -- a location where an object can stop or be placed at. Next, as far as ice holding firm until loosed on both ends of a run -- maybe you should have two Object reference fields in the class for the ice blocks to hold the left- and right-side objects that each is connected to. As long as either contain a reference to a wall or an ice object, the ice will remain in place; and if both are null, the ice will fall to any object below it. This way, when an ice block is removed, they can pass on the fact that a connection is lost along the run (each tells its neighbor to nullify a reference and pass to the other reference).
WhitePorpoise WhitePorpoise

2016/3/11

#
Sorry, I'm still new I have several questions: 1. So I need to add the pixel value to solve the first problem? 2. For the second problem, I can't understand your instruction. Can you give me example please? :)
danpost danpost

2016/3/11

#
For the first issue, you just need to ensure uniformity as far as placement of your objects (Wall, Fire, and Ice). Let me say that your Wall objects are 50x50 in size, which would be your implicit "cellsize". Then all these objects must be placed at 'n*50+50/2', where 'n' is a non-negative whole number. As such, you could add the following to those classes:
1
2
3
4
5
protected void addedToWorld(World world)
{
    int size = 50;
    setLocation((getX()/size)*size+size/2, (get()/size)*size+size/2);
}
Actually, the value in line 3 would be better if it were held as a class constant in your World subclass and set to 'size' in line 3. Let us say your World subclass is named 'MyWorld'. Then, with this in that class
1
public static final int CELLSIZE = 50;
you could replace line 3 with this:
1
int size = MyWorld.CELLSIZE;
For the second problem -- it is more involved than I initially thought (realized after reviewing the video several times). I am working on finding a decent way to go about it. I have a feeling that each block will need to check its own possible links to both sides as well as side-connected ice blocks being on top of another object to determine whether it can fall or not. Each will also need to know whether it is already in the falling state or not. This will take some time and effort. This is something that will not be prompty responded to (could take days -- not that I will be working on it 24/7).
danpost danpost

2016/3/18

#
Update: I have been able to somewhat reproduce the behavior of the ice blocks and it is quite involved -- as well as the player class. There were several parts that required implementing some 'tricks', like timers, delays, and player position adjustments (when creating or removing ice blocks during a level). As you have already found out, the condition for ice to fall cannot be solely determined by what is next to it. You will need a field or two to track whether they are holding on to the left or right object. You will need methods to get and set the value of the field(s), helper methods to return the objects aside the ice block and possibly an image updater method if you are visually showing what holds exist. You will also need to know when the ice is falling or sliding (a field for direction along the x-axis which could be just positive one, negative one or zero). I mentioned a delay timer for falling; a delay for the player is useful when pushing an ice block so player does not immediately go under falling object(s) above ice that is now sliding; a field to track the key triggering the creation or removal of ice blocks by the player will be needed; etc. I will post my reproduction of the game. It does not include any of the dialog, interludes or animations -- just the level play. Will edit link here when it is posted. (code will not be supplied as you cannot learn anything if I include it -- also, it would be like supplying the entire project to you, which would not be justly right). EDIT: my demo is here.
WhitePorpoise WhitePorpoise

2016/3/22

#
Thank you so much. I'll try my best to learn it :)
You need to login to post a reply.