Unnamed Game Engine is known as Roole

[kyonides]

Unnamed Game Engine

better known as Roole

Introduction

Well, you know me, I love dealing with a couple of game engines. This is especially true if talking about Linux or Cross Platform applications.
There are a few based on Ruby either completely or partially. Yeah, among those are:

• HiddenChest
  
• MKXP
  
• Gosu
  
• Ruby SDL2
  
• Rubygame (old)
  
• Dragon Ruby (commercial)
  

I don't mind working on HiddenChest at all but sometimes you need a break and working on another project is enticing indeed. That's how I ended up customizing Gosu once again. I've forgotten how many times I've tried to make it look more complete or look as some production ready engine.  Yeah, I even tried contributing to the Gosu codebase by suggesting a couple of basic changes to no avail.

It's just that I kind of hate this "one man team" sort of projects. I hope that makes some sense to you, guys.

Extremely Basic Features

By the way, you can check THIS POST to get an idea on what I've been trying to do so far.

Since What's up, RMers? doesn't look like the best place ever to keep track of this project, I preferred to open this thread and see if one day I get my very own Game Engine Icon here.

So far I managed to implement a binary executable that encapsulates the old Gosu Rubygem. A Rubygem is a Pure Ruby or CRuby Extension that any Ruby script may require at any time. Since that didn't seem to work on my previous attempts of making it, I had to resort to the ugly and burdensome work of embedded its code in a CRuby executable. It's C because it depends on C programming language to contain some Ruby calls a la C. The truth is that you can also include as many C++ code as needed.

Actually I included some C++ namespace to let my executable intercommunicate between the Ruby and C++ portions of its codebase.
Don't worry! It's quite short indeed.

Code on HasteBin

What exactly are you able to do with this Unnamed Engine?

Good question! I guess it's pretty much the same you can do with any Ruby Gosu project.

• Load any kind of Pictures stores in JPG or PNG or TGA formats AFAIK
  
• Load and play any MP3 or OGG soundtrack
  
• Display text on screen using Normal, Bold, Italic and Underline styles
  
• No predefined Game Window Size!
  
• Execute custom Ruby scripts
  

Because it features a TrueType binding as the library in charge of all string characters to be rendered on screen, it's not possible to offer you some Outline style by default.

There's almost nothing by default except that I introduced a few curious changes.

Scripting Section

Main Loop

While you're used to some basic Main loop like the following:

RMXP and RMVX

Code:

while $scene != nil
  $scene.main
end

RMVX ACE

Code:

rgss_main { SceneManager.run }

GOSU

Code:

Gosu::Window.new.show

In this Unnamed Engine's case it'd be...

Code:

Scene.init

Actually it's a hidden script by default. You just need to define the contents of Scene.init method like this

Code:

module Scene
 def self.init
   #your code
   self.scene = NewScene.new
 end
end

Exiting the Main Loop

In XP and VX you'd exit the game by assigning no value to $scene like this:

Code:

$scene = nil

In Ace it's...

Code:

SceneManager.exit

In Gosu it'd be...

Code:

some_variable_representing_window.close

In my Unnamed Engine it's...

Code:

Scene.close

Which in turn would make the scene be equal to nil.

So what do you think about it so far?

Well, any suggestion or constructive criticism is welcome!  

[kyonides]

Gosu::Image's vs Sprite's

Any RPG Maker user gotta know by know what the Sprite class is. This basic class might also appear under a similar name on other game engines. As far as you know its a Hidden Class for a quite obvious reason: Ruby doesn't include any visuals by default. That makes you depend on third party libraries or your very own custom library. That also means they might be written in a different programming language like C or C++ or perhaps even C#.

In Gosu and my library directly based on it, we get the Gosu::Image class that's a mix between your typical Bitmap and Sprite classes.
Yeap, it handles both components at the same time. You'd might think it's a Sprite class, but it does get some access to its ImageData class data that might be considered its very own Bitmap object.

What happens if I depend on the default Gosu::Image class?

Well, it's not like anything should happen BUT you gotta remember there are 2 or 3 special steps you gotta add to your list of pending script calls once you've created your images alias sprites.

• There's a draw step!
  This means you gotta add your image to the list of drawables manually. Impossible in RM series!
  
• Your image needs you to pass some coordinates and optionally some x and y scale factors, a color and something dubbed the alpha mode.
  
• Disposal of images is automatic. So you don't really need to do it yourself, Ruby or C++ should handle that for you.
  

Now that you're aware of this curious fact about the engine, I'm in need of asking you this:

Which option do you prefer?

To pass any of those Drawing Arguments?

Or handle it a la RM where they're predefined?

If you choose the latter, you gotta know you'd still need to add a line of code telling the scene's draw method to actually draw it on screen... but you wouldn't need to pass any parameters.

[kyonides]

The Sprite Ruby Class Has Been Born!

Well, guys, I came back to tell you that my ideas on how to make pictures in the Gosu/Nameless Engine work more like RM has been successful!

Now you've got two options:

• Use the default Gosu::Image class as a sprite class
  ...and pass tons of methods in its scene's draw method like the following example: @sprite.draw(x, y, z, scale_x, scale_y, color, alpha_mode)
  
• Use the brand new Sprite Ruby class as a common sprite class
  ...and only paste a minimal call like @sprite.draw in the draw method.
  Of course, you'd have to predefine them in the initialize class or change them in the update method.
  

Sidenotes:

You know there is a slight advantage on using the Gosu::Image class, you can draw copies of it by pasting another line with different arguments.
The Sprite class would only allow you to draw a single instance of it, either as a picture or backdrop.
Both of them let you get some XP styled character spritesheet tiled!
What do I mean with this? Well, you can grab a whole image and let the engine divide it in n frames.
Then you'd only need to draw them like this: @images[@frame].draw

That way you'd get your very own animated hero sprite walking down the street on screen!