pirx's Forum Posts

  • So I haven't had a need to make a backend system for a couple of years. Last time I did parse.com was still a thing and it was ridiculously straightforward to use.

    step 1. create a database

    step 2. interface with the database with simple commands.

    Now I'm looking for something similar. Any good options out there? Two names that pop up are Playfab and Firebase but both seem somehow overly complicated so I'd better be sure there's not a better solution before diving into one of them.

    Thanks!

  • Hi,

    As in the title. It displays "not supported, please use Google Chrome" even when launched in Chrome. Is there a way around this?

    Thanks!

  • I think the easiest solution would be that if sprites are overlapping, the touch will touch only the sprite on the top of the layer it's currently on.

    That's the way I thought it worked.

    The problem is, that would break all past projects that actually rely on touching multiple things across the Z axis at once. I do think this is hardly ever the case but surely there are some creative ideas that use this as a feature.

    That is why I propose just a tick box or something to disable this on the object- or layer level.

    While the problem in question is usually work-around-able there are situations where it seriously gets in the way. Imagine a game like Simcity with loads of clickable buildings and a bird travelling over in a random direction.

    Now we want the player to click the bird to get a coin, but not mess with any random objects that happen to be below it. Since we don't know where the bird will be at the moment of clicking; and we want everything else to stay interactive we now need to go to every single object on the board and check if it's not overlapping with the bird (good luck if you have multiple object types). And in case of PARTIAL overlap it's not possible at all (or at least requires some serious complicated multi-event mechanics).

    I know this is possibly a contrived example but still all of this would be solved instantly with just being able to make the object/layer non-touch-transparent.

  • I like the argument that the system is designed with an idea in mind; this is elegant. That said the solution (if any) should not be changing the way it works by default now (it would break compatibility for a lot of projects). Rather than that what I had in mind is adding a behavior or property (or a layer setting?) like "stop touch" as a small convenience feature. It would not break anything while getting rid of the hassle once and for all.

    I don't mean to rant in any case but with numerous projects containing numerous overlaps managing "click transparency" quickly stacks up to a small chore. After all how <div>s work in web development is they do not let touch through; maybe that's why it's how I sort of expected it to be...

  • Just a couple of threads below yours is mine "Why is touch propagating to other objects and how to prevent this?" that is about exactly this same problem.

    I also asked the same thing a couple years back and the answer hasn't changed since then -- you have to logic around the touch "leaking" every time you have overlapping touchable objects (including pop-up windows; menu bars; sprites like in your game).

    For me personally this is just counterintuitive and opposite to what should be the default so it's either:

    a) this is a specific design choice made for reasons I am not aware of

    b) it is problematic to solve due to Construct's/HTML5/JavaScipt/whatever architecture

    c) it is not considered to be an issue in the first place (or if so, a super low priority one)

    As I said in the other topic I would postulate that in 99% cases you want the touch NOT to activate anything below what you intend to click/touch.

    Ashley Could you perhaps drop in a word or two on this?

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Actually clever approach; with the FunctionName. I'll try it out.

    Adding groups or control variables and enabling/disabling is more or less what I do; still none of the hoop jumping would be necessary if objects just didn't let touch/mouse through, especially because in 99% cases this is the intended behavior.

  • I agree that Construct's arrays in general feel somewhat fiddly.

    I haven't had time to take a closer look at the new JavaScript features so no idea if they work that way but maybe it can be used to declare a "real" JS array and use where needed?

  • While I love Construct's workflow there is one issue with the touch handling that has came up in every single of my projects for years.

    The lack of a setting for not letting touch/click through to the underlying objects.

    Example: You display a dialog box on top of the game; now clicking anything in it will also trigger random touch events below. Same with menu bars, pause screens etc..

    Actually it's kind of hard to find use cases where it would be the desired behavior for touches/clicks to leak all the way across everything on the Z axis.

    It would be way more convenient to just slap a "stop touch" tickbox on a button rather than go around juggling variables and conditions to prevent said issue from happening.

    Since a lot of games contain popup boxes etc. I'm starting to think maybe I'm missing something or maybe there is a go-to obvious workaround (other than "manually" disabling touch handlers by means of variables/conditions etc)?

  • I USED to make money publishing apps/games a couple years back (mainly Construct and Corona SDK). This was a one man gig. I published my own free apps and got money from ads.

    At peak I earned about half a standard monthly pay a day which was awesome.

    The problem is you need to a) be super invested into this i.e. spend a lot of time, post regular updates and do at least a minimal amount of marketing (I only bought ads on FB and Google) b) keep coming up with great ideas.

    The pattern for successful apps was always the same: sudden peak in popularity, then a couple of weeks of significant income; then boom one day it plummets down to peanuts a day and stays there. And of course there were some that earned peanuts start to end.

    So I would say it IS possible to earn significant money; but I wouldn't count on steadily living off of this for years.

  • Nepeo

    Good points.

    I’ll have a look at what’s eating my resources the most. Also will post capx if there is no apparent cause.

  • Asmodean

    Nice trick for future reference but I need collisions to be checked kind of precisely within time so I would not take risks here. ;)

  • teahousemoon

    Good point about the debugger but unfortunately in this case the number of circles is strictly controlled and displayed on screen in a statistics box and new ones are created only sporadically on reproduction in a visible manner. So it is practically impossible that more than I know of would be created by mistake.

  • Define:

    > with 1-3 additional objects attached and some instance variables and calculations.

    Each circle (a container) has a larger circle (as a proximity sensor), a 1x1 px anchor sprite for making sure pinned labels don’t rotate, two labels and an invisible shooter sprite that’s used for some interactions and a dictionary object (for storing genes).

    There’s about 10 instance variables and more or less 20 different simple calculations “every second” on these (e.g food -1). On collisions there’s an additional calculation for pointing the shooter sprite at the colliding object.

    EDIT: ah that’s more than three but initially there was only one label, the larger circle and the anchor sprite. The decline in performance at large number of instances was just as noticeable as currently though.

  • Thanks!

    Just to be clear:

    If I have a one-screen white layout (1920x1080), and say 1000 small circles moving via Bullet and bouncing of walls and each other, and given that everything is as optimized as it gets, do you think it should be more or less handle-able on a fast computer?

  • Hi,

    So I'm making this evolution simulator for experiment purposes (not a game) and stumbled upon performance issues.

    There is no physics but quite a large number of objects (simple circles) with 1-3 additional objects attached and some instance variables and calculations.

    At 300-400 objects the simulation stutters and at ~500 it practically stops.

    So I was thinking, I know that this is high-level code etc., but still, shouldn't modern computers be able to easily handle a few hundred moving circles?

    Ideally I would like to be able to simulate a few K of objects. Is there a way around this? I don't need to run it on mobile at all.