|You don't have any items in your cart|
|Subtotal (ex. VAT)|
We all know that GameMaker: Studio permits just about anyone to make games and then port them to multiple platforms and that thanks to tools like this there has been a boom in indie gaming. Small studios and hobbyists are now able to get their games out to the world in a way that was unthinkable just a few years ago, and there are more opportunities than ever to make a bit of money from your projects.
However, to a new developer or someone just breaking into publishing for the first time, making money from your work can seem a bit of a daunting task, and it can be difficult to know where to start. In this article we are going to briefly explore some of the options available to you and hopefully give you a starting point for the monetisation of your work.
While I admit that making games for a living with GameMaker: Studio is a fun and interesting way to spend your time, there is unfortunately a large amount of paperwork and legal stuff that has to be done too otherwise you'll face problems later on down the line - like not getting paid! This doesn't get talked about much, so, in this article I'm just going to touch on some of the things that you really should have done if you want to be a "proper" dev and not get into trouble when you finally poke your head out from behind the monitor.
Note that as a UK citizen this advice is written from a UK perspective, but I'll try to keep things as general as possible and I'm pretty sure that you'll have to do the same stuff no matter what country you live in... although some things may be easier/harder depending on your location!
In a previous Dev Diary, I briefly touched on the tools I use when making games and as a part of that article I listed the tools I use for sound design, I didn't really go into too much depth about the process, however... but while doing some new effects for my game Skein, I realised that sound design is one of the only subjects that this dev diary hasn't really talked about properly, and I feel that my neglect to touch on this subject reflects an overall attitude amongst small devs - sound design isn't as important as the gameplay or the visuals.
I can illustrate this simply by going through my own general progress on a game: it begins with a tech demo, then some graphics, then core gameplay elements, then more graphics, then testing and only then, when I'm pretty far into the project, do I start to add sounds, almost as an afterthought. I'm sure I can't be the only dev that works this way, but THIS IS WRONG! I know this is wrong and with Skein I've been trying to treat sounds with the same importance as I do the graphics and the core gameplay. I doubt that games like Journey or Limbo had the audio slapped in at the last minute...
In the coming Early Access update support for the following 3rd party API's will be getting removed from the GameMaker: Studio runner and added to the Marketplace as extensions, across all platforms that support them (Android and iOS currently):
Note too that with this change the way that you add ads and analytics to your game has also been updated. Here we explain what this means for you and how to use the new system.
It's well known that marketing is important. In fact, if you were to ask any successful dev how they split their time up, they'll probably say 50% making the game and 50% marketing. Which may seem like a lot of time spent on something that you think is unimportant - the attitude that a good game will sell itself is still prevalent amongst many people - but in the super-saturated stores that everyone uses, your game will disappear if it's not marketed correctly.
So, what does marketing your game consist of? When do you start to tout it about and generate interest? Where and how can you market it? Those are questions that I'll try to answer in this article, although it should be noted that I'm going to talk in general terms about things as marketing is almost as much an art-form as making games, and what works for one will not always work for another...
Many people who use GameMaker: Studio to make mobile games start out with the Android module due to it's accessibility and ease of use. Basically if it works on Windows, it'll work on Android (with a minimum of tweaking), and when it comes to publishing, that too is also made extremely easy, since you just have to create an APK and upload it to Google Play.
However, the Google Play market is an extremely saturated one, has little or no controls over quality, and it doesn't cover a very large number of countries. Do you want people in China to play your game? Well, they can't because Google Play doesn't sell there, which means you are missing out on literally millions of potential users! The good news is that the Google Play market is not the only one available to you and in this article I'm going to list some of the other markets that are available to you for your Android games, as well as some of the pros and cons of going elsewhere.
This weeks Friday tech blog is the third (and final) tech blog written by our guest writer Ryan Loader, and follows on from the one we posted last week.
The trouble with persisting data, is the finality of it. If something goes wrong when you save data to disk then it’s messed up, restarting the game doesn’t fix anything. If it isn’t human readable then it can’t really be fixed by hand either. Worst case you store it somewhere that isn’t cleaned on an uninstall and you’ve managed to completely break that game for that device.
This weeks Friday tech blog is the second tech blog written by our guest writer Ryan Loader, and follows on from the one we posted last week.
Last time I discussed how I had set-up a rest service for GameMaker that could make http_requests and then ‘callback’ using scripts with either a success or failure. Requests also had ‘meta data’ bundled with them that carried information about the request, including where to callback. This time I want to delve more into the specifics of how I handle Flox responses in GameMaker and give you some tips on how to avoid some platform specific quirks.
In this article, we're going to take you through the entire process of creating a game and deploying to Windows 10 devices using GameMaker: Studio. Windows 10 introduces the new Universal Windows Platform (UWP), which is designed to be playable across a wide range of devices from tablets, to phones, to desktop PC's and even the Xbox One. So, to help you get the most from this new GameMaker: Studio target platform we are going to explain how to set up the development environment, and then talk through the making and deploying a very simple game.
Before we can get down to the really fun stuff of actually making a game, we need to get the grunt work done and set up our development PC correctly, as well as sign up for the UWP alpha from YoYo Games. For that you will need to have fulfilled all of the following steps (in the order given):
This weeks tech blog is the first in what we hope will be a long list of tech blogs written by guest writers from the GameMaker community. To get the ball rolling we have invited Ryan Loader to talk about how he created the fantastic Flox extension for GameMaker...
I've been working (for a while now!) on an extension for GameMaker: Studio called Flox GM. It simply allows GameMaker developers to use the Flox back-end, which includes things like analytics, leaderboards, cloud data, logging, player authentication, all in a really easy to understand API. This is an important library for GameMaker! I've seen a few leaderboard extensions, one good analytics extension, a couple for saving key-values in the cloud, but none that can offer all that and player auth and handle loads of traffic!
Recently, YoYoGames added the YoYo Compiler to the Linux (Ubuntu) target platform, and so we are going to take this opportunity to explain how to set up this module correctly so that you can easily port your games to Linux. Before going any further however, it is worth noting that due to the many different possible configurations of a Linux system, the GameMaker:Studio Linux module is only aimed at Ubuntu OS version 14.04 LTS to ensure that it works correctly for everyone. As such this tutorial will focus on that operating system.
Obviously you first have to install Ubuntu on a machine (this can be a regular desktop installation, a dual boot instalation, or a Virtual Machine, which we explain in this article from the helpdesk). Once yo have your version of Ubuntu installed, you will need to make sure that your current install has the OpenSSH server installed - this is a powerful collection of tools for the transfer of data between networked computers, which GameMaker:Studio will use to communicate with the remote computer - and you will also need to confirm that you have the correct set of OpenAL libraries, as without them your games will not run correctly.
I'd love to be able to continue these tech blogs indefinitely, but unfortunately I can't... I've been writing them retro-actively until now, but with this weeks blog we are up to date with the development of my game Skein, and so further development diaries will be published as and when I have something new worth sharing. However, before I bow out for a few weeks, I'll leave you with a discussion of how I've been dealing with saving the game information and what different solutions I've come up with for things like player statistics, high scores, and level/checkpoint saves.
What is it about statistics that players love? Is it being able to track their progress throughout the life of the game? Is the fact they can brag that they've captured more flags than anyone else on their team? Is it related to hoarding and that part of our brain that loves to just keep adding to our stock of "things" - material or otherwise? I honestly don't know, but it seems that everybody loves statistics - myself included - and a lot of games track them, so I had to have them in my game.
When I play a game, I am always on the lookout for little details that make me laugh or that immerse me further the game world or that simply make me think "that was cool!". These details, in general, have nothing to do with the gameplay, add nothing to the main plot, nor do they change anything in the game world, but they are still often the high points of a session for me. What I'm talking about are easter eggs and eye candy - two things that add far more to a game than you might suspect at first glance.
What do I mean when I talk about "eye candy"? Well, I'm sure you immediately think of things like explosions and special effects, but to me the phrase "eye candy" is much, much more.
As game developers, it's very easy for us to take things like the user interface and HUD (heads-up-display) design for granted. I mean, how hard can it be to make a couple of buttons and a healthbar? As it turns out it's not very hard at all... With the GUI layer and a couple of objects you can quickly throw together menu elements and HUD elements in GameMaker: Studio, but the difficulty comes in making them user friendly, unobtrusive and consistent. The UI (user Interface) for Skein went through various iterations before I finally felt that I got this right, and in this weeks article we'll talk about the reasons behind the final designs and the problems with the ones I had initially.
My first UI for Skein consisted of some rather garish gold filigree-style menus and HUD elements. I chose this style for one simple reason - I'd made a logo that used it and the logo integrated the play/start button, meaning that it was also a part of the UI. Naturally this made me feel that I should use the same style for all my UI elements.
At the end of last weeks diary, I said that I was going to talk about how I designed and coded the UI for Skein, but I'm afraid to say I lied... I'll leave that for next week, as this week I think it would be a good idea to take a moment to talk about the tools that I use to make my games, since I constantly see questions from people asking what is the “best” art program, or where can they source sound effects, etc...
The other day someone commented to me that they were a “bit disappointed” that I'd used licensed sprites in my game instead of making them myself. Now, this actually made me feel a little bad as in all honesty the sprites I've licensed only make up about 20% of the final graphic package, and even then they form a base that I have then adapted and animated and built on. Why do I mention this? Well, it's because licensing art or using free resources is a valid direction to take when you are deving a game, especially when you either don't have the skill or the time or the budget to make them yourself or get an artist. In my case, it's a bit of all three! Here are the main complaints in my opinion about using free/licenced art: