SAAj's Forum Posts

  • the link is dead...

    Holy crap, this is from so long ago that I forgot it existed. Don't worry, that version has an abysmal interface. I've since cleaned it up and will convert it to Construct 2 sooner or later.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • >

    >

    > That's the problem, I need the soldier to always face the same direction as the Commander; if a shieldwall is not facing forward, it's useless as a shieldwall. If not for that, it would be easy and I wouldn't need the Direction at all.

    >

    > If I can't get each Soldier to follow its Direction while each Direction follows its Formation, I'd have to find a way to make the Soldier move in the direction of its Formation while still facing forward. Is it possible to translate an object in a direction without changing its angle?

    Added it to the example. :)

    Formations

    Thank you, that solved the problem! I just assumed an object couldn't move in a direction it wasn't facing. That's what I get for not paying attention in math class.

  • I removed the whole on overlap, as it doesn't differentiate betwee the units own formation and other ones. Also got rid of the whole angle thing, as there really is no point in that :)

    Fixed formations

    That's the problem, I need the soldier to always face the same direction as the Commander; if a shieldwall is not facing forward, it's useless as a shieldwall. If not for that, it would be easy and I wouldn't need the Direction at all.

    If I can't get each Soldier to follow its Direction while each Direction follows its Formation, I'd have to find a way to make the Soldier move in the direction of its Formation while still facing forward. Is it possible to translate an object in a direction without changing its angle?

  • bump :C

  • vee41

    Thank you for the reply! It fixed the issue of Soldiers jumping from one Direction to another, but there is still the issue of Directions coming to a stop when their Formation overlaps another Direction (if you click and drag a Formation onto a Direction other than the one in its container, the Direction stops rotating and moving until the Formation is no longer overlapping another Direction).

    I checked the page on picking for Construct 2 and it didn't seem to cover what I should do here. I think I need to use 'for each Formation', but since I don't have Formation selected as an object in my conditions (it is instead selected as a position), it's not registering. Or I could be completely wrong.

    What should I do to prevent a Direction from stopping when its Formation overlaps another Direction? I've included the updated .capx below.

    dropbox.com/s/dkxmcom1qnmbgxu/M%26B%20Commander.capx

  • I'm kind of surprised there aren't more topics about this; my search mostly turned up stuff that was outdated/from Classic.

    I'm making a game in which you control a Commander using WASD and your Soldiers follow you in formation. You can adjust their formation using drag-and-drop. I went about this as follows:

    Each Soldier is comprised of 3 objects: Formation, Direction, and Soldier. Direction and Soldier are in Formation's container.

    Formation: this is the drag-and-drop object that pins to the Commander and tells the Soldier where it should ideally be at all times.

    Direction: this is the 'motor' that always faces the Formation and moves toward it if they are not already overlapping.

    Soldier: this is the main sprite; it always sets its position to its Direction and its angle to the Commander, so that it faces outward no matter which way it's moving.

    The problem I'm having is that Direction and Soldier are not sticking with their Formation; they behave strangely when interacting with other Directions and Formations, even if they're not part of that container.

    I know there are ways to make them ignore all such objects except the ones they spawned with, but the method I used in Classic isn't working here for some reason (I had a private variable on all 3 objects that was set to Formation.Count when the objects spawned, and all commands involving movement and positioning applied only to objects that shared this private variable).

    Here is the .capx as I have it so far. As soon as Directions/Soldiers start overlapping or moving past each other, everything goes crazy.

    dropbox.com/s/dkxmcom1qnmbgxu/M%26B%20Commander.capx

    Edit: I'm running this in Chrome.

  • O:

    I am simultaneously baffled and intrigued. Not sure I really understand the point of this, but it's interesting and I admit I zoned out watching them get all bunched up, lol.

    I'm glad it held your attention! There's no point, really; it's just a screensaver that illustrates group dynamics. It works well as an analogy for dating within social circles, competition within markets, diplomacy between nations, and so on. The distance between the sprites is symbolic of unfamiliarity, market saturation, and exclusivity of interests, respectively.

    Originally, I programmed it as a way for characters to target and pursue enemies in an RTS game, but found, to my amusement, that by switching the 'pick closest' function to 'pick farthest', it ended up looking more like a fast-paced dating sim. Ultimately, it was both: it was equally representative of the diplomatic failures leading up to warfare and the hostilities that result from dating the same people as your friends.

  • I programmed this AI to illustrate why you shouldn't date within a circle of friends. People tend to be attracted to potential more so than substance, so they are drawn to those who are most distant to them. Eventually, everyone becomes familiar with everyone else. Soon, everyone is in everyone else's business and it's time to hit the space bar. Coincidentally, this is also a great example of how World War I started.

    mediafire.com/file/jp1dwzjlow66vj9/Love.exe

  • The programming seems to be fine (no bugs so far), though you might want to make a few changes for playability. Just a few suggestions:

    -have enemies spawn from off-screen at the beginning of the level; there's almost no way to avoid a few initial collisions.

    -adjust the damage or program auto-fire; mashing the space bar this much simply isn't feasible.

    -enemy movement is too fast; slowing it down a bit allows players time to establish patterns and escape routes, but at its current speed, it's far too dependent on luck.

    On the technical side of things, you might want to address the player character's tendency to start spinning when it reaches the mouse; you could perhaps program it to stop seeking when the mouse is over the player character.

  • *facepalm*

    I can't believe I overlooked something like that. I'm glad it was an oversight on my part rather than an issue with Construct.

    Thanks a lot for your help, both of you!

  • That's the first thing I tried. Unfortunately, custom LOS settings kill the framerate after the application runs for a minute or two. I have no idea why this occurs, but I know my machine isn't the only one that experiences this issue. Here's the original .cap running with custom LOS:

    mediafire.com

    It'll run at a healthy 70+ fps for about half a minute, then start dropping into the 30s, and finally plateau at below 10 fps. This may not be an issue on fast machines, but this is meant to be a simple, 16-bit-style game. If my machine, which can just barely run Orange Box, can't handle it, a lot of my target audience won't be able to either.

    That's why I need to figure out how to bypass the need for custom LOS. I was hoping there's a way to ignore an entire layer, or something to that effect.

  • mediafire.com

    I've got LOS2 and S2 on a different layer, but I can't seem to get LOS2 to acknowledge the target and ignore S1.

  • I'm not sure how to apply that to the problem I have. I have two objects with line-of-sight behavior (LOS1 and LOS2), and two objects with the solid attribute (S1 and S2). I want LOS1 to treat both S1 and S2 as obstacles, but I want LOS2 to treat only S2 as an obstacle.

    I want to avoid using custom obstacles, leaving both line-of-sight behaviors on 'solid'. I want to put S1 and S2 on different layers and tell LOS2 to ignore S1 (perhaps to ignore the entire layer it's on).

    The way I currently have it set up, S1 is not directly targeted at all. LOS1 and LOS2 are both targeting an object behind S1, so I'm not sure how to get LOS2 to ignore S1 or the layer it's on.

  • Is it possible to instruct an object to ignore all objects on a specific layer? Specifically, I want a line-of-sight behavior to ignore all solids on a layer different than its own.

  • Or, you could always do your own "cone of sight" routine.

    Have a look at the image.

    o = object with cone of sight

    a = angle, to which o faces

    c = the cone of sight

    r = the radius of the cone

    p = sample points within the cone

    d = distance between points on r

    g = distance between points on cone

    All there is to do is creating a virtual cone, and sample only a small subsets of the possible points within the cone (for speed reasons).

    c exists angular, centered around a. The radius is needed and should probably be the border of the visible screen of your game.

    What you need:

    - The height (r) of the cone in pixel => cH

    - The width of the cone in degrees => cA

    - The sample density along r => pH

    - The sample density along the circumference of the cone => pV

    The position of a sample on the virtual grid is

    x = cos( (a - cA / 2) + loop_through_pV * (cA / pV) ) * loop_through_pH * (cH / pH)

    y = sin( (a - cA / 2) + loop_through_pV * (cA / pV) ) * loop_through_pH * (cH / pH)

    Then do whatever suits your needs at that sample point. In my example I did a collision-at-offset check.

    Download coneofview.cap

    Wow, this works really well, actually. I've been trying to replicate it from scratch, however, and can't. I'm just not math-savvy enough to do it intuitively. As such, I don't feel right including it in my programming, since this is meant for me to be able to alter at will. I'll definitely hold on to the example and do my best to familiarize myself with it, though. I appreciate you taking the time to put it together.