Hi Plinkie, thanks for the advice! Worked a treat in the end. I'll try to remember to post up the event sheet in case anyone else might need it in future.

Cheers

Hi all,

I was just wondering if there was a way to get the information of the 'thing' or 'wall' in this example that you're currently colliding with. I've set up a platformer that's got some wall grabbing on it, but since I don't want this to be apparent on every wall, I figured I'd just use an instance variable or something.

After a bit of tinkering I had no luck. If this isn't possible, I'm thinking of just doing some sort of checking sprite that'll overlap the wall and I'll get hold of things that way.

Anyone ever had a similar scenario?

Cheers

That's a nice result, thanks Tekniko! Still got the assets knocking around so it might be worth opening them up again and ironing out whatever point I left it at. Think I got as far as the BG scrolling and some patterned movement from the enemy ships, but nothing too substantial sadly...

I disappeared for a while and then came back (sorry about that). Thanks very much for the replies! Ended up sacking the project due to time constraints, but the points mentioned above do hold true. Before the thing was put to bed I believe they worked rather well.

Hey everyone,

I've been toying with the idea of creating an old-school shoot 'em up and have just been wondering a few things and wondered if anyone here might have some ideas.

Looking at something like R.Types you notice that the player moves forward through an infested screen with both moving and static enemies, both of which seem to spawn at designated times, or, appear to be 'fixed' to the actual layout (such as turrets). What got me wondering was how that actually even works. I mean, does the player basically move through the level, and the enemies just spawn at certain 'trigger points'?

If that's the case, does the player 'ship' have some sort of constant thrust, or, does the camera track along automatically, and the player is just kind of fixed to its bounds?

My other thought was that, does the world just move around the player instead perhaps, and all enemy spawners are just fixed to the moving layout which trigger when just before on-stage perhaps? It seemed like this approach might be quite expensive, as you'd have to move everythings x and y position. Seemed more logical that the player and / or camera would be the only moving part instead.

Anyway, cheers for reading and if you have any thoughts, would love to hear them.

Thanks, take care.

Just to confirm that it was pretty much just a case of sticking a block on the left of the camera using ViewPortLeft("CameraLayer"), and ViewPortRight("CameraLayer") to fix them in place. When the camera stops scrolling, the player cannot leave the bounds.

Also, enemies can freely pass through, so if you wanted to spawn stuff off-screen, you don't need to worry about that bit either.

It's made even nicer by the fact you can just turn the camera 'scrollTo' back on again whenever you wish.

Thanks again fm for your help!

Ah! I see what you mean. Thanks very much, I'll give it a shot.

Thanks for your reply! That's a good point, could work pretty well actually. It sounds more friendly rather than having to mess around with velocity and whatnot.

Currently player behaviour 'scrollTo' is active. Disabling this would freeze the screen tracking, is that what you're referring to?

Hi all,

I've been toying with the idea of making a streets of rage sort of clone of sorts. What sprang to mind was the progression through the stages. First off you walk forward then at certain points hit a 'choke point' in which you need to defeat a bunch of enemies before moving on.

I wondered how this might be achieved with something like C2. So my thinking was that you restrict the player to the visible area (so they can't go past those boundaries), until of course they've met certain conditions, then you re-enable it again.

So far I've just thought of dropping some solid objects just out of view, but that seems a bit messy. Or doing some sort of x coordinate comparison, if they're heading off-screen then prevent movement in that direction, etc.

Is there a simpler solution, or do you think the coord check might do the job smoothly enough?

Cheers!

Oh... Oh I see now...! I was doing it the wrong way round! *facepalm*

What I really need to do (which is what you've done Asmodean), is add the instance var to the family, then set it on the sprite that way instead, as it filters down to it (which I had no idea of).

It makes so much sense!

Thanks so much for that Asmodean, I owe you bigtime!

*bro hug*

Yes, if I use a family instance variable, that doesn't allow for a fixed unique property. So, for instance I could use a 'health' property on each different enemy, as that doesn't need any specific identity.

But if it's say a 'name' of an npc, then that needs to be set on the actual child itself, as you'd have different characters with different names assigned to them.

Something like that : P

Hello sir,

I've uploaded an uber simple case example for your / anyone else to look at:

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

You'll notice when clicking the boxes, the correct UID is shown so we know it's picking up the different instances, but there's no way to access the individual static ID on said instance. If however you look at the browser console log, you'll notice in the JSON output that the static ID value is actually visible (you'll notice a '1a' and a '2a').

Those are basically what I need to access.