s.Mason

If your resource loader is returning the images/audio from the hash map by reference, then your instance is using the SAME copy and taking up no additional memory (except the size of a pointer/reference.) However, for images, if you're rendering with hardware, then you are also necessarily holding a copy of the image in video memory.

Also, I go about my resource loading in a different way. I like to have a completely generic loading backend, when possible, that loads files from some source (generally the filesystem, but could be the network, or an archive) and puts them into memory as a blob. Then, I pass that blob off the particular subsystem to be decoded and whatnot. This way, you don't end up duplicating your file loading logic. Loading images, loading audio, loading models, etc. are all the same at the most basic level.

Great, thanks for resolving that inquiry of mine. And thanks for the tip there. I'll work on abstracting my file loading logic a bit more so that I could go at the same you do. Thanks .

Here is an example of a Sci-Fi ship I made a while back. It uses the Sci-Fi blue theme. Don't mind the intense contrast, I made it for a game i made in a week for a competition.

Wow, that's pretty cool. Whats the engineering on this though? are the four legs meant to be engines? Where are the engines? Is the center circle some sort of reactor? I tend to like to design spacecraft that makes sense in a engineering perspective as much as possible so I'm just curious. Other then that, love the detail and style .

@thatOneProgrammer Java or not, you get the point. However I apologize on my criticism, reading it now is barely constructive. I guess what I was trying to say is that you need to think less like a programmer and more like a gamer (if you plan on improving this game and releasing it). For example, I would have been less likely to close the game window if there was at least a quick initial and interactive tutorial on the controllers of the control panel. The fact that you have some text in a help file isn't the way to go either. You're gonna want to give in basic instructions on how to use your interface the first time a user is playing your game. THEN have a help file or something on a website that further explains parts of the game. So that once a player is into your game, they can use that help file or webpage for reference. It should only be there to expand the knowledge the player has about your game if they so wish to do so. It shouldn't have to be read to be able to play the game.

Other then that, try to read up a little bit on game design, there are several articles you can find just by doing a google search or checking out the game design forum here. I'll say that especially for a game like this, that is somewhat unusual. You're gonna want to hold your player's hand and explain the most important things of your game in the quickest and most interactive way you can think of. So like I said, do a little bit of research on game design.

Lastly, disregard my graphics comment. I tend to praise more functionality and gameplay over graphics. And really unless you're trying to sell this, I'd say just keep using the placeholders and focus on the gameplay.

I don't really understand why that isn't already perfect, at a glance I can tell the depth.
If it gets darker+darker as it gets deeper, eventually it will be black, most people understand that black means it's so deep that no light gets down there.

Reading this made think, if you really wanted to add so many layers. What you could essentially do is have different world maps all linked together. For example in reference to that image in which the tiles get darker as the area gets deeper, it could then eventually just be pitch black. A player could then jump through that to realize the player is now on just a lower layer. Its pitch dark so they would need some lighting.

ex.
tile layer 1 _ _ _ _ _ _ _ _ _ _
tile layer 2 _ _ _ _ _ _ _ _ _ _ _ _
tile layer 4 _ _ _ _ _ _ _ _ _ _ _ _ _
tile layer 5 _ _ _ _ _ _ _ _ _ _ _ _ _ _

so on that little representation there, layer 5 from a top down view would be pitch dark and could potentially be just a endless void. This is all part of game map. When the player goes through layer 5 and jumps through that little entrance there.

player lands on new game map

tile layer 5 _ _ _ _ _ _ _ _ _ _ _ _ _ _
tile layer 6 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
tile layer 7 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
tile layer 8 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

with such a method, you could potentially have plenty of layers, you would essentially have players just jumping through different game maps. If done right, getting layers pre-loaded and what not, it could be sync seamlessly with as much depth as you need.

IMHO you got a good start. I downloaded the game. First thing I noticed was the level selector, Seeing no game interface what-so-ever I simply assume this is just a prototype so I let i slip. I select a level, and here is where I'm surprised, immediately I'm thrown into a storyline about a robot (though it could use some work in terms of the actual dialogue, its good enough to get someone emerged to a small extent to at least want to continue through the dialogue). After the whole dialogue, I finally got to that map window and thats when I was just confused and with a "wtf?" reaction... Seconds after I just closed it.
For being a game its got too much programmer spice on it. You need to add some more design toppings with a layer of graphics. No offense but I've seen 13 years old make more visually appealing games. And the fact that you using awt and/or swing components such as the buttons doesn't make it anymore appealing.

So on a final note, I would say the idea has some potential but it needs some serious work in terms of interface, design, and visuals.