Need help on Library Design

[MuteClown]

Ok, i've been deterred to work on my little game library, i think the reason is i don't have a good way to create a OOP interface for the library. I'm especially stuck on how to handle the input class, i want to make sure that i keep it as open as i can, so i can change the backend while keeping the front end the same.

I was hoping i could get some code example of how other people do it, even if its in C++, also any articles on ways to create good design for a library? i think design is my biggest trouble, i keep making it too complex.

[Stoney]

I was hoping i could get some code example of how other people do it, even if its in C++, also any articles on ways to create good design for a library?
In my library I have a global Input class which contains classes of the different input type (mouse, keyboard, gamepad). Those input types have functions like IsKeyDown(LongInt): Boolean or IsKeyUp(LongInt): Boolean

So the full call would be: if Input.Keyboard.IsKeyDown(Key.Space) then DoSomething;

Key is also a global class which returns a constant integer value of a key. So theoretically if I would switch from SDL to GLFW all I need to is to copy the global key values from GLFW and it should work just fine.

You can see the full source code here: https://github.com/freezedev/elysion/blob/master/lib/ElysionInput.pas

My design is quite similar to how input is handled in Unity3D: http://unity3d.com/support/documentation/ScriptReference/Input.html


i think design is my biggest trouble, i keep making it too complex.
Try to one have class for each purpose, so if you have a Sprite class just keep everything necessary for this sprite class. If you would need a moving sprite, don't add attributes to the sprite class, but create a derivate of the sprite class called MovingSprite for example.
Try not to repeat yourself. If you have two classes with the same or similar purpose try to merge them. If you need to keep those classes separate, create a common interface for them or inherit one class from the other.
Merge or delete classes you usually don't use. Chances are if you refrain from using classes you designed for yourself, something is "wrong" with them. (Either too complex or missing something.)
Try to keep method names as simple as possible without having to think what this method does. For example with Sprite.Draw it is safe to assume that this sprite will be drawn onto the screen by calling this method, Sprite.Rotate(Single) will most likely rotate the sprite by the given parameter.

[MuteClown]

Thanks, nice library you got there!

You see what i did was start to implement a class which did all the backend stuff(SDL atm), then had three observers(KeyBoard,Mouse,Joystick(didn't do much on the joystick left till last)) which would be notified when an event happened. But i ended up spending too much time designing the behavior of the relationship between the back end and front end.. result is a mess.
It was abd because i was using techniques that wasn't confident with, so was second guessing what i was doing the whole time.

Can't stress enough how helpful it is to see how someone else does the same thing, even more so, that im not an experienced developer =]

[chronozphere]

Don't want to be rude but the topic title "help" doesn't encourage me to offer any.

Please use a more descriptive topic title next time. :)

(Sorry, I just feel that this should be addressed)