Hey guys, recently I have been getting into a lot of Java game development after a semester course on Java at university. I'm doing everything in my own spare time and sometimes it's hard to wrap my head around the more technical aspects of the language.

I'm in a similar boat for learning to program but I hope I can give you a few tips.

As far as creating a separate class, I would definitely recommend it. Usually the answer for me is yes anytime I ask myself if I should create another class. It is good OOP and helps a ton with keeping things organized. The fewer classes I have, the harder I find it to remember what each one does haha. When you separate them logically, it's easy to remember each class's function and to remember what you plan with each part.

Also, if you want to get a good idea of how to organize your game, I HIGHLY recommend looking at other game developers' source. I've got a couple projects set up in my Eclipse that Notch wrote for Ludum Dare. They might not be a perfect example because they were done in 48 hours, but they still help guide me through the process.

Best of luck man, good to see someone doing the same thing as me. MORE GAMES!!!

Iirc it just stores the objects/blocks in a big 2d array of ArrayLists. The database of how to handle the objects is really nothing special, it's just that the view is "warped" to look isometric when the game is drawn.

I'm in a similar boat for learning to program but I hope I can give you a few tips.

As far as creating a separate class, I would definitely recommend it. Usually the answer for me is yes anytime I ask myself if I should create another class. It is good OOP and helps a ton with keeping things organized. The fewer classes I have, the harder I find it to remember what each one does haha. When you separate them logically, it's easy to remember each class's function and to remember what you plan with each part.

Also, if you want to get a good idea of how to organize your game, I HIGHLY recommend looking at other game developers' source. I've got a couple projects set up in my Eclipse that Notch wrote for Ludum Dare. They might not be a perfect example because they were done in 48 hours, but they still help guide me through the process.

Best of luck man, good to see someone doing the same thing as me. MORE GAMES!!!

I'm glad someone else is feeling the same way as I am! I am the point now where I understand simple OOP structure, but when it starts to get larger and more complex I'm totally lost.

Iirc it just stores the objects/blocks in a big 2d array of ArrayLists. The database of how to handle the objects is really nothing special, it's just that the view is "warped" to look isometric when the game is drawn.

Thank you so much for the source code, so awesome! I may or may not have a few questions for you in the future if you'd be willing to help me out

I'm glad someone else is feeling the same way as I am! I am the point now where I understand simple OOP structure, but when it starts to get larger and more complex I'm totally lost.

We can do it!

Hey, I'd love to hear your input on the stuff I've put on my blog. It'll be good to hear from someone around my skill level. If you get a chance check it out. Link is in the signature. I'm actually working on tile maps for my game right now. We can probably learn some stuff from each other.

Also, if you have any requests for helpful tips or tutorials let me know. Thanks!

I know there are a lot of people around here who roar about it, but there's something in me that can't stand the idea of using ArrayList (Or any other sort of List structure/class) for this sort of thing. I've even been working on my own little library for dealing with them. Mainly, it's for storing a map of a known, probably static size (Google Drive Version & Dropbox Version). I need to work on documenting it a bit better, but if you want to look at the code, you can probably get an understanding of most everything through it. The important classes in there for isometric will probably be 'TwoDimensionalMap' which includes a 'Dense' version which is written using an Array of Arrays and a 'Sparse' version which uses a HashMap (Perhaps not the best method). The former is meant for a map that probably 75% < full of objects, the latter is more for 25% >. I know that leaves the middle 50% open, but I just haven't messed around to test it enough.

However, from what I've read so far you're confusing the issue slightly. What jdgamedev said is correct: You should be attempting to separate your objects/classes into logical components that do their job and only their job. But, take this one step further, you need separate your concepts between "Logic/Backend" and "Graphics/Frontend". The class that you're using to store the data about the tiles should probably not know anything about how it's going to be drawn. It shouldn't even know that it is going to be drawn. Instead, it should probably know enough information that you could write several different renders (ASCII, sprite-based isometric, sprite-based isometric 30-degree, 3d, etc.) to draw it.

As for writing a regular 2D sprite-based one? Really, you have the Renderer which will have access to your map, it will iterate through your map in some form (Several different ways to do this based on how you're going to set up your system) and then get the texture/image somewhere to draw it to the screen. Depending on how complex you want to go, you can just have your rendered hold the images internally, or fetched some how. I don't have one written that uses Slick, but I do have a few that make use of LibGDX (They're technically Hex-Isometric) that I can post if you'd like to see a specific instance.

On a side note, you should probably figure out how you'd draw it as a regular Sprite-based isometric (Meaning squares instead of diamonds), first. This will make sure you know how to draw stuff to the screen before you try to figure out the way you'd actually map it to a 30-degree isometric (Diamonds).

However, from what I've read so far you're confusing the issue slightly. What jdgamedev said is correct: You should be attempting to separate your objects/classes into logical components that do their job and only their job. But, take this one step further, you need separate your concepts between "Logic/Backend" and "Graphics/Frontend". The class that you're using to store the data about the tiles should probably not know anything about how it's going to be drawn. It shouldn't even know that it is going to be drawn. Instead, it should probably know enough information that you could write several different renders (ASCII, sprite-based isometric, sprite-based isometric 30-degree, 3d, etc.) to draw it.

I have never or rarely done that.I would just have different methods, if different kinds of rendering were interesting - which I have never had the case... maybe debug render and normal render. But again its just 2 methods...I like OOP but I dont like having 300 classes. I think game programming should be really pragmatic - cases that will never ever happen, dont really have to be coded. It depends of course.

I use lists/collections over Arrays every time single time I can. Unless there's a specific reason, I don't see why anyone would bother with simple Arrays over Lists?

Arrays have a set size. If you've got a structure (A game map) that will very rarely change sizes and that you don't want to be able to change sizes accidentally then you set up an array for it. I mean, yes, you can use a List and always ensure that you prepopulate it objects to hold your tile data and ensure that when you remove something you're actually switching it with null to ensure that your ArrayList remains square, but that really feels as though you're using an Object list (Which is backed by an Array) to create the behavior of a regular array.

I have never or rarely done that.I would just have different methods, if different kinds of rendering were interesting - which I have never had the case... maybe debug render and normal render. But again its just 2 methods...I like OOP but I dont like having 300 classes. I think game programming should be really pragmatic - cases that will never ever happen, dont really have to be coded. It depends of course.

Don't dis the idea of multiple renderers! Especially not when you're trying to work on the logic of the game and don't need to get bogged down with the graphical candy (Top-down square isometric is much easier to visualize path-finding on for most people, unless you're implementing certain types of height-maps-- multiple tiles can occupy the same XZ but have a different Y). Either way, it's considered a better practice (Correct me if this is incorrect!) not to tie your game logic to your renderer/GUI so that if you have to make a change to your GUI/Renderer you don't have to go back and tear out all of the GUI/Renderer code that had leaked into your logic.

However, from what I've read so far you're confusing the issue slightly. What jdgamedev said is correct: You should be attempting to separate your objects/classes into logical components that do their job and only their job. But, take this one step further, you need separate your concepts between "Logic/Backend" and "Graphics/Frontend". The class that you're using to store the data about the tiles should probably not know anything about how it's going to be drawn. It shouldn't even know that it is going to be drawn. Instead, it should probably know enough information that you could write several different renders (ASCII, sprite-based isometric, sprite-based isometric 30-degree, 3d, etc.) to draw it.

I think I'm at the stage in my programming where I can understand how object oriented programming works, but am confused with when I should use it.

However, what UprightPath said really hit home to me and helped me to understand the logical aspects of a object oriented structure. (Thank you!)

I'm glad someone else is feeling the same way as I am! I am the point now where I understand simple OOP structure, but when it starts to get larger and more complex I'm totally lost.

We can do it!

Hey, I'd love to hear your input on the stuff I've put on my blog. It'll be good to hear from someone around my skill level. If you get a chance check it out. Link is in the signature. I'm actually working on tile maps for my game right now. We can probably learn some stuff from each other.

Also, if you have any requests for helpful tips or tutorials let me know. Thanks!

Nice blog jdgamedev, very cool idea! It's inspiring to see someone just as enthusiastic as I am to get into game development! I will be sure to follow your blog!

I use lists/collections over Arrays every time single time I can. Unless there's a specific reason, I don't see why anyone would bother with simple Arrays over Lists?

Well, they behave differently. If I know I'm at all times going to have 2K of an item I won't use an ArrayList. The functionality the ArrayList provides is useless in my specific example. Also, I can change my array while I iterate it.

Well, they behave differently. If I know I'm at all times going to have 2K of an item I won't use an ArrayList. The functionality the ArrayList provides is useless in my specific example. Also, I can change my array while I iterate it.

You can change your ArrayList while you iterate through it (Technically!) by using the Iterator's methods rather than the List's. Well, you can remove values, and if you need to add things at the end, then add them at the end of the iteration.

Lists are more for dynamic sets of elements. They're suited to adding/removing/iterating type operations and obscure the actual code behind having to do that (ArrayLists shift elements on a mid-list remove, they grow the array backing it when you add enough elements, etc. and LinkedList obscures the creation of the List nodes).

Thing is, I never know before hand if I'm going to have exactly 2k of an item or what not. ArrayLists have it all with no additional costs. Unless there's something peculiarly specific or something trivial, there's no benefits of using the basic array over ArrayList.

The matter between Arrays and ArrayLists (Or Lists in general) is like comparing shears and scissors (They look alike, are used mostly in the same way, and in some ways you can say that one is just another form of the other). Yes, they're alike to a point, however they're tools made to do specific tasks. An ArrayList is, at its heart, a List. An Array is an array. While an ArrayList uses an array inside of it, they're meant to perform different tasks. With an ArrayList there is a lot of internal code that is an additional costs over a regular array. There's the code that shifts the elements in the backing array when you do a 'remove' or when you do an 'addAt', there's extra fluff in the form of keeping track of updates/additions to make sure that an Iterator created for use with the ArrayList doesn't break due to post-Iterator instantiation changes, and other such fun.

If you're using an ArrayList as a List (Meaning an unbounded collection of ordered elements which are likely to change order) then all of that other code is good. If you're using an ArrayList as an array (Meaning a size-bounded, index-accessed, ordered set of elements) then you're probably going to spend more time fighting with the API to ensure that it meets the other constraints.

What do you mean by "additional costs"? If you mean it's slower because of it then you're wrong unless you're nitpicking. However, in peculiar situations and trivial tasks the array could be easier to use but you're certainly not gaining performance.

If in doubt, use an ArrayList. You really shouldn't reach for raw arrays unless you need to save storage with primitives ... and even then you should probably use something like Trove collections instead.

The matter between Arrays and ArrayLists (Or Lists in general) is like comparing shears and scissors (They look alike, are used mostly in the same way, and in some ways you can say that one is just another form of the other). Yes, they're alike to a point, however they're tools made to do specific tasks. An ArrayList is, at its heart, a List. An Array is an array. While an ArrayList uses an array inside of it, they're meant to perform different tasks. With an ArrayList there is a lot of internal code that is an additional costs over a regular array. There's the code that shifts the elements in the backing array when you do a 'remove' or when you do an 'addAt', there's extra fluff in the form of keeping track of updates/additions to make sure that an Iterator created for use with the ArrayList doesn't break due to post-Iterator instantiation changes, and other such fun.

If you're using an ArrayList as a List (Meaning an unbounded collection of ordered elements which are likely to change order) then all of that other code is good. If you're using an ArrayList as an array (Meaning a size-bounded, index-accessed, ordered set of elements) then you're probably going to spend more time fighting with the API to ensure that it meets the other constraints.

I disagree -- most of the time you should be using ArrayLists -- arrays tend to be for "special cases" (e.g. fixed size pixel data, performance critical areas, modifying buffers, etc).

In the vast majority of situations, the performance/memory difference between ArrayLists and arrays is extremely negligible and should not affect your decision to use one over the other. Instead, you should choose whichever leads to better ease of use and readability for your particular situation.

Using an ArrayList as if it were an array is often a good idea -- it enables you to use generics with more freedom, allows you to use Collections API methods like sort(), etc -- and I can't imagine any reasons why it would lead to "fighting with the API".

The matter between Arrays and ArrayLists (Or Lists in general) is like comparing shears and scissors (They look alike, are used mostly in the same way, and in some ways you can say that one is just another form of the other). Yes, they're alike to a point, however they're tools made to do specific tasks. An ArrayList is, at its heart, a List. An Array is an array. While an ArrayList uses an array inside of it, they're meant to perform different tasks. With an ArrayList there is a lot of internal code that is an additional costs over a regular array. There's the code that shifts the elements in the backing array when you do a 'remove' or when you do an 'addAt', there's extra fluff in the form of keeping track of updates/additions to make sure that an Iterator created for use with the ArrayList doesn't break due to post-Iterator instantiation changes, and other such fun.

If you're using an ArrayList as a List (Meaning an unbounded collection of ordered elements which are likely to change order) then all of that other code is good. If you're using an ArrayList as an array (Meaning a size-bounded, index-accessed, ordered set of elements) then you're probably going to spend more time fighting with the API to ensure that it meets the other constraints.

I disagree -- most of the time you should be using ArrayLists -- arrays tend to be for "special cases" (e.g. fixed size pixel data, performance critical areas, modifying buffers, etc).

In the vast majority of situations, the performance/memory difference between ArrayLists and arrays is extremely negligible and should not affect your decision to use one over the other. Instead, you should choose whichever leads to better ease of use and readability for your particular situation.

Using an ArrayList as if it were an array is often a good idea -- it enables you to use generics with more freedom, allows you to use Collections API methods like sort(), etc -- and I can't imagine any reasons why it would lead to "fighting with the API".

I have changed my mind about ArrayLists too. I use them much more often now. But I totally disagree using something like this:

1

ArrayList<Integer> list [...]

because the memory footprint of Integer is so heavy, so this is totally not a good Idea.

I disagree -- most of the time you should be using ArrayLists -- arrays tend to be for "special cases" (e.g. fixed size pixel data, performance critical areas, modifying buffers, etc).

In the vast majority of situations, the performance/memory difference between ArrayLists and arrays is extremely negligible and should not affect your decision to use one over the other. Instead, you should choose whichever leads to better ease of use and readability for your particular situation.

I was nitpicking there. I'll admit it. When it comes to the amount of performance/memory difference between ArrayLists and arrays, there is very little. I just took issue with him saying "At no additional cost" earlier on. There is an additional cost, it's just really really small.

Using an ArrayList as if it were an array is often a good idea -- it enables you to use generics with more freedom, allows you to use Collections API methods like sort(), etc -- and I can't imagine any reasons why it would lead to "fighting with the API".

Well, I am honestly talking about the special case that this topic is about: Isometric Maps. Which tend to be a specialized type of grid indexed collection. You wouldn't be using many of the Collection API methods on it, like.. Sort. How/why would you want to sort a map? I mean yes I can think of a few reasons why you would (Find the positions with the least number of X or something), but on the whole many of those operations do not have a logical application when thinking about what's basically supposed to be the physical representation of a world. And even if you did want to do a sort on them, you probably wouldn't want the map's ordering to change.

As for the fighting with the API comment?1) When you instantiate an array each index is automatically given a default value. This means that as soon as you instantiate your array, the operation array[index] will return a value (It might be null, or 0, or something) but it won't throw out an IndexOutOfBoundsException, which rather is nice when you're dealing with a sparse map (Which is to say that you can do array[index] = thisElement without worrying that you didn't fill in the ArrayList with the correct number of null values to ensure that it's square).2) With the List API you can accidentally cause your data to shift by using an operation (list.addAt or list.remove), you can't do that with an array.

Yes, both of those issues are easily taken care of. One by ensuring that when you generate your ArrayList<ArrayList<Element>> that you fill in everything correctly to make it square and the other by ensuring that you don't use the addAt or remove functionality. But at that point, you're really just using the ArrayList like you would a regular array, so... Why use the ArrayList?

I'll admit that when I'm doing a map I don't tend to directly access an array any more, but that's because I took the time to define a data-structure just for dealing wit grid-based maps (Which is based off of the ArrayList's method of dealing with a 'Generic' Array).

Edit: Really, I'm just trying to point out that the ArrayList VS Array thing is sort of a "When all you have is a hammer" mentality. Actually deciding what the best tool for the given situation is is better than automatically saying "This is better because it's an Object" or something like that.

I was nitpicking there. I'll admit it. When it comes to the amount of performance/memory difference between ArrayLists and arrays, there is very little. I just took issue with him saying "At no additional cost" earlier on. There is an additional cost, it's just really really small.

You somehow make it sound as if it's better to use Arrays over ArrayLists because they're faster in terms of performance. A very dangerous illusion. It's like comparing a comfortable car with all kinds of useful gadgets that can go 100 km/h to an old rusty race car that can go 100.000000000000000000000000000000000000000000000000001 km/h.

Edit: Really, I'm just trying to point out that the ArrayList VS Array thing is sort of a "When all you have is a hammer" mentality. Actually deciding what the best tool for the given situation is is better than automatically saying "This is better because it's an Object" or something like that.

I agree, but unless the case is trivial you usually should need a very good reason to use a simple Array over an ArrayList. A very good reason might be e.g. "Straightforward" or "I'm lazy" but you might be setting yourself for some refactoring in the future.

In this case where we're talking about a map it's perfectly fine to use an Array imo. But I'd fill the Array with ArrayLists to handle objects based on z/depth.

Performance/memory is still extremely negligible unless you're dealing with many hundreds of thousands of elements every frame, or if you're dealing with a ridiculously huge array.

Err..you're math's off a bit. The cost of boxing/unboxing (although experimental version of hotspot are working on speed this up) and multiply the memory footprint by a factor of four is really quite significant. Presumably you're doing a bit more that simply walking this data-structure once per frame. Do most people need to worry about this? nope.

I have changed my mind about ArrayLists too. I use them much more often now. But I totally disagree using something like this:

1

ArrayList<Integer> list [...]

because the memory footprint of Integer is so heavy, so this is totally not a good Idea.

I don't see anything wrong with it. I don't see any particularly good uses for it either. But certainly nothing based on performance.

Premature optimization is much worse

An Integer is a class. So the JVM has to save resources about the Object. (Some info in the accepted answer (Stackoverflow))So at least (if running a 64-bit JVM) you need 64 bits for the adress of the Integer, and additional 32-bits for the int field inside Integer.Using int will reduce the memory used, to 32 bits.

It's still moot, as I said before. The differences are extremely negligible unless you are working on performance-critical areas -- in which case you should have used primitive types in the first place.

The boxing wastes an actually significant amount of space for something as large as a tile map. The JVM will try to reduce things to unboxed form where it can but there's nothing it can do about the storage.

Now if you have a list of just a few dozen elements, then sure, stop worrying about the overhead.

You guys have taken over this thread and turned it into an argument (multiple arguments actually...)

How bout we stick to addressing the questions that were actually asked and keep the other stuff to their own threads. As a matter of fact, this forum could probably benefit from a comprehensive discussion on Array vs ArrayList and other similar topics. Link to a different thread if you want to start it, otherwise you're just wasting people's time who come to this thread for answers pertaining to the original posters questions.

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