|You don't have any items in your cart|
|Subtotal (ex. VAT)|
In this article we will go through the steps required to submit your Windows 10 UWP game to the Microsoft Store. Before going through this, you will need to have set up your WIndows 10 development environment correctly for use with GameMaker: Studio, as explained in this article here:
With that done and a game finished and ready, we can start preparing it and then submit it to the store.
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. This new platform is supported by GameMaker: Studio (currently in the Early Access build only), and to help you get the most from this new target platform we are going to explain how to set up the development environment and deploy a game.
NOTE: While the UWP target does permit the porting to multiple targets, GameMaker: Studio UWP in Early Access currently only targets desktop with the other platforms being supported in the future.
YoYo Games is introducing a new target module in the latest Early Access version of GameMaker: Studio for the Amazon Fire range of devices - Fire TV, Fire TV Stick and Fire tablets. These devices run Fire OS, which is itself based on Android, and can run apps and games just like any other Android device. From a developement point of view, the Fire devices make for an excellent platform for your games, since one Fire OS app can be deployed to all devices and with Amazon behind it you can be assured of a huge potential market.
In today's tech blog we are going to explain how to get your hands on this module and what you'll need to get it set up and connected to your Fire device, and hopefully you'll be porting your games to this exciting new platform in no time! Note that although this new target produces an Android APK, this file will not work on any device that is not part of the Amazon Fire range.
In part 1 of this game design foundations series I talked about some general design tips and attitudes that will help you to create games that people want to play. However, there is a bit more to it than just having a killer idea and writing up a design document! In this article I am going to explore some gameplay mechanics and give tips related to them that will help raise the design values of almost any game you could make. Note that these tips are, again, very general and as such can be applied to almost any type of game in some way...
You may not realise it, but the most successful games are those that have a great atmosphere. For some games, it's the music that brings most of the atmospheric edge. For others, it's the graphics. For still others, it's a sense of progression within the gameplay. If you look at a game like Dark Souls, it has a fantastic atmosphere that is dark gritty and beautiful and it really helps draw you back to the game. Without the details and “feel” it would be a game that quickly bored as you die again and again... and again and again and again! In fact, I would go as far as to say that Dark Souls only selling point is its atmosphere! Another perfect example of a game which has succeeded because of its atmosphere (and that was made with GameMaker) is the game Undertale. Neither the graphics nor the sound design nor the gameplay stand out in this game - which is currently the highest scoring game ever on Metacritic - and taken on their own they could even be a turn off to many people since the art in particular is almost "programmer art". However those aspects of the game combine together with an outstanding and humorous story and together create an ambience, an atmosphere, which sucks you in and makes it a marvellous and unique experience to play.
In this first article of a two part series, I'm going to go through and explain what I think are the main foundations for good game design, but taken from a more holistic and general point of view rather than focusing on specific details related to genre and style. So, these tips are directed at guiding you in the game design process rather than actually giving you hard and fast design rules to follow.
In the articles we'll discuss some general design tips that have been proven to work, no matter what type of game you are creating, starting this week with discussing motivation, hook and documentation, and then next week we'll move on to discuss game atmosphere, variety and few other things. Hopefully they'll help you to think about your game in different ways and let you give it a unique set of design values to set it apart from all the others.
I was complaining the other day on Twitter that I didn't have much to show for all the work that I'd been putting into Skein these last few weeks and someone linked me to this article here on the Rampant Games blog. The tl;dr version is that some devs were all excited about drawing a single black triangle on the screen, and someone else thought that they were exaggerating as drawing a black triangle is nothing particularly special. However, the black triangle symbolised months of behind the scenes programming to get it to render correctly and opened the door for further more complex advances...
This is appropriate for the situation I've been in with Skein this last few weeks, as I've been working very hard on the engine itself, optimising and adding in new systems, but to the outside spectator I've nothing really spectacular to show for it! That doesn't mean I haven't been busy, however, as you'll see...
One of the hardest things for an independent developer to find when starting out is music. It's not difficult finding royalty free or Creative Commons licensed music for your games, but it is difficult finding music that has a decent quality and that "fits" your game. You can spend literally days searching through the public domain sites and never find anything that captures your attention and hope that you eventually find your diamond in the rough, or you can just give up and go hire someone (or just go visit Incompetech.com like everyone else).
However, before you decide, what if I told you there was another option? It’s called procedural generation, and you'd be surprised just how good music made this way can sound!
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.