R0J0hound's Forum Posts

  • One way is to just make a curve for one edge. Cubic or qarp for example. Or even using the arc of a circle for minimal distortion. Then you can get points from one edge.

    You can get the other curved edge by moving the points out perpendicular from the curves angle.

    I’m probably not doing the idea justice without an example. I’ll try to make one tomorrow.

    This page has ideas how to bend roads which is very similar to what you’re trying to do.

    redblobgames.com/articles/curved-paths

    That guy’s whole site is full of a wealth of information.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • You can use a dictionary for that. So basically use tokenat to get each number from the string and add a key to a dictionary. Duplicates will be the same key.

    Then you can loop over the keys and add it to a string and there will be no duplicates.

  • That was just what that algorithm did, which I honestly don’t fully understand. What I do know is it should be one of the faster algorithms for that problem, according to Wikipedia.

  • The algorithm came out cleaner in events than I expected.

    dropbox.com/s/t4hci8revuyaz1q/smallest_enclosing_circle.capx

  • It should be possible to implement the welzl algorithm to do it. We just need to use some cleverness to return multiple values and be able to pass arrays to the function.

    The meatiest part of the algorithm is probably the math to give the smallest circle around three points.

  • Instead of the average you could find the median and use that for the center.

    X = (xmax+xmin)/2

    Y = (ymax+ymin)/2

    Then just use the furthest point. Might give a tighter circle.

  • Here’s one way to do it. Basically when creating the X you save the distance between the player and the X to a variable. Then while swinging you move the player so it’s at that same distance from the x. Also we cancel the perpendicular velocity of the player.

    The result should be swinging while keeping momentum. 

    var d=0
var a=0
var vperp=0

on x created
-- set d to distance(player.x, player.y, x.x, x.y)

compare: x.count >0
-- set a to angle(player.x, player.y, x.x, x.y)
-- player: move d-distance(player.x, player.y, x.x, x.y) pixeks at angle a
-- set vperp to cos(a)*player.velocityX+sin(a)*player.velocityY
-- player: set velocity to (self.velocityX-cos(a)*vrel, self.velocityY-sin(a)*vrel)

  • I mean minifying would make the export smaller.

    By not minifying it doesn’t make the program any more able to be modded. What gets minified is the plugins and and JavaScript scripts you write in the event sheet. But those aren’t really easily accessible. If you want your program to be more modable I’d try different measures.

  • Hard to say what you’re trying to calculate with the angles and how.

    If you are just turning you could just set the bullets angle to the cameras angle.

    If you look up and down too you can use spherical coordinates to get the orientation from two angles. But your math doesn’t look like that.

    Here’s a way to just shoot in the direction the camera is facing. Maybe something like that is what you’re after?

    construct.net/en/forum/construct-3/how-do-i-8/bullet-fire-center-screen-3d-166334

  • Hey that’s a pretty cool result you got. I’m glad it was usable enough to allow changes. Utilizing the fact mesh points can’t go negative was clever.

    Anyways, I agree the math is hard to read in parts, especially when I used arrays. I’m always trying to find ways to make the math look cleaner if possible.

    That deforming idea sounds like a doable thing. I probably just need the raycast to also return the triangle index.

    Cheers

  • You’re welcome. In it I opted to duplicate the vertices when making the triangle list. If you just stored the indices you would have less points to transform. Also you can make the obj loader support quads too, which would be more efficient with distort meshes, but I opted to just use triangles because I needed that for the raycasting. And actually it should be possible to use less distorted to display a mesh if the mesh is made of triangle strips, but that would take more effort to design.

    -cheers

  • Here is a test of a way to do precise 3d raycasting against a triangle mesh.

    Construct doesn't provide a way to access the mesh of 3d objects, so this instead loads the triangles from an obj file into an array, and then uses mesh distort to display it.

    dropbox.com/s/uy6yfhpag7d1t2p/obj_loader_and_raycast.c3p

    Anyways, I'm pretty much at a stopping point with this. Developed further I can think of some uses, but performance isn't great with events, and currently I'd need to make the game work with the remaining 8 events.

  • Hello,

    Looking at the events that monsterSpeed variable is used four places.

    1. Where the variable is made as a global variable.

    2. Where it’s increased every time an enemy is killed.

    3. Under the every 3 seconds, it’s used to set the speed of newly created enemy.

    4. And when you hit space to reset the game. It’s set back to an initial small value. Most things get reset automatically when restarting or changing layouts, but when something is global it doesn’t reset automatically. This is useful for keeping scores between layouts or stuff like that. So anyways, in this case they wanted to reset it and not keep its value so it was done manually.

    I agree with you about the comment. It’s increasing the speed of the new enemies, not the rate they spawn.

    There seems to be lots of YouTube channels with video tutorials that may be useful to you. Especially if they explain what they are trying to do and explain each part.

    Anyways, here are my thoughts on how I’d come up with some of the enemy events.

    So first we have some enemies. We want them to move forward so we give them the bullet behavior and see them happily trudging forward.

    If it’s too fast or slow we adjust the speed in the layout editor.

    Ok cool. But these enemies seem pretty dumb. The player can avoid them easily. How about we have them chase the player? One way to do that is to change their angle to face the player.

    Every tick:

    — enemy: set angle towards (player.x, player.y)

    We test that and the enemies turn instantly to the player and pile up on him. The player can only get away if they are faster.

    So what if we made the the turning more gradual? Like maybe turn 1degree per frame toward the player? That would look like:

    Every tick

    — enemy: rotate 1 degree towards (player.x, player.y)

    The result is kind of nice now. Even is the enemies are a bit faster than the player you can out turn them. It gives the enemies a lumbering zombie like quality.

    However all the enemies seem to know where the player is at all times. What if their senses were more realistic. Like they could only detect the player if they were close enough.

    So how would we do that? There isn’t a compare distance condition. But we could use the compare values condition with an expression. There’s an expression called “distance” that will give you the distance between two points. So how close should the enemy and player be between each other for the enemy to year. Let’s say 200 or less so every position in a 200 pixel radius circle

    So we can change our event to

    Every tick

    Compare two values distance(player.x,player.y,enemy.x,enemy.y<200

    — enemy: rotate 1 degree toward (player.x, player.y)

    You can actually remove the every tick condition, since events are run every tick already.

    So anyways we test this and something seems amiss. It will work perfectly with a single enemy but with multiple it will seem to work with only the first enemy and not the rest. The reason has to do with picking. The system compare condition does no picking. It just uses the position of the first enemy instance in that distance calculation.

    Anyways we need to find the distance between each enemy and the player. One solution is use for each enemy to do that. What for each does is look at each instance one at a time.

    So the result is:

    For each enemy

    Compare two values distance(player.x,player.y,enemy.x,enemy.y<200

    — enemy: rotate 1 degree toward (player.x, player.y)

    Which works how we want it.

    Alternatively we could use a different condition like pick by comparison. It only will pick the enemies inside that radius. It will work the same for our purposes.

    System: Pick enemy by comparison: distance(player.x,player.y,enemy.x,enemy.y<200

    — enemy: rotate 1 degree toward (player.x, player.y)

    Anyways, hope some of that helps. I don’t have time to screenshot events so hopefully that text makes sense. I don’t usually write things so detailed but that is my thought process when I make events. The difference is over time you find more features you can utilize.

    -cheers

  • Probably just a typo or a misunderstanding when the behavior was made. Physics uses box2d, so looking at its manual it says damping can be any value from 0 to infinity.

    calhoun137.github.io/box2dgame/manual.pdf

  • I was going to google for some game names, as I know of some, but, eh. Reaching out to those companies can answer most of your questions about price, games they’ve ported, and if they can work with you.

    Most, if not all, that have replied so far in this topic haven’t actually used their porting services I’d guess? I really have no idea.

    Anyways, I have no skin in the game either way. I’m going to stop replying here.

    -cheers