GeometriX's Forum Posts

  • Why don't you use move commands, instead of manually setting the position every tick?

    Set up a custom movement behaviour and use that to move them to your touch locations, then give them an on collision event that tells them to stop when they bump into each other.

    Alternatively, set your entire "on touch do move" event to be conditional that the two sprites are not overlapping.

  • Hmm, yeah there's no inverse action of "on collision", so you could use the closest thing, which is "is overlapping with". This tests if the two are actually overlapping, which isn't possible with a wall which I assume you've set to have a solid behaviour.

    My solution: create a new object, called WallBuffer, which is dynamically spawned and resized to match every wall instance in the map, but is a few pixels wider. Test if the player "is/not overlapping with" this buffer (which is invisible, and isn't set to solid), to change your opacity to 50% and back.

    A quick capx to illustrate my point: here.

    EDIT: Ah, beaten by Nimtrix. That solution is actually more elegant, setting opacity to 100% at every tick, which is obviously then counteracted by the 50% opacity event. Nice.

  • If your sprites are in evenly sized cells in the sprite sheet then you can import the whole thing directly into Construct. With the animation editor open, right click on the animation frames window the bottom of the screen and click "import sprite strip". Choose the number of cells across and down, and it'll slice up your sheet.

    You can use parts of the sprite sheet, but you have to import the full sheet first and then delete the frames you don't want.

    If your sprites aren't in uniform cells, then you'll have to do it manually.

    In Construct speak, a sprite is a single 2D image. Multiple sprites can be arranged in succession to form an animation, and a single object can have multiple animations stored within it. A sprite sheet is a collection of sprites arranged in a single image.

  • No problem, I've updated my above capx to have a top-down perspective. Click on the ball to fire it off in a random direction. It'll slow down when it's over a sand trap.

    Linear damping does work. If you're not getting it right then check my file for the correct way to implement it.

  • A quick way to do this is to set up an invisible collision tester that sits over the sand trap. Whenever the ball is within that tester, set its linear damping to something quite high, like 5. When it's not within the tester, set it back to its original value.

    example capx

  • Ceil just means that it rounds the number up, as opposed to floor which rounds down, or round which rounds to the nearest whole.

  • There's no built-in way to select random objects, but you could make something yourself fairly easily:

    Create a global variable called randomiser, set it to 0

    • Every X seconds -> Set global variable randomiser to ceil(random(3))

    > Compare global variable randomiser = 1; trigger once -> Spawn object 1; set randomiser to 0

    Compare global variable randomiser = 2; trigger once -> Spawn object 2; set randomiser to 0

    Compare global variable randomiser = 3; trigger once -> Spawn object 3; set randomiser to 0

  • I'm sure that — could provide some input, but a very simple method would be to make your own particle system using lots small red blobs or pixel clusters with the bullet behaviour (maybe throw in some gravity, too). Run a repeat loop a good number of times to spawn these objects in a semi-random direction whenever you want some blood spray. Lastly, stop the objects in their tracks whenever they collide with the platform - introducing a degree of randomness with a very brief age timer to determine how far "into" the platform the blood penetrates.

    Edit: thought this was a fun idea so I made a quick little file to show you what I mean: arrow keys to move, space to splat

    Obviously it's not very performance friendly - it's generating hundreds of objects every time, but with some age culling and mixing in larger chunks with the small ones (by randomly choosing an animation on creation), you could probably get some decent spatter coverage.

  • In my current project (not an RPG per se, but a game that handles stats in much the same way) I use a bit of everything: Base stats are stored in local variables; upgrades to those stats are stored in arrays; anything that I need global access to even when the player isn't in the layout (in your case, stats like XP or gold) are stored as global variables.

    There's no universal wrong way or right way to store the information that you need - it just depends on the situation. I'd suggest that you start off with what you know. Arrays seemed like a weird, foreign concept to me when I started with Construct two months ago, and now I'm loving how useful they are. As my project has progressed and become more complex, I've grown to use the tools available and find better ways to manage things in my game, and I'll continue to develop new skills. I'm sure you can do the same, too.

  • If you're trying to create static UI elements, then you're half way there. In addition to the anchor behaviour, you also need to put the UI objects into their own layer right at the top of the stack, and set that layer's parallax property to 0,0.

    updated capx

  • You do not have permission to view this post

  • Nimtrix, just wanted to drop in and say thanks for that simple but very effective idea. I've been toying with how to do popup dialogue boxes for a while and for some reason using layers never occurred to me.

    So, thanks!

  • I'm trying to understand exactly what you need but it's a little difficult. Basically, you want to find a way to determine whether or not the red dots are ultimately connected through the pipe network?

    I'd suggest you give each pipe piece a boolean variable, like "connected" or something, that is activated under two circumstances: the pipe is adjacent to a dot piece; or if it's adjacent to another sprite that has connected set to true. Check each instance every tick to see if these conditions are met. If they're not, set connected to false.

  • You had already done most of the work - setting the arm to follow the mouse within certain constraints. Repeating that process to set the bullet angle threw out most of that work though; setting the bullet to use the arm's angle when spawned is the way to go.

    Updated capx.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • There seems to be a problem with your download link. Could you re-upload it somewhere else (like Dropbox)?