I rarely post about Windows tips and tricks but this one kind of saved my day, especially because drag and drop and middle click are vital features in the GameMaker Studio workflow.
YMMVYour mileage may vary. This is not guaranteed to work but worked for me twice (before AND after the Windows 10 Creators Update).
Three Fingers Tap as Middle Click
Let’s fix the Three Fingers Tap behavior. I want to disable Cortana and enable the middle click button.
Open the Start menu and type regedit. Open it (and give it all the authorizations it needs to make changes to your computer).
On the left panel navigate to this location Computer\HKEY_CURRENT_USER\Software\Elantech\SmartPad
In the right panel search for Tap_Three_Finger and double click it. Set its value to 2
Eventually check that the Tap_Three_Finger_Enable is set to 1.
No Delay for Drop when Dragging (drop on finger lift)
Again in Computer\HKEY_CURRENT_USER\Software\Elantech\SmartPad
Search for the Drag_Radio key.
Set its value to 2 to immediately drop on finger lift.
Done. Now the three finger tap will be a middle click and the drag and drop will be instantaneous.
As some of you might know, Fuzeboy’s project scope changed considerably during its development. There’s been an overhaul of features, specifications, goals and deadlines.
A small mobile game…
Originally thought to be a quick mobile only game, we then shifted our vision a bit to make it playable on desktops as well; now we decided to abandon the mobile world altogether to focus exclusively on the Desktop platform.
This opened up a ton of possibilities as we’re not limited to touchscreen inputs anymore. The very essence of the game changed, as we made changes to game mechanics, enriching and expanding the world of Fuzeboy.
This is the tower with the locked doors… very mysterious…
Fuzeboy’s going to be a full fledged, complete platformer game for desktops (Win, Linux, Mac) but we’re not yet ready to show anything new to the world as I’m rewriting it from scratch in GameMaker Studio 2 while Darftey is reviewing (and adapting) all of the graphics.
We’re also starting a new project. Not because we suffer from shiny object syndrome (basically a disease of distraction) but because rewriting Fuzeboy from scratch, made it possible for us to reset our mental state.
Although far from a possible Fuzeboy-induced burnout, our mental state was then set for something new; different. That not only applied to Fuzeboy, but to both of us as a game development team. We took a step back and looked at our future as team Blocksword. And we saw things…
As we reviewed and re-started Fuzeboy, we reviewed our plans, projects and priorities as well. And we saw this…
Here’s a small teaser GIF
Due to the overwhelmingly positive feedback we received, we’re now thinking about making it our primary focus. We’re also considering funding as I didn’t plan to live off of my savings for this long without publishing a commercial title.
Two projects, two options
Should we decide to crowdfund the new game, we will have to define a clear project scope and commit exclusively to that for the time it will take to ship it. In that case the development of Fuzeboy will be put on hold (let’s say we will change it’s queue priority). As of now this is the most probable scenario.
Should we decide to keep going without funding (or fail at funding), we’ll suffer from a bit of a slowdown. I will have to seek a part-time job (or something) while working on both games at our discretion (we would have zero deadlines and relatively more freedom in the way we manage and evolve our own projects).
All of this might annoy someone; especially those who were waiting for Fuzeboy anytime soon this year. Especially if they were waiting for a mobile game. We know it and we don’t like when people get annoyed because of us; we will make up for it.
In conclusion
To sum it up: we’re working on the new Fuzeboy while defining the scope of this second project and defining the resources we need to allocate to each of these projects. Just know that we could completely shift our focus toward this new RPG game very soon (we’re evaluating feedback).
When you try to import multiple images into a single sprite in GameMaker Studio 2, you could end up with unexpected results. Specifically, if the images have different sizes (width and height), the sprite size will be equal to that of the largest image, but all the other images will be imported stretched to fill the canvas (effectively ruining the sprite).
Let’s say that you have a sprite with a complex animation (i.e. variable frame rate). As you can see from the following image, each frame will play at a specific time (I use a simple Photoshop script to export the frames, I’ll write an article about it later).
This is the folder’s content, exported from Photoshop. File naming scheme is important.
Today I made my first contribution to the opengameart.org website.
(opens external link)
It’s a simple edit of Michele “Buch” Bucelli’s sci-fi interior tileset. I adapted it to be used in GameMaker Studio 2 with the 47-tiles autotile feature (I needed it for a personal project of mine).
I’ve also opened a Patreon page. You can directly support my writing and game development projects there. (I no longer have a patreon page).
Much has been written about resolution scaling in pixel art games. It usually comes down to this simplistic rule: always resize 2D games by integer values (2x, 3x, 4x, 5x, etc) so pixel art will always look correct.
I wrote that myself; to make a good looking low-res pixel art game on modern monitors, you should stick with a 384×216 resolution and scale it up 5 times to get a perfect 1920×1080 (1080p) game.
This article will guide you through the setup of a Xubuntu 16.04 LTS Virtual Machine to test, compile and run your GameMaker Studio 2 projects on Linux.
I’m choosing Xubuntu instead of Ubuntu simply because Xubuntu is less resource hungry (and my notebook is 5 years old I got a new notebook btw). The resulting package will run just fine on Ubuntu machines as well.
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.
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.
It’s a well known fact that GameMaker: Studio 1.4 follows this order of events:
Create Event of each instance
Instance Creation Code of each instance
Game Start Event (this will only be run in the very first room of the game)
Room Creation Code
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?
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)
