Slick Forums

As the title says, I am wondering if it would be plausible to use Strings instead of integers for state ID's. As far as I know, state id's are only supposed to be 'The game unique ID of this state'.

Now I'm not suggesting we use Strings instead, of course, hashes of Strings would be fine for this use case. This way, people could use both integers and strings.

Opinions?

_________________
Liam (liamzebedee) Edwards-Playne
Cryptum

Why exactly do you want to do that? Because of naming? If so you should simply use public static finals

_________________
Current Projects:
Mr. Hat I
Vegan Vs. Zombies
Projects:
RadicalFish Engine - Build on top of Slick2D, Ideas, Bugs? Open an Issue ticket!

I also like strings for state names, compare following code

how it could be:

instead of

or


good idea!

I fail to see the advantage...

You can easily use constants as you showed and import them statically if writing "Globals." in front of it is too much.

Also using constants has the advantage that you can use your IDE to easily find every location where to this state by just searching the usages of the constant.

Nitram

_________________
http://illarion.org

I don't see the upsides too. It's also slower since the lookup will work on int == int and not string.equals(string). (Altough this is fast and you don't jump constantly through your states)

_________________
Current Projects:
Mr. Hat I
Vegan Vs. Zombies
Projects:
RadicalFish Engine - Build on top of Slick2D, Ideas, Bugs? Open an Issue ticket!

yes, strings could be used instead, but i dont think the source should be changed to implement this.

The use of strings may make certian programs look easier to write, but i don't think it adds any extra functionality or conventionality (if thats even a word). The way I understand it, global variables are the cleanest way of using both constant integers and constant strings, meaning that the method proposed would not actually make clean code cleaner. Also, because the string and integer serve the same purpose, there is no functional benefit. if needed, Strings can be implemented by the user (as you said).

_________________
"Artificial intelligence will never be a match for human stupidity" - "Jamos Kennedynos"

When you give each state a name. There is no need for a global variable. See my previous post.


The idea was to use the hashcode of the string:


This discussion is about adding 2 new methods in statebasedgame:

addState(String) will take the hashcode of the state name and set it to the stateId,
enterState(String) calls the enterState(int) again using the hashcode.

I see real usage in this! please give it another thought

Saving the hashcode as the identifier is possible. How ever you could do that with the current state too.

Just write addState("blabla".hashCode()); if you like this. But if we introduce that as feature we get a whole set of new problems namely hashcode collisions (and how ever unlikely they are... they are possible, so they will happen.)

Nitram

_________________
http://illarion.org

It also means users would need to do this:


Which seems very redundant and unnecessary when they could just as well use ID = 1. It would introduce two different ways of doing the same thing, i.e. adding clutter and confusion to something that should be simple. And hash code collisions become a problem as Nitram said. Two states named "Aa" and "BB" would collide, and it would not be clear to the user why.

Ideally strings should have just been used from the beginning instead of ints, i.e. in the StateBasedGame's hash map itself (to avoid such collisions). But at this point changing it would break a lot of code and require some significant refactoring, all with minimal gain.

If we ever make major changes to Slick (i.e. "Slick 2.0") then IMO Strings would be better. Personally I find the whole state based game architecture to be a bit messy right now -- e.g. ambiguity of enter(), ID of -1 is reserved (but it's not clear to the user), etc.

Why not use a semi enum system like this the StateKey class in TWL. This allows fast (integer) based compare and array indexing, and at the same time gives named access.

_________________
TWL - The Themable Widget Library

Because as davedes said. It would add clutter to something which already works and is fast imho.

_________________
Current Projects:
Mr. Hat I
Vegan Vs. Zombies
Projects:
RadicalFish Engine - Build on top of Slick2D, Ideas, Bugs? Open an Issue ticket!

Something like this might be worth adding to ShaderProgram for faster glUniform lookups.

Adding it smoothly to game states would require refactoring as I see it -- a constructor or something which will break slick games.

i didn't read the complete post but for the sake of simplicity and readablity in my game i've converted them to enums
also my states (used in the update method), zones, block types etc... (its a match3 game with puzzle and endurance mode)