The thing is, I"m going to have over 100 images by the time the game is complete. Is it normal/standard to have 100+ BufferedImages defined in the field above the constructor in a given class? Once the images are initialized as the program is loaded, will it have any hinderence on performance during map scrolling later on?

It would be more normal to list the image filenames in an external file of some kind. You can have a text file with lines like "treasure_chest1 = some filename". It's always good to move the data out of the code.

You can then store the images in a HashMap, hashed by the name of each tile (e.g. treasure_chest1). This at least saves you from typing all those "BufferedImage whatever = ..." lines.

If the tiles are the same for every map, you will only need to load the images once. If they are different on different maps, having it set up this way allows you to load new images when you change maps.

I'm sure this can be improved upon, but it's a start.

Having over 100 BufferedImages shouldn't be too bad unless your tiles are really big. If you don't have much video RAM, you don't really need for all the tiles to be hardware accelerated, so long as the most common are.

If drawing the screen takes longer than scrolling the screen, you won't be able to scroll the screen as fast as you like. When you scroll the screen, you basically have to redraw the whole thing. If you have a sufficiently large area in video RAM (which might not even be possible), you could scroll by just changing what part of the area you're displaying. That might resolve any problems.

And loading... well, you can for example call em tile0001.png, tile0002.png etc and load em in a loop or put several of those tiles into one image. Or name mapping in the editor and packaging/map-remapping during the build process, but that's somewhat complicated and not really required for simple games with rather little media.

Ye, arrays are faster and far simpler than any of the collection classes. If you can use arrays without having to jump through hoops, you should really use em. For this kind of thing the number of elements is known beforehand and the size remains as it is for the whole run.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org