Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics

DragonRuby Game Toolkit

An intuitive 2D game engine. Fast, cross-platform, tiny, hot loaded. · By DragonRuby

Posts feature requests here!

A topic by DragonRuby created Jul 24, 2019 Views: 1,385 Replies: 21
Viewing posts 1 to 10
Developer (16 edits) (+1)

Post your feature requests here. Upvote ones that you would like to see happen sooner rather than later.

"big" things currently in development:

  • Arbitrary collision detection.
  • YAML/JSON support.
  • HTTP GET/POST support.
  • Regex and BigDecimal support.
  • Ability to create iOS apps (without the need for a pricey Mac, OH SNAP).
  • Ruby keyword arguments support. (Ruby 2.x support)
  • Mouse held attribute.
  • "Bug replication mode".
  • Fix bug with sound looping.
  • Named arguments/hashes to generate primitives (as opposed to just positional array values 
  • Sample app that shows faux 3D using line primitives.
  • XML support.

Done list:

  • Keyboard top level properties are functions that return `key_held.KEY || key_down.KEY`.
  • Ability to press § to bring up the console.
  • Reasonable defaults for dragonruby-publish.
  • Training video/intermediate Ruby crash course.
  • DragonRuby sandbox/html based editor.
  • More sample apps (so many sample apps).

Flesh out the DragonConsole a bit more to get it closer to IRB.
I'm dependent on return values and line editing, I'd really appreciate getting the full overt and implied feedback from every command and the ability to edit a line rather than backspace through it.
I was going to make this separate, but we need some sort of hyperlinked help. An ri-like command in the console would be great, but at least some formatted docs with an overview of the API pieces so I'm not studying the samples to (poorly) infer functionality. It took me about 6 hours to grok the 3 x,y parameters in a sprite (I was approaching it as absolute value stretching) and I'm still not convinced I have the parameters sanely labelled.  

(I'm super stoked about you adding Hashes, that will resolve a lot of my derpiness)


The "Advanced Sprites" sample app has a helper method in there that names all the parameters. Patch that in for now (named params is on a high todo, I promise).


Reference source code for the console. Maybe see if it sparks some ideas?

Yes, that's great! Source is always a welcome way to view intent of design for me! I'll do a deep dive this evening.


The key takeaway here is GTK's developer support stuff is built with GTK.

And from a philosophical standpoint: no matter how good the HUD becomes, you will eventually out grow it over the lifetime of a non-trivial game. "Batteries include" tool chains are really great getting started, but it doesn't show the dev that it's just as "easy" to extend the tool chain and tune it such that it "grows" with the application being built.

I'd encourage you to make your own HUD that's customized/optimized for the work you are trying to do (I definitely looks like you  have a grasp of advanced Ruby concepts and I think you'll make some really amazing things). 

I have a Pie in the Sky wish too, and that's for a synthesizer built into the SDK. I have no illusions that that's an easy request, and in fact, I'm starting to work on resolving the issue to help simplify Sonic Pi and other live-code concepts in Ruby (and Crystal). I'll talk to y'all about it as my progress matures.

But I'd give anything for a GDK with a synthesis engine baked in so that I can create a generative soundtrack based on user input.


Believe it or not, I do want to add the capability to create "chip tunes" on the fly :-)

I'm working on my Ruby "201" right now specifically to fork Sonic Pi into a (literally) modular system with a (hypothetical) JIT/AOT compiled synthesis description language written in Crystal (an up and coming Ruby-like language for LLVM). I love Sam Aaron to death as he's essentially my first Ruby mentor, but I can tell his goals for the project as an educational tool are very different from my own as a glitch/breakcore/chiptune/electro-jazz performer.
It's an ambitious project but I hope to have the pieces together for Ruby to sequence a compiled synth with minimal outside dependencies within a year in order to build both the DSL for the synth and a library that will send build directives to Crystal/LLVM from Ruby and then magically connect to the resulting optimized binary in the background. I have a feeling I'll have to do the former myself, but I think when I can show a proof of concept about a live coding a compiled language, live coders and web developers who hate building between updates will see the value. I noted that Matz unveiled an MJIT in Ruby 2.6 and what he's doing here is basically the same idea with a pure Ruby twist and automatic decisions about what to compile.

Long story short... OMG that would be awesome and if there's any way I can help to enable that within the Ruby ecosystem, I certainly will. By the same token, if you have a lib out there in a Ruby-like syntax that generates a waveform with only minimal c dependencies, I'd be grateful to know about it as that would save me a lot of fundamental work and let me focus on the implementation language.


Ping @amirrajan on, he’ll get you some insider details on the synth stuff.

  • Ability to write shaders.
  • Ability to render only part of the sprite to enable sprite sheets.

Rendering part of a sprite can already be done. Take a look at the advanced sprites sample app. 

(1 edit) (+2)

Shader support would be nice,  set shader before draw command like LOVE2D is a good way.

Or make some filter like Brightness / Tint, I normally use this for sprite effect ( flashing / special status).

Developer (2 edits) (+2)

Shaders are on the feature list definitely. 

We currently support tint/brightness on Sprites. Here are all the options

args.outputs.sprites << {
  x: 100, y: 100,
  w: 100, h: 100,
  path: "sprites/player.png",
  angle: 0,
  a, 255
  r: 255, #  red saturation
  g: 255, # geen saturation
  b: 255, # blue saturation
  tile_x:  0,
  tile_y:  0,
  tile_w: -1,
  tile_h: -1,
  flip_vertically: false,
  flip_horizontally: false,
  angle_anchor_x: 0.5,
  angle_anchor_y: 1.0

As far as I know, saturation works like this:
out.r = in.r * r
out.g = in.g * g
out.b = in.b * b
out.a = in.a * a

So the output color is limit to input color, but some time we need over expose effect like:
out.r = in.r + r
out.g = in.g + g
out.b = in.b + b
out.a = in.a

or just tint to single color:
out.r = tint.r
out.g = tint.g
out.b = tint.b
out.a = in.a



I don't know if this has been asked before elsewhere or if it is in the pipes already or if there is a way to access already that I don't know of, but I would love to have the matrix class ( ) available. I know DragonRuby is a ( fantastic ) 2D framework, but for many pseudo-3D effects, matrices are necessary.

I rolled out my own matrix class written in full Ruby but it is way to slow and doesn't scale well. I am sure there is room for optimisation in that Ruby code, but probably nothing that would beat a pure, even naive, C implementation.


(1 edit)

Hi,  Just purchased and jumping into GTK now! Very cool framework.

One thing I would really like is a bit more flexibility and options when it comes to primative drawing (solids, lines, borers). For instance, Id really like the ability set a "thickness" on borders and lines. Also it would be helpful to maybe have a couple more types like circle, triangle, etc. Maybe even the ability use a solid type as a clipping mask. And... rotating solids, etc. :)




The primitives are nice for prototyping, but you definitely want to move to sprites as soon as you can. Bezier curves are on the list right now (but again, it’s best to just move to sprites/pngs after you’ve reached a certain point in complexity).

(3 edits) (+1)

Tilemap rendering and camera support without having to write your own (unless you need fancy stuff like split screen). Basically, a function that would offset all drawing operations (unless you set a bool to ignore the camera when passing an array to e.g. handle the HUD) by certain x/y.

Also, unless it's already there, a top-left coordinate system. Many new devs may come from engines/framework that use it such as various "fantasy consoles" such as PICO8 or TIC80. Bottom-left or center coordinate system may confuse them a lot.

//edit: Also, could we get SVG sprites so they won't pixelate or blur no matter how much we zoom in?

//edit: Another one: A ready to go IDE, possibly Eclipse-based would be nice so you don't have to use several different tools to get what you need. Also, it would allow for stuff like auto completion (a.k.a. intellisense) to be possible (no more typos, yay!)

Shaders would be amazing. I'm loving how easy DR is to work in but I'm worried I'll hit a limit with only being able to use sprites.

Might be a bit niche; but does this already have a way to link a midi controller to it? I've been thinking of making a game using one and I can't find much documentation about it

I think you would have to use a C extension to achieve that.