I am putting some time in improving my code and make my tiny game smooth and decently playable.
The result I obtained is really far from this (bugs everywhere, the game is slow and boring, it accelerates and slows down without any apparent reason).
Clearly there is a lot to do and a long path to walk but I'd love if you guys can share any suggestion like changes I need to implement, maths / physics / trigonometry I need to study.
I am sorry if this question is very broad but I'd be incredibly happy to get even the tiniest hint.
This is my current code:
A version of the game can be found online:
Thanks for your time and patience :)
You're doing it the right way, I mean, recognize the boringness of your game and asking for help, and only for that, I will spend some time to give you my feedback.
I think, if the game is boring, it's because of the slow speed of the ball. So first, I suggest increasing it. Also, every short amount of hit with any pad, you need to increase it again, in a way that the player will notice it, plus a special sound to tell the players.
Second cause, you decide to implement a blockout-style control: the direction the ball will take after a hit with a pad is relative to the distance of the ball with the center of the pad. The player and the CPU can throw the ball to each other in a straight line, and can never lose. Remove the feature and do it like pong. 45° forever.
There is also a problem with your actual implementation of ball speed. The ball is faster if it goes n diagonal than if it goes in a straight line. If you want to keep the blockout-style control you have to fix that, using two information: a number for the speed, and a normalized vector for the direction.
Third reason. The CPU always try to catch the ball using the center of its pad, making the ball it hit, always goes in a straight line. I can write an entire post about how to code the CPU to make it more fun. Maybe later if you ask for it.
Fourth, if you increase the ball of the speed you will notice that you can't catch the ball anymore because of the slow speed of the pad. Guess what you have to increase also the pad speed.
Now, because the ball will gain speed faster it should be harder to catch it after a couple of seconds. The player has no other choice to guess where the ball will hit when it will return to predict the exact position where he should move his pad to catch it again. Right? (make sure you understand this). But, because the ball will always go 45°, it is possible now. And that's part of the game-play. That's making the game fun, like pong. Newbies players will chase the ball and good players will predict the next hit.
Regarding the pad control, there is tones of way to create a good feeling. I will explain a simple solution, easy to implement and good enough for a pico-8 game. Use a variable for the pad acceleration. Increase it by one every frame when player press the down button. Combine it with a max value, something like 3 or 4. And add this value to the position of the pad. (y axis). When the down key is not pressed anymore, decrease the acceleration until it reachs zero. Do the same thing for the up key. Test it, it should have a weirld effect if player rapidly switch between up and down key. To fix that, you can invert the sign of the acceleration value when, e.g.: if down key and acceleration lesser than zero.
To finish :
- the green color is ugly :p
- the sfx when a ball is missed should not sound like success, but failure.
- pad and ball are too big.
- win message burn my eye.
- the game need a lot of polishes.
To be fair, your title music is pretty solid. Why not keep it around during the actual game?
You could even increase the speed of the music as the ball gains speed. Would require some poke()'ing into the RAM though, I guess. Has anyone ever tried this?
How can I push my cart to the bbs?
I will check pico-8's manual.
Wow, thanks for such a long and detailed feedback!
Are you sure that pong just does 45 degrees forever?
All the implementation I tried allow the player to change the degrees depending on position / speed...
"There is also a problem with your actual implementation of ball speed. The ball is faster if it goes n diagonal than if it goes in a straight line. If you want to keep the blockout-style control you have to fix that, using two information: a number for the speed, and a normalized vector for the direction."
This is not really clear to me...
Would you mind explaining with a small example?
"Third reason. The CPU always try to catch the ball using the center of its pad, making the ball it hit, always goes in a straight line. I can write an entire post about how to code the CPU to make it more fun. Maybe later if you ask for it."
I would be VERY happy to read such a post (and I think I would not be the only one) :)
Other suggestions are more or less clear, really thanks for your time and patience.
Thanks for your suggestion!
I'll find something to play during the game, good idea...
Awesome quality of my music is just thanks to Gruber's genius:
ltpitt: I have been thinking about vector movement recently, so I made a demo cart that shows what (I think) moechofe means about using a number for the speed and a vector for the direction.
Basically, your ball is moving in a certain direction (the angle) at a certain speed. If you store these values in their own variables, then you can change them very easily. When your ball actually moves, you can use sin() and cos() to calculate the x and y distance using the angle and speed.
[Please log in to post a comment]