GeometriX's Forum Posts

  • You need to share the capx for your project, not the caproj. File -> Save as single file.

  • When you pin an object to another one, the pinned object uses its current position relative to that object as its base position. You can move the pinned object to anywhere on that receiving object that you'd like, but once you pin it, it'll stay in the same relative position to that object, just duplicating the receiving object's change in position and angle, but not its actual position and angle.

    So, first move the object to exactly where you want it to be, then pin it. If you want it to move to an image point on that object, then move it to an image point.

    If the receiving object is animated in such a way that this image point moves or otherwise changes, then the pin behaviour is not suitable. In such a case you should rather use every tick -> set position to object, and specify the image point in the action.

  • There is GPU/CPU overhead for running multiple instances of the same sprite, but in terms of memory usage it's treated as a single object.

  • It'd be the same thing, since sprites are fully loaded into memory (with every single animation and frame) as soon as the layout starts.

    Also, relevant. If you're really haggling for memory then you should probably just use one or two base layers as tiled backgrounds, then sprinkle them with sprites to add variety.

  • Pinning is pretty straightforward:

    1) Create the object to be pinned, and the object to be pinned to.

    2) Give the pinning object the pin behaviour.

    3) Either in the layout or the event sheet, set the pinning object to the correct position on the receiving object.

    4) In the event sheet, select the object -> set pin -> receiving object.

    If you don't come right, post your capx so we can take a look.

  • There are a number of touch tutorials that cover this topic in detail:

    scirra.com/tutorials/398/touch-stick-controllers

    scirra.com/tutorials/189/on-screen-touch-controls-for-button-games

    scirra.com/tutorials/202/touch-controls-and-a-trick-to-detect-input-method

    Also read this manual entry on the subject: scirra.com/manual/119/touch

    But basically, the easiest way is to use on-screen "buttons" (sprites) that the player taps instead of the physical keyboard buttons. And in this case, you'd then create events to simulate control of the 8-direction behaviour and shooting mechanism.

  • sosensible, we encourage people to post capx files that they're working on, purely so that people who do wish to help can download the files, have a look through them and give suggestions based on evaluating the project, rather than simply guessing as to the inner workings of it by playing it online.

    It also allows those who wish to help to simply edit the broken capx files and re-upload them, usually with an explanation of what was fixed and how.

    While people can share their capx through the Arcade, Dropbox is by far the simplest method to upload and share these files.

  • keepee, ah, cheers for that. Makes sense.

    sosensible, Dropbox is the de facto standard for sharing files around here.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • sosensible, uploading to the Arcade is a waste of time for these quick fixes. People much prefer to download the capx directly from Dropbox - it's hardly a random site :P

    fassFlash, my pleasure.

  • Random doesn't produce whole, rounded numbers.

    This means that random(4) will give you anything from 0 to 3.999r, with 1.89237783 and 2.12301203 and everything else in between. You should use round(random(4)) to get a whole random number from 0-4.

  • It sounds like the events are running a loop, since reappearing at the destination triggers the collision event, sending the player back to the first teleporter, and on and on it goes...

    I'd suggest adding a short timer to the player to prevent this from happening: reset the timer whenever the player teleports, and only activate the teleporters if the timer has elapsed a few seconds.

  • Rhindon, yeah, that sounds about right. I'll organise major groups under initialisation, UI, player controls, enemy behaviour and so on, with sub-groups for more specific things.

    Personally, I find the tabbing in C2 to be pretty chaotic. It never saves tab positions and with all the tabs on one line it becomes a chore to flip through them when you get quite a few going.

  • I like to keep all of my core gameplay mechanisms in a single event sheet, which I organise by being very liberal with groups and sub-groups. It's also where I keep my debug group, which I sometimes split off into its own sheet if it gets too big. I then use a small event sheet for each of my game's levels. I also use a separate event sheet for global variables, as those can't be neatly tucked away in a group (for some strange reason).

    I find that this process forces me to make my events reusable, so in my level event sheets I basically just put in the parameters for each level, like MonsterSpawnRate or LevelTime, which is then passed along to the main event sheet. If a particular level has its own unique mechanisms, then I just put those events in the local event sheet. As soon as I find that I want to use those events in another level, I go back to them and make them suitable for reuse by changing any fixed numbers that need to be variable, and move them to the core sheet.

    Otherwise, I comment for every major block of code, but this is often superfluous and I just do it to visually break up the events. I also make sure that my projects tab is well organise with groups and sub-groups, and I do my best to use families wherever possible. I'm also now starting to get into the habit of making better use of functions where it's appropriate, like for character dialogue.

  • I can't be certain, and if you'd share your capx it'd make helping you a lot easier, but try format your events like this, with everything after num player in sub-events:

    num player = 2

    is touching player1area -> set animation

    else -> set animation; destroy countdown

    is touching player1area -> set animation

    else -> set animation; destroy countdown

  • cesarzevil, we get that you're frustrated, but you need to keep a cool head about this. Nobody told you to shut up. There's been some bad advice given in this thread, but most of it has been good, and you seem to have ignored all the good stuff.

    I still think that this is a matter of incorrect use of the software rather than the software itself, and I strongly suggest that you send an email to Scirra directly with your capx. That way the best possible people can have a look through your project without you standing to have anyone steal your idea/game/whatever.

    I'm not saying that it's unreasonable to ask for a refund if the software doesn't do as advertised, or even if it's just not suitable for you (in my country, we have a seven day, no questions asked return policy for all goods, for example), but I do think that you should give it a proper go before giving up.