GDSag3's Recent Forum Activity

  • I had stuttering using a Galaxy Tab 2 7.0 at first boot up but later plays had it running fine, so your game works well on an old tablet at least. I suspect the stuttering had to do with the google account prompt and when connecting to Google Play.

    The design is deceptively simple. You end up thinking "Yeah, that's not going to be hard" but when it speeds up the tiniest amount it has you panicking. I agree on the coins. Having to drag coins to the chest takes you away from the core gameplay. Now, that might have been the original intention (having to balance when to swap dragon heads and when to go for the coins) but when it speeds up, you end up not bothering with the coins because no matter when you go for it, it's gonna mess up your current play. You could have a tap to collect OR you could have a flick to collect (flick it towards the chest).

    I don't agree with a life system, though. The sense of progression should come when you're adept enough to push on further and being able to purchase multiple lives sort of undermines that. A one time use lifesaver powerup would be a good compromise, though. Something that appears every so often and you have to drag it to the Dragon heads to activate it. For example... Fire Breath. When activated, if the wrong food gets eaten instead of a game over the dragon head that is about to eat the wrong food burns it to a cinder. One time use and doesn't stack (gotta make sure another powerup doesn't appear when it is currently activated).

  • Ok, I have an idea I'm going to try out but I'm stuck on one thing.

    Basically, I set a global variable known as Charge and have it where if the "C" key is held down a 1 is added to Charge every 0.2 seconds. The max for that charge will be 7, which would be reached in 1.4 seconds (I may change these timings depending on what feels good in terms of mechanics). Then, when "C" key is released, whatever value the Charge variable was at will be stored. What I do then is use that value to determine the length of the jump. So, if the value was between 0 and 1, a short hop to the right will be executed (x angle of motion). If over 1 but under 2, a slightly lengthier jump to the right is executed. And so on, with over 2 but under 3, etc, etc.

    Does that look good? If so, and this is where I'm stuck, how do I store the value of a global variable when the key is released?

  • Spring Ninja's spring mechanics is perhaps the best way to describe what I am aiming for. So, depending on how long a button is held down for, upon release, the object jumps at a certain angle to cover a certain amount of distance. So, a simple tap would just make the object hop slightly to the side (almost like a sidestep) whereas holding down for a second would charge up for a medium jump and any longer would charge up a larger leap. Again, the input only charges the jump. The actual jump action does not activate until the player has released the input. I was looking into Platform behaviour for this but now I'm thinking maybe Bullet behaviour would be more fitting (angle of motion and all).

  • I really like the art style. Nice and chunky.

  • Looks cool and making it open source... very nice *tips hat*

    I actually have a concept rolling around in my head that I intend to work on (after my current project) and it too would be top down Zelda-like (albeit more arcadey, bite-sized), so having a template out there I can sift through if I have trouble with my own is good to know. Hope it all works out for you.

  • Damn it, I am a numbskull. My layout size was different to my window size. >O<

    It works now. Thanks for all your help.

  • Thanks again. If it's not too much trouble, could you explain the code? I'm trying to get a handle on it but since I am using a different layout size I think the hard coded numbers are incompatible (the wrap is starting late). If I understood it better I might be able to go about making it work for my project. I did try LayoutWidth but that doesn't seem to work (object starts to disappear as it nears the edge, it does this in your capx if I use LayoutWidth in that). I think what's tripping me up is the hard coded numbers say 600, 800, etc, and I'm trying to figure out how that corresponds to the actual layout. Sorry for being so dense I just want to actually understand it.

  • [quote:3cs3assw]Take a look at these 2 events. If you use 2 paddles exactly 1 WindowWidth apart and both with all the same behaviors (remove the wrap behavior), this will give you exactly what you want.

    Wow. That's a brilliant idea for a workaround. Thank you very much. One thing, I think it is on my end (a setting of some sort) but when I run the capx the paddle disappears when it passes the center of the screen.

  • Ok, so I've looked through the below topic since:

    And I downloaded the test.capx in the last post in that topic and what I want works perfectly in that test.capx. So I've tried to incorporate what works there into my own and... there is a wrap for my paddle but it isn't instant and seamless as the one in the test.capx. Going right results in the same sort of delayed wrap that the wrap behaviour does and going left results in my paddle disappearing before it hits the edge and then the same delayed wrapping as when moving to the right.

    X > LayoutWidth+self.Width/2

    set X to self.X-LayoutWidth-self.Width

    X < -self.Width/2

    set X to self.X+LayoutWidth+self.Width

    I'm trying to get a feel about what the code above means but I don't think I've got it. Could someone explain it to me, please?

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Have my game set in portrait mode and I basically want what is essentially a paddle in a breakout-like game to wrap to the other side of the screen instantly (so if the paddle sits perfectly on the edge of the layout the right side of the paddle sits on the left of the screen and the left side of the paddle sits at the right). Collisions intact. So the player can 'cheat' to get to the other side quickly and hit the ball. The wrap behaviour as it is isn't good enough for this. Will this be a complex thing to pull off it's just I don't have the slightest idea for what would be a good starting point. Thanks

  • Think of an activity you used to play as a kid for inspiration. I find that is better in coming up with your own thing than putting a twist on an already established videogame.

  • AHA!

    Thank you very much

GDSag3's avatar

GDSag3

Member since 2 Mar, 2015

None one is following GDSag3 yet!

Trophy Case

  • 9-Year Club
  • Email Verified

Progress

10/44
How to earn trophies