Fuzeboy is now being made in GameMaker Studio 2

Yet another official announcement: Fuzeboy is now being rewritten in GameMaker Studio 2.

After getting familiar with the new UI and the new GML functionalities, I’ve realized it made little to no sense at all to keep using GM:S 1.x. I’m already rewriting Fuzeboy from scratch so I might just use the new, improved IDE. I need a faster workflow and GameMaker Studio 2 definitely improves the workflow.

Coding with the new intellisense code-completion and making levels in the new room editor is just fantastic.

Since I’m working on a 1366×768 13″ notebook, I set the DPI scaling of GMS2 to 80% (76 DPI) so it doesn’t feel claustrophobic working in it.

I already feel better when coding Fuzeboy in GMS 2.

Fuzeboy – A new beginning

Me and Darftey have been developing Fuzeboy for five months now. We met in late Novemeber 2016, experimented a bit with prototypes and then started serious development in January 2017.

It was small… it was cute… it was mobile…

It all started as a small mobile game (you can see the touch controls in the image above) but soon it was clear Fuzeboy was no small game anymore; the mobile world isn’t fit for him. He’s bigger than that.

This is the tower with the locked doors… very mysterious…

So here we are today officially announcing to the world that Fuzeboy will be developed uniquely for Steam (PC, Linux and Mac). A mobile adventure of Fuzeboy is still being planned but we’re not actively working on it (and it will be a different game).

In fact I am rebooting the development of Fuzeboy. From scratch. Still, I’ll be using GameMaker 1.x but this time the whole project will be PC oriented. We’re letting go of the many mobile limitations to expand on the gameplay mechanics.

While I’m starting to rewrite the engine from scratch, Darftey is already at work to come up with exciting new elements and ideas for the game. It’s going to take time and effort. It’s going to be exciting. It’s going to be big.

Room Start Event Execution Order for Persistent Objects in GameMaker: Studio

It’s a well known fact that GameMaker: Studio 1.4 follows this order of events:

  1. Create Event of each instance
  2. Instance Creation Code of each instance
  3. Game Start Event (this will only be run in the very first room of the game)
  4. Room Creation Code
  5. Room Start Event of all instances

You can set the order in which specific instances are created within the room editor itself. But what about the Room Start event of persistent instances? Such instances are carried over from room to room. What if we have a room with another, newly created instance, that also executes a Room Start event?

room_01                 room_02
obj_persistent -------->obj_persistent
                        obj_new

I made a few tests and it seems that GameMaker, for this specific case, uses Depth. That is: the smaller/lower the depth value of the instance, the sooner it will execute its Room Start event.

I’m talking about instances and not objects because if we change the instance’s depth via code, GameMaker will use that value, not the one defined inside the object editor.

Now jump into your code and have dozens of objects with different conflicting Room Start events (I’m kidding, please don’t)

How I Scale Fuzeboy Resolution on Mobile and Desktop Devices

Fuzeboy's still in development so it's only natural that sometimes I take time to rewrite stuff, to fix things, to experiment and so on. We try, we break, we fix, we extend, we change. We evolve.
A scene from Fuzeboy. There's only one way to view pixel art... and that is with pixel perfect scaling.
One issue we faced from the start, is the game resolution. What we knew was that we wanted pixel perfect scaling no matter what. Remember that this game will be both for mobile and desktop.Here's my solution as of today.

The Ideal Game Resolution

Fuzeboy cares about its height. The width depends on the monitor aspect ratio (within reasonable limits). The ideal height of Fuzeboy is around 240px. Keep this in mind.

Pixel Perfect, Full Screen, No Black Bars (didn't work)

This approach was the first I used. Since not every device has a vertical resolution that's a multiple of 240px, I allowed different devices to show more or less "game world".First I get the display vertical resolution. Then I cycle from 200px to 300px to see which one fits perfectly the device vertical resolution. If I don't find a perfect fit, I give up and just use 240px.

Fuzeboy on Devices, method 1

DeviceResolution (vertical)Game Vertical ResolutionMultiplier
Amazon Kindle Fire 7"1024 x 600 (600)3002
Samsung S3 Mini800 x 480 (480)2402
Asus MeMO Pad 71280 x 800 (800)2004
This doesn't work. It's pixel perfect most of the times, there are no black bars... but you might end up seeing an unplayable 200px vertical resolution on a 7" tablet.
We don't want this to happen... do we?
Let's have a look at an Amazon Kindle Fire 7"
This is better. Or... is it?
There's a huge 100px difference in height from the Asus to the Kindle. The Fire users would have been able to see 50% more game world than the Asus players. That's wrong. Especially since Asus has a higher screen resolution than the Amazon Fire.

Pixel Perfect, Black Bars (in use as of today)

First of all I decided to restrict the range of vertical resolution of the game. Now it's from 230px to 260px. Still a 30px difference but it's bearable.So I still ask for the device vertical resolution, of course. Then I check which number, from 230 to 260, fits best. By that I mean it either fits perfectly or has the lowest remainder.This is the initialization script. It goes inside the create event of the very first object created in the game.I also leave the view settings in the room editor as they are. Disabled. I enable them via code.
///scr_init_display()

// Let's disable the drawing of the App Surface
application_surface_draw_enable(false);

dw = display_get_width()        // Device Display Width
dh = display_get_height()       // Device display height
ar = dw / dh                    // Aspect Ratio

min_h   = 230                   // Minimum Height
max_h   = 260                   // Maximum Height
height  = min_h                 // We start from the minimum
fract   = frac(dh / height)     // This is the fractional part
mult    = floor(dh / height)    // This is integer multiplier

// We cycle from min_h to max_h
for (var h = min_h; h < max_h + 1; h++)
{   
    var new_fract   = frac(dh / h)
    var new_mult    = floor(dh / h)
    
    // If we have a lower remainder, we store
    // the multiplier and the height we're testing
    if new_fract < fract
    {
        fract   = new_fract
        height  = h
        mult    = new_mult
    }
}

// This will show you the found resolution in the debug console
show_debug_message("Found resolution: " + string(height))

// Width gets decided with a simple division
width = floor(dw / mult)

// And made divisible by 2
if width mod 2 != 0
    width--

/***************************************************
  SET THE VIEW AND THE PORT FOR ALL ROOMS
 ***************************************************/
var i   = true;
var rm  = room_next(room);
while (i)
{
    room_set_view(rm, 0, true, 0, 0, width, height, 0, 0, width * mult, height * mult, 0, 0, -1, -1, -1)
    room_set_view_enabled(rm, true)
    if (rm == room_last)
        i = false
    else
        rm = room_next(rm)
}

// Resize the application surface
surface_resize(application_surface, width, height);

// Let the GUI layer be as big as the device screen
display_set_gui_size(dw, dh)

gw = display_get_gui_width()    // GUI width variable
gh = display_get_gui_height()   // GUI height variable

// We'll need these to figure out the touch commands coordinates
wscale = width / (dw / mult)
hscale = height / (dh / mult)

// Let's figure out the App Surface offset (we want it centered)
Xoffset = floor((dw - (width * mult)) / 2);     // Horizontal Offset
Yoffset = floor((dh - (height * mult)) / 2);    // Vertical Offset

/// Go Fullscreen on desktop
if os_type == os_windows
{
    window_set_fullscreen(true)
}
Then we need to draw the App Surface. So in the game controller object, I have the following code in a Post Draw event.
///Draw the App Surface with correct offset

// This line prevents strange artifacts in Fuzeboy.
draw_enable_alphablend(false);

// The real drawing.
draw_surface_ext(application_surface, Xoffset, Yoffset, mult, mult, 0, c_white, 1);
If I run the game on the Amazon tablet, the result is this:
The game now has a height of 260px

Fuzeboy on Devices, method 2

DeviceResolution (vertical)Game Vertical ResolutionMultiplierBlack bars top/bottom
Amazon Kindle Fire 7"1024 x 600 (600)260220px
Samsung S3 Mini800 x 480 (480)24020
Asus MeMO Pad 71280 x 800 (800)260310px
Now the game scales much better.

Let's fix the Touch Controls.

Those touch buttons share the obj_touch parent so I can do this in the controller Begin Step event.
// Add these in the display init script
xoffsetmult = (Xoffset / mult)
yoffsetmult = (Yoffset / mult)
// Touch Controls
for (var dev = 0; dev < 4; dev++)
{
    touch_dev       = dev
    var _xpos = (device_mouse_x_to_gui(dev) / mult) + view_xview - xoffsetmult
    var _ypos = (device_mouse_y_to_gui(dev) / mult) + view_yview - yoffsetmult
    
    var this_button = instance_position(_xpos, _ypos, obj_touch);
    
    if this_button != noone
    {
        if device_mouse_check_button(dev, mb_left)
        { 
            with(this_button)
            {
                touch_press_action()
            }
        }
        
        
        if device_mouse_check_button_pressed(dev, mb_left)
        {
            with(this_button)
            {
                touch_pressed_action()
            }
        }

        
        if device_mouse_check_button_released(dev, mb_left)
        {
            with(this_button)
            {
                touch_released_action()
            }
        }
    }
}

The Future

As of today, I still experiment with the resolution of the game. I haven't found a perfect way to scale low res pixel graphic fullscreen with no black bars and no distortion... simply because such a way doesn't exist.Things change frequently around here, so we'll see if I'm going to stick with this method or not. Feel free to let me know your ideas on this matter.

Optimizing Collision Code

As I said in a previous post about my platformer engine (the one I’m working on for Fuzeboy), I’m using Zack Bell‘s code as a base. Recently I started to look into ways to optimize such code without losing the functionality (slopes are a big feature of that simple collision/movement code).

Looks like I was able to gain some speed here…

And as someone once told me “sharing is how better games are made”… so here it is my “improved” version.

Continue reading Optimizing Collision Code

Basic Platformer Mechanics in GameMaker: Studio

I’m fond of platformers. It’s only natural that I spent the past year studying and refining platformer engines for GameMaker: Studio. Here’s what I actually use for my engine.

Fuzeboy early gameplay

Continue reading Basic Platformer Mechanics in GameMaker: Studio

Fuzeboy devlog – Fair death system

Don’t you hate it when, during a death animation/sequence, your character accidentally touches a powerup or a health pack… and then it dies anyway?!

Normal Death vs Last Chance (non)Death ™

This is what we wanted to avoid in Fuzeboy: unfairness. If you catch a heart during the final knockback, you will have another shot at it.

Fuzeboy full steam ahead!

In November 2016 I met Denis (@darftey). He’s a pixel artist. One of the best I’ve ever met, actually. We teamed up to develop Fuzeboy.

Full steam ahead! ouch!

It shouldn’t come as a surprise that since then, the development of KREN has been put on hold indefinitely.

We’re pushing hard on this mobile platformer game.

Unnecessary tricks…

There is still no official release date but we’re making progress 24/7 on every front. From music and sound to gameplay mechanics, from platform specific issues to minor graphic details.

Lots of care is being put into making this game as fun as possible. We care about details. We care about story and gameplay. We are in love with this game and we’re making sure everything goes the way we envision.

Stay tuned for more Fuzeboy news in the near future.

Devlog #1 – GameMaker: Studio new Project

This entry marks the first entry of a new Devlog Series.

I’m currently working on a couple of GameMaker projects and I thought it might be useful to document my development process. I’ve been inspired to do so by reading the Loadworld Devlog PT. 2 by @ZackBellGames

Continue reading Devlog #1 – GameMaker: Studio new Project

Metroidvania Metroid-like World Design

The Metroidvania Metroid-like game genre, from a development perspective, is quite complex to master. World and level design, for examples, are core elements of the game along with player abilities and game physics. You cannot plan one without the other. This is because player abilities, powerups and game physics, are the very elements that allow the Player to  progress and advance (or backtrack) throughout the levels. This also means that levels must be designed around the player’s abilities, powerups and game physics (among other things).

Super Metroid Map
You might get one step closer in learning how to create such a layout.

Continue reading Metroidvania Metroid-like World Design