LittleStain's Forum Posts

  • I believe the 4 stands for R,G,B and Alpha.

    Some simple questions to help you along:

    Do you really need the sprites to be this big?

    Could you work with repetition instead of using new sprites?

    Can the animations be shortened without instantly looking bad?

    Even large game-making-companies use techniques like repetition to reduce the amount of graphic memory used by the game. It's just one of those things gamemakers should take into account.

  • If you have the map, and the framework to import positions of the car in realtime, it should be possible.

  • There is a difference between a saved image and a rendered image. Saved images are compressed to take up the least amount of space possible.

    While being rendered the image is not compressed. so one 512x512 image will take up 512x512x4 = 1048576bytes of graphic memory.

  • I'm working on a tutorial about picking, because there are still many questions about it. I'm not that good at writing (and explaining), so it might take some time..

    Here's a quick look at the rough draft:

    How does picking work?

    When first starting to work with construct 2 (and even for some of us working with C2 for a longer period) it can be hard to make actions that only affect the instances of an object you'd like to affect.

    Let's start with the simplest event:

    Bullet on collision with enemy ? enemy destroy

    In this event it is clear that it is our intention to only destroy the enemy that is hit by the bullet and it works as expected.

    In my understanding Construct 2 reads this line something like this:

    Destroy each enemy instanc that is hit by a bullet.

    Without undertsanding how picking works one of the first issues arrive when trying to destroy enemies when their healthpoints are low.

    Let's have a look at these events:

    (enemy has been given an instance variable ?health? set to 2)

    Bullet on collision with enemy ? enemy subtract 1 from health

    System compare two values : enemy.health < 1 ? enemy destroy

    When testing these events with multiple enemies on screen, you will see that if you hit one enemy two times, all enemies on screen are destroyed. What is wrong here?

    Basically the first event works as intended, 1 is subtracted from the enemy health variable of that instance only, much like the enemy destroy action mentioned before C2 reads the first event something like this:

    Subtract 1 point from the health from each enemy instance that is hit by a bullet

    So the trouble must be in the second event.

    How does C2 interpret that event.

    Check if the health from any enemy is lower than one, if so destroy all enemies.

    But why?

    This is because we haven't told C2 in the event which enemy we are talking about in the action following the event. No enemy instance is referenced in the event, so the actions apply to all enemy instances.

    How to solve this?

    The simple answer is: By telling C2 what instances should be affected by the action(s)

    One way would be to make the system compare event a subevent of the collision event. We have seen that in the collision event the right enemy is picked so adding a subevent it's actions will be referencing the same instance.

    Another way would be adding a system for each enemy as a condition to the second event. That way C2 will pick an enemy, test if the condition is true, act accordingly and pick the next instance and repeat the testing, untill all enemies have been picked and tested.

    So with the for each event the instances are picked before testing the other conditions and as such the actions are related to the picked instance.

    ...

  • Like I thought..

    The nutsack event is like this:

    acornbullet on collision with nutsack - do stuff

    Both acornbullet and nutsack are referenced in the event.

    There is only one acornbullet colliding with one nutsack, so it is very clear which nutsack is meant.

  • I'm not sure why it seems to you that scaling for mobiles like explained in the tutorial wouldn't work on the most used exporter for mobile.

    The ways described should work.

  • Using a global variable would probably be best here, but if you want to use an array it would be something like this:

    player on collision with finish

    trigger once

    -array set value at 0,0 : array.At(0,0)+1

    system every tick

    text set text : "score: "& array.At(0,0)

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Your not picking an instance in your event, so the event works for all instances of the object.

    In the FAQ of this forum there are many topics about how picking works and how events work.

    In this case if adding a for each condition would work, for it would check per instance if your conditions are true, but I recommend you read up on how events work and how picking works, it will save you a lot of headaches.

  • Well 8=8 is always true, isn't it?

    You should compare a variable that changes to the 8.

    So, on ghost destroyed add 1 to variable. if variable is 8 set "you win" visible

  • Ok, but that seems to have little to do with the "birds" example.

    Im not any good with construct classic, but in Construct 2 you can set the angle of gravity in the events for platformer behaviour.

    That way it should be relatively easy to do what you desire.

  • That's almost like asking how do I make this car drive on water..

    To which my answer would be: "why not try a boat? That's what it's for!"

    If you are talking about making a rotational platformer however, there is an example shipped with construct 2.

    If you'd like to use both the physics part and be able to control the "bird" after launch, you might be able to use grouped events to switch between the different behaviours, but I'm not sure that would be a great idea.

    Could you maybe explain what it is you'd like to be able to do and why you want to use the platform behaviour instead of the physics behaviour?

  • what behaviour are you using to move your sprites?

    Are you using the mouse or the keyboard to make the player move?

    Will the player be able to go diagonally or only straight?

    will the player be able to set destination further away than one grid-move?

    grid-based movement can mean a lot of different things to different people. In the FAQ there are some links to topics where people have tried. Using the search function you can find even more topics.

    Basically it's setting the destination of movement based on the size of your grid.

  • I'm thinking you are overcomplicating things a bit.

    Couldn't you just have the direction the object is moving on collision determin the imagepoint to connect to?

    Also using buildable and buildableother is confusing me, but that might be a personal issue.

  • Like my Art-teacher once said:

    You will never learn to paint like Van Gogh by reverse engineering his brush-strokes..

    :)

  • Is there a reason it should be externally?

    Why not use what you have at your disposal inside Construct2?