WackyToaster's Recent Forum Activity

  • Just wanna do a little thought experiment. I have roughly an idea on how I'd do this myself, mostly using javascript. But the point is to do this via events only, because that's one of the main things in Construct. So here's the task:

    1. Have an object

    2. This object should get destroyed whenever it overlaps with something that's "spiky"

    3. "Spiky" objects can be pretty much anything, be it Sprites, 9-patch, tiled backgrounds, maybe even a specific tile in a tilemap

    Seems deceptively simple, but how do you actually define "spiky" objects? Instance variable perhaps? That means I will need an "on collision with familyA OR familyB OR familyC OR..." for each type of family. Super annoying to work with, should be easier imo.

    In javascript I'd subclass all my objects, so it's pretty easy to just add a property "this.spiky = true", then gather all relevant instances and execute a testOverlap() on them. Done, maybe I need some extra handling for the tilemap part at worst.

    	const instances = [array of instances I wanna check for overlap];
    	const spiky = instances.filter(obj => obj.spiky === true);
    
    	for(const i of spiky) {
    		if(this.testOverlap(i)) {
    			this.destroy();
    			break;
    		} 
    	}
    

    I think the key here is the fact that the collection of instances can simply be a wild mix of any type of instances. The filter function doesn't care, neither does testOverlap().

    Any idea on how or even if it's possible to replicate that in events with the same effectiveness?

  • Well if it's an option it should probably be supported. You should post such requests to the suggestions platform too construct.net/en/forum/construct-3/general-discussion-7/announcing-new-construct-161682

    But also... you could just not show an interstitial ad the second the app is opened :V Surely there is a better way to monetize than that.

  • I couldn'see anything wrong with the project, this does actually look like a bug. You probably should post it in the issue tracker

    github.com/Scirra/Construct-bugs/issues

    I thought that maybe a ray shoots off randomly somewhere or that the order of polygon points gets messed up somehow, but since drawing the outline works perfectly that can't be it.

  • Congrats, a lot of people don't even get this far in the first place.

    I am being inundated with spam emails asking for free steam keys.

    Lmao yeah, those are pretty much all key resellers trying to nab a free key. Most of them might look legit at first glance but they don't pass a closer look. Thankfully this dies off somewhat after a while.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • You also have to set the lvl variable of the object. And also there's no check in place where and how quickly you can create the objects.

    I'll let you figure out the rest. ;)

  • Here's a basic setup

    wackytoaster.at/parachute/basicsuika.c3p

  • Checking for collision between the same objects is a little whack in Construct. You have to put the sprite into a Family and then do:

    SpriteA is overlapping SpriteAFamily

    construct.net/en/make-games/manuals/construct-3/project-primitives/objects/families

    So in my code you'd just replace Sprite2 with SpriteFamily.

  • Are the objects roughly circular? That'd make it somewhat easy, since the intersection will always happen at the same distance from the middle point.

    cos(angle(obj1.x, obj1.y, obj2.x, obj2.y))*obj1.radius

    sin(angle(obj1.x, obj1.y, obj2.x, obj2.y))*obj1.radius

    It's not a perfect solution but it's simple and will likely do the trick for what I'm assuming is a suika style game.

  • If there is no empty space on top of the object, you can use the bounding box. BBoxTop specifically

    construct.net/en/make-games/manuals/construct-3/plugin-reference/common-features/common-expressions

  • Do you think some of the frustration with the controls in your game go back to the origin? Was it Solomon's Key?

    It was solomons key 2 in some regions and fire n' ice in some others. I don't think it has anything to do with the original game, just that the way I programmed it turned out to be terrible with a whole range of knock-on effects on the movement. The main problem was exactly what you described as players often failed to stop where they intended to. I tried a bunch of methods but most were just kind of slapping a bandaid on an open fracture.

    If it's the movement controls I'd say just remove all inertia from the player.

    That's part of what I did for version 2. Funny enough, this would have not properly worked in version 1, it is really bad lmao. But the movement in this version is now very much linear and I think I also have a better buffering system.

  • It would be cool to see the quadtree method adapted to work as a 3rd party addon. I could help with that as I think there is still some value in having it as an alternative collision algorithm.

    Go for it, I'm pretty tight on time currently so I cannot help much more here, not to mention I haven't touched the SDK in a while. I think if you go for an algorithm it's probably a good idea to go for rBush since it's even faster. I sort of toyed around with the idea in my head in case missed it:

    What about a plugin that can be placed like a sprite though? For infinite games you'd pin it to the player and ignore everything outside. The object could easily be adjusted with the properties bar and it being an object rather than being buried in the depths of the engine allows to tap into its optimization outside of just collision detection. It would have a "Pick candidates" action that can be called to pick the candidates from the relevant cells. This then allows to do whatever with the picked instances, be it "is overlapping" or any kind of loop. Although that means that the engine builds both collision cells and the tree then for the instances, which could again be not ideal.

  • I also use a mouse for pixelart. Pixelart isn't exactly requiring the features that a tablet provides. There are maybe some features that could be interesting, but mostly it isn't required at all. But a tablet can still be used regardless and obviously can also be used to draw other stuff.

    I personally recommend a cheap wacom over pretty much any other brand if you wanna buy one. Even though other brands can be dirt cheap, they often end up feeling cheaply made. Also seems like there's black cyber week right now with some nice discounts.

WackyToaster's avatar

WackyToaster

Member since 18 Feb, 2014

Twitter
WackyToaster has 25 followers

Connect with WackyToaster

Blogs