oosyrag's Forum Posts

  • The Global Text name should just be NameVariable.

    & is used to put strings and expressions together (for when you need to display it later).

    Edit: quick example - https://www.dropbox.com/s/ixxhux3nofbsb ... .capx?dl=0

  • Default name? I imagine you won't actually need to use this variable until after the player has set their name, so it shouldn't be an issue. You could probably leave it blank even if that's the case.

  • Sorry I don't think I'm going to be of much help for troubleshooting, I don't really have any experience in this particular application. I feel like in a bit of an awkward place, like a beginner giving advice to an expert ><

    I hadn't thought about pathfinding, that is going to be quite a lot of work! Even regardless of multiplayer, I don't think there are any easy ways about having multiple floors with pathfinding... Maybe might be of use? Run pathfinding per floor via tilemap, at least to the "exit" or "stairs" to the next floor.

  • Alternatively, you can round() your value so that you hit whole numbers. Use whatever fits best for your project.

  • First off I want to say don't be intimidated by arrays - they are in essence spreadsheets where you can store and manipulate data. One important feature is that they can grow and shrink as you need them, unlike variables, of which you have a fixed amount defined ahead of time. Very useful.

    Basically, your goal is to get teams randomly from a list without repeating. I would use two arrays - the first array contains all your teams and data, the second array starts off empty but when we need to we can move the teams in the desired order to the second array (so that the first two slots play each other, next two, ect.). After the data is processed, they can be moved back to the original array in the correct order as well.

    Here is the commented example - https://www.dropbox.com/s/uu31uxt73zkfx ... .capx?dl=0

    I made heavy use of loopindex, let me know if you have any questions.

    This technique is very similar to shuffling a deck of cards. Imagine you have a "deck" of 52 teams (or 4 in your case), and after you shuffle you draw the top two teams, play them against each other, and then keep repeating until you run out of cards. Sorting them back into the original order is optional.

    If you don't mind using plugins, here is a plugin that might be useful - plugin-smart-random_t163624

  • To be specific, construct exported games that push the limits of device capabilities will not run well on phones that do not support webgl. Overheating of processor can be caused by inefficient events. 20% of a desktop CPU can be significantly more on a phone.

    Basically, devices do have limits, and you need to design within those limits for whatever target for are aiming for. Changing engines will not magically remedy this.

  • First you need to clearly define what you are trying to simulate. So when you click the button...

    Who plays? Pick a random team. Then do they play another random team? And then the two remaining teams play each other?

    What to record? Score and win count? Is score chosen randomly as well? Otherwise what are the constraints or logic for scoring? Win can be based on score. Do you want to keep track of ties?

  • For each x condition and action, add a corresponding y condition and action with the numbers you want.

    I always like to suggest using an invisible helper camera sprite to make things easy to understand though. Just add to "scroll to" behaviour on it, and move it around as needed.

  • Ah. Well then you can use 10*2. 1^(n-1) for both displaying and subtracting money, and just add n items straight away.

  • On click

    Repeat x times -

    subtract cost from cash

    Add 1 item

    Set cost to floor(cost*2. 1)

  • I'm not really sure how to help you here, your project sounds pretty normal. 64 megs is fairly hefty though, compared to what I normally work with. If you have a lot of images to process into sprite sheets, it could explains the long save times.

  • https://www.dropbox.com/s/8a2ulvjh7033p ... .capx?dl=0

    Two problems (unique to going slow, my first example actually didn't work completely right either, it was just hidden by going fast).

    1. You didn't turn off using default controls. Jump overrides the move up one pixel event (you jump first, and then move up), so you pick up all the momentum from your jump when climbing the ladder, which is way faster than what you want. With simulate controls, you can put the jump event AFTER the move up one pixel event - you move up one pixel first, and are no longer on the floor, so you can no longer trigger the jump.

    2. Having two ladder events using else - the second else runs even if your first one doesn't, setting gravity back to 1500 thus overriding the first set gravity to 0. Moving one pixel at a time is not fast enough to fight against that gravity (moving 50 was).

  • Rounding error, very common when dealing with angles.

    https://www.scirra.com/blog/141/common- ... nd-gotchas

    [quote:127woonl]Expecting math calculations to be exact

    All modern computers store fractional numbers like 0.5 in a floating point format. If you want to learn more about it feel free to follow up the link, but we won't be detailing it here. The main point is because computers don't have infinite processing power and memory, they must sometimes slightly round results. This in turn can cause the result of a calculation to be slightly off its true mathematical answer, such as getting 0.999999 when you expected 1.

    To illustrate why this happens, consider dividing 1 by 3 with limited precision. The answer is of course 0.333333333... recurring forever. However computers have a limited amount of memory and can't possibly store an infinitely recurring number like that in full. Therefore they reserve room for a fixed number of digits, then stop. For example it might calculate with six digits and come up with the answer 0.333333. This is mathematically wrong, but your computer cannot possibly store the "right" answer, so it has to make do. Then suppose you multiply this result by 3 again. You'd expect three thirds to equal 1, but in fact you get 0.999999 - close to the right answer, but not exact. If your game expected the answer to exactly equal 1, you might find it's not working like you expected. You can usually inspect your project with the debugger to see the real answer that was calculated.

    This type of error affects all floating-point calculations in almost all software in all modern processors. There's no escape! It's just a fact of how computers work. The real details are slightly different - my example used decimal (base 10) whereas the actual representation is in binary (base 2), and recurring decimals work differently in base 2. For example the number 0.1 is exact in base 10, but is a recurring decimal in base 2. This means rounding can happen in unexpected places, even if you think you're dealing with exact numbers. It's particularly likely to affect object positions, since moving an object at an angle involves calculating sin and cos, which will usually produce results close to but not exactly the true answer.

    The workaround, which you must use with any software and any framework, is to allow a small tolerance. Don't expect an event like "Sprite X = 100" to ever be true. Instead use something like abs(Sprite.X - 100) < 0.01. This allows the comparison to be true so long as the result is within 0.01 of 100, so if it works out to 99.999999 your event still runs as expected.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • It should be as simple as changing c. Maybe you missed something.

    https://www.dropbox.com/s/bp2i7y0g7ie87 ... .capx?dl=0