calminthenight's Forum Posts

  • Have your users provide you with specific feedback and then use that information to narrow and troubleshoot. Look for patterns such as devices they are using, things they are doing in the game at time of crash etc.

  • No one can help you unless you post either your project file or images of your code. Without that nobody has any idea what you have or haven't done.

  • You can't use any non-physics behaviours with physics behaviours. If you need to move a physics object you need to move it using apply force or impulse.

  • Post your project file. This should work to scale the size of the text area.

  • I can attest to that. I experimented with it a while ago and it worked but I remember it being a bit of a pain. The new layer features will certainly help

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • You could rotate the layer that the tilemap is on (rotates around centre of viewport) and can use the new set layer scroll feature to set the rotation point to the centre of the layout.

  • Pinning and setting scale for width and height will scale the size of the spritefont text area.

    Are you saying this is not working? Or are you saying that you want the text itself to scale in relation to the object it is pinned to?

  • After dying no "playerlives" objects are respawned, meaning that the condition Playerlives.ID=Game.Lives is not true and the event actions do not take place.

    You need to respawn the three playerlives objects when you press the green sqaure.

  • Ok. Visual novels can be implemented without too much complexity once you know what you want. The core element is a dialogue system where you can store and retrieve the correct dialogue based on the player's choices.

    There's a few ways to do this but the most versatile would be using Arrays.

    If you can't find any links to visual novel tutorials for Construct I would begin by learning how arrays work using the C3 manual and some example projects.

    This is a C2 tutorial but the array object works the same in C3: construct.net/en/tutorials/arrays-beginners-170

    This is a tutorial on a dialogue system: construct.net/en/courses/displaying-dialogue-games-36

    Essentially what you need to do is write your dialogue options for each player choice and store them in a way that you can intuitively retrieve the correct dialogue from the array when it is required.

    I would start simple by creating a short and basic conversation with a yes no response to each dialogue.

    Example:

    Game - "Hello, are you having a good day?"

    Player Input - "Yes"/"No"

    Game for YES - "That's great! Do you want to play a game?" / NO - "That's too bad. Do you want to go to the park?"

    Player Input for Play a game? - "YES/"NO" / Go to park? - "YES/"NO"

    Game for Play a game YES - "Let's play!" / NO - "Ok, Goodbye."

    Game for Go to Park YES - "Let's go!" / NO - "Ok, Goodbye."

    END

  • What do you mean by "Choose your adventure game"?

    Do you mean a visual novel choose your adventure, a puzzle game choose your adventure etc?

  • You will need to use a different behaviour rather than tween, pathfinding or moveto will work, however proper collision avoidance is indeed a classic problem. I have previously used states such as IsChasing, IsBlocked. IsChasing would be when the enemy has line of sight and is not about to collide with another enemy, and it should move towards the player. IsBlocked is triggered by using raycasting to determine if a collision is about to happen and at what angle etc. Knowing that you can move the nearly colliding objects by math at an appropriate angle to avoid the collision and continue moving towards the player.

    I would avoid using solid collisions as it causes the exact issue you see in that video.

    Check out this video on Boids, it's not construct related but is good understanding: youtube.com/watch

  • Most of those things you listed aren't exactly behaviours, and can be achieved with only a few lines of code using existing behaviours.

    If you want to suggest a new behaviour I would try and narrow down something to a specific core function that does not exist as a behaviour, then test that against the difficulty of implementing it with current options.

    I welcome new behaviours that are relevant and improve qol, but I wouldn't want to see the behaviours menu bloated with the addition of behaviours that can easily be achieved in events.

    For example your placing objects in game suggestion can be achieved in three events using:

    On click - create shadow mouse.XY

    Every tick - set shadow to mouse.XY

    On button release - create sprite mouse.XY - Destroy shadow

  • create an instance variable on your player object and use 1,2 or even strings "sword" "fist".

    Set the variable to the correct choice when the player switches the weapon.

    In your 'on Y or B button pressed' event have two sub subevents that check for "sword" or "fist" and then place your relevant actions in those sub events.

  • Your event 3 is a top level event with no dependencies on other events. It will run every tick and will check for every enemies health value and return them all to 0 if there are any that are greater than 0.

    If there were continuously enemies with health greater than 0 you would see 1 added to kill count every tick.

  • A simple way is to create a boolean instance variable on your player object called "dash_ready". Make sure it is set to false initially.

    You can then use on player collision with trigger object - Set player "dash_ready" true.

    In your event 12 add the condition at the top "Player Dash=true". This means that the events will only occur if the player has picked up the dash ability.

    I would also add the timer behaviour to your player and on the b button pressed event, start the timer once for X seconds and call it "dash_cooldown". Then add the condition: player is timer "dash_cooldown" running (inverted) to the top event.

    This will stop the player from being able to infinitely dash.

    As for your other events you could improve them by moving your disable bullet action to the top level else event and delete the two sub conditions of the else event.

    The else will trigger if the platform object isn't jumping or falling so there is no need for the is on floor condition.

    I would also not disable the bullet behaviour on the b button released unless you intend for the player to have to hold the b button while dashing? otherwise it will cancel the dash as soon as it is released.