stainsor's Forum Posts

  • > I'm not entirely sure without seeing the .cap file, but I just did a quick test, and if I add a tiled background/sprite with a solid attribute, I can't pass through them with the Grid behavior.

    >

    That's true, but it appears that only works with keyboard input. If you manually tell the grid object to move spaces, it ignores the Solid attribute

    Hmm, I was just using keyboard input, not manually telling him to move. Here is a cap that demonstrates the grid movement.

    But after playing with the Grid behavior in this .cap, I don't really think it's suited to a Pac-Man style game anyway... Pac-Man can turn on a dime, and Grid movement won't change direction until the object has reached the grid space it's heading for.

    Actually that's what I like about the grid movement. With pacman turning on a dime it takes some skill to turn at the appropriate time. Maybe that's just part of the challenge of the game. But I wanted a smarter pacman that would wait to turn until the appropriate time. It's much harder to turn with the 8-direction movement, even if you set it to only 4 directions. In the cap above try making the turn drawn in the arrow. With the grid movement it's easy to do at full speed. Now try changing the movement to 8-direction. With the 8-direction movement it's difficult to do the turn without slowing down.

    Edit: I forgot to mention that I think with Deadeye's manual input scheme I can do the collision checking that I was talking about and make it all work.

  • I'm making a pacman style game, you can take a look at what I've got so far. I'm having movement problems. The player (grid behavior) moves smoothly but can pass through walls. The enemy (ball behavior) can't pass through walls, but often gets stuck on corners.

    I've also tried bullet behavior for the enemy (which would work if I wanted to make it work) and 8-direction movement for the player. But I think grid movement will produce the smoothest movement with the least chance to get caught on a wall. (This was what I found most annoying about the original pacman and it didn't have the problem nearly as bad as this does when I try using 8-direction movement. Check it out for yourself.)

    So as I said, my real question is how to I restrict my player's movement if he's using grid behavior? I have enough unique background tiles that I can use collision detection to easily determine which directions are passable. The problem is just preventing the character from going in the directions that I know he shouldn't.

    edit: by the way, ALL the artwork is final. hope you like it.

  • You're correct. This fixes the first problem: Your character will no longer continue in the same direction. But the second problem still remains. Try doing something like David did in the cap posted on this thread.

    Now that I think about it if you can fix the second problem you'll probably fix the first problem anyway. So you may not need the code I gave you anyway.

    I'm actually having basically the same problem with a Pacman style game right now. But I'm planning to use either Ball movement or grid movement. I suppose I should post about it in a new thread though.

    edit: Here is the new thread.

  • Maybe we could just get his voice built in to the Text to Speech object

  • my head is spinning

    I'm speechless

  • Okay, I posted a cap of what I meant here. There are some comments in the cap that explain the details.

  • those are all three from the same game?

  • It does what you want except for two problems:

    1) Sometimes it continues in the same direction.

    2) Sometimes it chooses to turn into a block.

    To fix the first problem I suggest that you give the ghost a private variable old_angle.

    Then:

    + On Collision between Ghost and Block

    + while Ghost.old_angle = Ghost.GetAngle()

    - Set Ghost.old_angle to floor(random(4))*90

    I hope you can read my pseudo-code. Please let me know if you can't.

    To fix the second problem I suggest you try something like David showed in this example:

    viewtopic.php?f=16&t=2397

  • Construct converts everything to png, so you'll want to use either png or bmp. I'm not sure why you'd get the quality loss if you're using either one of those.

  • Okay, wow. It's like a light just clicked on. I don't know how I didn't see it before. Thanks.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • But when I try to view the content of that variable for a randomly picked sign it seems to be blank.

  • Don't worry table, I've wondered where the text was too. Although I confess I haven't performed a thorough search ... at least not lately.

  • I think you can destroy two bricks at once in the real breakout. Of course you have to hit right between them. So anyway I guess I'm saying I would go with a detector that extends on or two pixels beyond the ball in all directions.

    Good point about the offset ... I guess I didn't really think that one through enough.

  • Yikes, that's more complicated than I thought it would be.

    Here's what I would suggest:

    <img src="http://www.1728.com/quadtrp7.gif">

    Divide the trapezoid into two triangles by drawing AC. Now instead of having all four sides pretend that you have the three sides and angle of your choice. Let's pretend you know b, c, d and angle B. Then you can solve triangle ABC. Drop a line down from B perpendicular to AD and you can solve the right triangle you just made. This gives you the height. Solve the corresponding right triangle on the other side of the trapezoid. At this point solving the rest of the trapezoid is simple.

    Once you've got all those equations written down you should have enough equations to solve for any four unknowns. So you should be able to use those same equations to solve the trapezoid given the four side lengths.

    Just a thought, sorry I'm too lazy to go through all the math. But anyway this method avoids having to use the expression they give for the height. (I don't like using expressions I can't derive.)

  • So many times, so many ways Ashley reminds us that in Construct you can do a lot with what you've already got.

    Hey that was almost a poem. Here, I'll give it to you in Haiku form ... nevermind.