Notes to Future Programmers
1) Make the I/O more robust
Currently the I/O can handle a lot of user mistakes, but more can be done. To make sure any .env or txt file can be deleted, hard code the creation of the “MushroomKingdom.env” file, so if it is missing, a new one is generated to replace it. Also make the program more forgiving to out of order information by checking the tag every time, so anything can go in any order. You could even go a step further with this and take in each piece of data as a string, attempt a parse with a try catch, and substitute hard-coded data if it fails
2) Organize the code
The code has gotten a little out of control, and before expanding the game any more, it could use a little combing over. How to do this would be completely up to you.
3) Allow importing indestructible objects
Currently the ground only changes based on the gravity, this causes a problem if you want a barrier on the top and bottom of the screen, or if you want the gravity making the bullet go away from the ground. Indestructible objects could remedy this, because ground, platforms, and anything else you can’t shoot through or destroy could be imported (instead of being a part of the background image as they are now).
4) Create a way to loose
This is an arcade style game, so we never had an intention to have a way to win, but a way to lose (other than quitting to the menu would be nice). Deciding what makes a loss is the hardest part. Once you decide, simply use the same code that the “Main Menu” buttons in the shop and game panels use. This will bring up the Submit Score frame, and process their score.
5) Take in code from .env files
This would allow you to execute code when a destructible object was destroyed, increasing score, powder, money, or perhaps something more complex. The .env files are already equipped to handle this with the DestructableSpecial: tags, you just need to figure out how to process it. Stack overflow has some good information on this, try there.
6) Allow Custom Projectiles
Everything else can be user created, why not the projectiles? The code can handle this fairly easily, and you can just add a button to pnlPlayShop to accommodate its purchase.
7) Background Sound
All you need is a compatible sound file; the GameSettings.txt file is already equipped with the BackgroundSound: tag. All you need to do is add the location of the sound file and it will play, I just couldn’t find something compatible.
8) AI
AI would be a whole different area of the game where the boss could shoot back at the player. This would require extensive work, but its where I see the game going next.
9) Efficiency
Although the game doesn’t lag, I have a bit of an idea for better efficiency. This is sort of like double buffering, but only with the images that are static (unmoving). Things like Mario and the Boss could be painted on to one background image, when would be updated from the original background whenever a boss dies etc. This would reduce the amount of code in the overloaded paintComponent() method.