deadeye's Forum Posts

  • >

    > You don't need to do this for every kind of game, but the way the platform object works you're just going to run into trouble.

    >

    It's generally good practice to create invisible hitboxes for most sprites anyway as oppose to pixel perfect collision I think. I think it's a fairly common practice but I usually draw my backgrounds seperately in photoshop and then after importing the image, build the platforms using hitboxes also, which makes the whole thing run a lot smoother.

    True, but it's not exactly best for all games. Like a top-down space shooter for instance, where you don't really have walls or solid objects. Bullets hitting your ship would work better with Per Pixel in that case. Especially if your ship has an odd, angular shape (which most tend to do).

    A better way to handle pause is to use the ELSE condition and a subevent. Eg:

    + On P pressed

    ----+ (conditions saying it's already paused)

    ----> Unpause

    ----+ Else

    ----> Pause

    This way you don't need any flags or other events (and it's easier to make sense of too).

    Ah, that is better. I remember someone posting an alternative to my method before but I couldn't recall what it was.

  • Awesome

  • We're in the process of completely rewriting the event sheet editor right now (every line must go) as it's in rather terrible shape.

    Once that's done this is one of the first features on the list, along with many others we'll then be able to add as a result .

    Will it be compatible with our current projects? Should we hold off on starting any big projects just to be safe?

  • You might be able to get away with an angle compare. Something like:

    sprite.Angle is greater than sprite.Value('lastAngle')

    You'd have to compensate for the 360/0 boundary though by adding in some more complex checks:

    +round(sprite.Angle) is greater than sprite.Value('lastAngle')
+round(sprite.Angle) does not equal 360
   ->Set sprite.Value('rotDir') to "right"

+round(sprite.Angle) = 360
+sprite.Value('lastAngle') = 0
   ->Set sprite.Value('rotDir') to "left"

+round(sprite.Angle) is less than sprite.Value('lastAngle')
+round(sprite.Angle) does not equal 0
   ->Set sprite.Value('rotDir') to "left"

+round(sprite.Angle) = 360
+sprite.Value('lastAngle') = 0
   ->Set sprite.Value('rotDir') to "right"

+round(sprite.Angle) = sprite.Value('lastAngle')
   ->Set sprite.Value('rotDir') to "stopped"

+Always
   ->Set set sprite.Value('lastAngle') to round(sprite.Angle)[/code:2wgbui6z]

Then you could record the 'rotDir' states and use those for the playback.  I haven't tested it but with some tweaking it might do what you need.

  • Yeah, now that you know how to fix your button presses you should make the dialogue thing use just one mouse button. Or better yet, a key, preferably the Enter key or the main action key for the game (in this case, Shift). It's a good idea design-wise to make it so you don't have to touch the mouse unless there are actual mouse controls in-game.

  • You don't really need a container for your player because there's only going to be one player. Containers are for muliple multi-part objects. For instance, if you had several enemy sprites with several separate enemy hitboxes.

    As for sub-animations, I really don't know. I've never even tried them out, I have no idea how they work. As far as I know, I've never had any need for them.

  • Also another tip is to use the tiled background object and set the width. That works well with a health bar that gets smaller (doesn't scale, just becomes less and less) or hearts where you have a tiled image of a 16x16 heart and each time u get hit you subtract 16

    That's a clever trick

  • I finally got the game to play, for some reason it stalls at the dialogue scene and I thought it was just freezing or something.

    Like I mentioned in your Help thread, the Per Pixel collision on your animated sprite causes problems. You can hang off the edge of a platform by his arm, for instance.

    It will also cause problems at walls. Since your sprite is animated, it doesn't have a constant width. If you run into a wall on one frame, the next frame might intersect with the wall because it's wider than the previous frame. If it does that, your sprite will pop to the top of the wall due to the way the push-out function works on the platform behavior (it's designed to always push out of the ground if it's stuck).

    Even if you changed the collision type to Bounding Box, you could still run into this problem. It's best for platforming objects to use a separate collision box sprite that has only one frame so it never changes size. Put the Platform behavior onto this box sprite, and take it off of your animated sprite. Then set the position of your animated sprite to the box every tick.

    You don't need to worry about this so much with other kinds of games really, just platformers. If you're doing a top-down space shooter, for instance. But it's still a good idea to use this method whenever you have objects that need to come into contact with solid objects like walls or platforms.

    As for the movement, Belmont is way too fast. You should slow him down a lot.

  • One thing... you have fifteen Start of Layout events in your test layout alone. You only need one. You should really learn to use sub events.

    Edit:

    In fact, I can see a lot of common mistakes in general in your .cap. You have your animated sprites as your Platform objects, and you have them set to Per Pixel collision. This is just going to cause problems for you. You should make a separate, invisible box and use that as your platforming object, and just position your sprites on top of it.

    You don't need to do this for every kind of game, but the way the platform object works you're just going to run into trouble.

    Plus, you would only need one platforming object, and you can use it to put your different character sprites on. If they have to have different speed or jump heights or whatever, you can change those at runtime depending on what character is selected.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Here's what's wrong with the pause:

    <img src="http://i38.tinypic.com/rvf05f.png">

    The first event activates when you hit P, and changes the Pause variable to 1.

    Then it moves on to the next event. Since the Pause variable is now 1, it triggers this event too, which changes Pause to 0. So you're pausing and then immediately unpausing again in the same tick, so you never see it. You need a toggle in there:

    <img src="http://i33.tinypic.com/23vc01z.png">

    The toggle always resets to 0 before it checks your On Key events. When your On Key event is reached, it makes sure that pauseToggle is 0 before performing the action. If it is 0, it will change to 1. That way when it reaches the next event, it won't trigger.

    I'll take a look at the other stuff really quick, but just a heads up I can't seem to play your game. I don't know what's up, but nothing moves.

  • Check your PM's, I fixed your jump.

    It seems that Containers and Families aren't communicating properly somewhere, I had to pick instances by object instead of by family. When you try to recreate your bug for Ashley, focus on that.

    Also, I changed some things around and made some notes for you. It's all in the comments.

    And something I did made it so that the regular preview runs now too, it doesn't just run in debug any more. I have no idea what it was though.

    One piece of advice: I know that organization is a good thing, and I admire your tenacity with naming everything properly, but you've taken it to extremes. You have one layout and fifteen event sheets. At least three of those are for player actions. I think you might just be making more work for yourself there... most (if not all) of your player controls should be under just one event sheet, if only so that you can access them more easily. It'll be harder to keep track of how actions interact if you have your them spread across so many event sheets.

    Also I only have 2 ground enemies but it made 3 terrain trackers....

    You should make sure you have an equal number of enemies and trackers in your layout, since they're contained together. I created a second tracker for your second enemy and it seems to have sorted out.

    Or, do like I did and check "Destroy on startup" for all of the contained objects that go along with your enemy, then use spawners to create your enemies at runtime.

    In fact, I'd go so far as to say you should probably look into making a level editor/loader for this game. It seems that you want to make something big here. Once you get your engine down, concentrate on making a level editor instead of placing all of your stuff in the layout. It'll keep things lean when it comes to the final build.

  • Weird, it won't run at all for me. I click Run, and nothing happens. There isn't even a Temp.exe in my task list. No error message, no nothing.

  • Drasa's right, if you can do it easily without collision events then that's always better. The distance expression is just one line of code, so it'll be easy to implement.

    +For each enemy
   +distance(enemyX, enemyY, playerX, playerY) is less than 100
     -> move away code (or flag)
   +else
     -> move towards code (or flag)[/code:2i585vw1]

where 100 is the number of pixels radius you want.

You might need some sort of intermediary event to smooth out the moving towards/moving away actions though, or your enemies might jitter back and forth at the edge of the boundary.

  • Okay, so you got your TerrainTrackers lining up with your Ground objects correctly? All right then...

    but now if one terrain tracker overlaps an object with the terrain attribute they all jump...

    and if I add a for each ground object it crashes...

    Hmm... try adding the "jump" action to the main For Each loop, like so:

    +For each Ground
   +Ground X Greater than PlayerSprite.X
      ->Ground: Set 'Facing' to -1
      ->TerrainTracker: Set position blah blah
   +Ground X Less than PlayerSprite.X
      ->Ground: Set 'Facing' to 1
      ->TerrainTracker: Set position to blah blah
   +Ground Platform: Is on ground
   +TerrainTracker overlaps Terrain
      -> Ground Platform: Jump[/code:oiw5hk3w]

The reason I included "+Ground Platform: Is on ground" is so it picks the proper instance of Ground, even though it should be doing that anyway with the For each loop.  I did have some trouble keeping track of picked objects in my AI so you might need to remind Construct which Ground you're talking about.  Theoretically picking TerrainTracker by itself should also pick the proper instance of Ground to go with it though, so test it without that at first and see if it works.

(Note for the devs:  I haven't had a chance to do any testing yet on the loops and picking problem.  It might not be a problem at all, just bad code on my part.  It's on my list of bugs to check out though, I'll get to it eventually.)

Oh, and if you still can't get it working, PM me the .cap.  Tell your friend I won't steal it.

Edit:
You do know that setting it up this way will make all your enemies jump the moment they hit the ground, right?  They'll be bouncing like rubber balls all over the place.  If that's the effect you're going for, that's cool, just a heads up.

  • What do your containers look like? Is TerrainTracker in the same container as GroundCollision? Or are those families, not objects? It's kind of hard to tell exactly how things are set up from your screenshot.

    Also, reverse the order of your For Each and X Greater Than events. It should look like this:

    +For each Ground
   +Ground X Greater than PlayerSprite.X
      ->Ground: Set 'Facing' to -1
      ->TerrainTracker: Set position blah blah
   +Ground X Less than PlayerSprite.X
      ->Ground: Set 'Facing' to 1
      ->TerrainTracker: Set position to blah blah[/code:29u6a9ks]

That way you only need one loop.  And get rid of the Always under your For Each, it's not necessary because the loop will run every tick regardless.

Final question: were you able to get the AI working for one object without families?  Just to make sure it worked in the first place.  If not, give that a test first.  And if you can't get it to run, try posting a .cap so someone can take a look.