So not a whole lot got done on the project this week. It was a rough week at work, which kinda put me in a state where I didn’t want to work on this project when I got home, I just wanted to play video games or do whatever else. Also the feature that I had put forward as the first thing I wanted to accomplish in Phase 2, refactoring the ball-paddle collision physics, is a little involved and didn’t lend itself to a “put 30 minutes in and get something done” kind of feature. This should improve next week and I hope to make up time from last week and get back on my timeline. That said I did get some cool stuff done which should be exciting to see.

The first thing I accomplished this week was modify the Jenkins CI pipeline a bit. The pipeline had previously been creating and maintaining .tar.gz artifacts that contained the executable JAR. I realized this was a little silly, as the JAR should be runnable on both Linux and Windows machines without modification. So I refactored the Jenkins pipeline to create .zip files instead so that we have artifacts that can be extracted on both Windows and Linux systems.

The next thing I did was add a shake effect to the camera. This wasn’t even on my To-Do list for the week, but the idea came to me one evening and it seemed like a fun task to focus on for a few hours. I pulled most of the implementation from here. The core idea is to make a class that can translate an orthographic camera around “randomly”, and build in some logic so that it knows when to shake the camera. This was a really fun task to work on for an evening, as the resultant product isn’t really tied to this game’s implementation at all. I could use this on any number of projects going forward. I tied the shaking to whenever a ball breaks a SimpleBrick. My plan going forward is that that destruction of the brick is what triggers it, so if a ball hit’s a ToughBrick that doesn’t break on the first hit, the hit that breaks it is what will trigger the shake. A gif of the shake in action is below.

After this detour I did get what I think is a good new concept for ball-paddle physics interactions designed, and I even prototyped it in the game. However I stopped a little short from full implementation of the new idea, as it seemed wasteful to implement it without having first implemented a BallManager. So, implementing a BallManager class is the other thing I did this week. This class works similarly to the BrickManager in that it’s a “model” object that keeps track of all game balls, and it is the object that interfaces with game balls directly. I believe there will be a time in the near future where the player will be able to get more then one ball on the board at any time, and since I think I may implement that kind of gameplay, the BallManager was a must.

The only real notable thing with the BallManager implementation was that I ran into a bunch of concurrency errors during implementation. The BallManager keeps a reference to all Ball objects in an ArrayList, and it ends up accessing this ArrayList for most of what it does. I had built a method for the ball to call when the ball died, and in this method I had the BallManager parse through the list and determine if all balls were dead (which would cause the BallManager to tell the GameMaster that the player had lost a life). I found that when the last ball died (if there had been a large number of balls in play, and thus the list was large), I would crash the application with a concurrency exception. This was because the BallManager was trying to parse the list to see if all balls where dead, and at the same time the game would try to update, which would cause the BallManager to try to access the list to update the game. I tried synchronizing these operations for awhile, but ended up just landing on an implementation where the BallManger does the check to see if any balls are alive as a part of it’s update cycle.

To test this BallManager functionality, I built in some test code where I can arbitrarily add new balls to the game by pressing the ‘A’ key. A gif of this is below.

That’s about all that I accomplished on the project this week. Like I said, it’s less then I would have liked, but I’ve been busy. I hope to devote more time to the project this week to make up for lost time, get back on schedule, and hopefully wrap this thing up.