J2ME development experience-use of arrays

Array | Experience It is not surprising that there are dozens of of rows of variable definitions in the game logic class. Especially for J2ME, in order to save memory space many people abandon the object-oriented features to squeeze the code together. The usual situation is that you have been drowned by your own code!! So when I do structural design I pay attention to this, always trying to make the code a little bit more scalable. This is not a very difficult thing. As long as the careful scrutiny can always find something to optimize, the variable is an example.
Most people are more accustomed to a variable of a property, for example, suppose you want to represent a character's attributes you might do this:
int life;
int magic;
int money;
int attack;
int defensive force;
The x axis where the int character is located;
The y axis where the int character is located
The line where the int character is located
The column of the int character
The current action of an int character
The direction of the int character's current walk
.....
It's just a part of it, and it's hard to think about naming so many variables, especially the bad English comrades. You may have seen it now. Using arrays is the best way.  At least two benefits 1 all variables are defined as a line of int fairy[], the variable is cleaned up and even a little bit of the taste of the object, when you want to write the character related code, you will automatically hit fair[]. 2 is extensible. It's easy to overlook the fact that when the character has a new attribute, you can use Fair[x+1 's lattice to indicate that it's not affected at all, assuming that the data type must be consistent.

A typical example of an array application is to represent a map. Let's say we're going to make a map of RPG. Most people's first reaction is to use a two-dimensional array to represent map[rows [columns] It seems plausible, but the problem is that maybe I want something on the map to move. This must be coupled with a few variable 1 currently displayed picture, 2 remaining how long to switch pictures. This is only the most common situation, there are more problems to be encountered. It is impossible for us to define variables for every moving place, which is too much to gain, for this three-dimensional array appears now to represent the map as follows
int map[line [column] [attribute];
Map [][][0] represents a category of pictures
Map [][][1] Indicates how many pictures are currently played to
Map [][][2] How long does it take to switch pictures?
Map [][][3] Whether this location can walk
Whether map [][][4] Triggers dialog 0 to indicate whether the remaining ID for the conversation
.....
We gracefully put the map-related things nicely in an array, and imagine what it would be like if you didn't use a three-dimensional array.