Slick Forums

Discuss the Slick 2D Library
It is currently Sun Jul 21, 2019 9:18 am

All times are UTC




Post new topic Reply to topic  [ 13 posts ] 
Author Message
PostPosted: Fri Mar 23, 2012 8:32 am 
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?


Top
  
 
PostPosted: Fri Mar 23, 2012 9:20 am 
Offline
Game Developer
User avatar

Joined: Thu Mar 03, 2011 6:22 pm
Posts: 534
Why exactly do you want to do that? Because of naming? If so you should simply use public static finals :)

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


Top
 Profile  
 
PostPosted: Sat Mar 24, 2012 9:28 pm 
Offline
Regular

Joined: Mon Dec 08, 2008 2:17 pm
Posts: 160
I also like strings for state names, compare following code

how it could be:
Code:
statebasedgame.enterState("in_game");

instead of
Code:
statebasedgame.enterState(5);

or
Code:
statebasedgame.enterState(Globals.IN_GAME_STATE);


good idea!


Top
 Profile  
 
PostPosted: Sun Mar 25, 2012 12:17 am 
Offline
Regular

Joined: Sun Oct 30, 2011 4:47 pm
Posts: 184
Location: Mittweida, Saxony, Germany
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


Top
 Profile  
 
PostPosted: Sun Mar 25, 2012 10:45 am 
Offline
Game Developer
User avatar

Joined: Thu Mar 03, 2011 6:22 pm
Posts: 534
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:
Image Mr. Hat I
Image Vegan Vs. Zombies
Projects:
RadicalFish Engine - Build on top of Slick2D, Ideas, Bugs? Open an Issue ticket!


Top
 Profile  
 
PostPosted: Mon Mar 26, 2012 7:31 pm 
Offline
Oldbie
User avatar

Joined: Thu Jan 13, 2011 4:42 pm
Posts: 349
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"


Top
 Profile  
 
PostPosted: Tue Mar 27, 2012 12:13 pm 
Offline
Regular

Joined: Mon Dec 08, 2008 2:17 pm
Posts: 160
Quote:
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.

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

Quote:
It's also slower since the lookup will work on int == int and not string.equals(string)

The idea was to use the hashcode of the string:
Quote:
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.


This discussion is about adding 2 new methods in statebasedgame:
Code:
enterState(String) and addState(String)


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 :)


Top
 Profile  
 
PostPosted: Tue Mar 27, 2012 12:57 pm 
Offline
Regular

Joined: Sun Oct 30, 2011 4:47 pm
Posts: 184
Location: Mittweida, Saxony, Germany
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


Top
 Profile  
 
PostPosted: Tue Mar 27, 2012 4:51 pm 
Offline
Slick Zombie

Joined: Sat Jan 27, 2007 7:10 pm
Posts: 1482
It also means users would need to do this:
Code:
   public static final String ID_NAME = "MyState";
   public static final int ID = ID_NAME.hashCode();

   public int getID() {
      return ID;
   }


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.


Top
 Profile  
 
PostPosted: Tue Mar 27, 2012 6:56 pm 
Offline
Slick Zombie

Joined: Fri Jan 29, 2010 7:02 pm
Posts: 1242
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


Top
 Profile  
 
PostPosted: Wed Mar 28, 2012 8:08 am 
Offline
Game Developer
User avatar

Joined: Thu Mar 03, 2011 6:22 pm
Posts: 534
Because as davedes said. It would add clutter to something which already works and is fast imho.

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


Top
 Profile  
 
PostPosted: Wed Mar 28, 2012 1:36 pm 
Offline
Slick Zombie

Joined: Sat Jan 27, 2007 7:10 pm
Posts: 1482
MatthiasM wrote:
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.

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.


Top
 Profile  
 
PostPosted: Wed Mar 28, 2012 3:04 pm 
Offline
Regular

Joined: Thu Sep 22, 2011 4:39 pm
Posts: 165
Location: Belgium
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)


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 13 posts ] 

All times are UTC


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group