Chris PlaysOldGames's Forum Posts

  • Let me make sure I understand... your wanting the invisible damage sprites to spawn 3 in a row and then be destroyed followed by a delay and then repeat?

    ie. damageSprite, damageSprite, damageSprite (destroy,destroy,destroy) (delay) damageSprite, damageSprite, damageSprite (destroy,destroy,destroy) ?

    As far as sprite fire or particle fire it really depends on the look of your game.. particle fire would be easier once you got the right particle look since you don't have to animate it... but particles can begin to add up if you use many in your game at once.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • On overlap should work fine.. sounds like you have something else going wrong.

    If I was making this I would use 2 invisible sprite "zones" one covering each box and use the on-overlap condition. I would however use a double condition test for overlapping both (ie. is overlapping spriteOrange and spriteApple).

    You could get more complex and grab the orangeBox.X and the AppleBox.X and then test against their values to determine which one is closer to the apple.x or orange.x but for a simple project like this I would just use overlapping sprites.

  • Did you use System-Trigger Once While True in your randomize condition?

  • The comment about every bullet hurting every monster refers to picking specific instances of an object...

    If anytime a bullet hit a monster, ALL monsters on the level take damage is what it is referring to.

    That paragraph is talking about "picking" instances.

  • Yes.. and no. You can link event sheets so they can be used in multiple layouts.

    Only one layout will be "running" at a time though. You can "track" the changes to the other layouts via global variables and then update the other layouts when they are in focus...

  • Containers.. should do what your looking to do.

  • The key with Construct2 instance selection is "picking" (read about it in manual, its essential). Basically you need to make sure you are picking the instance you want to be doing something, otherwise it picks all instances of the type specified. You pick instances using conditions in your events. In Bloodshot's example you are picking the "visible" sprite to act on. You can pick using basically anything that singles out a specific object... closest, furthest, visible, X-visible, on-screen, X-on-screen, UID, instance variables, etc. to name just a few.

  • Use round(random#) instead

  • You will need to use the enable turret / disable turret actions.

  • You may have to use the turrent built in actions to change its projectile type based on your variable value would be all I would think.

  • Are you telling it to increase?

    You will need to use set Width action each time it is supposed to update.

  • You use variables with event actions.

    On your shooter sprite put an instance variable.. say enemyShot=0

    Now prior to or in your shoot event initialize variable using action set variable enemyShot=random(0,6), or enemyShot=(choose1,2,3,4,5,6)

    Then use System compare instance variable and = 1 then action whatever, = 2, etc.. or in your example enemyShot<=5 regular shot >=6 special shot. (0 = 1.. so 1-7 is actually 0-6 in Construct2)

  • If I understand you correctly your problem is understanding the difference between saving as a .proj or as a .capx. Project or as a single executable file.

    Saving as a project keep your folder tree open and reduced load time with huge builds.

    Saving as a single .capx makes your project compressed into an executable file that neatly contains all your assets for you. The only problem with single file is HUGE projects tend to take longer to load than project (.proj) ones.

    I would recommend using the single .capx method. I save to the same .capx (keeping a backup or two periodically saved to dropbox via internal option) whenever I make a major change I save as a new .capx version number... mygame.capx - mygame-1.capx - etc. Makes keeping them organized in a versions folder much easier and I can go back to an older version if I learn my new change just isn't fun or working as I wanted.

    Construct2 will open multiple pojects/capx into the same editor session.. this is handy when you want to copy out code blocks from other projects/capx. They are added to the editor tree in the order you opened them so you simply need to find the start of each and close them from the tree view (right click option I think).

  • You can put as many instance variables as you want on a sprite object... of more than one type... are you assigning the instance variables in the left properties area when the sprite object is selected or creating global variables in the event sheet?

  • You can also use On-created event to do actions on the object being created.

    On created sprite1 set var x.snazzy = 5