R0J0hound's Recent Forum Activity

  • Here's one way. There are many ways it can be tweaked.

    dropbox.com/s/u9mlfrlccppi30d/vine_grow.capx

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Try your family idea, it could work. If it doesn't another idea is to use js scripting, but I haven't looked into it. Another ideas is to just use the normal create action, just do one per type. You could also change it to use one object type with different animations for the different images.

    When it comes to picking two separate objects to make a line between them it helps to simplify as much as possible, that's why I suggest to make one object type with animations to distinguish between them. Then having a family with that single type allows you to pick two separate instances at the same time.

    However with the picking system of events it is a bit more complicated to connect two different objects just created since only the latest will be picked in that event. One solution is to create all the objects and then in a second top level event (when they can be picked as normal) do the picking.

    Anyways, here's one way to do it. The data has a list of objects to create and links to make between them. It utilizes a 1d array to keep track of the new object uids and a family to be able to pick them.

    dropbox.com/s/3ke0ef3zlndyqyb/createNconnect.capx

  • It just sets the return value and does not exit the function. There is no way to exit the function other than running to the end of it. So what you did with else’s is one solution to do that.

    You can consider the event sheet as its own unique programming language. The object picking is the most unique part. Take away that and it’s similar to most programming languages with if/else/loops/functions. It does have its differences though, such as no way to immediately exit out of a function or loop like return or break.

    I don’t have a good explanation for why that is. It was inspired by the click team products event sheets, but made more hybrid to better resemble structured programming. At this point we are in comparability mode. They can add new features but changing existing ones will break a bunch of things. But event sheets as a whole would benefit from tweaks and redesign in parts.

  • No idea. But your event screenshot gives a very partial view of what’s happening. Can’t see all the behaviors used, or other events that may change the scroll.

    As is, it looks like it can be simplified to one event:

    Right mouse down: scroll to mouse.x, mouse.y

    Anyways my best guess is some of those other camera objects also have the scroll to behavior. When the scroll is changed the mouse position will change since it gives the position on the layout.

  • It starts as 0 till you there is some kind of mouse input such as a click or motion.

    Never have encountered it always being zero. You’ll have to provide more info.

  • The variable is a local variable, so it resets every frame. You can edit it and make it static, that will make it remember it's value.

  • Nice. It is helpful to do stuff from another point of reference. Can be easier to debug in 2d, plus easier to use behaviors.

    Those game jams do look fun. I haven’t done one as of yet. Seems like a good challenge to make something in a short amount of time. Good way to break out of the endless design phase and just start making something. Although I’d probably bite off more than I can chew.

    I do like reading the progress updates for such challenges though.

  • I like the idea to limit the range to try casting rays.

    Here's the current idea. We find the bounding circle of the target object and only shoot a random ray that would hit that circle. It tries at most 20 times to find a ray that hits the object. Seems to work well enough, but the more obscured the object is the less likely it succeeds.

    dropbox.com/s/w8f937c8y0edfyh/LOS_Object.capx

  • I was curious about the math so he's an attempt. I got much of the math from this skinning tutorial.

    webglfundamentals.org/webgl/lessons/webgl-skinning.html

    dropbox.com/s/o6s9wuot219egx0/skinning_test.c3p

    Making the mesh itself and weighting it is probably one area it can be improved. How the verts are weighted now makes the joints turn sharply. I just had it linearly blend the weights between the verts.

    Another idea is to make a curve fit through the points to make the distort.

    Also here is an idea to do the ik without trig, if needed.

    iquilezles.org/articles/simpleik

    Anyways, as always just some ideas and preliminary attempts. Hope it's useful in some way.

  • 1.

    Conceptually they should be the same. The graphics card can draw tiled textures just as fast a non tiled ones.

    2.

    You’ll have to look in the manual/blog posts about it. C3 had more work on the atlasing of textures so it’s probably all lumped together when it can. Power of two textures shouldn’t matter. That is handled behind the scenes with construct. Atlasing is to use less vram mostly.

    3.

    Construct’s renderer is batched. Which just means it draws as many objects with the same texture all at once with one draw call. They are always bragging about the speed of that in blogs

  • I often use for each ordered to do that. Here it would shoot at the 3rd closet. This method is also useful when you want to do stuff with the n closest like it sounds like you are. 

    For each enemy ordered by distance(player.x,player.y,enemy.x,enemy.y)ascending
Loopindex+1=3
— stop loop
— shoot

  • I like that kind of problem.

    One idea is a rough LOS check. Basically repeatedly pick a random point inside the collision poly a do a LOS with that. Would fail more with smaller loops if the object is obstructed but it may give a true eventually. Could be a useful approximation of vision. Anyways the main sub problem to solve would be to get a random point in a polygon.

    A second idea is to utilize raycasts. Either a uniform spread of rays in roughly the direction of the object or use a bit of random. If any of the rays hit, there is LOS. I think this one is the most doable. Not sure if the ray cast feature in c3 can be used for this but making a ray cast with events would work.

    Another idea if to calculate the view polygon from one point and check to see if that view poly overlaps an objects collision poly. May be tricky to calculate though. One approach would be to do what shadow casting does and clip away from the collision poly the shadow bits. This would give an absolute is in in Los or not check.

    Anyways just some ideas, each with their own set of sub problems to solve. Maybe some are useful.