Fimbul's Forum Posts

  • So if we want to use big images, don't care about slight pauses, but care about memory usage (say, if we're making a hidden object game, point and click or RPG), we either use a separate layout or "load image from URL"?

    Ughhhh, not another one of these...

  • Try this:

    [attachment=0:3fhkr9uy][/attachment:3fhkr9uy]

  • Problem Description

    When moving an object "up" (270º) using the "move at angle" action, the final X position is not consistent. Sometimes you get a rounding error and some times not. The error is related to the initial X position of the object and the distance moved.

    For some reason, moving the object "down" (90º), left (0º) or right (180º) doesn't seem to trigger the bug.

    Steps to Reproduce Bug

    • Run the project in the debugger
    • See that the sprite's X position (after it has been moved 20 pixels) is 63.99999999999999. This is unexpected.
    • Change the sprite's initial X position in the layout editor to 128
    • Run the project in the debugger
    • See that the sprite's X position (after it has been moved 20 pixels) is 128. This is correct.
    • Change the sprite's initial X position in the layout editor back to 64
    • Disable the second line and enable the first
    • Run the project in the debugger
    • See that the sprite's X position (after it has been moved 19 pixels) is 64. This is correct.

    Observed Result

    The final X position has a rounding error depending on distance moved and initial X position. The exact values that trigger the bug are somewhat arbitrary.

    Expected Result

    Since we're moving the sprite exactly 270º (that is, on the vertical axis), the X position should be unaffected.

    Affected Browsers

    • Chrome: YES
    • FireFox: YES

    Operating System and Service Pack

    Windows 7 x64

    Construct 2 Version ID

    Construct 2 r166 64-bit

  • It's almost same to Firefox OS

    I wish FirefoxOS would overtake Android. Alas, it will probably never happen...

  • Well I was somewhat wrong and somewhat right. Yes the downward motion is to be expected if you do it like that (like I said), but it's also what you want. The downward motion is desirable.

    It stems from the fact that once the engine places the first platform, it starts connecting them front-to-back, and since you're always correcting the newest platform (pushing it down), the newer platforms will accumulate the effect.

    How do you fix it? By making the platforms go "up" to offset the motion: Like the comments say, the engine is lacking scrolling. You need to add logic to keep the platforms (or the player) centered on the screen, and you cannot rely on the automatic centering provided by Construct 2 because your game is an infinite scroller, not a predefined level.

    There are many problems with using "tiles" in the way you're describing:

    • The player has a cyan "detector" sprite below him, and it relies on thin, rectangular platforms to work, otherwise it might detect two platforms simultaneously and not know which angle to pick. The thinner the platforms, the less this problem happens.
    • With fixed tile platforms, you can only bend the pipes in 90º increments.
    • With tile platforms, you can no longer use the platformer behavior to handle player movement, you'll have to come up with custom movement logic.
    • setting addY to 24 does not make the platforms align. 34 works better, but makes the tiles overlap. Also this only works for the initial angle, all other angles break. That's because addY depends on the angle, it can't be a fixed value.
    • Having isometric tiles make the whole connecting logic collapse, since when the engine tries to figure out where to attach the new platforms to the old ones, the maths give it the wrong answer, and things look jumbled.

    This is not to say that isometric tiles are impossible, it's just that they're very very hard to work with this engine, which is designed to support a platformer.

    If you do want to stick with tiles, I can help you a bit, but it involves starting over from scratch.

  • I forgot to upload the fixed version. Here you go.

    Also helena, don't just "round" the values, please, otherwise this bug might come back to haunt you.

    My "fixed" version is a better workaround than rounding, but it's even better to implement the proper fix like I described (by using gridX and gridY as basis for player.x and player.y).

  • Got it.

    The problem was a rounding error when setting the player's X position when moving UP in the first column.

    It was being set to 63.99999999999 instead of 64.

    This is likely due to using the "move at angle" action not being precise enough.

    The bug is fixed by replacing those actions with "Set Position" actions and manually adding/subtracting from X/Y coordinates.

    It would also be fixed if you replaced your int() logic with round() logic, but that would be more akin to masking the bug than to actually fixing it.

    A better solution would be to not rely on the player's X/Y position on the canvas to determine it's X/Y position on the grid. Set the player's X/Y position on the canvas based on it's X/Y position on the grid, not the other way around.

    To see the bug in action, open your broken capx and:

    • select the player object in the debugger
    • Watch it's X position, it should be TILESIZE (in this case, 64)
    • Move down. It's X position should still be the same (64)
    • Move up. It's X position should be slightly lower than TILESIZE (63.999999999)
    • Your expression evaluates GridX to int((63.999999999/64)-1) -> int(0.99999-1) ->int(-0.00001) -> 0
    • You expected it to evaluate to 1, so your code breaks.

    That was a tough one! Ashley, we have a rounding error here, possible bug?

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Nope, it still requires JSON-TMX importer.

  • Post your capx again and I'll take a look.

  • Could you please create a version that uses no third-party plugins? I might be able to take a look.

  • You'd probably get some performance boost (due to them using a better browser as a wrapper), but I think it would be more about look and feel.

    For instance you could expect zero overlays (no address bar at the top), APIs for accessing phone features, automatic packaging of assets (in some other format that is not APK), direct download from the Play Store, ability to invoke system dialogues and create alerts/reminders, ability to run in the background, etc.

    I am just speculating, though.

  • Fimbul, only the graphics look like isometric but concept is still the same. Instead of rotating the platform, I want to use a curved platform to represent the change in direction. I drew an isometric diamond around the pipes to give you an idea of what ends need to join when a new tile is created.

    I see. Well in that case you could draw a "connector" bend every time the direction changes.

    Your logic works perfectly, I was even able to randomly pick variously tiles and make a continuous path. The problem I am facing is when I try to adjust the height with the previous tile, the whole platform starts drifting downwards.

    Y= (Platform.Y)-sin(Platform.Angle)*(PlatformWidth/2)-sin(PlatformCreationAngle)*(PlatformWidth/2) + addY[/code:1qb3e2sa]

    That code is responsible for scrolling all platforms! Adding/subtracting a number means "add drift" in this context, whereas multiplying by a number means "change the speed". Your code adds to Y, which means it's going to drift downwards.

    Let's simplify the formula so that it becomes easier to see:

    Y=(Platform.Y)-sin(Platform.Angle)*(PlatformWidth/2)-sin(PlatformCreationAngle)*(PlatformWidth/2) + addY

    This looks suspiciously like:

    Y=Y+addY[/code:1qb3e2sa]

What you need to do is:
[ul][li]Pick only the instance you just created (the create-object action pre-picks the newest instance for you, but I don't know if it "un-picks" the other instances, you'll have to test)[/li]
[li]Add/Subtract to it's Y position only once (preferrably at the moment of creation). You don't need any fancy formulas to it, just add directly to it's Y position.[/li]
[li]I would avoid adjusting the X position, since that can cause seams to appear. The platforms will always be coming from the right, correct?[/li][/ul]

    Most Importantly: If my game ever sees light of day.... I will give you all the credit for helping me

    Don't worry about that man, just pay it forward.

  • Ah, I understand now what you're trying to do. I was operating under the impression that this auto-runner of yours was a platformer, but it's an isometric game...

    Which is quite weird since your drawing on the original post showed a platformer-style auto-runner. Did you change the scope of your project? If so, this smells like feature creep, and you should probably revert to the original platformer design.

    However, if you still want to press on with the isometric gameplay, you're better off ditching the whole logic and starting over with a modified iso tiling engine (one that only draws the tiles you need), since your pipes are basically tiles. There should be some examples around in the forum.

    When creating new tiles, remember to push them to the bottom of the z-order, and use image points (as well as instance variables) to create attachment points for the newest pipes.

    You'll need to scroll all the tiles instead of the player, which will have to be done using basic trig (you can't rely on the layout editor to handle the scrolling for you).

    All in all, I recommend reverting to the original design.

  • Thanks for this advice, I'm really grateful My goal was to work on a large game company and make my own games, but sometimes i feel hesitant. Actually I'm the 1st in my school, always get high grades, thus my dad wants me to be a doctor or an engineer, and earlier when I began making games and told him that I want to make games as a career, he discouraged me and made me feel bad, but I know he wants the best for me and want me to live better than him. That's why I'm asking all this questions about salaries and the industry.

    If you're good at school, definitely don't go towards gaming as your primary mean of generating income. In this point, your dad is correct.

    On the other hand, I don't think a career as a lawyer or doctor will be good for you. Yes you'll make money, but those jobs leave you too exhausted to do anything else. Since you're young, I would look towards a job that:

    • Requires skills you can reuse to develop games. Programming and design are good bets.
    • Has stable long-term prospects. You don't want to become a bus driver, gasoline-engine mechanic or anything you suspect will cease existing in the next 20 years.
    • Is an office job with low hours and/or low workload. For instance you don't want to become a civil engineer and always be walking around a construction site giving orders. Don't worry too much about high payment, but do look for something that can sustain you comfortably.
    • A high barrier to entry would be nice, especially considering you're a good student. For instance, government jobs usually require a test, and once you're in it's impossible to be fired.

    You could also try a more fancy route, such as becoming a Computer Scientist, since you get all the perks above and, if you're lucky, can even integrate your game design directly into your research.

    Mostly, it's about finding non-standard routes into the industry.

    Avoid becoming a professional game developer. You'll notice I didn't even list it as an option in my list, and that's because it's not viable. The AAA industry is on the verge of a crisis, all the jobs are concentrated in the USA/Canada, the pay is horrible, the journey to become an actual designer is super boring and unrewarding (you join through QA, then become a programmer, then a designer), filled with overtime, turnover is extremely high (with professionals in the industry lasting less than 5 years on average) and you'll rarely design the games you want.

    That said, for now, you don't have to worry about it. Keep making games!