So. I have a generated tile map. I want to make it so that when you make it, there will be a variable called “default_tile.” I want to be able to put in a default object that will be copied and used. Until now, I just made a huge class that wen something like this:
public static final int Rock=0, Sand=1;
public static Tile getTileOf(float x, float y, int type) {
if(type == Rock)
return new Rock(x, y);
if(type == Sand)
return new Sand(x, y);
}
I’m assuming you’re using ints because you want to read/write from file? You can use Enum.ordinal(), but a better solution would be to just use the name:
//write tile to file...
String name = Tile.Rock.name();
//parse tile from file...
Tile tile = Tile.valueOf(name);
You can do a lot of cool things with enums. For example, implement an interface:
public interface ButtonListener {
public void clicked(GameContext context);
}
protected enum MenuActions implements ButtonListener {
PLAY("Play") {
public void clicked(GameContext context) {
//States is another enum!
context.enterState(States.GAME);
}
},
HELP("Help") {
public void clicked(GameContext context) {
context.enterState(States.HELP);
}
},
EXIT("Exit") {
public void clicked(GameContext context) {
context.exit();
}
};
public final String text;
MenuActions(String text) {
this.text = text;
}
}
Now your GUI code is decoupled from the actual content of your GUI. In other words; when you want to change the menu text or button actions, you don’t need to touch your GUI code. Typical usage:
//iterate through each button in the menu buttons enum
for (final MenuActions a : MenuActions.values()) {
//use the text we specified in the num
TextButton btn = new TextButton(a.text, skin);
//add the listener specified in the enum...
btn.addListener(new ClickListener() {
public void clicked(InputEvent e, float x, float y) {
a.clicked(context);
}
});
//add the button
table.add(btn);
//then move down a row
table.row();
}
You ninja’d me with recommending enums, but now I’m glad you did! That is actually quite useful and I wouldn’t have though of it myself. I’ll probably start using that technique now. Thanks!
It does not have anything to do with enums, hashmaps are just genric java stuff.
An hashmap allows you to look for objects really fast, example:
HashMap<Integer, Person> people = new HashMap<Integer, Person>();
people.put(4564534, new Person("Person1"));
people.put(2342423, new Person("Person2"));
people.put(2135344, new Person("Person3"));
Now imagine this list is very long (100+ / 10000+ maybe).
When your looking for an person in a array (with his id), you need to loop trough the whole array.
With an hashmap, you dont have to!
if(people.containsKey(id)){
return people.get(id);
}else{
//Person does not exist
}
There really isn’t much (optimization?) of your example you can do (that I can think of):
public static enum Type {
Rock, Sand;
}
public static Tile getTileOf(float x, float y, Type type) {
if(type == Type.Rock)
return new Rock(x, y);
if(type == Type.Sand)
return new Sand(x, y);
}
This at least makes it so that you can’t pass in an invalid Type. (Like you could accidentally with ints)
Also there is Reflection: (there’s probably a better way of using generics, I’m not too practiced with them)
Best not to use reflection. Generally it is poor practice / code smell when used in this fashion. Better to use object-oriented patterns, or plain old enums if you know your types are fixed. Here is a related design pattern: http://alvinalexander.com/java/java-command-design-pattern-in-java-examples
If you have very few and very simple tiles, then enums work fine like I posted earlier. You don’t need reflection to get the enum Type. Just use [icode]Type.valueOf(String)[/icode] or [icode]Type.values()[index][/icode].
Tile type also should not have any information about x/y coordinates. Why? Because a tile is just a type; either rock, sand, or grass. It isn’t an entity on the screen.
In most cases you will want to store more than just “tile type” along with a tile. For example; see the following tile map:
Most of it falls under “Sand” although it can’t all point to the same tile type. So your options here are to use a tile type for each tile (SandDirtTopLeft, SandDirtTopCenter, etc) – but that gets ugly real quick. Another option is to use “traits” instead of focusing strictly on tile types. So, the sand tiles have [icode]Trait.Walkable[/icode], the objects might have [icode]Trait.Blocked[/icode], and some objects might have mutliple traights, like [icode]Trait.SignPost[/icode].
It quickly becomes pretty daunting to work with tiled maps, which is why it’s almost always a better idea to use pre-made solutions rather than trying to reinvent the wheel. For example:
LibGDX supports the TMX format, so it’s a piece of cake to use.
Ah, but it will take you many years to make your own that is up to the same standard. Some of them spent troubleshooting. :point:
Also, libGDX isn’t a fad by any means of the word.
[quote]I am surprisingly ‘meh’ about libGDX. I mean, I would rather make my own awesome engine, that I understand completely, and will never have to troubleshoot on, than use an even awesome-er one, that will maybe be just a fad in a year, of which will take a year to fully understand. Plus, you get to say that you made an engine from scratch, and that is fun to say with truth.
[/quote]
It doesn’t take a long time to learn LibGDX. Maybe a month or two. Keep in mind LibGDX has been in development for years and is made up of several million lines of code.
For example; why write your own TMX loader when you can just use LibGDX? LibGDX TMX Loader
Rather than spending your time writing a lot of boilerplate code, IMHO your time would be better spent learning higher level OpenGL concepts, like shaders and meshes:
If you want a good tile map editor, with even a fraction of the features of Tiled, then it will most likely take a lot longer to develop than it will to write a TMX parser.
Anyways; good luck. I’m sure in time you will realize that building an engine is tedious. Or, maybe after a number of years of development, your engine will rival LibGDX.
good programmers write good code; great programmers steal great code