BluePhaze's Forum Posts

  • Rhindon Exactly, I have had some cases for example where I want to know if a person jumped. While the built in events have a detection method to tell if jumping, it is really just looking for the sprite moving upwards. Which also means at the apex of the jump it stops counting as jump as you start your descent. There is also the on floor event which you can invert to test if they are in the air, but that isn't the same, falling off something would also trigger that. So I created a variable isJumping and when they jump I set it to true. When they land I set it back to false. The beauty of this is that I can now differentiate between actually jumping, or falling off of something or being launched out of something. As the latter two events would not trigger the isJumping to true. This can be very useful especially in a game where you need to keep track of the exact state a sprite is in. In my case certain moves or abilities or actions should only take place if the person actually jumped as opposed to falling off an object.

    This is just one small example but you can see from it that it can make really complex logic much easier to implement. It also simplifies my events so that instead of saying if the player did A, B, and D but not C the do something. Instead I just say if isJumping is true do this... Since I track all the important states with variables, I can also use those variables as conditions for other events. It is now easy to put a test for isJumping into any of my other events/conditions if they should not be enabled when a jump is occurring, or if they should only be enabled when a jump is occurring. You can also take this further and use your state variables to enable and disable groups as needed.

  • The point of variables is for YOU to easily tell what it is for. I keep them short and abbreviate where possible because I don't have to worry about anyone else ever seeing them. So I make them short, but also very logical. Like: playHealth, isPaused, isWallSlide, etc...

  • You should check out the physics slingshot examples... you may be able to find more about them here in the forums... the only difference between this and a slingshot (like angry birds) is the visual representation of the slingshot would instead be a circle with an arrow pointed at your target trajectory.

  • Are you using the image points as the spawn location?

  • Much easier than using "another" sprite is to simply add it as another animation to your existing sprite. If you really need to use a different sprite, then AllanR is on the right track. Use an invisible sprite as your actual controllable character and just pin a visible sprite to it and that is what the player sees. You can then just pin whichever sprite you want as the visual representation of your character.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • It is centering them based on their original image point, make sure the image point is in the center of the object not in the upper left corner of it if you really want it centered. Otherwise you need to offset the x and y to account for where the image point is.

  • You can check the color in the editor, you can also use the paint bucket in the editor to fill in areas of the sprite with solid colors.

  • Really no way for us to guess at where the problem is as we don't know what your game logic does, etc... the best way to figure it out is using the debugging tools for each platform, if you are using cocoonjs you can use the platform launchers, on ios you can use XCode simulator, etc.... to find issues.

  • That should work fine, if you can define a starting point (x/y) and an ending point you can use some simple bullet behavior to get from one to the other. Have an overlap condition that stops them when they hit the target coordinates.

  • On touched will also work with that if you have the touch object.

  • — You are more kind than I... know way would I do someone's school project for them

    onyichi You really need to put in the time and effort do learn the tools for yourself. And hope that none of your classmates are on these forums...

  • Kcpunk666 Never read the graphic novel but I will admit that Buffy is one of my all time favorite shows... ok... so maybe just maybe I have the Boxed set of all seasons...

  • They are already in groups. Sounds and Music are two separate groups. However, if you turn them off, you also need to make sure that any place in your code that would normally start them checks to see if they are supposed to start. That is what the above examples do for you. Outside of that you may want to think about reading the manual and doing the tutorials. You will get much more out of working with them then by listening to us when you haven't worked much with them yet.

  • Group objects into families. This helps a LOT! For example in one of my games I had a lot of different types of terrain (Desert, Volcanic, Jungle, Ice...) and I needed to allow for wall sliding and other behaviors to occur on most wall types, but not on Ice. So I created a family called SlideWalls and put them all in it, except for the ice tiles. Now in my logic I no longer have to test for each type of wall, it automatically works for any wall type that is added to the family. The same type of logic carries to enemies, bullets, hazards, etc... anything with similar behaviors or similar events should be grouped in families to simplify your logic. It really reduces the amount of redundancy in your events. And remember that objects can belong to more than one family. For example I have some enemies that can be shot and some enemies that can be jumped on. So I have a family for each, but some enemies fall into both categories so instead of doing special logic for those ones, I just add them to both families.

    The other major tip I have is to use variables to track the state of just about everything. For example in my logic I have some pretty crazy tests that have to be done as certain moves can't be done when wall sliding, or when bouncing off a bounce pad, etc... so I create variables to track each of these "states". isWallSliding, isBouncing, etc... that way when I have to check if they can do a certain move, etc... I just test to see what state they are currently in. This allows for much more complex interactions without having to add a ton of extra logic, you use variable to track the state of objects that you may need to test for in your logic. By thinking ahead a bit you can make things much easier on yourself this way.

  • Have you looked at the turrets sample that comes with construct 2? I would also look at some of the tutorials for turrets. The nice thing about turrets is you can make them invisible and pin them to other objects which gives you nice multi-direction shooting.