Comment : blog post assignment 4
|
Hey Adam, good post! Movement was also a big part of Depth, my game. I had to revamp it a lot as well, since it always felt a bit “off”. I think there’s a balance to be had between gameplay and realism : the more realistic the better as long as it doesn’t destroy gameplay, since we want the player to be immersed while also having fun. Umibozu’s movement is a big challenge, since, as you’ve said it’s a huge part of the user’s experience. I think the one you propose is sound. It might, however, feel a bit off if you switch from one direction to the opposite and your speed changes instantly. I’ve also played a lot of um The sprite switching is also slightly tricky, it can get real messy real quick. Here’s what I did with my movement system. There are two functions, one which takes input on the X axis and another on the Y axis. Those functions return a boolean, which is used to decide if friction will be applied on that axis or not (if there is movement on the X axis, don’t remove velocity on that axis). Since I don’t need to switch sprites, I then simply change my Rigidbody2D’s position to the current position + the velocity vector * the actual speed * the deltaTime. The speed is a public float which you can adjust to your liking. Since you want to switch sprites, though, I guess you’d calculate the direction of the velocity vector and then have a few ifs which decide the sprite which should be set. Since you want the boat to rotate instead of simply going to its left/right, you’d have to change some stuff from what I did, of course, but the basics are pretty much the same. I didn’t have to think about the sprite switching during my development process, so it was interesting to read about your problem and think about it. I wish you luck!  |