GeometriX's Forum Posts

  • I'd also seriously recommend against using set frames. Why go through all that hassle for a bit of trickery?

    Using rotation towards a dummy object that uses the drag-and-drop behaviour, you can quickly put together a rotating dial as you can see in this example (taken from a metronome app I made a little while ago).

    For the directional emboss (which doesn't rotate), I used an object with transparency overlaid on the dial. I think the effect is convincing enough, and I imagine you could extend it to some simple lighting effects.

    If you are totally set on the masochistic practice of creating 30-odd frames for your dial, you could create an event to set its animation frame every tick to int(Dial.Angle/10)-1, with the frames loaded up in the correct order and the animation speed set to zero.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Ashley I've followed the best practice and I am using a collision object. This particular situation came about when I was trying to implement a sliding animation in a game, which needs more width than the standing animation to keep the sprite from overlapping the wall during the animation.

    I already have a workaround in which I check which side the wall is on and move the collision object out by x pixels. It's not really a matter of finding something that works; I posted a thread about this in General and the consensus was that I should report it as a bug because it's so consistently... inconsistent - it's spot on every time there's a wall to its right. California thought it might be linked to some greater issue.

    I do get your point though - it's simply not designed this way, and if it's not a straight-forward fix then I'm totally okay with that and I'm prepared to work around it. I think the concern (California's, at least) is that whatever its design is, is affecting other parts of the engine.

  • The jittery movement is caused be a small "fall" taking place (courtesy of the platform behaviour) after you set the X position to +1.

    I found it easiest to actually use the platform behaviour itself. Find the angle of the platform beneath the player, and, based on that, simulate movement left or right.

    Here's an example I made recently for someone else, based on the platform template. I've since applied it to my own current project and it needs a little tweaking, but the basic functions work fine.

  • California, I appreciate the vote of confidence, but I'm literally just referring to the floating issue here. I don't want to dilute my bug report with a broad approach, I'm just after a tightening up of an existing feature.

  • Ashley I expected you to say that, and to be honest I was reluctant to report this as a bug since you're obviously aware of this issue.

    But I have to reaffirm that this is an issue, because it's inconsistent. That "get me out of here" mode could actually be useful if it were reliable, but as it stands now it just doesn't make sense. It works perfectly well on one wall but not the other.

    If you could make it work in a predictable manner, that'd take care of the issue (and possibly solve that other anchoring issue that keeps popping up) and make the behaviour that much more powerful - it's half solved already.

  • Link to .capx file (required!):

    dl.dropboxusercontent.com/u/14522925/C2%20examples/PlatformerAnimationChange.capx

    Steps to reproduce:

    1. Use arrow keys to walk to the right of the platform (against the wall).

    2. Press C to change animation states.

    3. Now walk all the way over to the wall on the left. Press C.

    Observed result:

    In step 2, observe how the sideways block is simply pushed away from the wall and remains on the floor.

    In step 3, observe how the block is pushed away from the wall and a bit up. It then falls to the ground.

    Expected result:

    The change in animation should be identical whether there is a wall to the right or the left - i.e.: the block should not "float" when there's a wall to its left.

    Browsers affected:

    Chrome: yes

    Firefox: n/a

    Internet Explorer: yes

    Operating system & service pack:

    Windows 8 64-bit

    Construct 2 version:

    r134

  • 1: Mostly. The music took too long to load (there was about 6-7 ten seconds of silence before the track loaded), and once, when I died, the music doubled up and played on top of itself. Everything else played fine.

    2: It's a good level of difficulty, but the deaths felt a bit cheap (i.e.: I didn't feel like I had control over them). I died quite a few times because I couldn't see the spikes. I found the light circle frustrating because of this.

    3: It's fine. Bit confusing though. A black dude with a 'fro is fighting scorpions in what I can only assume is a temple, and there's this weird chanting down-tempo playing. I could handle two asynchronicities, but three is a bit much. Cheesy Indiana Jones-type orchestral or some hip-hop would either (or both) go down well.

    4: Taking my time and making the jumps felt pretty good. That's a really positive thing: when the player feels rewarded from pure gameplay mechanisms.

    5: The stabbing animation. It's so soft, so effortless. I'm sure this is a limitation of your own animation skills, and I know it's still in progress, but I'd seriously put some effort into this department.

    Good start though. Could be a fun platformer!

    Are you contractually obligated to tell us where the fonts are from?

  • California, No, so I suppose I should just post a bug report thread. Kind of worried it'll just get written off as me not following the prescribed practice of never ever changing animation sizes for collisions, but it is inconsistent, so there's clearly a greater problem here.

  • How far apart are they, though? What are the chances of the user really accidentally tapping on one of them? I tested a twitch-type puzzle game on my phone - one with objects that are only a cm away from each other - and I almost never accidentally touched two at a time, even during frantic sessions.

  • A simple way would be to adjust their collision polygons - make them smaller than the actual sprites so there's less chance of overlapping touches.

    If that's no good (maybe you need precise collision polygons), a slightly more complicated way would be to give each sprite a child object that is the one that's actually touched, and make that smaller. Be sure to pair them up in containers to make it easy to reference the parent sprites.

    A third option is to use different animations or frames - one with a smaller collision polygon, and the other with the full-sized one used for collisions.

  • I seldom use groups as coding mechanisms. I always thought they were just there to organise things :P

  • Everything is downloaded (to the hard drive) during the loading screen - either a custom loader or the default one.

    However, the actual artwork hasn't yet been loaded into system memory - this only happens when the object appears in a layout for the first time. So what's happening is you're loading a ton of artwork and animations into memory in your third layout, which takes a few seconds to happen, depending on the speed the PC it's running on.

    To avoid this sudden lag, I suggest loading some in-game artwork during your first two layouts. Just put some of the objects off to the side where they can't be seen. Maybe split it up into thirds, or whatever is necessary to avoid the lag in the actual game layout.

    Or make a fake loading screen to load everything into memory - create a single layout with all your artwork and something to hide it all, and make a fake progress bar to show the user that something is happening. When that progress bar's timer has elapsed, then move onto the game screen.

    So your game would look something like:

    0: Download screen

    1: Choose language

    2: Choose character

    3: Fake memory loading screen

    4: Game

    5: End screen

    Think about a game like Call of Duty: first you install/download it, then you load it up and go through some menus. But before you can get to the actual gameplay it has to load all of those assets into system memory. If it tried to load all the assets on-the-fly without at least a base of assets pre-loaded, performance would be terribly slow.

  • Create an event: At start of layout, set the sprite to the position of the rectangle, and pin it to the rectangle.

    If it's still offset then the origins must be off, or there's something else affecting the position of your sprite. Post your capx for us to see if you don't come right.

  • You've got a few options, but I like host on my Dropbox for testing. Export as HTML and copy that entire exported folder to your Public folder on Dropbox. Then, once it's uploaded, right-click on index.html in that folder and click "Copy public link". Paste that link in your post in the following format: Text for people to click on[./url] (Remove the . before the /url).

  • Thought this was an interesting challenge so I had a go at it. It's not perfect (the blocks sometimes go a little wonky), but otherwise it's fully-functional. I wouldn't usually make what's practically an entire game for people, but once I got started I realised it was actually really quick to do. The real challenge for you will be in creating compelling variants, and obviously tightening up the block movement.

    Nothing fancy, just some drag-and-drop with the snap-to-grid system from my tower defence tutorial, and checking when things overlap. Be sure to pay attention to the collision polygons for each shape - those are the key to this thing working.

    Here you go.

    Enjoy!