Rouge Rogue Rabbit Puncher

RRRP is a rogue-like where you explore 10 levels of killer rabbits.  It's fairly simple, you punch rabbits.  Hope you enjoy it.

It was made during TOJam10 in April this year, but I wanted to add music and sound to the game, but never got around to it until now.

You can download it from the rpgmaker.net site: http://rpgmaker.net/games/8176/

I'm always pleasantly surprised by Beaker. Another marvelous game.

I'll have to try this later and also see if it'll run in minisphere.  The premise (punching rabbits) sounds fun at least. 

Woo, another Beaker game!

...I remember that goat.

Hm, lack of mp3 support in minisphere strikes again.  I'll have to convert the mp3s to test it properly, but it's going to have to wait until I use my desktop PC again, the insane resolution is too high for my laptop (1600x900, laptop is only 1366x768).  In the meantime I'll try this in Sphere 1.5.

I ended up just walking past the mid-boss, but the ending is great.

Super cool to see a new beaker game in 2015.

I ended up just walking past the mid-boss, but the ending is great.

Super cool to see a new beaker game in 2015.

Walking pass bosses is an underrated option in games.

I was actually hoping to release another game in 2015, but it'll probably be next year instead.  Much like it was for RRRP, soundtracks can take a long time.

Speaking of new games though, have you been able to work on new stuff?

Speaking of new games though, have you been able to work on new stuff?

Most my energy for the last several years has been going into one game. I hope it gets released next year. I really hope.

I've done some weird side projects in the meantime though:

Dracula Resurrecting Dating Sim & LowFi First Person Horror Thingy
Majora's Mask Style NPC Schedule RPG
Text Based Exploration Game
Card Based Dungeon Crawler

Mostly a bunch of OHR games since I could snag artists during contests (big game is a custom engine using SFML for the curious. Also part of why it's taking so long). Didn't manage to get any side stuff out this year, though.

Mostly a bunch of OHR games since I could snag artists during contests (big game is a custom engine using SFML for the curious. Also part of why it's taking so long). Didn't manage to get any side stuff out this year, though.

Awesome! I've been toying with the idea of using SFML on many projects. I even created the Sphere SFML engine as a proof of concept. I've been working on a few projects too, but I would write like one line of code every few months. I really need to get back into the habit again...

How did I miss so many SDHawk games on RMN!?

Custom engines are the way to go! I'm still sticking with SDL2. But either way, as time goes on I really find it to be more and more fun to make things from scratch that way.

That's what's so awesome to me about minisphere - I get to use Sphere and code games in JS (which is a blast), while still being able to say it's my own "custom" engine since much of its development was guided by my needs for Spectacles.

Really though, this is what sets Sphere apart from other generic engines like, e.g. Game Maker - All the low-level stuff that is tedious to program from scratch is already there for the taking--why reinvent the wheel?--while you get to write all the high-level game logic yourself (the actually fun part of game development).  I mean, yeah, RPG Maker and Game Maker do have their custom scripting (the new one is even JS), but from what I've seen, scripts are second-class citizens at best in those engines.  Sphere uses scripting end-to-end, which is awesome and makes it feel like a proper development environment instead of a toy.

I guess using middleware like SFML and SDL serves the same purpose, but I've taken a liking to using Sphere as I can skip the endless compile/link cycles that make testing tedious.  Plus it's automatically cross-platform to whatever I can get the engine to compile on, which is very nice.

I've been using the C# .NET bindings for SFML, so I'm not sure what sdhawk is using, but making a game with Visual Studio was the awesome part. I mean debugging in an editor environment before minisphere was cool? That was neat! But also natively using SFML is still loads faster and can do many lower level things than Sphere could do.

(My SFML engine is still far faster than minisphere and my pet project now almost natively uses my SphereSFML because of the speed + JS). It's the space game I've been wanting to make for many years now in case you're curious.

I think minisphere has the potential to be fast (and Duktape gets faster all the time), but it would require writing for the Galileo API.  The legacy primitives and blitting will probably always be slow due to the way Allegro handles them (with individual GL calls and minimal batching).  I'm actually amazed at how SSFML manages to be so fast at this, your sprite batcher admittedly is awesome (if a bit glitchy, as proven when I managed to get Specs to run there).

I will say single-step debugging is invaluable, which is why I took so many pains to get it working in minisphere despite Duktape's tedious debug API/protocol.  I even ended up contributing a bunch of enhancements back as a result, for example callstack walking (viewing variables of calling functions) and error-throw notifications.

Yeah. For the most part working with SFML bindings in a higher level language (or monogame and a lot of other such libraries) probably isn't that much different than working with sphere (or its sibling engines like ika/verge). The main difference is the lack of a built-in map engine, which probably isn't that much of a hardship to do yourself if you've been working with sphere for long enough (for map editing using tiled or something is generally fine).

I could see myself switching to SDL2 at some point just for peace of mind of having directx support for windows and a few other things. Especially since I pretty much ended up making my own wrapper around SFML anyway (for the sake of simplicity when interacting with the python scripting side that handles most of the game logic). But for just starting out with C++, SFML was far more comforting to have a familiar style of API.

Picking a tool at the time was kind of weird. XNA had just lost official support, so I was hesitant to continue to use C# (also I was kind of hesitant about portability back then since mono was youngish). The ika community had pretty much dried up entirely for maintaining it, and I wasn't very fond of pygame and other python game stuff. Unity was years away from proper 2d support and I kind of hated how heavy handed it is about the engine being in full control of certain things. So C++ with python scripting it was.

It has been one heck of a learning experience, but being able to plop things into a lower level language whenever python couldn't cut it performance wise has been handy (though I'm sure my naive C++ is way slower than other options). The biggest bummer has actually been how many smaller game tools (game ui, particle effect editors, etc) have moved to operating solely within specific engines or libraries (mostly Unity, but also other things).

I can certainly agree SDL2 is not the best if you are starting out writing C++. I'm amazed I managed to learn any real C++ when I started out right into Google V8 and SDL2 at the same time.

I generally dislike Unity for a few reasons. It has language interfaces other than C#, but they are mostly pretty poor, and it doesn't really look like they were designed by people who actually use those languages, making them very cumbersome to use. I also find that its divide between what belongs in the engine and what belongs in the game a bit odd. And I don't like how a Unity game is so easy to spot!