InDWrekt's Forum Posts

  • Here is an example that should do every thing you want.

    To use touch as the platform controls, just check the touch x value against the player x value. If the touch x is greater, simulate pressing right. If it is less, simulate pressing left. It's as easy as that. The only other thing you need to do is account for the jump control. I added an on screen button for that.

  • edit: Please tell me by the way that Construct can create games the same quality as the Stencyl arcade. If it couldn't.. that'd be upsetting! Though it should, but just incase, I'd like some reassurance.

    The answer is, "It Absolutely Can!" When you look at the Stencyl arcade, the one thing that the game there have is, attractive graphics. The graphics are not the game. If you want to make a game as "high quality" as those on the Stencyl site, all you need is a really good artist and someone familiar with Construct. Construct is, in my opinion, a much more powerful tool. It can do pretty much anything Stencyl can and more. That also means it is more complex. Adding power almost always adds complexity which takes time to learn.

    Your concern is, you don't see the same quality of games on the Scirra arcade as you do the Stencyl arcade. That is an issue with the people submitting their games to the arcade. Not an issue with the tool creating the games. Here is a list of a few games made with Construct that I think will show you what it can do:

    http://dirigogames.com/?page_id=114%22

    http://www.rustwork.com/games/evolve/

    http://www.superubieland.com/

    http://mortarmelon.com/

    [Edit] I removed a link to a game called "Bumper's Quest." I saw a game-play video for it some time ago and liked the look of it but, it never had a playable demo and doesn't appear to have changed since 2012. Sad because it looked like a really good project.

  • Though Stylus has a better arcade, why is that? I must admit, even though it looks like Construct 2 is better... the arcades really aren't convincing me! You should REALLY ask people to start uploading, err, better games to the arcade

    All I can say is, AMEN. This has been my biggest issue with the arcade. Users upload their junk tests (and even the result of following a tutorial) to the arcade instead of trying to put out a well designed game.

    On the other hand, as Aphrodite said, Construct is a tool. It only works as well as the person using it. You can make extremely high quality games. You just need to take the time to learn the tool. The only reason so many projects have such bad performance is, the people making them don't optimize them. This will happen with any tool you choose.

  • You do not have permission to view this post

  • I don't know of any tutorials that go over the differences. These are really html input boxes. You can google the differences between those. Basically, a Text input object is a single line input box which takes most ANSI standard symbol (numbers, letters and special characters). A Textarea takes the same values but allows the use of multi-line input.

    The Number type only accepts number values.

    All other options require specifically formatted inputs to be valid (example: the phone number field expects a 10 digit phone number). The name of the type describes how the input should be formatted

  • Try changing the Type in the properties to Textarea instead of Text.

  • Oh. I don't know then why it is doing that. Sorry.

  • This is an issue with the Tilemap object as seen in the manual under tilemap:

    https://www.scirra.com/manual/172/tilemap

    "When inserting the Tilemap object, Construct 2 may prompt you to use the recommended settings for tile based games. These settings are Point sampling, Pixel rounding enabled and Letterbox integer scale fullscreen mode. It is highly recommended to use these settings to avoid the appearance of seams, which can make thin gaps or lines appear between or along tiles. Seams occur due to fractional positioning or scaling of the display...."

  • You could also give the ghost an instance variable that is a cooldown time. When the character collides with the ghost, set the cooldown value and have it count down to 0. Only allow books to drop when the value is 0.

    Another way to do it would be to set a the current time as the variable and only spawn a book when the current time value is greater then the desired cooldown + the time value.

    Conversely, you could set the next time a book is allowed to spawn on the ghost and only spawn the book when the current time is greater than the time value set.

    Attached is a capx with all 3 examples. Pick the 1 you like the best.

  • Irbis

    I tend to disagree with you. The purpose of these default behaviors is to create a quick and simple series of actions which follow (what is perceived to be) the most common usage of these actions. It is not to handle EVERY SINGLE possible usage. As such, there are many things these behaviors are not going to do that each individual user may want. In these cases, there are 3 options:

    1 - learn to work with the behavior as it is.

    2 - create your own behavior that does what you want.

    3 - send in an enhancement request to have the behavior changed. If enough people show interest in changing the behavior to change Ashley's perceived idea of the most common way it would be used, and to add enough value to the product, then the change will most likely be made. If not, the change will only take away time for adding features that will add value. Why change something that is working as desired for the majority of users.

    Developing new features adds value that makes the product more marketable and brings in income. Changing features that are working just fine for the majority of users, just because a small minority want it, does not. That being said, I believe at least some of the features mentioned by shinkan would be very useful. Especially having the fade behavior take into account the current alpha value of the object when it begins to fade.

    BTW shinkan the axes drag and drop feature can be faked easily, and without too many extra events, by setting the x/y value to it's locked position every tick. If the locked axes is the y axes, set a variable to store the start y position and every tick, set the sprite y back to the stored value. If the locked axes is the x, do the same for the x. See the attached capx. You can do a similar work around to fake many of the other things you are requesting as well.

  • 1 - Cut down the number of events to 100 or less

    2 - Cut down the number of layars to 4 or less

    3 - Cut down the number of effects to 2 or less

    4 - Buy the program

    These are really the only options you have.

  • You could use the array "For each element" event. Create a variable to store the value. Then as you loop through the array, compare the current value to the stored value. If it is higher (or lower as the case may be), you would set the variable to the current value.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • That all depends on if you want the game to randomly choose the image each time, or if you want it to choose the background in a specific order.

    If you want to make sure it specifically cycles through each background in a specific order you will need to store the last bg used in a variable on the computer and update it each time the game runs. If you do this, you would have an event on start of layout to load the information and select the next bg in the sequence.

    If you just want a random background (and this is the easier solution) you would just need to create your background objects, and use the random(N) function to decide which to use.

    In both scenarios, you would use a global variable contained in an event sheet, which all scenes had access to, to store the background you have currently selected. You would set this variable on the first scene and and all the other scenes would just reference it to properly set their bg.

  • Instead of using a static value to represent each and every action, use instance variables to represent which version to display.

    I am assuming the list above of boy number and direction is what you name each of your animations.

    Use a variable to store the selected boy number: BoyNum = 1

    Use a variable to store the selected direction: BoyDir = "up"

    Then when setting the animation set it to: "boy" & BoyNum & BoyDir

    The above will result in the "boy1up" animation being played.

  • You could do it easily using an array. Use the array to keep track of the position of all the sprites on the board. Then, when the piece is dropped into place, test the array values. See the attached example.