Correct. That is something that I wanted to implement several times and gazillions of versions ago. Maybe it will happen when I get to the Linux gamepad support, but maybe it won't even be coming this year.
After I have finished Arthur's Adventures,im going to make a 2D RPG Game in the style of Breath of Fire 1 and 2 ,Final Fantasy 6
After I have finished the 2D RPG im going to make a 2D Beatem up game in the style of Final Fight and Street of Rage/Bare Knuckle
Hopefully Gosu will have dual gamepad support by the time I start making the 2D Beatem(First few days of 2011)
I plan to have Arthur's Adventures finished around Mid December 2009(December 24th at the lastest) as it has to be finished for the "The Shinobi Chef Gosu Game/App Competition 2009" then I will take a week break from programming games and then start the 2D RPG in the first few days of 2010 ;)
at this stage I plan to have the 2D RPG finished by Mid December 2010 and submit it into the "The Shinobi Chef Gosu Game/App Competition 2010",hopefully by then Gosu will have Dual Gamepad support as I will start programming the 2D Beatem up in the first few days of 2011,if Gosu does not have dual gamepad support by December 2011 then I will have to make player one use the gamepad and player two use the keyboard or have the second player gamepad mapped to the keyboard with something like joy2key
I have lots of work ahead for myself :) though it will be a lot of fun as programming games for me is one of the most fun thing ive ever done in my life so far,game programming is a labor of love
You know what would be nice, at least in Ruby? If the Gosu::KbX & GpX & MsX constants were objects rather than fixnums (frankly, *any* class of object other than fixnum or symbol would be good. Even just bare instances of Object with no extra methods or functionality). Why? Because then I could easily monkey-patch individual keys to do things like
def Gosu::KbEnter.==(id) return (id == Gosu::KbReturn) || super end def Gosu::KbReturn.==(id) return (id == Gosu::KbEnter) || super end
There are more elegant and flexible ways to do this, but this one is shortest. Regardless, none of them are possible with fixnums. I could, as a workaround, use the numbers that gosu already returns as keys into an array or hash which had values corresponding to equivalence classes... hmm. Maybe I should just do that :-p But I still like the non-fixnum-button-objects idea. If you made an actual button class, you could have a method like 'controller' or 'device' that could be used to differentiate between a Gosu::GpUp from one controller vs. the same button on a different controller. Though you'd have to go through some (minor) trickery to get id == Gosu::KbA to work, since they'd not actually be same object. And you'd have object creation every time a key was pressed.
So, that's all getting pretty complicated, and maybe it isn't the best idea, but it's worth thinking about.
Shinobi Chef, I don't plan ahead a lot. However, games that are finished otherwise but would benefit from a given feature always motivate me to add something, mostly because I know it will immediately be tested in the real world and not immediately rot away. Announcements of products in the far future don't count though ;)
philomory, yeah, I wanted to abstract everything to either axes (0.0..1.0) and buttons (0 or 1), and also allow for or'ing of buttons to create new buttons, or to use two buttons to build an axis. Buttons are already objects in C++ (vs. ids), but I didn't port it over to Ruby because it seemed like some extra overhead that I didn't find a justification for :)