WackyToaster's Recent Forum Activity

  • I'd also go with the first approach. Managing the second option seems like more of a headache. I don't think modern computers will struggle much with big layouts, and resetting enemies doesn't seem like it's that daunting of a task. You can also implement the classic elevators like in super metroid, to still split up the game into maybe 4-5 big layouts instead of hundrets of small layouts. You will have to take care about making sure that enemies/elements that are not in the current room are disabled, otherwise you'll have some random enemy on the other side of the map waste CPU power.

  • The game looks nicely polished. The art is simple and crisp and sounddesign seems polished too. Puzzlegames are a bit of a weird niche and it's not easy to garner tons of attention unless you're about to make the next baba is you or talos principle. How many wishlists have you collected, some say the magic number is 10.000, although I think you can make do with less too. Getting reviews is also important once it's released, because steam won't really show your game off much unless you got 10 legit reviews, regardless if positive or negative. Legit in this case meaning reviews from non-gifted copies. So unleash your friends or bribe them if you have to :D

  • Glad to see my little experiments bear fruit :)

  • Well for starters you'd have a variable price that you adjust every second, for example it changes somewhere between -10 and +10 every second:

    System -> Every 1 second: Set value "price" = price + random(-10,10)

    Then you'd store this into an array. The length would be how long into the past you want to show the graph, for example, 1 minute = 60 seconds, so your array should be length 60. You'd use the FIFO method construct.net/en/make-games/manuals/construct-3/plugin-reference/array which will remove the oldest value (older than 60 seconds) and add the newest value to the front.

    Finally you use canvas to draw the line. Clear the canvas, then loop through your array.

    construct.net/en/make-games/manuals/construct-3/plugin-reference/drawing-canvas

    Then draw a line for each value from the previous value to the current value

    Array for Each: Draw line from X: (array.currentX-1)*20 Y: array.at(array.currentX-1) to X: array.currentX*20 Y: array.currentValue

    This is off the top of my head, you might need to tinker with some values etc.

  • I haven't seen anything up to date, but just from taking a glance at it a lot of principles probably still apply, it's just that in C3 there's better options to deal with it. For example, class inheritence is possible through custom actions. Here's roughly what I do:

    • Use families/custom actions where needed, which for example will apply to things like enemies.

    • Use functions where possible, especially if you suspect that you need to re-use the same functionality multiple times. E.g. saving the game can be triggered via autosave or via a button

    • Use eventsheets to group things that belong together, e.g. enemies

    • Then use groups to further divide the eventsheet up into the respective parts, e.g. I like to have a group called "enemies" and then have subgroups for each enemy like "enemies.goomba", "enemies.koopa",...

    • use local variables/instance variables/data objects in favor of global variables whereever possible. It's technically fine to have a lot of global vars, but often times it's not needed and it clutters the variable selection. So I'd reserve global variables for specific cases where it MUST be available globally and it's not worth putting into a data object (e.g. settings is a data object, not a bunch of global variables for each individual setting.

    • After a while you might notice certain parts of the code to "spaghettify", at least it always starts to happen in my projects eventually :D Especially when it's time to add a new feature. If you notice that, consider taking the time and refactor your code

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Just wanted to show even with changing values like the picture below it does not work. It only registers the first click and then wont come back.

    Ah, I saw another thing: since events are executed from top to bottom, it will first send the platform left, set directionID to "right" and then instantly after the second condition will be true, sending the platform right again and resetting the directionID to "left". You have to use an "else" in the second condition.

  • This doesn't work because both Tweens send the Platform to the same position X = 1200. One of them should be different.

  • Isn't this the main benefit of a tree structure, that sparse areas can just be one large node/cell and it only sub-divides where many instances are?

    I think the issue is that an infinite area cannot really be devided into two smaller areas as a quadtree does, because mathematically speaking infinity/2 = infinity. And a tree structure also has the limit of how many times it can divide. Even if we assume a limited size of 1 million x 1 million units, a quadtree depth of 4 would have the smallest cell size be 125k units, which possibly still contains a vast amount of instances.

    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 have the feeling that just with construct events you might not have much luck. You can load the binary data and then convert it into either text or base64. Are you trying to make a hexeditor or something? What exactly are you trying to achieve?

    I'm also not very familiar with hexadecimal values in general. Maybe this helps you? byby.dev/js-hex-to-decimal

  • According to the manual

    construct.net/en/make-games/manuals/construct-3/plugin-reference/filesystem

    List content

    nly applies to folder pickers. Retrieves a list of all files and folders within a previously picked folder. The Folder path identifies a subfolder to list the contents for, or can be left empty to list the contents of the originally picked folder. The File tag is optional and allows identifying when the listing operation completes or fails with the On file operation complete/error triggers. Once completed, the available files and folders can be accessed with the FileCount, FileNameAt, FolderCount and FolderNameAt expressions.

    So you'll make a loop using FolderCount, get FolderNameAt(loopindex) and then also list that content. You'll probably want to set this up so it runs recursively until no more folders are found.

  • I stand corrected, this is the best vampire survivors example I found, by fedca I guess I wasn't up-to-date.

    drive.google.com/file/d/1xL7J-6fcYV0DROR24FHLW_w1j78QgD4a/view

    BUT the example does not even use the collision system, it uses the physics behavior, which I assume uses it's own implementation and also runs as wasm. I don't particularly like working with the physics behavior though, it rubs me the wrong way, but that's besides the point. So I change my statement to: I have not seen a vampire survivors example that performs well that uses default methods of collision detection. I don't have any examples at hand, I just vaguely remember that one from r0j0hound.

    I'd be curious if tuning collision cell size (or even better: allowing us users to tune the collision cell size) would improve things already. It seems quite clear that at least the current settings do not fare well with densly packed sprites, due to the collision cell size. And that rBush thing Fedca just "hacked in", wow this thing is fast. :D I've never heard of it before.

  • I'd assume the los behavior shoots raycasts at all imagepoints to attempt to make sure that even if a small part of the object peeks out, it triggers the los. With such a small cone you'll shoot through these objects if it doesn't happen to hit an imagepoint + I think the objects being a obstacle themselves will potentially obscure image points on the backside that otherwise would trigger the los.

    Meaning small gaps can also fail to register los even if you set the cone bigger if no imagepoint happens to be visible behind the gap.

    I guess the way to mitigate that would be to cast a bunch of raycasts along the lines defined by the image points, rather than only the imagepoints themselves, with the tradeoff being that it's more expensive to do. Although I've been told raycasts are super cheap. OR you increase the amount of imagepoints but I don't think that's the smart way.

WackyToaster's avatar

WackyToaster

Member since 18 Feb, 2014

Twitter
WackyToaster has 25 followers

Connect with WackyToaster

Blogs