Quote:
What? I don't force anybody with the code to use it. It's just a few new methods oO Nobody must use them.
I disagree -- adding methods to an interface like GameState places burden on the user to implement them. Standard practice tells us that we should implement all of an interface's methods, otherwise throw an unsupported operation exception. Adding duplication (GameContainer pause vs. StateBasedGame pause) leads to a more confusing and cluttered API, and increases the chances of bugs/problems later on.
Quote:
I don't force anybody with the code to use it. It's just a few new methods oO Nobody must use them. That it the genrel course of a framework. We offer the user functionality.
This is not a good way to go about software development. Slick has specific aims as a graphics library; many of us (kev included) feel that UI, tiled maps, etc. are too "game specific" and should one day be pulled out of Slick and turned into extensions. By adding more game-specific features, you are making Slick
less focused and more cluttered. Just because Slick currently includes a lot of "unnecessary" stuff doesn't mean we should continue to pack it with useless/game-specific content. Slick's broad scope and "adding every feature that gets requested" attitude is one of its downfalls, and ultimately one of the reasons it fails from a design perspective. (Most importantly; I have not seen users ever request a pause feature aside from the one provided by GameContainer.)
Why is Pausable in the util package? Why do you have pauseRender and unpauseRender, as well as setRenderPaused? Why does Game and BasicGame not implement pausing, since they are supposed to be more or less equivalent to the game states API? What about handling all input listeners, rather than just the default input listeners? What about the functionality of GameContainer's pause -- why do we need to duplicate that?
And most importantly -- like I asked earlier -- what is the benefit for the user? How often do users need to pause the update loop of a particular game state, and let other game states continue updating? And how hard would it be for them to do it themselves, with an if-els statement? Something so game-specific would be better implemented by the user rather than the library -- for the same reason that Slick hasn't implemented entities, collisions, platformer physics, etc.
Not trying to discourage you from making changes to Slick... Everybody should contribute, and I'm glad you're helping!
But sometimes contributions are more suitable in the form of a 3rd party extension, rather than modifying Slick's core classes and adding clutter/bugs/inconsistencies/etc.
Maybe a different way to go about this, if you really feel individual state and render/update pausing is necessary, is to scrap the interface idea and add setUpdating(boolean) and setRendering(boolean) to BasicGameState. The reason BasicGameState exists is to provide simplicity for the user, so if something game-specific were to go anywhere, it would be there. This naming would also remove conflict with AppGameContainer's pausing.
Login
Register
FAQ
Search
I still find it very useful but I actually don't want to argue about it.