Recent community posts
like all the fundamentals to create a completed game, or a full game code-along that isn’t pong or breakout
Take a look at the sample apps prefixed with
./samples/99_genre_*. There are definitely sample apps that are non-trivial.
Things like figuring out top down 8 way movement.
The third directory of sample apps does exactly this. Located at
./samples/03_rendering_sprites/03_animation_states_advanced. There’s also a topdown RPG
99_genre_* directory that has more advanced implementations. The specific method is
args.inputs.directional_vector that returns a normalized value depending on what the D-Pad/left analog reports back.
setting up long quests with dialogue and branching conditionals
There are a couple of sample apps under the
./samples/99_genre_rpg directory that cover branching narratives (one of them is called Return of Serenity which has fairly complex branches).
happily reading a tutorial book for the engine made
If it’s the book Building Games with DragonRuby, we have a channel on our Discord Server where you can report bugs and give feedback. The Discord Server in general is a fantastic place to get help (and probably the best place to get help as of right now, we’re still a relatively young engine and working on getting more content out there).
C Extensions are useful for doing OS specific integration. The game you’re describing doesn’t seem to need that kind of customization.
These sample apps give a deeper dive into what you can do with C Extensions: https://github.com/DragonRuby/dragonruby-game-toolkit-contrib/tree/master/samples/12_c_extensions
We should be able to. Lemme ask Ryan and see if that can be added (we currently support Apple M1s so I’m assuming it won’t be a big lift). If you come to our Discord server, we can troubleshoot there
Sorry, no discount for the conversion. It’s heavily discounted as is.
Just a heads up: once HD/All Screen capabilities are added, we’ll be increasing the price (this will happen in the next couple of months). Those with an existing pro license will be grandfathered in of course.
We do have a coding challenge taking place in our Discord. Those who participate are eligible to win a Pro license.
If your goal is 3D, then yes, it’s probably best to use another engine.
With regards to 2D games and the respective codebase size: A Dark Room for the Nintendo Switch is made with DragonRuby. The codebase is around 20,000 lines and has ~8 hours of gameplay. 20k lines might not seem like a lot, but implementing the game in C#, C++, or Objective C would have yielded a codebase close to 60k lines easily (Ruby is a very expressive language that lets you do a lot with very little code).
We considered incorporating one, but at the end of the day it just added complexity to the apis. We’ve never had great experiences with built-in physics engines. And for 2D games, we found that the geometry apis we provide to determine collision were good enough.
I understand that you think it should be a standard/default feature. I really do get that. But we didn’t want to incorporate something half-assed just to check a checkbox on a feature list.
To prove my point.
Take any of the engines you’ve evaluated and try to get a sprite to run up a diagonal ramp. It should be a piece of cake with a built in physics engine. Right?
Another thing to try. Have a platform that moves up and down. And try to get your player sprite to stay in sync with the platform’s movement, until they jump. Again, this should be trivial to do.
Try this structure:
################ app/main.rb require 'app/init.rb' require 'app/tick.rb' ################ app/init.rb Color = [100,100,100] module Init def fun puts "sup" end end ################ app/tick.rb class Game include Init end $game = Game.new puts Color def tick puts Color $game.fun end