Colonel Justice's Forum Posts

  • This is because the effect code is not properly written for C3. It will consider the whole spritesheet where the texture is packed in.

    I used to work around this by using 1024x1024 textures for the mode7 effect and then setting the max spritesheet size to 1024 in the project settings. This will ensure that the mode7 texture is always the only texture on a spritesheet.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • You have to factor in the players viewport angle.

    Therefore :

    mode7 x: Player.X / scrollingfactor + cos(Player.Angle)

    mode7 y: Player.Y / scrollingfactor + sin(Player.Angle)

    scrollingfactor is related to player viewport height and screen resolution / mode7 object height and has to be tweaked.

    Also keep in mind for FPS purposes, the horizon line has to be at Y viewportheight /2.

  • I would check conditions inside the damage function, and then launch animations subfunctions whatever accordingly.

    My experience is that if you funnel everything through a damage function, you have a single point were to debug later on.

    Best example is the classic of the player being alive with negative HP. Not saying that it happens in your game but in general. To prevent this from happening, you have to put an event somewhere in your code that checks if the player health is 0 or below. Then do stuff. Not only do you need to put it in the right place in the event order, but it will get called every tick even if not needed.

    A better way would be to check it only when needed, and that is inside the damage function, because intrinsically the function only gets called when needed (mainly collisions, overlaps).

    The "downside" is that you should let the player only lose health through the damage function then.

    I played your example a couple of minutes and didn't seem to run into any problem but again, maybe I was missing a certain constellation that makes this happen. Overall I would vouch you go with damage function generalization. E.g. also do the player damage stuff with progress bar from there.

  • Thanks, I've been looking at the code and trying to understand what you want to achieve.

    Right now you have the functon "damage" that only seems to handle damage dealt by the player to enemies.

    You got several hitbox objects that contain the damage value depending on the attack I suppose, and try to retrieve the correct damage value inside the function (for each playerhits : substract damage, etc).

    You should abstract the damage function in order to make it more universal. That means no object picking inside the function other than UIDs. The reason is, how the function is built now, it won't work in the absence of playerhits (the loop would run 0 times).

    Also, I think by Construct's picking laws, every shuriken would get destroyed. If you later decide to have more than 1 shuriken on screen at a time (power ups etc.) this would be a source for bugs.

    The basic function setup is fine, however I would extend it to a certain degree.

    Think of what can cause damage in your game (enemies, shurikens, sword strikes, etc). Create a family, put all relevant objects inside and name it "damagedealers" or something. Attach a variable damage to it and set it accordingly across all objects.

    Think of what can receive damage in your game (player, enemies, destructible objects), put all relevant objects inside and name it "damagereceivers" or similar.

    Then in your damage function, add number paramater "source" or something.

    Now you are able to build more generalized damage events.

    Handle the rest inside the function.

    For example, create a basic collision damage trigger.

    ->On collision damagedealers with damagereceivers: Call function "damage" , passing damagedealers.uid as source and damagereceivers.uid as target, damagedealers.damage as damage

    Now you got everything you need to work with inside the function.

    For example, you can let the player lose health, let the enemy lose HP, destroy the shuriken, etc.

    On function damage ->

    "damagedealers": Pick instance with UID source:Do generalized stuff valid for the whole family. E.g. play hit sound.

    "damagereceivers" Pick instance with UID target: Do generalized stuff, e.g. substract HP or play hit

    "shuriken" Pick instance with UID source: Destroy shuriken

    "playerhits" Pick instance with UID source:

    ---> "playerhits" is sword-> spawn damage on layer main etc.

    "hitbox6" Pick instance with UID source: Destroy "hitbox6"

    Etc.

    The key point is to have every sub event using UID instance picking to get the desired object.

    I hope this helps.

    P.S.: Cool prototype!

  • Please share a sample c3p that we can work with together.

  • — I would love to see the last capx for c2 too.

    Maybe i will join the c3 train later this year.

    Keep up the good work!

    Hi, thx for your continued interest and support!

    I fear that this will not be possible, as the last state (53 or so) is not ready to be released without major commenting and code cleanup. I decided to put the effort in porting and developing the engine to C3.

    If there is enough interest, I may consider backporting the dev state to C2 (tilemaps etc), but it would be a major effort.

    I'm still evaluating what to do with it. Instead of creating a template I'd rather look for devs that want to collaborate and are serious about creating a game that sees the light of day.

    Cheerio!

  • You do not have permission to view this post

  • Since the save state is a JSON string, you can use the JSON object, locate the score data by parsing the string through the object, and then load the score.

  • I've been porting it to C3:

    Subscribe to Construct videos now

  • You have a while loop in the second event that runs infinitely. That is why the C3 runtime never will render the first frame, so you get a black screen.

    Since you don't have any other condition, it basically reads:

    While () : Do stuff.

    I guess your intent was to only add 0.1 to pump while E is pressed.

    In that case try the following:

    Keyboard: Key E is down: Add 0.1 to Pump

    This will at 0.1 to Pump every tick while E is pressed, basically meaning 6.0 per second (since the engine runs at 60 frames per second).

    If you need smaller amounts, either use a smaller value, or add another condition like every 0.1 seconds.

  • to 1) Ok. Be reminded however that this has an impact on sound caching. Sound files in the the sound root folder will be downloaded and cached before the game starts. Sounds in the music folder are downloaded while the game is already running and played when ready. Maybe that was causing the issue.

    to 2) Totally, you can add another animation to the explosive box called "Explode" for example, then put the explosion frames there.

    Then you adjust your event accordingly:

    On player collides with explosive box -> Explosive Box: Change animation to "Explode".

    Then add another event:

    On explosive box animation "Explode" finished: Explosive Box: Destroy

    This should spare you a lot of tedious work.

  • Nice work R0J0hound!

    Seems like your fingers were itchier than mine :D

  • Instead of spawn bullet at object, imagepoint 0, can you try:

    Create bullet at object.imagepointX(0),object.imagepointY(0)

  • to 1) Can you try with Chrome?

    to 2) No, since you pick precisely one with the collision event, namely the instance the player sprite collides with.