The Gravity of the situation

More work on the game. Added black/white holes which cause the shots to bend around the screen. This necessitated rewriting all the movement/velocity/acceleration code to use floating-point arithmetic – anathema based on my 20-years-out-of-date experiences on the Atari ST, but PCs can do gazillions of those calcuations per frame. Still not quite used to the fact that I don’t have to optimise the hell out of the main game loop. No excuses for being a sloppy coder obviously, but a lot of the old worries simply don’t apply any more.

InterScaptre with black/white holes

InterScaptre with black/white holes

If a shot is swallowed into the black hole, it gets spat out of the white hole. The ‘reach’ of the holes is infinite, and operates according to the inverse square law. However I do have to force the maximum shot velocity at 6 pixels/update, otherwise they can leap over the bricks. Thank you for self-normalising vectors!

This has a few interesting repercussions. Firstly, the bat’s maximum velocity is 8, so they move faster than the shots – so maybe it’s too easy to catch a shot. Secondly this means that the shot’s velocity isn’t changed by the black/white holes, only their direction. Which means that ‘c’ is 6 in my game and the bats move faster than light… 😉

I’ve also started work on the AI for the computer player. At the moment this is very simple: move towards the closest incoming shot. Unfortunately, that makes the computer almost unbeatable with just 2 shots on the screen – maybe when we’re both firing that will change.

The upshot of all this is that I think I need to make the bricks larger, so that the shots can move faster. Either that or I have to start doing some serious mathematics to calculate whether a shot would have passed through a brick since the last update… it’s been a long time sice A-level maths and calculating intersections between vectors…

Advertisements
    • RyokuMas
    • April 28th, 2010

    Nothing on the AI?

    • pauliharman
    • April 28th, 2010

    Um… I did mention the AI in paragraph 4! As I said the player is too good just following the simple “block closest incoming shot” rule.

    I will be extending the AI so that it has a sliding scale of preferring attack or defense. it will analyse the level of brick damage on each side and if offensive will try to fire shots at the opponent’s damage, and if defensive try to protect its own holes.

    • RyokuMas
    • April 28th, 2010

    Meh, I’m going senile… too much staring at screens! 😛

    • Ben
    • January 21st, 2011

    Surely you can do something based on the balls current X/Y coord vs that at it’s previous update?

    Also look into Ray.Intersects method – might help.

  1. September 6th, 2010

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: