|You don't have any items in your cart|
|Subtotal (ex. VAT)|
With the addition of console support, as well as the release of the new GameMaker: Player, it's more important than ever to have gamepad support in your projects. To many users, this can seem a complicated process, but hopefully in this tech-blog we can show how simple it can really be and you'll be able to integrate gamepad support in your games in no time!
One great way of increasing the monetisation opportunities for your games and apps is to use in-app purchases (“IAPs”) within your project, which then allows players to purchase further items after their initial purchase price – it’s also a great way of enabling your game to be free on initial store purchase but then recoup some revenue later on.
In the latest updates to the Early Access version of GameMaker: Studio there have been some major additions to the audio functions:
From the EA 1.99.260 and next 1.4 Beta update onwards of GameMaker: Studio, analytics for Android and iOS are no longer provided natively and instead are now available as extensions. If you are using the built-in analytics functions currently, you will need to remove them and instead add in the new extension functions, which we will explain below.
In this last part of out three part mini-tutorial series about physics in GameMaker: Studio, we are going to explore joints, advanced physics world functions, and debug drawing. If you haven't already read through the previous parts of this series, you can find them from the following links:
This week's tech blog is a follow on from the previous one we posted about physics in GameMaker: Studio. If you haven't read through that one (you can find it here) then we recommend that you do, and that you download the attached GMZ example from that article as this week follows on from where we left off, and will continue to build on what we have already.
This week's article is in the form of a mini-tutorial, where we will make a small physics simulation and at the same time discuss some of the issues that people come up against when transitioning from the "traditional" GameMaker: Studio approach to movement and collisions to the physics approach.
Anyone that works with a given set of tools will know that once they get used to a certain way of working it's almost impossible to change. This applies in particular to those of you who get used to a set of short-cut keys to get things done within a given tool's IDE. Short-cut keys are a fantastic way to do things that may otherwise require multiple mouse clicks through endless windows, and they can greatly speed up development time. However what happens when you are used to a specific set of keys, but one of the tools you use doesn't work that way? Or the same keys do different things? At best it's annoying, and at worst it can lead to the loss of valuable data as you accidentally delete something by using the wrong key-combination!
After the previous two tech blogs about scaling for devices, there have been a few requests for an extra article on how to scale games for the HTML5 target. So, in this tech blog we are going to cover scaling for this platform, although it should be noted that before continuing we recommend that you read through the Scaling For Devices tech blogs (Part 1, and Part 2) as we will be using the techniques that have previously been explained there in more depth.
In Part 1 of this tech blog, we looked at different methods to scale the GUI layer so that it can be adapted to the different screen sizes and aspect ratios of any given device. This was a relatively simple thing to do, since the GUI layer permits resizing and doesn't require views nor surfaces to work. But what about scaling the game itself? Making your game fill the whole device display is easy, but making it fill the display and look correct (ie: no blurring or stretching) is not, so in this tech blog we will cover various different methods that you can choose from to scale the game properly.
This article is part one of a two part series in which we will explore the different ways to scale your game to fit different device screens. Scaling your game can be a headache for many users and hopefully through these articles we can help to make it a simpler task and provide you with a framework within which to get the correct results every time.
In today’s article we are going to go over the motion planning functions in GameMaker: Studio. If you are not familiar with them, they are a set of functions that use different methods to get an instance from point A to point B, and they can be configured in different ways to make this movement more complex. You can get an overview of the functions from the GameMaker manual here: Motion Planning Functions.
In this article we are going to cover some "best practices" for when you are using the GameMaker Language (GML) to code your game, and at the same time explain a little bit about the inner workings of GameMaker: Studio. Before we continue, however, it is worth noting two very important points:
The GameMaker: Studio IDE comes with a number of handy shortcuts and features that are often overlooked by both new and veteran users of the product. Some of these are purely convenient ways to do things, while others can significantly increase productivity and change the way you work, so here we give a list of the most over-looked, yet most useful methods for using GameMaker: Studio to its fullest.
The 1.4 update to GameMaker: Studio is perhaps the most important to date. Apart from greatly increasing the UI stability and adding new features, it also marks the official launch of the GameMaker: Marketplace! Most of the new features and changes being introduced have been discussed in previous tech blogs and were available in the Early Access version of GameMaker: Studio. However, since most users don't use the EA version, in this article we'll give you a brief run-down of what to expect from 1.4 and link to any relevant articles so you can find out more.