WackyToaster's Recent Forum Activity

  • Congrats dude, way to go! (Unlike other people... like myself :V)

  • Then you'll have to manually store what coins were taken and destroy them on start of layout. You could save the X and Y of the coin when it's taken in an array with array.push that you then save to local storage with array.asjson

    When the game is loaded you load the data back into the array and loop through the stored coordinates with pick nearest coin > destroy

  • I wonder what possibilities this would open up so... curious.

  • Just posting this as an update if anyone with similar issues finds this thread.

    Ads are now serving even with this setting enabled, took about 2 weeks overall but didn´t require that many users. So the key seems to be just... waiting. Kinda annoying but ok. Also include a fallback in case no ads are served!

  • Yeah, that's basically it.

  • What I mean is that you do not set a specific object, like "Sprite2 on touched" but rather "this on touched" (kinda like in js). If you do it with Sprite2, copying between projects gets annoying. You can´t just copypaste because Sprite2 doesn´t exist, so you create it and then you wanna replace the object with a different one (say a Tiled background) and you can´t use the build-in replace object because it doesn´t allow replacing different types. So you might aswell recreate it from scratch anyway.

    By referencing the object as "this" it would be a generalized event that can be copypasted between projects and reused for different objects without much hassle. And as mentioned, it would be another step in the "plugin via events" direction.

  • What about how I described it earlier though? I also don´t like the idea of adjusting events on a per-instance basis. I pretty much want it to be exactly like a behavior, except via events.

    Also I just noticed my earlier post ceased to exist :V luckily chunchun quoted it so here it is again:

    Like behaviors I see it as a mostly self-contained thing that could be used (and especially reused) in a generalized way.

    Lets just say you need an object to move in a specific way, for example have it constantly circle around the viewport edges. The eventsheet would allow you to add properties (e.g. speed) that then are exposed in the object properties. "Global variables" could be exposed in the form of expressions so you can read e.g. how many times the object circled around the viewport.

    Further the idea would be that you can´t specify an object inside the event sheet, and the events always automatically reference the instance. This means you can plop it on any object without having to change anything in the code and have it work (including across projects), assuming you don´t access conditions/actions that aren´t available. You can´t "set text to" on a Sprite afterall.

    This would also make it easily shareable. Kinda like the plugin database, there could/should be a place to share that kind of eventsheets. Maybe, don´t call it eventsheets just to avoid confusion.

    That´s roughly the idea I had in mind, I hope it makes sense.

  • I'd say this looks fine. You could try disabling the timescale, maybe that messes with something. You could also check if it actually is triggered only once, there are some cases where you can still manage trigger it every tick. And you could try adding dt to the force you apply to the player (self.force+4)*dt though I feel like that shouldn't be the issue if it's actually only triggered once, but who knows.

  • It's kind of a quirk of construct. You can add the player object to a family and pick the sprite on one hand and the sprite[family] on the other.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • For the first issue, did you set the physics mode to framerate-independent? Because by default it is framerate-dependent and can cause such issues.

    And the second one, did you check the collision polygons of the tiles? The character just bumps into them it seems. It´s probably better (and more performant) if you use an extra invisible collision object to avoid that since you can just strech them at will.

  • But I would generally advise you structure your game logic with the assumption that you will only sometimes get an advert. Perhaps trying to load a video advert, then offering a reward to users if it loaded?

    Yeah, lesson learned I guess. The thing is it still completely demonetizes the app (I don't have IAP) and that's not exactly good. I think once I have more apps online I can fall back to in-house ads but right now...

    other than "get more users" ( because that's nice and easy... )

    If things go well (talking about 1-2% conversion rate) I should get a nice boost soon. But we'll see if that improves the ad serving.

    If you do discover something we can change/add that will improve the number of adverts being served then we're happy to look into it

    Thanks! I'll let you know if I find something.

  • From my understanding the idea is to create a special eventsheet that you can assign to objects rather than layouts like a behavior and that also work like behaviors.

    I like the idea because it could be useful in terms of reusability and is a step towards the "write plugins with events" idea that Ashley hinted at about 2 years ago.

WackyToaster's avatar

WackyToaster

Member since 18 Feb, 2014

Twitter
WackyToaster has 25 followers

Connect with WackyToaster

Blogs