brettcodes

Author here. I built a single Fresh 1 app 18 months ago but moved on due to lack of HMR. So I decided to give Fresh 2 a serious try after the beta announcement in September.

Since then I've: migrated my personal site from ~10 years of Jekyll, built a story authoring platform, a URL shortener, and a service provisioning app.

The HMR works, minimal config is real, and using Deno's built-in tooling (fmt, lint, check, test) instead of fighting with build configs has been refreshing.

But: ecosystem is young, docs are thin on advanced topics, and the dev server sometimes runs into crashes (I submitted a PR to fix it but it hasn't landed yet).

I've been deploying to the new Deno Deploy, which my thoughts on are a bit more complicated. Lots of pros and lots of cons. Last week was particularly rocky in terms of stability.

I use Next.js + Node.js + Tailwind at my day job, as well as maintain a legacy Rails app. So I've got a pretty got direct comparison to ergonomics and productivity. It's very very nice to not have to deal with things like Biome or Eslint + Prettier. I'm quite interested in exploring what Fresh 2 + Deno could look like for some apps at work, as Fresh 2 seems stable enough to use beyond just hobby projects.

Overall though, if you want a fast and simple dev experience for content-heavy sites or small-to-medium web apps, Fresh 2 is mature enough to ship with and genuinely enjoyable to work with. I am curious to see how it feels for larger apps too as I keep building with it.

Happy to answer questions about the migration process or building with Fresh 2 in general.

The DragonRuby Zine free digital magazine (with a handmade print edition available too) on making games with Ruby! It's got interviews, tutorials, essays, and more. The zine is a way to celebrate the DragonRuby community and what people are making.

In case you're unfamiliar, DragonRuby is a Ruby runtime that makes cross-platform game development really fast and simple. It's got hot reloading of the game code and cross-platform deploys from any operating system. It makes use of SDL and mruby.

I've been making games in it for a few months and having a blast, so I just want to make resources and share that with other people. Thanks for checking it out!

+1 on the community being kind and welcoming. That to me is a major factor. I've learned so much from the community, and it extends beyond just making game dev. The community organizes jams, monthly game clubs, and supports one another.

I think it may be the opposite with regards to Unity and being time constrained, as there's a lot more to learn with Unity when making games rather than something like DragonRuby Game Toolkit. For a hobby that you have only a little bit of time to dedicate to, I think 2D games in an engine with a simple API would be quite a bit easier. But that's just me!

I can understand where you're coming from, but I disagree with the sentiment of it basically being just a wrapper around SDL and naive.

DragonRuby Game Toolkit's API is simple, and that's a good thing! It provides the foundations needed for building any kind of 2D game without introducing dozens of classes, an inheritance tree, or complex data models. With just a few primitive data types and some methods, everything one needs it there. Combine that with the sample code and the community, and there's not a type of 2D game out there that you can't get going with in DRGTK within a couple of hours.

DRGTK does make it easy to render sprites and text and handle input on top of SDL, which is valuable in and of itself. But it's not just direct bindings where you have to look at and understand how SDL works. I've never once had to look at the SDL docs to understand DragonRuby GTK's API. What the engine then gives you is: cross-platform builds with a single command, its simple API, ability to write games in a fantastic language, live reload of your game while developing without needing to recompile, the ability to use the toolchain of your liking, and more.

I'm personally not interested in using C++ to make games, and I think if someone is, they probably wouldn't want to use DragonRuby GTK anyway. But choosing between JS, Lua, or Ruby, I'd choose Ruby every single time. It's a more enjoyable language to use. That to me is a big factor in why I like DRGTK—the toolchain. After spending 10+ years making 2D games as a hobby by experimenting with XNA/MonoGame, Unity, HaxeFlixel, Love2D (Lua), Phaser.js, Gosu (Ruby), C++, and AS3, I really think DragonRuby has a unique combination of offerings that has me so excited about it and wanting to see it succeed.

Thanks for the kind words! I appreciate where you're coming from.

My perspective on the license and price is that it's a small team of less than 5 people who work on DragonRuby Game Toolkit. To spend $32 for a lifetime basic license is totally worth it to me for everything that comes with it. The work that's gone into the cross-platform support, designing the API, gluing together mruby and SDL, and more without a doubt is an incredibly compelling offering. I want to see DRGTK sustain itself for the long-term, and I think the team getting paid for helps make that happen.

I've thought about what it'd be like if the basic license was always free... The book is free, so it's a little awkward to then have a reader need to pay to use the software it's about. Sure, maybe more people would use it, but for an engine still in its early days (~3 years isn't that long compared to those that have been around for 10+ years), I think having a slight barrier to entry may benefit the project so it's not flooded by needing to support the flood of people that'd come from an always free version while it grows, stabilizes, and establishes itself.

I wrote this free book on how to make games with Ruby using the DragonRuby Game Toolkit. As I've been learning the engine, I've felt really inspired by how quickly I can prototype my ideas and release them for all the major platforms. DragonRuby GTK is a really interesting use of mruby and SDL. To see Ruby be used for anything other than Rails is always exciting. I thought maybe this book would nudge others interested in Ruby game dev to take the plunge. Would love any feedback! Thanks.