0x416c616e/2d_game_redo

2D game written in Java/OpenJFX

2d_game_redo's Issues

Online high scores

Eventually, I can use one of my LAMP servers for high scores.

The score will be simple: when you beat the game, the total XP you have is the score. Your name and score get submitted as a query string for a PHP script on the LAMP server, which then checks to make sure there's no SQL injection or whatever, and then stores the values in a highscores database table. There can also be a menu option to view the high scores. Names might not be unique, so there has to be a primary key, like submissionID, that is auto-incremented.

Town Events = interface rather than map

A Town will be a type of Event that puts a new Pane on the screen.

The game world will be an overworld map, and there will be no town maps per se.

A "town" will just be an overlay on top of the worldPane that lets you click on stuff for things like shopping, talking to local NPCs (a tavern or something?), and things like that. This is so that the coding and loading/unloading will be simpler. Fewer maps to make, and subsequently fewer loading/unloading methods needed in the MapLoader class.

Pseudo-destructors

Java doesn't have destructors per se, but you can use Object.finalize() to run when an object is removed via GC:
https://stackoverflow.com/questions/29814050/how-to-define-destructors
System.gc() doesn't always run. It's kind of nondeterministic and basically just a suggestion to the JVM to run GC. But you can tell when someone has been garbage-collected when the finalize() method is run. So maybe I can use that to make sure Event/Tile/WorldMap/worldPane stuff gets destroyed for map unloading when transitioning to a new map so ensure that there aren't any memory leaks.

Memory leak

Reevaluate the menu stuff, do more testing, and also look at the stuff that involves new, like new Font(FONT_SIZE). Replace all of that with a single Font object, i.e. Font globalFont = new Font(FONT_SIZE);
Maybe also set the Scanners and File objects to null after using them.

Event types should be subclasses of Event

i.e. shop, dialogue, random encounter, mapMove, etc. Maybe has a polymorphic method called getEvent() which takes args for WorldMap and Pane, and then gets the resolution of the game from the WorldMap object's x/y getters (or maybe it will need a separate String resolution arg), and then uses that to determine where it should put the different Event objects on the screen.

Types of event triggers: on movement and on interact key. Examples of on movement triggers: mapMove and random encounters. Interact key events: shop or dialogue.

Combat

To keep things simple, there will only be one character, and you only fight one enemy at a time. There is only one class: warrior, but with a healing spell. Abilities are unlocked automatically when you level up. The scope of the project has to be limited in order for it to be completed in a timely fashion.

Implement WorldMap class

Then it can be populated from XML using the loadMap() method in Main.

After the WorldMap class is finished, and then a WorldMap object is created in the loadMap() class, then it can use the player x,y position and other map info in order to load the tiles of the game world, using an offset for the character position in the middle of the screen which has to account for the resolution, because different resolutions have different numbers of rows and columns for tiles on the screen.

New ideas to address performance issues

1. Don't load map from XML. This is too slow. Instead, hard-code each level. This is worse in every way except for performance, which is important. Of course, there's no guarantee that hard-coded levels will be faster. But I'm pretty sure they will be. Current loadMap() takes about 20 seconds, and keep in mind that this is with the minimalist implementation and only for 720p too, which is not good.
2. Delete all current classes except for Main and Player. Tiles should be redone for the new hard-coded method.
3. Don't use loadMap(). Make new levels for loadMap0_0, loadMap0_1, and so on. And the values for the image, event, collision, etc. should be hard-coded, not from XML. For performance reasons.

Heap and metaspace size

I found out that I can decrease the memory usage of the program by using the vm arg -Xmx32m. This sets the max heap size to 32 megabytes. Of course, the program still uses more than 32MB of RAM, because there's other memory being used too, such as the metaspace, which by default is 1GB. I didn't change that. But the unloading/loading test (doing it hundreds of times in a single session) yielded memory usage of 130MB instead of 190MB like before. This is because the garbage collector will be more likely to collect garbage if the used heap memory is a higher percent of the max heap size.

There's also the issue of reserved vs. actively used heap memory. Some Java GC options prefer to have a higher amount of reserved heap for performance reasons, because GC can be expensive from a CPU perspective.

But all in all, -Xmx32m seems to work fine for reducing memory usage. However, in the future, when there are more features added to the game, a 32MB heap might become insufficient, and then I'd have to use -Xmx64m, -Xmx128m, or even -Xmx256m. But by default, it seems like the max heap will be about 1/4 of your computer's total RAM.

So it's not a memory leak after all, just that the GC doesn't collect garbage unless it thinks there isn't enough free heap space left.

Add 1280x800 back in

It turns out that the tablet display is actually 16:10 aspect ratio. It supports 1920x1200, but I don't feel like adding that, so I will just add 1280x800 back in as a resolution option.

Interface Busy player attribute

There should be a boolean in the Player class (along with getters and setters) for keeping track of the player's busy status due to having open interfaces. Controls, such as generic movement methods in the MapLoader class, should check if the player is busy due to an interface before they can move. For example, if the player opens a menu or inventory, they should not be able to move with WASD or the touchscreen keys.