Dachre's Forum Posts

  • 15 posts

  • I hate bumping a resolved topic, but I wanted to add one thing:

    I changed the [Repeat Function.Param(2) times] condition to a [While; Increment > 2] condition, and it seems to have improved the overall complexity of the function as a whole. Rather than executing the sizing loop a flat number of times, it should execute at most ten times (assuming MaxRange is 2,000).

    Again, sorry to bump a resolved thread, but I wanted to throw that in there as a theoretical optimization.

  • I've completed simplifying and testing the function. Below is the pseudo-final version of my game's shooting code.

    This function works exactly as I desired. It's called only once per "shot," it selects only the target that is first "impacted" by the ray, and it properly sizes the visual representation of the bullet to stretch from the muzzle to the point of impact. From here, more post-processing could be added easily, and adding in an "accuracy" variance (as I plan to do later) could be done simply by altering the initial angle of the projectile object (Bullet2 in the example).

    The function could be (and probably should be) generalized using Families instead of specific objects (as was done in the original tutorial I scavenged from the Internet).

    The base complexity of the function should be minimal. The actual logic itself should have base complexity of log(base 2)(n), however, since the repeat command is used, it degrades to (n) complexity—but, that shouldn't have a very big impact on performance. Even if it did, the number of iterations could be reduced without much consequence, as that part of the function is strictly for aesthetics (since the target of the impact has already been decided at that point, functionality wouldn't be impacted at all).

    I left in the additional function parameter from the tutorial I used in case I need to identify specific bullets later as the game progresses. In the example shown above, that parameter is not used.

    I'm calling the issue resolved. I'd like to thank everyone who took the time to offer their insight during the thread, and also the author of the raycasting tutorial I found on the site, which, again, regrettably, I cannot directly link to because of my lack of forum reputation (Lightning-fast-raycasting by sqiddster).

    I've managed to learn a ton about Construct 2 during this process, and I look forward to pestering you all again when the next issue arises.

  • I would try simplifying by cutting out the for each and avoiding UID, two common sources of problems. You probably don't need the array either.

    Try using "pick nearest hrrrn to player.x player.y" in place of the "for each hrrnn" underneath the overlap condition. From then on in this event, only that hrrnn will be affected by actions.

    It is somewhat complex, but I believe that is because the original tutorial that I was working from was designed to detect collisions as accurately as possible when firing a continuous ray through a series of targets with complex motion. I downgraded it somewhat to fit my simpler needs. It's probably true that I could stand to simplify it, but I'd like to try to get it working first, if for no other reason than just for the practice.

    I tried using "pick nearest" in a function that I'd written before, but it never worked well. Using it just on those objects that satisfy the overlap condition, however, would probably work as intended. I'll give that a shot later.

    No thoughts other than that looks complex. It probably doesn't need to be.

    The idea I presented basically points a sprite in a direction and increases it's width until an object is hit. That gives the hit object and a point of collision.

    Yours seems to set the sprite to be full length first and then add all the overlapping objects to an array, then loops over the array in some way while shortening the line by halves. So I'm guessing some kind of binary search? I guess I'd have to look at the tutorial you reference. My guess is the issue may be the order of the sprites, but really there is no way of knowing without something to test.

    Yeah, the logic behind it is a simple binary search. That's why I latched on to that tutorial in the first place—it was very familiar to me. In the other game software that I've used in the past, I had written a very similar function for both bullets and beams that determined the exact position of impact by casting a line, checking for collision, halving the distance, and repeating until I got the position of the impact to within two pixels of the object. Then I'd spawn a "collision" object at the end of the ray that actually handled the post-impact processing (incidentally, I'm going to skip that step this time around, as I never did like having to rely on that "third party object" to do the processing). I'm totally unfamiliar with Construct 2, however, and, additionally, its event-based system is something that I haven't yet gotten used to. I was finding it difficult to port the functionality from the old procedural approach to the new event-based one.

    I'm gonna give a few more things a try, but if I can't seem to get it to work right, I'll upload the file and ask if folks can take a look at it. If necessary, I'll switch my approach. Really the only reason I haven't uploaded it yet is because I had already added the tons of sounds and music that I already had laying around to the project which, when packaged into the .capx made the file size somewhat ridiculous for what it was. I'll have to yank all that back out so that people won't have to sit there and wait for a zillion megs of sounds to download just so they can test a few lines of game logic. Heh.

  • With the help of the information I've gleaned from this thread, and the raycasting tutorial I discovered, I put together the following function:

    This function performs very well, since it is only called once per "pull of the trigger," so to speak. There's no need to constantly call it since I only need to check once whether or not each bullet hits.

    However, there is still one small problem I'm experiencing when dealing with multiple targets. If multiple targets are lined up, both horizontally and vertically, then when shots are fired into the group, shots coming from the left and from the top (firing toward 0° and 270° respectively) hit only the first target in range, as it's supposed to, leaving the ones "behind" them in line untouched. However, if firing into the group from the bottom or from the right (90° and 180° respectively), then the shots hit all targets in the line instead of just the first one.

    I find it odd that it works perfectly from two sides, and not from the other. The sprite itself (the visual component) is properly sized for all shots, those that work right and those that don't. i.e., even when shots are hitting multiple targets, the width of the "ray" sprite displays correctly (stops upon hitting the first target in line). This leads me to believe I'm selecting instances from the data structure incorrectly.

    Any thoughts?

  • EDIT: Unfortunately, the forum's auto-moderation is preventing me from posting the link to the tutorial I describe below. However, it's a pretty popular one, and comes up pretty quick in a search engine.

    Is it in line with where it should be? Maybe it is travelling a frame before it gets rendered. Another thing I thought of was maybe it is starting out invisible (50%chance?) And gets revealed on the next tick.

    Yes, it's spawned at the proper angle. The delay between spawn and render is my best guess as to why it's not showing up at the proper point. For testing purposes, the sprite is set to visible by default, bypassing the random "tracer chance," so I know it's probably not that.

    Just to clarify a few things:

    The distance an object moves per frame is speed*dt, so with a speed of 5000 the object will move 5000/60 or about 83 pixels per frame, which is why it can pass other objects without colliding.

    For doing an instant hit, the common approach is called "ray casting", but you can also find examples on the forum about lasers that do it too. By using a sprite and changing the width you can do the same thing as the line segment idea.

    That error is a bug I'd say, and a good candidate for an error report.

    Your last issue is probably something simple, but we'd need to see a capx to find it. The posted events don't seem to cause it.

    When I was first exploring the site, before I actually downloaded the software, I found what looked to be a good raycasting tutorial (https://www.scirra.com/tutorials/902/li ... raycasting), but, unfortunately, due to my bumbling unfamiliarity with Construct 2, I was unable to determine how to return the values I need from that function for post-impact processing:

    • The ID of the entity that was hit by the ray, for damage/stat/knockback calculations
    • The relative position of the impact for my ridiculous, stomach-turning, nightmare inducing gore splatter engine

    If anyone can help me figure out getting that information from that style of raycasting function, then that would be perfect. The function I used in my other editors followed very similar logic, and I'd love to use it here, if possible.

  • The first thing that comes to mind is your image point being off for that animation/frame but you said you checked that already. Did you check the origin point for the bullet itself? Is that animated?

    The "bullet" itself is nothing more than a single image. I've tried moving its origin point around to see if that had any effect, but it does not. The first shot is still placed considerably farther away from all subsequent shots.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Okay, I was able to achieve the summation of the effects I desired by elongating the actual image for the bullet (a spin-off of an above suggestion) and leaving everything else (the high speed, etc) the same. As it turns out, the elongated sprite works both for helping with the collision detection and (combined with the high velocity) providing a nice "tracer" effect. I guess I was overthinking the problem, something which I'm notorious for.

    I do, however, have one more problem I'd like to resolve: the first bullet being fired doesn't seem to be originating from the correct position. All of my player sprites have an image point called "Muzzle." It is image point 1. The "Muzzle" point, as the name implies, is supposed to be the origin of muzzle flashes and bullets. I have verified that it's position is correct on all animations, in all sub-images.

    However, the first bullet fired, and only the first bullet fired, in a sequence is positioned a good distance away from the player sprite, i.e.: nowhere near the "Muzzle" point. If an automatic weapon is fired, and there are therefore subsequent shots, all of those shots are fired from the "Muzzle" point. Only shots from "single-shot" weapons, and the first shot from automatic weapons is affected.

    I assume there is an error somewhere in my sequence of events that I have been unable to detect. Below is an image of the relevant events.

    If anyone can provide some insight into why only the first bullet seems to be off in position, I'd greatly appreciate it.

  • that is a fish/shark i have never seen before

    That, my friend, is a sturgeon. I'm not an expert (I'm just a novice, heh), but I'd say it's either a Green, Lake, or Shortnose sturgeon. There are a plethora of varieties. These species are the origin of the majority of the world's caviar trade.

  • It might just be because I have a horrible headache, but the solution to this is still illuding me. Basically what I want is:

    On mouse click, draw a line.

    If that line hits something, anything, return the position of the collision, and the object that was hit.

    Set the end-position of the shot to the position of the hit

    Handle the collision (damage, sparks, debris flying, whatever)

    Else, if the line hits nothing

    Set the end position to the border of the window (keeps errant bullets from hitting things off screen)

    Draw a tracer between the muzzle of the gun and the end position (whichever end position that may be)

    I just can't find the methods I'd need to pull that off, nor a suitable replacement for that behavior. Maybe I'm looking in the wrong places, or maybe there's a different way of looking at it. The editor that I used to use had a function for determining whether or not there was a collision along some line segment (x1,y1,x2,y2), so I'd just call that in a recursive binary search until I determined the exact pixellate location of the impact and go from there. I lack enough familiarity with Construct 2 to duplicate the effect.

    I appreciate the input, I'll take it back up tomorrow. I can't stare at my screen anymore right now. Heh.

  • Okay, folks, I'm about to write another dissertation, here, so sorry about the text-wall again beforehand.

    I got some excellent help here with the last problem I encountered trying to learn the engine, so I'm back again with yet another problem that I could use some help with. More accurately: I have a whole set of problems this time. Heh.

    I'm dealing, now, with bullets. The game I'm working on is, quote, unquote "realistic," so I'm desperately trying to avoid having any visible projectile when my guns are firing. But, there doesn't seem to be an option for instant-hit projectiles in Construct 2, so I've simply made an object with Bullet behavior with a very small sprite (3x3) that travels very fast (speed: 5000). Unfortunately, this combination of small sprite and fast speed seems to be leading to a "skipping" problem, where the bullets are not registering collision.

    Also, I would like to occasionally (about 1/8 chance; 100% on critical hit, but that's another discussion) display a tracer effect on the screen when a shot is fired, just so that there is some visible indication as to where the shots are going. Since my bullet is very fast, the tracer effect basically amounts to a line drawn across the screen in the direction of the bullet.

    I've achieved some success with the tracer by making a spherical gradient sprite, blending it Additive, and attempting to stretch it from the muzzle of the gun to the bullet as it travels across the screen by setting its width and height. The effect looks nice, but it begins several hundred pixels out from the muzzle of the gun, rather than at the coordinates of the image point. I'm assuming this is because the bullet to which it is pinned is traveling extremely fast. I'm hoping someone can give me some insight about how to fix that.

    Finally: I would like to group the bullet object and the tracer object together such that when a bullet is spawned, a tracer is also spawned along with it automatically; furthermore, when that bullet is destroyed, be it on contact with a solid object, or target, or out of the layout, or what-have-you, I'd like the tracer to be simultaneously destroyed along with it. Using the Container feature seems to be the way to do this—again, I'm new, I don't know these things for sure—but unfortunately, every time I try to combine the two objects into a container, I'm greeted with this:

    I've been working on it off and on all day, and have come up with nothing satisfactory. I honestly can't provide much in the way of examples of my work because I've completely discombobulated it with about a zillion lines of crud, and it would be very difficult to make sense of. At this point, I probably need to scrap what I have and start over.

    Can anyone offer advice, or point me in the general direction of examples that I can use to achieve the effects I'm after?

  • My avatar, as stated quite clearly along the bottom, there, is an actual photo.

  • This a very surprising story because usually the ones that major in CS are the ones that enjoy efficiently coding and live on C. But for you, you need simplicity, a way to just develop rather than take time and go through the logic. I mean it's fascinating! Because here we have CS major that actually enjoys C2 a lot, which was mostly meant for non-coders but here we are.

    I don't know, I find it really cool.

    Don't want to deviate from the feel of the post too much, but I just had to toss my two cents in. As a programmer, myself, I get sick and tired of staring at a vertical monitor laced with seemingly endless lines of code practically all day every day, a subset of which isn't even your code, a subset again of which being virtually impossible to read without your eyes going crossed.

    When I get home, I want to do something leisurely. I want to make games that I can then play and share with family. I really, really don't want to sit and stare at yet more lines of code. Construct 2 provides an excellently designed interface that allows me to arrange my logic in a manner much like a pseudocode flowchart, which is the part of application development that I really love. (Well, GUI design is my absolute favorite, but the pseudocode flowchart's gotta be a close second.)

    I'm sure everyone has their own opinion on raw code access / simplicity, and maybe I'm just projecting my own feelings out there, but I'm sure there are lots of programmers that feel that way: when we're working, yeah, sure, show me the lines. But when we're playing, we just want to play. Heh.

  • Hello, all. Name's Dachre. Just joined the forum, and have been using Construct 2 for a couple of days. So far: I'm pretty impressed with it. I was wary at first, as I haven't liked "drag-and-drop" development environments in the past, but this software seems more powerful than similar software I've used before.

    I've dabbled in game development in one way or another for about fifteen years or so. I've never "released" anything I've made—I do it purely for my own enjoyment, and that of my immediate family and friends.

    I also enjoy sound design, various types of visual art, and am an avid, if discombobulated and somewhat private, writer of fiction of various sub-genres. My current focus is a mildly dystopian space opera, but I have a nasty tendency to jump around from project to project.

    Neh, not much else I can think of to say about myself, really. Looking forward to the community.

  • Thank you both for the help and feedback. ramones, your movement detection solution functions perfectly, and is significantly easier than the methods I was using. Since I'm new to the engine, I didn't even know those methods existed.

    Not only does my movement system now work as intended, but I was able to shave nineteen events off of my event sheet. Again, thanks for the hand.

  • Foreword: I noticed, after I was done typing, that this turned into something of a dissertation. Apologies beforehand for the wall of text.

    Hello, all. I have some experience with various other game-making software, but I'm completely new to Consturct 2, so I decided that this might be the best forum for my question. I started throwing together a simple top-down-shooter the other day, and I'm having a little issue in my movement sequence.

    The "player" consists of two sprites: Player, and Player_Feet. The Player sprite is the body/arms/gun/etc., and the Player_Feet sprite, as the name might imply, is just movement animations for the legs and feet. I separate the two because I'd like them to move independently of one another. The player rotates to face the mouse, and WSAD is used for 8-direction movement.

    What I'm trying to achieve is an effect that I've done before in other engines: since the player always faces the mouse, but has free range of movement, I want the animation for the feet to switch between back-and-forth and strafing left/strafing right based on his movement and relative angle to the mouse. (It looks bad, to me, to have the legs swinging back and forth when the player is obviously moving side-to-side.)

    What I have thus far works just fine, except during diagonal movement. Whenever multiple movement keys are pressed at once, the leg animation "sticks" on the first frame, and does not animate. My previous programming experience is telling me that my problem is likely that I have one or more of the conditions in my event sequence firing repeatedly, and it's setting the animation back to the start while the buttons are held down, giving the illusion that the sprite isn't animated. But, I'm either too tired, or too nearsighted to find the error.

    Below is posted an image of the event sequence that I'm using for movement. I also have the .capx file up in my Google Drive, and I can provide a download link to that if necessary.

    As an aside: Like I said, I'm new to Construct 2 and it's way of doing things. If anyone has any advice for optimizing or compacting my event structure, I'd be delighted to hear it.

  • 15 posts