|You don't have any items in your cart|
|Subtotal (ex. VAT)|
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:
Now that I was starting to get some structure and progression into the game, I felt that it was time to elaborate a bit more on the enemy AI and the differences between enemy types. Currently I had about 8 or 9 test sprites in the game for different looking enemies, but they all used the same basic FSM (see here for how I went about that) and all had the same hitpoints and abilities. This lack of any differentiation contributed to the feeling of sameness that I'd been having while play testing, and so it was important to improve upon what I had, especially now that I was beginning to add structure to my game.
Improving things, however, meant planning, and so far I hadn't really given too much thought to the enemies in the game. Sure I knew I wanted them to be dumb and I'd written a basic FSM for them to use, but all games, no matter what style or genre, need the player to feel like they are progressing, that they're getting somewhere, otherwise boredom sets in. This also ties in with another thing I wanted to implement in the game, namely a bestiary. People like to collect things too, which is why games like Pokemon and Diablo are so good! They arouse our hoarding instinct and make us want to play just one more game to see what new creature or loot we can find. In my game I wanted to try to capture that feeling as best I could within the style of gameplay - and one of the ways I came up with was to make a bestiary that starts off empty and slowly fills up with every new enemy encounter. Before that though, I had to make the enemies different enough to warrant a page in that book, which meant looking carefully at what I had and starting to think ahead...
With my mid-game crisis more or less over (see last week!), it was time to get my hands dirty again and start digging into the core code to expand on the gameplay for Skein. All I had at that moment were a bunch of test rooms which ran the same scripts and generated pretty much the same gameplay experience, just with slightly different graphics, so my first real task would be to organise this into something a bit more progressive and distinct...
I knew right from the start that I didn't want my game to be a simple succession of rooms all based on the same maze algorithm, so I had to decide what kind of rooms I wanted and then modify my BSP code to create them. The structure I came up with was something like this:
After adding in lights to the game, I set about expanding and developing a bit more the enemies and magic/inventory for the player. I also set about creating a proper HUD to show the controls on devices as well as the player information - health, gold, the current level and whether they had a key or not (I had also made it so that certain levels are "lockable" and require a key to leave, hence the space for a key in the HUD). I'll talk a bit more about these additions in next weeks blog, but this week I want to talk about a small crisis I had while working on these things...
I had what I felt was a pretty solid start to my game. Lighting worked well, enemies did what I wanted, the basics for the magic system were in place and my dungeon generation was awesome... so why wasn't I happy?
At the time I started to make my action RPG game, the GameMaker: Marketplace had more or less just opened and it was getting some pretty interesting stuff thrown up. In particluar there were a few lighting engines on there that use shaders to create dynamic lights and shadows from instances or tiles, and these interested me greatly as good 2D lighting in GameMaker has long been a "holy grail". So, I dug into my PayPal account and downloaded two of the best looking ones to test with my project...
To tell the truth, I was pretty excited by this, as I remember old GM users like GearGOD or Adventus creating super complex lighting engines in GM6 which looked absolutely gorgeous but were complex as hell:
At the end of last weeks diary, I was just getting to grips with the player movement and some basic controls, and I'd decided to use a grid-based approach to collisions. With that working it was time to move on and start breathing some life into the enemies in the game, which meant that I was going to have to start working on one of may favourite parts of developing a game... the AI.
When I start to code the AI for a new game, I generally don't ever rely on previously made frameworks or scripts from other games. I've found that each game requires a unique solution and that if you want it to work correctly and do what you require, then the only way to go is to build it from scratch. That doesn't mean to say I don't look over the rather large number AI demos and scripts I have lying around as they provide a valuable resource for ideas and techniques as well as fast-prototyping, but I generally start from zero and just take snippets that are appropriate (you can find a load of my old GM7/8 AI stuff - as well as other tech demos - from here if you're interested, but beware! It's all quite old and probably a mess...)
With the basic design of my HUD finished, and the core dungeon generation code working well, it was time to move on and get stuck into the core gameplay mechanics. This would have to start with the player, as the decisions I took about how the player moves and how it reacts to the environment would later shape other gameplay features like the enemy AI, or item placing, etc... So, it was finally time to add a player object to the game world!
Moving from Stable 1.4.1474 to 1.4.1567
We will shortly be updating the version we have set to the Stable channel to be the recent 1.4.1567 release currently live on the Beta channel, and there have been an awful lot of changes and improvements made in the last run of Betas since 1.4.1474, so I thought I’d take you through some of the key things to be aware of as you upgrade to the new release.