deadeye's Forum Posts

  • Looking good, man . Looks like those spriting tuts are paying off.

  • I seem to be able to zoom things just fine scidave, but your .cap is missing so I can't see what's up on your end.

    And eski, you can create a zoom effect by actually zooming the screen with System events, or you can fake it by scaling sprites. Either way. Perhaps a .cap of the problem you're having would help to fix the issue.

  • That .cap is using v0.99.72, you should be able to open it with that. Sorry for the confusion.

    Anyway, you could try a For Each loop on your wall objects, and add up all their X and Y velocities (make sure to change them to a positive number first, like abs(wall[physics].VelocityX), etc.). Then when the loop is done, if the total of all their velocities is, say, less than 1 or 2 then you know they're pretty much settled. Of course you should only start checking for this after you confirm a hit.

    As for setting states for your game, you could try putting your events into groups. All of your control events in one group, all of your collision events in another, etc. Then when you "win" you disable the control and collision groups and activate the "win" group which has all of your winning events in it. Same for "game over." You can disable groups by default in the event sheet editor and activate/deactivate them at runtime using System actions.

  • Okay eski, sorry for the delay. I got what you're looking for here, to help slow down your pucks faster.

    I changed event 15 to this:

    + System: For each Sprite
     -> Sprite: Set 'Speed' to sqrt(Sprite[Physics].VelocityX^2+Sprite[Physics].VelocityY^2)
     -> Sprite: Set 'id' to Sprite.UID[/code:3mk0s3gm]

The way you had it before, you were just setting Speed to the X velocity.  This combines the X and Y velocity to get total velocity.  The ^2 also changes it so that you always get a positive number.

(You can thank Quazi for that one, he helped me figure that out in this thread: )

Anyway, back to the .cap.  I un-toggled the last event you had (event 22) and changed it to this:

[code:3mk0s3gm]+ Sprite: Pick by Sprite.Value('Speed') Greater than 0
+ Sprite: Pick by Sprite.Value('Speed') Lower than 2
    -> Sprite: Set velocity to (0, 0)[/code:3mk0s3gm]

I used Sprite compare rather than System compare so the picking would work properly.  You can find it in the Sprite conditions labeled "Pick by comparison."  I used "Lower than 2" just to stop them faster, you could probably get away with 3 or 4 and it wouldn't look too weird.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • First, I'd like to implement some kind of ball counter showing the remaining amount of balls left represented by little ball icons. So I figure you'd have to spawn as many ball sprite instances as a ballcounter variable counts - any ideas on what might be the easiest way to achieve that ? (especially the spawning part)

    Here's one easy way of doing that:

    http://dl.dropbox.com/u/529356/ballcounter.cap

    It uses Tiled Background. I resized your ball sprite to fit in a 32x32 space.

    As for the game over thing... do you mean you want to know when all of the wall pieces have stopped moving?

  • And, also... on the same subject of sound, check out what happens when you mix sound with a non-newtonian fluid. You get a pet cymatic blob:

    Subscribe to Construct videos now

    That's wicked cool looking . Kind of reminds me of this:

    Here's a collaboration between Salvador Dali and Walt Disney. As a fan of Dali I think it's pretty cool, too bad they had to Disneyify the character's faces, though . Anyway, it's still pretty neat:

    (Also, lol at the copyright infringement notice at the beginning... better watch this one while you can, guys )

  • Oh, hey Rich. What's up?

  • It'd be nice to have some offline help, yes. Perhaps when the wiki documentation gets better, a .chm file could be compiled from it. I don't know about a full-on interactive help thingy like you described though, seems like a pretty tall order.

  • I like naked women.

    ~Sol

    to bad you will never get to see one IRL cause your a permavirgin

    haha, owned noob! that's how we treat noobs around here

  • Sweet game!

    I totally **** at it, though . David is right, your video makes it look like a piece of cake.

  • HOLY CRAP THAT'S EFFING CRAZY

  • Yeah, I'll find another way of doing it, although a couple of thousand entries in a dropbox or list isn't that many in memory terms.

    And it's not for the end user to select from anyway.

    It was just a way of keeping the list internal to the game.

    You could always populate your list from a text object. You could even use instances with PVs if you have multiple lists. I used text objects with INI info in them to load levels in Vert, in order avoid having a pile of .lvl files hanging around. They're just all tucked away on a hidden and locked layer.

    I'm sure you could do something similar to keep from having external text lists.

  • So choose-your-own-adventure books/games are second person? Eg. "You go in to the cave... press A to light a match, B to shout etc"

    I think that would count, yeah. "You were eaten by a Grue."

    As I said before I think Dance Dance Revolution or WiiFit might be as well, since "you" are the one dancing or doing situps or whatever. I suppose that's debatable though.

    And I think the amount of dust on your dance pad or balance board would factor into the equation somehow.

  • Hmmm. What about making a boundary for my level? My plane can fly right off the screen ****

    The easiest way to keep things in-bounds would be to create Solid objects outside the edges of your layout for things to collide with. ("Solid" is an attribute in the properties window, just put a check next to it.)

    Such a device is known as Stainsor's Wall, after forum member Stainsor who asked the same question many eons ago.

    Anyway, if you are using behaviors for your plane then keep in mind only some behaviors have Solid collision capabilities. Ball, Car, 8Direction, and Platform behaviors can all keep from passing through Solid objects automatically.

    Custom Movement behavior can define what objects to push out of using events.

    Physics objects only interact with other Physics objects. You can define what collision type a Physics object is in the properties.

    Bullet behavior doesn't have any built-in collision for Solid objects, it'll just pass right through (unless you make events to tell it to do otherwise).

    If you are making your own custom movement with events then you will have to make your own custom collision events as well.

  • the problem with windows controls is they are always rendered on top of things not matter what layer they are on.

    Which wouldn't be a problem for scrollbars, I don't think. Wouldn't you always want them on top anyway?