Okay, had a look at this. The problem is that you have the condition of mouse click on the envelop as a sub group of the condition when the player is NOT in the dining room. If you take the mouse click on letter condition out of this subgroup, it works. So it's just a matter of putting the condition in a different spot.

I would actually suggest you stop at this point and take a bit of time to start using groups, as it's going to make tracking this sort of stuff a lot easier, especially as your project gets bigger.

Are you saying you want to max the variable out at 100 (so a player can't have 101, 102, etc...)?

If so, just have an event setup like so:

Condition: variable health greater than 100

Action: variable health set to 100

If that's not what you mean then sorry, having a hard time understanding what you're trying to say

Heya

Had an idea rumbling around in my head for a few years without ever touching it as I felt it was above my skills, though as I get more experienced with game design, it's something I think about more and more, and now that I've discovered C2, I ask myself if it's an engine that would fit this type of idea.

Anyway, got a hypothetical question regarding this idea. I wanted to create a game that potentially has a lot of characters on screen at once, thinking up to 30, and have the potential for each character to be visually different.

With Spriter, I could see this working well as I can rig up my animations once and set the sprites to switch out to change things like hair, weapons, skin tone and clothing without too much trouble. This would give a nice amount of variation to the characters on screen, and would also allow additions later on to increase the variance if I wanted. If I went with sprites, I'm pretty sure the system could handle this if all the characters are being loaded off the same sheet, but spritesheets can be pretty limited as you can't really make little adjustments to characters without redrawing the whole sheet. And even if I did have a bunch of different sheets (say 10 all up), I wonder what the impact on the performance would be by having so many loaded in at once.

My question is about performance. If each character has 16 bones, and there's 30 characters, that's going to equate to 480 bones on screen at once. Seems like a lot, and I'm wondering if C2 can even handle something like that.

Has anyone worked with Spriter in C2 and can give feedback on performance with large numbers of bones on screen at once?

Sounds like you want separate global variables for life and regeneration stored as a number value.

When you level up, you can add to the variable by however much you wish it to be.

remove the https:// from the link and try posting again. I know, it's annoying.

probably lots of ways. One way I could think of is to have an idle timer set in a variable which activates when the character stops moving and increases by 1 every second, then compare that in an event. If it reaches a certain number (thinking in seconds and however long you want it to wait), then set animation to the sleeping loop.

when the character moves, that variable just needs to be set back to zero.

Hey CreativeMind, sounds like fisholith has this covered. just thought I'd add to it though in case you decide to go with the tiled background method.

I've been working on a game for a couple of years called Wildfire. It's a GameMaker game, so we're not concerned about mobile performance, but one of the ways we handled snow was by creating tiling sprites that are largely empty aside from the snow. By having several of these layers, and working within the current layer order of your game, you can add a greater sense of depth. this can be achieved by having the closest layer with larger drops, scaling down as you go further back. for you it might be dependent on how far you want to push the hardware whether you go multi-layered. You can also change the fall angle for each page to add further differentiation.

One thing I would suggest, if you go this way, is to download a program called Pyxel Edit and create the image to the size you want it, by having a bunch of tiles to display (so, for example, start a new doc, you might want to set it to 20 x 20 tiles, with a pixel resolution of 32x32). You can then assign each tile to be the same, so when you draw on one, all of them get drawn on. This is massively helpful for making tiled backgrounds as you'll be able to see it in a live update as you draw inside the tile.

It's what I used when I did the snow, which looks like this:

I haven't been using C2 for that long, so not sure on best method for this. But my suggestion would be, you have an event there for the key press already, so use the action 'set animation' in there. Have it mirrored in the opposite direction for the other key press event.

How's this?

dropbox.com/s/9k2722k6x3rmdc1/escalator.capx?dl=0

I used platform behaviour on the box as I had no idea how you planned on getting them to move around.

Cheers R0J0hound, that's really nice.

In terms of CPU performance, would using LOS be a better option over pathfinding? I'm feeling like the answer to that one is probably a yes, based on what I've read of the pathfinding behaviour but I wouldn't know.

While I'm only ever planning to have a maximum of three friendly instances following the player, it's something that I can see being easily transferred to enemy behaviour too.

I might run some tests with multiple instances all following the player and see what uses the most cpu.

Cheers

Awesome, thanks 99instances2Go. I'll have an in depth look at this later, but it looks pretty smooth.

Ethan, I considered LOS, but it's not something that I think fits my friendly ai. Will be something that I consider for the enemies though.

Cheers

No worries.

Just had a thought with that capX though, as soon as you start adding ship movement, the beam will break as it's a series of overlapping minisprites.

Should be an easy fix though. What I would suggest is an invisible sprite with a timer set to it that spawns the beam. so when you shoot, an instance is created at the ship, that instance spawns the beam until the timer runs out, then is destroyed.

That way, you can shoot and move away and the beam will continue to fire from a single point.