Welcome to another episode of Game Development Design. This time I’m going to talk about the world of optimizing and engineering code: When and how much should I optimize? What level of generality is reasonable? What are the dangers of code improvements? How can I prevent common mistakes and bad habits?
Welcome to another small update on Tankoid, my Arkanoid clone.
I’m still in the process of building the C++ pendant to the Python prototype I did before. I did not come across any issues, but I didn’t have much time lately to work on it, out of two reasons: 1) Daily work. 2) Spent my free time on another project as well.
First things first: The C++ version already contains rendering of the playing field, the paddle and the ball. You can start the game, and collision detection is also present, together with disappearing blocks when you hit them. So it’s almost at the Python version’s state.
I have to admit that I’m (again) having a lot of fun with C++. The latest standard (C+11) is much less awful than what you had to do before, and having great control over CPU and memory is simply fun and entertaining. Granted, sometimes I have to roll my eyes when there’s again a situation where you have to think about how to design your code to reach a very basic pattern, but well, C++ is strongly typed and low-level, so that’s the cost I guess.
The “other project” is the one I have also mentioned in my initial post about coming back to game dev. I have finally decided to give it a go. It’s a serious game project, and it’s not easy. But it’s fun, and reaching a solid playable state is my ultimate goal for it. I feel very motivated.
My biggest wish is dedicating all my free time to the new game, but I really have to follow my initial plans: Do Tankoid, create another GDD article (or more), work on SFML. This is a MUST, and I think it’s also useful in terms of getting some rewards (i.e. when finishing something). It’s just hard to not do something that you would love to do, when all you have is a couple of hours per week of time that you can freely assign to such things.
And in the end, the new game will also benefit from Tankoid, at least. Writing C++ already feels familiar again, but I can still need some more practice. 😉
So stay tuned, and thanks for reading this!
Today I have completed the Tankoid prototype in Python, yay! The details:
Last time I had some issues with collision detection and proper response. After more experiments for finding the ideal solution, I stopped and exchanged the circle/rectangle collision test by a simple rect/rect collision test. The reason is that it’s simpler and makes the expected collision response easier.
When you play Breakout/Arkanoid, you expect the ball to bounce off the bricks by inverting its velocity. For example, if the ball bounces off the right side of a brick, the vertical velocity is inverted. When doing “correct” ball/rectangle collision response, however, the ball would behave completely different when hitting an edge, for example. I don’t want that, I want the gameplay to be easily predictable.
And now it works good enough! “Good enough” because there are still some glitches in very rare cases: When the movement of the ball is too high in one sampled step, the side detection might be wrong. But I can live with that.
The prototype contains a starting point, the gameplay itself and winning and losing conditions, everything you basically need for a game. And it’s already fun to play around in, so I guess it’s enough for a prototype.
The next step will be implementing a similar prototype in C++. I keep you updated!