Rikifive

@Tacodidra Thank you!  I'm sure you will.  Heh yeah, just like me trying to get back to practicing more on guitar, I get what you mean.  No worries though, take your time, but you know, it would be nice to see you make some progress.  

Goodnight! 

Goodnight! Good luck with drawing and programming! 

@EpicEnergy Thank you, I'll totally need that.  Goodnight! 

I have seen foreground art as rather distractible, and usually removed during development in several games. I would say wait with it for now. it can always be added in later. (I have nothing against it)

^ pretty much this. Sometimes it tends to be distracting and since I can't really control where exactly the elements will pop out, sometimes they might end up covering important things, for what players will automatically roast me.

I'll try things after I'll build a level to see how it will feel.

It's a good idea of course, though I gotta be careful with that.

I loved how Everfree Forest looked!  Especially how the far-back navy-blue background got darker as Twilight moved further to the right; it gave a very subtle sense of the forest getting denser and darker.

Oh yes, it should look better- and I hope it will.  

Everfree Forest may contain caves / underground passages, but this is still subject to change. For now I made some of the most important (basic) graphics for that location to help me visualize it better. I haven't got into actual level design yet, so I'll be planning the layout of the whole Everfree Forest soon.

Also I think of these more as locations, rather than levels, as it will be kind of an open world, where you will be able to travel between locations pretty much whenever you want, unless restricted by story event. Where you'll have to go will be told by story/objectives, but you can go there sooner or later. With that being said, some locations may require being visited more than once, pretty much just like in the show.

Backtracking can actually be an excellent part of gaming, sometimes, especially if the environments are interesting and eye-catching, or if changes related to the story have happened to the areas you're backtracking through.  Metroid Prime 3 comes to mind, especially Elysium.  (I hope you've played that game so you'll know what I'm talking about!)

Heh I haven't played any Metroid game, which I suppose is kinda a shame. Never owned these games, so I guess I've missed some stuff. I keep hearing about these games and I have a basic idea what it is about.

So I'm not getting the reference, but I can imagine what you mean. I think I've played games, that had something similar, though I can't think of any from the top of my head right now. 

Oh yes! That would be something!

Twilight the Pony?  

@Rikifive, Yes! And she can charge Gnasty Gnorc's, I mean Grogar's minions with her horn!  

Hasbro, forget Pony Life, make this game!    

Yeah, such game would be way better!

@Treeglow Flicker Oh I'm not a fan of it either.  Depending on what kind of movement and collision you have, it tends to get really, really tricky, I know that feel. It took me a while to setup that properly, imagining behavior, drawing on paper - boxes and walls simulating movement frame by frame to get the idea of what to expect - when and where's collision and what to do to handle that. At first I had some funny things, like teleporting, getting stuck in a wall or the worst - getting the game stuck in a loop, freezing it.  It's a bit confusing yeah, but I think I got it now, haven't bumped into any issues.

@Bas But that's the opposite - Twilight in my game doesn't move fast, but slow - just 1.5 pixels / frame. And if I recall correctly, Ponyvania handles the camera in a different way - it's sorta centered to the character, it is dragged by the character at the same speed, where in my game it smoothly follows the player, introducing tiny fractions.

(the gif is a bit choppy, 'coz it has a limited framerate, otherwise it would be too large; It's already pretty big as it is)

Ponyvania pretty much does what I've mentioned earlier:

Quote

If I'd stick the camera to her (like in Terraria, for example), everything looks perfect even when she moves that 1-2-1-2-1-2-1-2-1-2 pixels per frame.

The problem is the smooth approach I have, where the camera has its own dynamic speed depending on the distance to target, rather than being dragged by the character at the same speed. In short, what I have is something Ponyvania doesn't have.

Besides, I'm a member of that server already, I've been invited by someone earlier, don't remember by who though.

@HereComesTom Yeah, your game has a simple system, where the character either moves at static speed or doesn't move, so no sliding, friction and that stuff. Moves and suddenly stops.  There's nothing wrong with that of course, it all depends on what you want to have in your game and such static speed is a totally viable option used in many games. So, this decision is entirely up to you.  

Though one thing I could suggest considering is to smoother the vertical speed a bit. The character is going up at static speed for a specified amount of time and then suddenly sharply goes down at the same speed without slowing down in the middle. So basically jumps are "V" shaped, which is a little bit odd in my opinion. With horizontal movement it's totally fine, but vertical speed is usually smoothed a bit to a "U" shape. 

A perfect example would be "Contra" from NES. If you hold a key, the rambo-guy moves at static speed, when you release the key, he suddenly stops (unless in midair, where he continues to move at that speed), so it's similarly to your game. However, the jumps are smoothed a bit, where the character slows down before reaching the top and starting to fall.

So yeah, that's the one thing I could suggest, but it isn't an issue of course, that's mostly a matter of the style you want to have.

As for camera, there's the same thing, it's a matter of preference and the style you want to go with, so I'm unable to give an accurate answer.  

@Rikifive While I watch your gameplay, I don't sense the camera the way you intend it to do. So let's think simple...

Twilight's position is key here. Take Twilight's integer position only (the stage coords), and the state she is in, such as walking in a direction, ducking, jumping, her speed, anything that the camera should interact to, and now you have all the data you need, but the camera will act on them in reverse. The camera doesn't follow Twilight. The camera is relative to her stage coordinates. The relative value must be integer and fraction away from Twilight's integer position only (for pixel perfect drawing).

The camera is placed on its own defined x and y axis relative to Twilight, so many integer and fraction needed to get what you want, as far as camera movement goes. But the position is always relative from Twilight's integer position, when her frame movement and collision has been calculated (her final position for the frame). Lastly, you clamp the camera to the outer parts of the map as a visual step (you don't modify the distance from Twilight).

Example: Camera starts dead center to Twilight (same position), such as local_cam_x and local_cam_y are both 0 (biased to center of screen). As soon as Twilight does anything, like ducking, the camera will starts changing the local_cam_y in such a way that she is looking downwards. If Twilight walks forward, the local_cam_x is increased in the opposite direction, making it look like the camera is pushed backwards, but now, believe the camera moved outside the stage boundaries? The final camera position is clamped to the edges of the stage.

When the camera has been calculated, all the sprites including Twilight herself, should be displayed on the screen relative to the camera. Result is the same as you have now, only you have more control over custom movement, and you don't have to think about those nasty jumping between pixels trying to target an odd coordinate.

I recommend scrapping the fraction and going back to floating point. Always round to floor (that's what integer does, and also that's what all your favorite games did in the past), and round at the last possible moment (when the sprites are being shown). Trust me, just do it. you save yourself headache later. You will get the same result as you do now, same errors as you do now. The issue is in GML, using floating point as default anyways. When you do integer + integer, you fail and lose more pixels than if you let floating point add up the fractions. (this is a floating point problem, not an integer problem. Floating point will always lose precision if you start modifying anything beyond the decimal point, as floating point values are stored as exponent and mantissa, not as an integer plus a fraction!!!).

Yeah, that's one of the approaches I was thinking of giving a try, but it was really late when I was working on it (that status update was created at almost 5AM), so I kind of couldn't think straight lol. I tried that, overcomplicating things and it didn't work hah. I'm still not exactly sure if it will work well in the way I want it to behave, but that's something I'll have to test.

The camera is already basing on Twi's target position (her coords + direction offset) specified in integers and follows that point on its own. ... in a very simple system at the moment. Welp, currently the camera does its job and allows me to easily switch target it should follow, so it will be fine for now. This is something, that can be adjusted anytime, so I'll get to it later.

Quote

believe the camera moved outside the stage boundaries?

Clamping is one of the first things I did - implemented, not added at the beginning of the calculation process, that is.