tunepunk's Forum Posts

  • Hey Sirvoid and tunepunk - quick question for you guys... is this a pretty common latency/lag scenario? I'm only sending X and Y every .3 seconds, and I'm sending it via a token:

    I know it's not TOO bad, but is there any way to tighten it up a bit more? OR in either of your experience, can you still have a great and competitive game session experience with that bit of lag? Or how would I work around it?

    Thanks guys - you guys seem to know a lot about Photon so I figured I'd ask. Sorry to resurrect an old thread like this.

    Hmmmm. For this kind of game i don't think i would send XY, except for adjusting positions.

    If movement speed is constant, you can just send for example on key press: Sending only move, and the direction. For jump, send jump, speed and direction, and when the character stops moving you send stop moving, along with the XY position of the place to stop at, so the position is synced. A little bit of lag you can't really escape, but for this kind of game i would limit messages by just sending, on key down, and key up, basically. No need to send every 0.3 seconds.

    The other clients would simulate exactly what the other player did.

    For bullet's I'm not really using real bullets with collisions. I'm using a raycast approach on fire, and only send the XY position of the origin of the bullet, and the end position of the bullet (an solid object hit), when the other client get's that informatioin, i just move a sprite between those points, and detect collisions simply by distance between bullet player < XX pixels.

    Hope that helps. If you have any other questions you can send me a PM,

  • Yeah it's probably the tint effect. I tried that as well, and it's not a good idea for mobile. Try remove the tint effect and you should be fine.

    Never use webGL effects for mobile. Not even blend modes, as they can also be heavy.

    For mobile i would recommend using sprites of different color. It will use a bit more memory, but you will have much more smooth fps.

    Opacity is not really a problem. If you want something to have different color, the best solution is to tint in the sprites in photoshop or something, and have different set of sprites for the different colors you need.

  • Are you using any or these:

    WebGL effects?

    Particles?

    Text object?

    Those are usually the biggest FPS drainers on Mobile.

    If your CPU is high and FPS is high (Usually it's code optimization problem)

    If your CPU is low/average and FPS is low (Usually graphics problem, particles, WebGL, Blend modes, text object etc)

    IF CPU is high and FPS is low it could be a mix of both or simply too many things going on at the same time.

  • I think he is trying to reach a point with pathfiding that has moved since he clicked?. (a bullet) So when the character reaches that place he wants to end up at the bullet's current position. Not where he clicked?

  • I think you can use the physics behaviour?

    https://www.scirra.com/manual/98/physics

    Edit:

    Apply force towards position might be what you're looking for.

  • Does spriter characters have any ragdoll mode?

    Can you edit bones within a game? Could you for example create a rock climbing game where you move the limbs of a spriter character individually in game?

  • It's not going to work well when in close proximity to corners.

    Why would that be? If the ray is wide enough (wider than the character) it would detect overlap even on corners.

  • This was just an theory i had to try to create an alternative pathfinding, that doesn't always take the shortest way, but has a little bit of randomness to it. I just wanted some feedback if this would be a good approach and maybe some way on how to improve it. Hopefully it will be quite lightweight as well as it can be called in a function each time the NPC reaches one waypoint.

    It's basically built on a raycaster that works in 2 steps. First step just calculates the next impact point, towards the target, next step creates 2 rays that rotates either clockwise or counterclockwise, then shortens that ray to the next edge of the impact point.

    1. I use a normal raycaster to determine the next impact object, and get a distance to the next casting point (black circle).

    2. Two new rays are cast, which instead of shortening, rotates towards a few degrees the next angle that doesn't have impact. After an angle is found that doesn't have any collisions, the ray length is adjusted to edges of the impact object, and determines 2 points to where the character can go. (Green arrows). The character picks one of these 2 positions and moves there.

    3. in this case the character picked the red path, so when he reach that point the raycaster triggers again. Same as #1 in the image. A ray is cast towards the destination point.

    4. The new impact point creates two new rays that rotates again towards the next angle without colission, and adjusts the lenght. But here comes the tricky part. Do i adjust the length of the rays to be where the green arrows show?, since the character can't move through the blocking object?

    Any ideas on how to improve this?

  • The best is to have a couple of different smartphones and tablets to try on. If you're trying to optimize your game, it's good to have some, lower/mid end phone to try on. If you're developing for iPhone i suggest you get an iPhone. Maybe a second hand iphone 5 is good, and for android some cheaper mid range phone. You don't wanna test on the latest most powerful phones only, because you need to know how well your game runs on phones that are not that powerful.

    I do my testing by uploading the project to my server, then trying the game in the phone browser. You can also set up Construct to preview on LAN, so you can test directly on your phone/tablet without uploading anywhere.

    The phone browser performance will usually be very close to final build performance.

  • use an animated sprite at the feet looking like particles instead of using particles.

  • You can use the bullet behaviour with gravity to get that kind of movement. The character sticks to the ball and rotates. When you click the character with bullet behaviour should move in the angle of the rotating platform. I hope thats enough to get you started. Play around with it.

  • I think this is what you're looking for.

    The power if C2 is that allows custom plugins, so the community here offer a lot of good stuff, or if you know how to code you can make your own.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • +1

    I'm also missing very basic html/CSS functionality. Especially something like divs and tables or equivalent. Maybe it could be used for ingame UI and such as well.

    CSS transitions is one of the most missed features. The card flip feature in this thread is pretty neat.

    https://www.scirra.com/forum/viewtopic.php?f=147&t=168636&p=1015135&hilit=css+card+flip#p1015135

    I played around with it a litte bit. It renders a bit slower than sprites. If I'm not mistaking you also cant have any of these objects inline in between layers. They are always on top, rendered separately from canvas.

    I would love to have CSS styling and transitions on sprites, or at least some equivalent, but I don't know if it's possible or not.

    I friend of mine made this: http://chimely.co/ and I would love to make similar apps/webpages but using C2, as it's such a breeze to work with.

  • I would probably say Spriter. 7 second animation at 400x300 pixels can be quite heavy as a sequence. If you don't want to use spriter, you could devide your scene in smaller elements, and only using frames sequences for the things that are moving. but it all depends on what you're doing.

    Are you doing an advanced cutscene with a lot of moving objects, camera zoom, effects etc etc i would probably recommend a video, but if you're just animating some characters on a static scene i would probably go with a combination of spriter, and animated sprites, on static background image/level.

  • I'm not sure it's helpful in this case but i did some test a while back and noticed that just picking objects with events (conditions) becomes quite heavy when the number of objects increase, even on static objects. So i found out that some conditions were more efficient than others in terms of picking, but in general trying in smart ways to limit the amount of picks using certain conditions, some ways were more CPU friendly than others.

    For example. Let's say you have a huge layout, with tons sprites in a certain family. Just picking by family across the whole layout can be quite heavy, even without any actions applied.

    This is what you want to limit. Let's say you use the condition "is on screen" to first filter the things that are on the screen. That's a pretty good filtering right there and works quite well. But in some cases even the Line of sight behaviour (without obstacles) set to a radius a bit bigger than the screen width can be even cheaper than the "is on screen" condition. But so far the cheapest way i could find (in some cases) was using it in reverse. First pickin "is not on screen" or reversed has line of sight to, then picking pick nearest. It only applies actions to that particular sprite, that just became closest to any of the screen edges.

    I don't know why this particular condition. "Pick nearest" is so cheap, even if you have large amounts of sprites in a layout. I use that condition A LOT. I would like to know how it works, because it can't possible check the distances between every object in layout, that cheaply.

    Another good way, was to have one dedicated event setting a boolean value to every object that is on screen or has LOS. That way you don't have to use "is on screen" again in other events to pick by that, because picking by a boolean is way cheaper that picking by "is onscreen". the same amount of objects.

    Here's some testing i did using different kind of methods for picking just to check how heavy they are performance wise, picking from 200 sprites.

    Hope that helps.