WackyToaster's Forum Posts

  • 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.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • 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.

  • You do not have permission to view this post

  • It's not shipped yet, there will be a stable release first, then the next beta cycle starts. So maybe in a week or two.

  • Yeah I saw the hint system, seems pretty good. I couldn't get it to work properly in version 1 either, but I got it running well in version 2.

    If the feedback in general was good, and your movement is fool proof, I guess you don't absolutely need it. Some of my levels defenitely also need some adjustments to make them overall require less steps. I've cut out a few at least and some will get those adjustments. I think such a feature in puzzle games makes more sense than in shmups though. If I were to make a shmup I wouldn't add a rewind, that seems weird an silly unless I also make it a core mechanic in general.

  • The game looks great though.

    Thx, funny though one consistent feedback was that the graphics are meh.

    Most issues were regarding the controls being sluggish, the lack of a "step-by-step rewind" feature and a lot of people thought it costs too much. I rewrote the entire game from scratch in a 3 week burst of insane momentum that surprised myself. I even added a handful of new mechanics on top. I grew a lot since the release. It's not entirely done yet though. But I think one of the ultimate issues was the lack of marketing, so few people bought my game barely anyone even disliked it. People just don't know it even exists in the first place. I have some plans to hopefully get some eyes on it, even if it's gonna cost me some money.

    What's funny is that the only reason I have any incentive to do all that is just one guy who really enjoyed it (despite also disliking the graphics). He sank like 70+ hours into it and even made a walkthrough, contacted me for help on one of the final levels. He said it's a hidden gem :) So I believe there's merit here and not just my general insanity of updating a "failed" game.

    But back to your game, does it have a step by step rewind feature yet? Because that was like the #1 request I got. It's pretty much expected it seems and I can kinda understand it (especially if the controls are sluggish and you accidentally walk off a ledge and die and have to do all over again, duh. That's frustrating)

  • Have you looked into Steam visibility rounds?

    No I haven't touched steam in a while apart from writing the announcement that I'm working on the udpate. I'll look into it.

    What is the game you're updating?

    Rimebeard. Please don't go out and review it, I actually want to stay low right now until the update drops. :V

  • It's going to be an update that I hope I can get out with a little bit of fanfare as to draw attention.

    perhaps once released the game will popup in people's "more like this" queue if they've been shopping for similar types of puzzle games.

    I forgot to add, this is exactly why you want those 10 reviews. Your game will get a massive boost in how often it is shown to people in these queues. Here's an article about that: howtomarketagame.com/2022/01/25/why-your-first-10-reviews-are-the-most-important

    It doesn't even matter if the reviews are positive or negative as long as it's 10.

  • Well what can I tell you, you are literally describing word for word how my first big release went. No marketing, I was super burned out at the end and I just kinda pressed the release button because I wanted to be done with it. The result looks like this btw.

    But I actually think your game might have a better shot at it. I certainly made some mistakes that I never ended up really fixing due to said burnout... which you seem to not make. So... good luck don't get disheartened if it doesn't work out.

    (As for my game, I'm actually working on a big rework because I believe I can salvage it, so it's a weird blessing in disguise that it sold this bad :^) at least that's what I like to tell myself)

  • Looks like a fine prototype. One thing that I absolutely suggest are levels that are on the easy side with few elements just to demonstrate how the mechanics actually work and slowly introduce them. It took me a few minutes until I somewhat had an idea on what I'm actually doing and was able to solve levels, but if you were to ask me now to explain how exactly the mechanics work, I couldn't tell you.

    Another suggestion is a rewind feature that lets you rewind step by step. Trust me when I tell you that people 100% expect this to be in the game and will get frustrated if it isn't.

  • Events run top to bottom, your event runs like this:

    1. Touch object

    2. Object is not selected -> set selected

    3. Object is selected -> set not selected

    Add an "else" to the second condition to fix it.

  • That's not how triggers work, you don't need that every tick. Although it doesn't appear to cause any issues either.

  • The key is finding a position opposite of where the player is.

    Get the angle between player and enemy with angle(player.X, player.Y, enemy.X, enemy.Y)

    Convert it to vectors using cos() and sin()

    Define a distance the enemies should run away

    Then make them run :)

    For pathfinding you'd also have to find the path to that position. In this case the endposition could for example end up inside a wall, which will trigger "on failed to find path". So you'll need some extra handling in place to make sure the endposition is not inside a solid object.

  • How do you actually move the enemies though, I'm assuming pathfinding behavior? That's just the code for finding the targets, which looks fine.

    I think what might be the issue in your case is a setting in the pathfinding behavior, specifically the "rotate object" setting, which you can probably disable in your case. Or it's the acceleration being too slow, and you could increase it.