# Improving the flexibility of my library/what can be improved? [closed]

How can I make my library more flexible towards programmers? Here is my library. It's a basic library that provides a simple interface to organise your game (with scenes, and engine/game connection). The only problem that I dislike about it, is the fact that you cannot create a custom 'game loop', you must let the GameLoop class deal with that for you. You can only instead, call to update/draw of the loop if you cannot use a while loop and manually clog the main thread (e.g. Ogre3d and it's call backs to update your game).

I'm also curious on what I can improve upon this library. Does my tutorial make sense? Is my code clean?

https://github.com/miguelishawt/pine

• I am not sure you got notified, but your question was closed a while ago because we require code to be included in the question itself. We don't like being dependent on third-party sites as links tend to go away sooner or later. For more information see this meta question. The site is a lot more active now than it was half a year ago, so it is quite likely that some one can review your code - if you include it in your question. Apr 3 '14 at 18:35

A few observations/thoughts from a quick look at the code and accompanying description. Feel free to explain/correct as appropriate:

• For starters, the Game class seems to delegate everything to the GameLoop class, why? It seems more logical that GameLoop would drive the Game which would make use of GameEngine do to input/output and GameStateStack (or stacks) to keep track of game-related states. As it stands, I need to think in terms of frame changes/deltas in more than one section of the code.

• When would I want to use the GameLoop as-is as opposed to using isRunning()/update() or deriving from GameLoop? Why not place the call to initialize() in the constructor?

• Why does GameStateStackListener need to know about the GameStateStack? Does it consume events or produce events? Or both? How do you avoid infinite recursion if both?

• Why only one type of GameStateStack per listener? We might want to keep track and be informed of several state types (for instance, a character would want to be notified of changes in gravity and wind).

I think you should make and publish a simple game using this library to illustrate the purpose of each class

• When would I want to use the GameLoop as-is as opposed to using isRunning()/update() or deriving from GameLoop? As I mentioned, in case you don't have total control of the loop (libraries such as Ogre3D have call backs for updating/rendering your game). However, this is a bit iffy with the code in my GameLoop. Why does GameStateStackListener need to know about the GameStateStack? Does it consume events or produce events? Or both? How do you avoid infinite recursion if both? GameStateStackListener listens to events from a GameStateStack. Aug 19 '13 at 12:32
• Why only one type of GameStateStack per listener? We might want to keep track and be informed of several state types (for instance, a character would want to be notified of changes in gravity and wind). A state in the game is a main menu, the actual game itself, the paused "state". I don't think it makes sense to have multiple GameStateStack's per listener, plus that would be much more complex to implement. Aug 19 '13 at 12:33
• For starters, the Game class seems to delegate everything to the GameLoop class, why? It seems more logical that GameLoop would drive the Game which would make use of GameEngine do to input/output and GameStateStack (or stacks) to keep track of game-related states. Good point, I didn't think about that. I'm not quite sure, I just chose composition over inheritance. Aug 19 '13 at 12:34
• I see. The intention behind each class/template is a bit unclear. I stand by my wish to see a simple game implemented using this library. Even a game consisting of a single box moving in a world where gravity and wind change randomly would be enough IMO. Aug 19 '13 at 12:38