Building Street Fighter II in Ruby [video](nikolay.rocks)
nikolay.rocks
Building Street Fighter II in Ruby [video]
http://nikolay.rocks/2015-06-16-building-streetfighter
16 comments
That is how C and Pascal got to displace Assembly, and C++ eventually displaced C in game development.
By having devs that instead of following "it cannot be done", persisted and eventually were able to release something in those languages that others wanted to play.
Having watched this cycle a few times, I always look forward to see higher level programming languages used in broader contexts.
However for game development, maybe Crystal instead of Ruby would still be a better option, in terms of raw performance and distribution.
By having devs that instead of following "it cannot be done", persisted and eventually were able to release something in those languages that others wanted to play.
Having watched this cycle a few times, I always look forward to see higher level programming languages used in broader contexts.
However for game development, maybe Crystal instead of Ruby would still be a better option, in terms of raw performance and distribution.
considering rubymotion, i think ruby is still a feasible option though
RubyMotion support for Ruby/Gosu is on the way too (it does not work automatically): https://www.libgosu.org/cgi-bin/mwf/topic_show.pl?tid=1194
RubyMotion just badly needs a .NET/IronRuby port, or anything else that'll work well on Windows... :(
RubyMotion just badly needs a .NET/IronRuby port, or anything else that'll work well on Windows... :(
Yes, assuming something similar ever becomes available outside the Apple world. AFAIK they only focus on those systems.
But yeah, I imagine compiling Ruby is not much dissimilar than compiling Dylan.
But yeah, I imagine compiling Ruby is not much dissimilar than compiling Dylan.
I don't know Dylan, but compiling Ruby is a nightmare. As such it's also a fun challenge (working on "as static as possible" Ruby compiler).
Actually, compiling Ruby is not that bad, horrible grammar (from the perspective of having to write a parser - as a user o the language I like it) notwithstanding.
Compiling Ruby into efficient code is a nightmare.
The problem is largely that there's a total lack of delineation of application read/load time and runtime, coupled with the ease of being able to mutate the object model.
E.g. in theory on return from any method statement the entire world might have been transformed. 2 + 2 = 4 one moment, only for 2 + 2 to have side effects and return 5 the next...
The "quick and dirty" way of compiling Ruby is to accept that you'll need expensive dynamic message call invocations all over the place.
Optimizing beyond that is a lot of work to ensure you can handle it when people start playing silly games. The jRuby Truffle backend is probably the best bet at the moment (Chris Seaton who did the initial work on that is on HN). If I ever get that far with mine, I'll be stealing lots of ideas fro there...
Actually, compiling Ruby is not that bad, horrible grammar (from the perspective of having to write a parser - as a user o the language I like it) notwithstanding.
Compiling Ruby into efficient code is a nightmare.
The problem is largely that there's a total lack of delineation of application read/load time and runtime, coupled with the ease of being able to mutate the object model.
E.g. in theory on return from any method statement the entire world might have been transformed. 2 + 2 = 4 one moment, only for 2 + 2 to have side effects and return 5 the next...
The "quick and dirty" way of compiling Ruby is to accept that you'll need expensive dynamic message call invocations all over the place.
Optimizing beyond that is a lot of work to ensure you can handle it when people start playing silly games. The jRuby Truffle backend is probably the best bet at the moment (Chris Seaton who did the initial work on that is on HN). If I ever get that far with mine, I'll be stealing lots of ideas fro there...
Dylan is a Lisp with Algol like syntax targeted for systems programming with a REPL, AOT compiler and IDE like environment.
So what you are telling about Ruby is also an issue in Dylan, given its Lisp heritage and flexibility.
So what you are telling about Ruby is also an issue in Dylan, given its Lisp heritage and flexibility.
looks awesome, thanks for the link!
Very cool!
It's actually stunningly common to use high-level languages with managed run-times in games these days. Most indie and small-studio games we play today were built using one engine or another. The graphics pipeline in Unity, Gamemaker, etc might be heavily optimized but the majority of the game is written in an interpreted or managed language run-time like Lua or C#.
You can write 3D simulations with a decent frame-rate in Python. You just need a lot of help with the "hot" spots be calling out to C and C++ libraries for support. I've been experimenting with writing little 3D engines in Cython + Python + SDL2. It does end up taking a load more memory and performance can drop drastically if you're not consciously thinking about your data-flow. The trick I've found is to avoid most of the features that make Python great in those critical sections... plain old data structures, weak references, pack your data together and transform it once (ie: avoid copies).
However it's great for prototyping and toying with new ideas. Python is vastly more forgiving when you don't know up-front how you're going to structure your data flows.
But in the end I just end up going back to C99 at some point anyway.
Writing games in Ruby shouldn't be weird. It's cool.
It's actually stunningly common to use high-level languages with managed run-times in games these days. Most indie and small-studio games we play today were built using one engine or another. The graphics pipeline in Unity, Gamemaker, etc might be heavily optimized but the majority of the game is written in an interpreted or managed language run-time like Lua or C#.
You can write 3D simulations with a decent frame-rate in Python. You just need a lot of help with the "hot" spots be calling out to C and C++ libraries for support. I've been experimenting with writing little 3D engines in Cython + Python + SDL2. It does end up taking a load more memory and performance can drop drastically if you're not consciously thinking about your data-flow. The trick I've found is to avoid most of the features that make Python great in those critical sections... plain old data structures, weak references, pack your data together and transform it once (ie: avoid copies).
However it's great for prototyping and toying with new ideas. Python is vastly more forgiving when you don't know up-front how you're going to structure your data flows.
But in the end I just end up going back to C99 at some point anyway.
Writing games in Ruby shouldn't be weird. It's cool.
Very cool Nikolay. I also dig the git-wayback machine briefly showcased.
https://github.com/MadRabbit/git-wayback-machine
https://github.com/MadRabbit/git-wayback-machine
thanks for the find, tried it found a bug and fixed it too :)
hey Senthil, thanks for the fix! just rolled out a new version to rubygems :)
Fantastic tutorial, I really like his presentation style of progressively walking through the commits. Great work.
Cool stuff! Coding attack sequences, combos and reading commands like quarter-circles is a fun exercise, too. You have to balance between precision and ease of use.
Interesting strategies arise when this glitches:
http://wiki.shoryuken.com/E._Honda_(ST)#Stored_Oicho (Street fighter 2)
Interesting strategies arise when this glitches:
http://wiki.shoryuken.com/E._Honda_(ST)#Stored_Oicho (Street fighter 2)
Very cool and readable.
For something even cooler (but less readable) here is SF alpha, in js: https://github.com/gamedev8/js-sfa (very faithful to the SF alpha game mechanics)
For something even cooler (but less readable) here is SF alpha, in js: https://github.com/gamedev8/js-sfa (very faithful to the SF alpha game mechanics)
I used to be a die hard fan of this game in my early teenage days and now Ruby is my most favorite. It would be a lot of fun building this game and connecting to some of my old memories. Thanks Nikolay.
hey, no problem. send me a pull request! ;)
Awesome! Please finish this up I have always been so intrigued on game design, especially fighting games.
good watch
i liked the explanation of reducing draw() to 1 sprite per call and the little formula that went along with it; ive never seen that. make a video about just tricks used in the industry!
i liked the explanation of reducing draw() to 1 sprite per call and the little formula that went along with it; ive never seen that. make a video about just tricks used in the industry!
Very cool! Well done Nikolay. Cheers!
Very cool, thanks for sharing! :)
this is very awesome, big fan of the presentation technique
floridaguy01(2)
the link is dead
Works here (tm).
Releated links which may work for you if the article link is still dead:
https://youtu.be/_whiCEywodw https://github.com/MadRabbit/ruby-fighter
Releated links which may work for you if the article link is still dead:
https://youtu.be/_whiCEywodw https://github.com/MadRabbit/ruby-fighter
There is another great video similar to this of Tom Dalling coding a flappy bird clone using Gosu:
https://www.youtube.com/watch?v=QtIlyU2Br3o