bladedpenguin's Forum Posts

  • I noticed some funky behavior with the alignment forces, and I looked at the code. It seems like you are using a naive average for angles, which can sometimes result in odd things such as -170 and 170 averaging to 0 instead of 180

  • I played through that penguin game. it seems to be using a decent aerodynamic lift model. If you are interested in doing some maths, I like https://www.grc.nasa.gov/www/k-12/WindT ... rmula.html

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Sounds like apicking issue. I guess the first step, for testing purposes, would be to make the Danger_Zone flash or something when the player is overlapping it. You want to make sure you only have one danger zone selected. THEN when you test for enemy overlapping that zone, it should hopefully only pick the correct enemies. Let Us know!

  • Ah well nvm I thought azu was on to something. I can't wait to see what you produce!

  • I wouldn't try any kind of automated speech recognition. If you were capable of that, you wouldn't be asking us. If you are going to do that though, find a javascript library and implement it as a plugin. I would definitely look for a javascript library over a python one, as I'm not aware of any bridge between C2 and python. (as partial as I am to python <3)

    My solution would be to listen to the audio, possibly slowed down, and manually pick out the word boundaries. I would try and markup the text with timestamps, Alternately put each word of the text in a 2d array, with one column being a single word, and the next column being the start time of that word. However you get to this point, you can now check the audio time, and use it to determine where in the text you are.

    Have you played with the Text object? Is it dynamic enough for your purposes? I don't think it supports any kind of markup, so I think the highlighted word needs to be a separate text object. Have a look through the completed plugin list though, as there may be a more featureful addon text object, and using some kind of markup would be much easier than separate text objects.

  • Clicking on the empty spots in a tilemap doesn't result in the object under the tilemap getting a click.

    This looks really interesting! I guess everything above the current layer is invisible, and everything below has it's scale and parallax altered depending on how deep it is. I don't imagine having any serious resource issues with less than half a dozen layers, but you will have to build it and find out. I look forward to your progress!

  • Ashley Thanks for the detailed response! It's always great to learn more about C2 internals. It feels good to know about whats behind the things we are seeing

  • The end result of your code is fine, assuming I understand the context, but I would say it falls under a simple use case scenario.

    Yeah... there are a number of simple use cases that C2 makes you work pretty hard for

    [quote:2csdt82w]In general it has been my experience that if you are using prebuilt behaviors and common use case scenarios, nothing is wrong. But the moment you need more, construct is an inflexible quagmire stuck in its own assumption about what the game creator needs.

    I have spent as much time searching for plugins and behaviors and writing javascript as I have actually using C2. I think that C2, flexible as it is, has taught me that real gamedevs actually do need to write code, or else loosen up and let the game be "not quite right". I've chosen the former.

  • As a programmer, I always find my inspiration from playing with new tools. We were already working on Apprentice for a bit when my artist introduced me to C2. I started playing with it, and pretty soon I was going "hey this is so much freer than RPGmaker, I bet I can make C2 do X". Then I would go and do X and thats how I got started. That wears off after a little while and I keep going out of professionalism, respect for my team, caffeine and raw desire.

    If you are already familiar with the tools, get a design document going. Write up what your game needs to do, and try to pick the elements that will interact the most with the rest of the game and do those first.

  • So I did some actual profilling and it turns out the 60-70% CPU in "Engine" wasn't spend doing collisions, it was something else I didn't have any trouble taking care of. oops lol. That'll teach me to rely on the C2 debugger.

    I ended up starting with every onscreen obstacle and grabbing the nearest charachter and comparing distance. It seems not too bad to use Is On Screen, since I only do it once per frame. I'm not sure how good "Pick Nearest" is, but it doesn't seem to be giving me any trouble. The main good to come of this I think is that I don't have a separate collider for each tree/obstacle.

    You need the full version to export or preview on another device. Some browsers, though, have features that let them emulate tablets/phones somewhat. On chrome, it's F12

  • Pardon the necromancy, but I'd rather not scatter discussion.

    These are a number of good workarounds, thanks be to R0J0hound, but I would like to see an option for it in the core 8dir behavior. I'll be off using a modified 8dir for my own nefarious purposes muahaha

  • 8000 is indeed quite a lot, and at some point I am going to implement something where groups of small trees get replaced with larger ones. Part of me wants to tune performance now, so reducing the number of trees later on will be an even bigger boost, or I can have a larger level or something. I guess what i really want is for trees offscreen to go to sleep.

    Ok that Is Overlapping/On Collision thing is super weird. I would have figured the opposite. Thanks for the heads up!

    It seems like I could keep the origin at the bottom of the tree and use an image-point at the visual center, then check the player's distance from that imagepoint. Is that likely to be more efficient than collision? I imagine if I require trees to be onscreen that would help. I kinda wish there were a way to set the SOL to "everything in the collision cell with the player" Edit: I just realized that this needs to be done for every onscreen Tree + Charachter combination, since I want trees to go transparent for ANY charachter walking behind.

    R0J0hound that seems like the Collision cell thing that is supposed to be already in the engine?

    I tried Zsorting everything on the layer by Y, but that turned out to be terribly expensive, so I'm really using collisions on the Outer tree so I know what to sort. I'm also doing a funny transparency thing with trees when you walk behind.

    Am I no longer allowed to attach stuff?

  • Hello! I have a forest, filled with about 8000 trees, and the seems to be working kinda hard on it. I was hoping to reduce that impact.

    One of the problems I see is that I need two collision polys for each tree. The outer collision poly matches the visual tree, and detects whether the player is behind the tree or in front or whatever, for visual reasons. The inner collision poly matches the stump of the tree and just has the Solid behavior. I have each tree represented by two sprites, with the second being invisible and immobile. C2 seems to be doing about 60k collisions per tick whenever the player moves....

    Is there a collision only object, or perhaps a cheaper method than a collision poly for determining whether a charachter is behind a tree? I am trying to maybe collapse this tree down to a single object and avoid the overhead of 16000 sprites. Thanks!

  • Construct 2 Is really not all that object oriented, and I feel that this is something that needs to be corrected. It should be like Python: Procedural and easy to get into without understanding all that OOP nonsense, but with the advanced features available when the student is ready to understand. "Pass SOL" would be a neat checkbox to have on a function call.

    That said, It's not critical becuase of the workaround mentioned above. I haven't had any problem passing UIDs around. It's worked quite well for me.