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.

>

>

> 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.