Category: design

GameMaker tutorial: Elegant instance_change() in your state machine

In GameMaker, a commonly used technique is to build a system made up of a several objects to represent an entity in your game, such as the player or enemy, in various states, such as idle, dead, shooting, jumping, running, climbing, and so forth. This is what is known as a Finite State Machine pattern.

When the time is right in the game, we change an instance from one state object to another by using the powerful instance_change() function. Instance_change() takes the instance and transforms it into a new type of object. Its Event behaviors will change to those defined by the new object type, but its old properties (object variables) will remain the same as before, allowing the instance to retain its variables with their current values.

The instance_change() function takes two arguments: object, the object the instance will turn into, and perform_events, a boolean which controls whether the new object’s Create event will be performed or not.

Normally, the Create event is where an object initializes its variables and initiates its default behavior. When we’re dealing with a State Machine comprised of a number of objects, this can become problematic, however. Some code in the Create Event is initialization code that we may only want to execute one time, to set up the instance when a brand new instance is created, while other code in the Create event is behavioral and we may need to execute whenever an existing instance reverts back into that state again. Thus, the perform_events argument in the instance_change() function isn’t adequate for this situation — it’s too all or nothing.

For example, let’s say I have a generic object for an enemy, oEnemy. I want some visual variety to this enemy, so I’ve created a few different sprites for it. In the Create Event, I want to randomly choose one of those sprites to be the sprite for this instance. But if the instance changes into another state object, and then reverts back, if I call the Create Event, it will randomly choose a new sprite. I don’t want this, as it ruins the illusion of continuity — I need that instance to retain its sprite. But I do need the Create Event to run, whenever it re-enters this state, because I’m using it to set the instance in motion.

So, how can I elegantly select which lines of code I want to run in the Create Event?

Conditional blocks

This is the least elegant solution, but you could use if to check whether a variable exists or has a value. For example:

if sprite_index == -1 {sprite_index = choose(sprite1, sprite2, sprite3);}

This is inelegant because it adds lots of lines of code that only need to be run one time (when a brand new instance is created) but need to be checked potentially many times (any time that instance changes back into the object state). It also only checks certain, specific things, case by case. As I continue to build the state machine, I may end up introducing more features which require initialization, which would necessitate more checks, further bloating the code. I always want to write the least amount of code needed, both for reasons of performance and maintainability.

Move one-time code to an init state object.

The more elegant solution is to recognize that initialization is its own state, and we need to separate it out from the other states in the state machine. We can create an oEnemy_init object, put our one-time initialization code into it, and then the final step in the Create Event for the init object would be to change the object into the default state.

None of the other states in the state machine should put the instance back into the init state, thereby guaranteeing that the init code only executes once. Now your code is neatly separated, your states objects in your state machine are as simple as can be.

HTML5 Game Development With GameMaker published

Today Packt Publishing announced the publication of HTML5 Game Development with GameMaker by Jason Lee Elliott. I was involved with the creation of this book as a technical reviewer, and as such I’m intimately familiar with its contents.

While the book title refers to HTML5 games specifically, most of the content is applicable to any development in GameMaker Studio, regardless of your intended build target.

Some of the highlights include:

  • Numerous examples of the “Finite State Machine” pattern implemented as a system of related Objects
  • Building a Box2D physics-based game
  • Creating a particle system
  • Facebook integration
  • Flurry Analytics integration
  • How to publish your game on the web.

If you purchase through the link below, Amazon will compensate me for the referral.

Bad Puppy: Design Analysis

So, last weekend I made Bad Puppy for Ludum Dare 25. I didn’t realize it as I was making it, but it seems that I’ve come up with a game that is really pretty fun. I’ve gotten many compliments from people who’ve tried it, and the more I’ve played it, the more it’s grown on me.

I think it’s worth analyzing the game to identify factors that contributed to it being fun.

Mood/Humor

Bad Puppy is cute. Everyone loves puppies, they are irresistible. So this makes the game inherently enjoyable — if the puppy works. I think I did a good job with making the puppy cute enough, using just a simple animation and some basic sound effects. The running and wagging animations are winners. 

One of my most frequent feedbacks has been that the “graphics could use a little polish” — I agree. But I also don’t want to lose the charm of the simple/crude 8-bit pixel art aesthetic. I think the style works for the game, but it could be enhanced by more variety. That’s why I added an enhancement to make the sweater color random. I’m also planning on doing something similar to vary the skin tone of the person, and maybe create a selection of hair styles. There will definitely be a female person too, as soon as I’m able to create her.

The graphics for the pickup bonus items are rather crude, and I’d like to improve them as well. I’ll probably try something subtle, like adding shading and shadow to them, and see whether that works.

I’ve also thought about doing something with the drab grey background color, but I’m not entirely sure what I want to do with that yet.

The barking sounds, panting, and “good boy!” are also cute. I just recorded myself barking and manipulated the sample a bit in Audacity to make it sound 8-bit. Something about the lo-fi, crude aesthetic seems to enhance the cuteness.

Gameplay

Bad Puppy is a very simple game. It is also a relatively fast game (in terms of short play times). A typical play usually doesn’t last more than a minute or two. Short play makes the game enjoyable to repeat. 

I made the game short by increasing the difficulty, and by providing no means of regaining lost meanness, or gain extra lives. This means the game must inevitably end, and a play is only as long as the player is able to make it with their skill. When you play a short game and the length of play is determined by skill alone, it tends to make you want to play again, because you just know you can do better the next time.

Controls

The controls are very simple. You run around, and bark. The controls are simple enough that they could be done with a 1-button Atari joystick. The game doesn’t need anything more than this.

Despite being simple from the user input standpoint, the motion that is governed by the controls have a little bit of polish in them. First, you don’t keep moving if you release the controls, but you also don’t stop immediately, either. Rather, if you are not pressing an up/down control, your speed in the y-axis decelerates gradually until it reaches 0; and the same for left/right and the x-axis speed. This gives the puppy a slightly “slippery” feel, makes the motion feel like a more natural curve, rather than orthoganal directions, and “de-diagonalizes” the motion so that the only way you move diagonally is if you are pressing in both the x and y axis simultaneously. It is a motion mechanic which feels natural as well as puppy-like.

Strategy

The play mechanics and strategy are something I’m proud of. I can’t say I designed this from an ingenious flash of insight, but the way it came together, it felt very natural and like things were coming together in a way that felt right, and following my instincts to do the least complicated thing that seemed necessary worked well.

With the gameplay, there are a few things that stand in tension against each other, which result in a kind of dynamic equilibrium that makes the game fun.

  1. To bark at someone, you have to be close to them. You don’t get points for barking at someone who is too far away, you have to be a certain distance away from them or nearer. This means that you can’t be just anywhere in the room, and have to move in order to be in a good position to bark for optimal points. It also means that you have to put yourself at risk, because…
  2. When a walking person gets too near to you, they start to chase you. They don’t simply walk a predetermined course, unresponsive to your position. This creates a sense of adversary, as opposed to uncaring/ambivalent people who just walk and don’t react to your presence. It makes the game more interactive.
  3. Chasers give up if you get too far away from them, and go back to horizontal walking. This gives you additional incentive to run from them. But it can also influence the player to not run too far away from them, either, if you are trying to lead/herd them. Keeping you closer to the people makes the game riskier, and keeps the player on their toes more.
  4. You are faster than the people, which is good because if you weren’t, the game would end too quickly. You need to be able to get away. Puppies running faster than people is natural and feels right, and is in that sense realistic.
  5. The room wraps. You can take advantage of this to escape at the edge of the screen, rather than get boxed in by the edges of the room. 
  6. People will wrap horizontally, but due to the way the homing AI works, someone chasing you will “lose” you if you wrap off the edge of the screen, effectively giving up chase. However “normal” walkers who are not in pursuit of you will continue to move in the direction they are heading in, and wrap. Since there’s no visual way to differentiate between these two modes, it makes the enemy AI difficult to predict, and forces the player to react rather than anticipate.
  7. People do *not* wrap vertically, and mostly do not move in a vertical direction unless they are in pursuit mode. After playing a while, a player can pick up on this and use it as a strategy to evade a group of people when they are surrounded.
  8. To bark at someone, you need to be facing them — barking does not increase your score if you are facing away from the person, even if you are close enough to bark at them. This means a strategy of always running away while barking will not work; you need to repeatedly turn around and bark toward your pursuers. Coincidentally, this is very puppy-like behavior, running away and then turning around and running back, but trying to stay out of reach.
  9. An effective strategy is to try to “herd” the people by taking advantage of their pursuit response, in order to get them to bunch up. When bunched up, there is a lot of room to run around and avoid petting. And you can bark at the entire herd, which multiplies the points you get per bark. Having an effective strategy available to the player which they can discover through play makes the game more fun, because it rewards them for playing and making the discovery, and gives them a tactic through which they can feel they have achieved mastery over the game.
  10. To effectively counter the herding strategy, and prevent people from bunching up too much, I added an AI behavior, whereby a person who has been barked at too many times (which is randomly variable) will run away. Run away mode is mostly identical to walking mode, except that the direction is always away from the player, and the trigger distances to return to normal walking mode puts them a far enough distance from the player that they will not immediately revert to pursuit mode. The result of all this is that after a short time of successful herd-barking, the tactic’s reward diminishes as people start running away, and the risk increases because the retreating people spreading out makes the room more crowded, and it becomes harder for the player to avoid petting.
  11. The original version of the game lacked bonus pickup items. I realized quickly that with the player having only one thing to do, the game was a bit too one-dimensional and did not offer enough of a replay value. Adding the bonus pickups gives the player a secondary objective of collecting the bonuses.While this is completely optional, the game really seems transformed by presenting the player with temptation and giving them something else to do. Without the bonuses, a player can focus completely on avoiding petting, and will tend to last longer. With bonuses, there’s just enough temptation to try to pick them up that they become willing to take risks which will result in them getting petted a little bit, and the attrition wears the player down over time, reducing average play time. A clever player might see through this and decide that the way to get the highest score is to ignore the bonuses and focus on defensive play, trying to score only through barking, and picking up bonuses only accidentally. This might well be a better long-term strategy, but the value of the bonus items increases dramatically over time, which puts the value of going after them at a level where it seems worthwhile if you’re trying for a high score.

A few players have suggested adding something more to the gameplay, but I’m not sure what changes might improve on this without disrupting the dynamics of the core mechanic. I’ve thought of a few things, and will be experimenting with them in time. But sometimes knowing when something is complete and when not to add more is where the real design talent is.

I think there are many opportunities to polish what I’ve built so far without touching gameplay — an online scoreboard feature would be a great way to enhance the game and get people playing for global bragging rights, for example.

I’m interested in feedback, so if you’ve played the game and have something to say, please drop me a comment below or at the LD submission page, or tweet at me.

Influential Games: Mountain King

One of the more memorable and innovative titles on consoles and home computers in the early 80’s was Mountain King by CBS Electronics. I knew it on the Atari 2600, but it existed on other platforms also, including Atari 5200, Commodore 64, Vic20, and Colecovision. It was atmospheric and spooky and mysterious and inspiring, and one of my favorite games of all time.

Mountain King (Atari 2600)

There were a number of things that made Mountain King special, and examining them in detail is worthwhile.

Non-violent, Yet Scary As Hell

There was very little death or injury in Mountain King. It had a theme of exploring, not violence. The biggest threat in the game was the clock running out. Things that would hurt or kill you in another game imposed a time penalty on you in Mountain King. Fall too far, and rather than die or take damage, you’re stunned for a length of time proportionate to the height of your fall, and slo-o-o-o-wly get back on your feet. The wait could be agonizing, making seconds seem like hours. On certain difficulty levels, there are time limits for accomplishing certain objectives, and in any case your remaining time rolls over and is added to bonus time which dwindles with each re-claiming of the crown, so you are always under significant time pressure and there’s a feeling of speedrunning when you’re playing for a high score.

Mountain King spider

There is one deadly threat in the game, a giant man-eating spider that inhabits the lowest levels of the mountain. You can’t fight it, only run from it, but it is not normally necessary to descend to this level, so it is mainly in the game to provide a sense of fear of the depths. If you accidentally fell to the spider level, the scuttling sound of the approaching spider would fill you with panic and dread, and make you scramble toward safety with new urgency.

Audio Innovator

Most home videogames of the day did not feature music at all, or if they did, it was little beyond an introduction jingle that lasted a few bars, or a repetitive loop that quickly became annoying. Mountain King not only used music, but integrated it into the game in a novel way. A special theme plays when it is time to find the Flame Spirit, and the music gets louder as you come nearer to its location. A mostly-invisible entity which blinks sporadically, can can only be seen in full in the beam of your flashlight, using the music volume to triangulate and home in on the location of the Flame Spirit was one of the more novel mechanics in a videogame, and holds up well to this day.

Upon taking the Crown, a well-done TIA chip rendition of Grieg’s In The Hall Of The Mountain King plays, signaling your time-limited escape run to reach the Perpetual Flame at the top of the highest mountain peak in order to advance to the next level. The music created a sense of frenetic pace and urgency as you raced to the mountaintop. During the ascent, bats appear, which (similar to the Bat in Adventure) would rob you of the Crown. To avoid them, you sometimes had to hurry, and sometimes it was better to wait. This heightened the tension and anxiety you felt as you tried to make it out without losing the Crown, a setback which normally left you with insufficient time for a re-attempt, and meant an inevitable game over. More than any other feature, possibly rivaled only by the scare factor of the Spider, this made the game memorable.

Mountain King used silence to great effect, as well, for most of the time you are exploring the depths of the diamond mine in pitch dark and in complete silence, apart from the sound effects of picking up diamonds and the squeaking of bats. And if you fell, the sound effect — a simple descending tone — effectively conveyed not just that you had fallen, but how far. When you fell so long that part of the drop was in silence, you just knew you were going to be in for a long recovery time.

Each of these audio elements combined superbly to create a great mood, one of the best on the Atari 2600.

Mystery

Mountain King’s themes of mystery and exploration are enhanced in a number of ways. First, the instructions don’t tell you exactly what you need to do — rather, they hint and allow you to figure things out for yourself. Enough information is there to figure the game out, but enough is left out that it leaves the player with a sense of mystery and discovery. The Flame Spirit and the Skull Guardian and who placed the Crown in the mountain are never explained, leaving the player to wonder and speculate.

The game reinforces the mystery and discovery directly in game play, by making a number of things invisible — black sprites on black background, discoverable only by shining your flashlight everywhere. Treasure Chests, which are worth a lot of diamonds, are not essential to find, but are common enough that you are likely to encounter a few of them as you collect diamonds. The Flame Spirit is unique and critical to the game, and normally invisible, but the combination of the musical theme and its occasional flickering into visibility make it findable even without the flashlight, but by learning to use the flashlight to find Treasure Chests to boost your diamond score enough to find the Flame Spirit sooner, the game leads you to use it in discovering the Flame Spirit as well.

Glitch World

These mysteries are fine enough, yet pale in comparison to the Glitch World that hangs high above the mountain itself. It seems that not much is known for certain about the Glitch World, whether it is truly a bug in the game, or whether it might have been placed there by the programmers deliberately for unknown reasons. But there are platforms high above the mountain which are just barely reachable if you make a super jump from a specific place on the mountain.

I discovered this all on my own quite accidentally by jumping around aimlessly, and it was one of the most exciting things I had run into in a game before. In an era that predated the internet, there was little chance of learning anything about this but by discovering it yourself, and the excitement of this, and the intimacy of learning a secret that, for all you could know, was known only to you and (maybe) the programmers of the game, was very special.

In the early pre-Nintendo 80’s, kids would talk at school about accomplishments and discoveries they had made in video games, often times to incredulous schoolmates who would demand proof, or claim to have seen the same thing on their Atari. There were a few books and magazines out there, even then, but we didn’t have access to information the way we do today, and it gave us the opportunity to discover things ourselves. There were of course some kids who became notorious for lying and making up something in an effort to seem cool and special, as well, but the fact that you couldn’t 100% disprove a claim, and everyone would insist that they were not making stuff up. The only way one could verify extraordinary claims (in a still mostly pre-VCR-era) was if you witnessed it firsthand, so this made the rumors and secrets surrounding videogames something extra special, and if you were a witness, it made you special. I fear that era is gone forever, changed irrevocably by the Internet Age.

And for me, Mountain King might have been the most mysterious. Warren Robinett’s Adventure Eater Egg might have been cooler, but because it gave you a message, it seemed to have a purpose, and however cool it was, it just didn’t have the same mystery that the Glitch World in Mountain King had. We never found anything up there, no matter how high we climbed, but we never doubted that if we could only find some way past the impossible point, and get just a little bit higher, some great secret would be waiting for us, and all would be revealed.

LD48 24: Evolution. Karyote alpha

It’s not much at all yet, but I have an alpha build of my entry for Ludum Dare 24: Evolution up and running in HTML5.

Karyote

It’s not really playable yet, at the moment I’m just working out some motion and object prototypes. Graphics are all placeholders. You’re always in the center. Move with the arrow keys. Left/Right turns, Up moves forward.

Somehow, I’m doing another game with a microorganism theme. LD#23 was Bactarium, LD#24 will be called Karyote. You control a single celled organism that mutates as you play.

I still need to figure out what exactly you’re doing in the game, but I have some ideas that I haven’t implemented yet, so I’m a little further along than it looks as far as the concept goes. I’m designing as I go, mainly this is design by fiddling around. That’s a dangerous way to go on any project, but when I don’t have much of an idea to begin with, I find it’s one of the most reliable ways of getting me going. Hopefully I’ve learned enough lessons from previous projects to avoid messing up the code architecture, so debugging and feature changes don’t turn into a nightmare toward deadline.

Ludum Dare 24 This Weekend

It wasn’t that long ago (late April, in fact) that I participated in my first Ludum Dare. I really enjoyed that experience, and am really looking forward to Ludum Dare 24 this weekend. I’ll be hanging out this weekend at our Cleveland Game Developers LD48 site, generously hosted at the Shaker Launch House space.

I plan to work solo, and entering my game into the compo, again, but one of these times I’d really like to get into a team and work on something as a group. For the weekend, I’ll be blogging on my page on the LD site, so be sure to check there and see how I’m doing.

I’m trying to think about my goals for the last LD48, and how I’ve grown since then and what my new goals should be.

LD 23 goals:

  1. Finish a solo project in 48 hours. Achievement unlocked!

LD 24 goals:

  1. Blog my progress as I go, self-documenting the development process. Last time I blogged a little bit, this time I want to take that further.
  2. Post playable builds as I go, not just at the very end. Last time I saw other people doing this, and I felt envious as they got feedback from people playing sneak-preview releases of their projects. I was super impressed that they managed to release something playable so quickly, but I have some ideas about how to accomplish that.
  3. Produce builds for Windows, OSX, and HTML5 to reach a wider audience. Last time, I was still using Game Maker 8.1 Professional for my project, which limited me to Windows. This time I’ll be using GM:Studio. This will be my first project targeting multiple platforms, so kindof a new thing.
  4. Use fellow CleGameDevs people for feedback and encouragement. We used IRC for this, and had our first night at a common space, which was good. I just want to do this more.
  5. Play and rate more entries. Last time I did play a lot of games during the rating period, and played even more after the rankings were posted.

Incorporating music into my game will probably remain a future goal, for now. I’ve experimented a little with FamiTracker, and may attempt to produce a little music for my game, but I still think becoming a chiptune artist is a far-away goal. I think music is a really important element of videogame design, but it’s probably better to have no music at all, rather than bad music. There are certain game themes which lend themselves to silence, so I can possibly use that, or I can make a game that has an overwhelming amount of sound effects in it, like my last LD48 entry. Or maybe I’ll get lucky and one of our musically talented CleGameDevs people will throw me some resources, and I’ll make it a Jam entry instead of a Compo entry.

Tonight and tomorrow I plan to go over my preparation checklist and make sure I am ready. Gotta make sure all my software is up to date and working properly.

Robotron: 2084 and Zookeeper

Today was the day of Cleveland’s Classic Console and Arcade Gaming Show. This year was especially well attended, and I was very happy to see a higher proportion of female gamers attending. I’ve been going since I heard about it 2005, and every time I go there is always something I have never seen before, and it’s always a good time. In addition to rows of tables with old games to buy and look at, some homebrew and modding fun, and some old school systems set up with games to play, there are drawings and tournaments.

This year, they had two of my favorite 80’s arcade games: Zookeeper and Robotron 2084. Robotron was a tournament game. I thought I might have a chance at winning, but I didn’t come close to the top score — although I did have the second highest score. I played a lot of games to get sharp, but my top score of 214,000-some points was still far from the winner, who posted a score of almost 391,000. It’ll take me a while to get that good.

While the experience is still fresh in my mind, I thought I’d reflect on what makes Zookeeper and Robotron two of my favorite games.

(more…)

Making a Configuration System in Game Maker, part 2: Requirements

If you haven’t yet, go back and read Part 1

Design choices

Since we’re starting from (basically) nothing, we have a lot of decisions to make. Therefore, thinking about the design of your configuration system first before you start building things probably is a good idea.

Requirements

First, let’s think of the features that we need. When I brainstorm features, I tend to go crazy. I think about everything I might possibly need. I think about all the things that would be OMG SO AWESOME to have. I find it helpful to do this, but I have learned that while having all these ideas is great and exciting, in the end you have to build everything, so every idea you come up with represents a lot of work and a lot of testing.

I’m only one person, working on these projects in my spare time — not a design house, or even a full-time lone developer, so if I want to ever have a hope of finishing my work, I have to scale back to the essentials. So why think about everything I can imagine?

  1. I like my imagination. It’s awesome, and using it is fun.
  2. The more I think about things, the better my ideas get.
  3. When I think complex, even if I don’t ever build the whole thing, I can at least create a design that will better accommodate further development later if I want to extend the basic implementation. I might do the extending, or someone else might do it later; it doesn’t matter. Building code as a foundation for future code is a good thing if you can manage to do it. Doing so correctly means avoiding having to repeat yourself in future projects.
  4. Even if I don’t have all the resources or talent that I might need in order to implement a design, having a good design documents makes it that much more likely to inspire others to contribute something to the project.

A very simple Options system might consist only of a single screen. But as we’ll soon see, there may be need to break things up into multiple screens, especially if we have many different options or categories of options.

If we have multiple screens, we’re going to need a means of navigating between them. This can be as simple as a group of rooms with room_goto commands linking them up, or it can be something else.

To design our Configuration Options system, we need to address a few things:

  1. Features: What options do we want the user to be able to configure? What choices do we want each configuration option to have?
  2. Interface/Controls: How do we want to present these options to the user? How will the user interact with the interface to set it?
  3. Implementation/Integration: How do these configuration choices get applied, technically? How will these configuration options interface with the game itself?

Features

Some of these will be fairly standard, common to many games, while some will be highly specific to the specifics of this game. I’ll address the standard ones, but don’t worry — once you see how we implement the standard features, it will be easy to set up config options for the features that are unique to your game.

You don’t need to support all of these options, but the following list is a good start for what you might want to consider:

Graphics

PC hardware very commonly has different graphical capabilities, due to differences in hardware, particularly the video card and monitor. While just about any video card is going to be capable of playing most Game Maker games at full quality, there is still the monitor to contend with.

Display settings

It might be easiest to force a specific display mode, but that’s not a flexible approach and may not work for all players. By far, it’s better to assume that the display mode the game starts up in is the player’s preferred (or only) graphics mode, and leave it as is.

If you want to enable everyone to play your game, it’s a good idea to give them some control over how the graphics of your game will be displayed on their screen.

The easier approach is to allow the player to set the display settings through the computer’s control panel, and just run in whatever mode the display is set to when the game runs.

More professional looking games usually offer the play an in-game configuration menu that allows them to change the same settings without having to leave the game program. It’s a convenience, to be sure, but it does keep the user in your game.

Keep in mind, too, that in GameMaker, there’s a distinction drawn between the Display (the physical hardware), the Window, the Room, and the View. Most of what you might think could be accomplished by forcing a specific display configuration can be better accomplished through Widow, Room, and View settings.

  • Fullscreen or Windowed mode?
  • Display resolution
  • Aspect ratio
  • Refresh rate
  • Color depth

Fullscreen or windowed mode?

Most games play best in fullscreen mode, but sometimes players like the option of playing inside a window, as it allows them to switch between other applications more easily. The downside of this is that it becomes all too easy to mouse outside of the game window, and lose focus. You can set the game to pause if the window loses focus, but this is still annoying disruption and can mess the player up even with pausing the game.

When to run in a window?  As a general rule, I like to develop and debug my game in windowed mode, since it’s easier for me to get at other windows that I’m working in. But for finished games, I usually like the game to run fullscreen. I want the game experience to be distraction-free.

That’s not always the case, though. Casual style games, pausable games, puzzle games, and turn-based games that wait on you to act are good candidates to have a Windowed mode as an option.

Resolution

These days, it’s probably not necessary to change the display resolution. Just about everyone uses LCD displays with fixed resolution. While these screens are capable of emulating other resolutions, they do not look as good when they do. Games for mobile devices of course will play on a device with a specific resolution that cannot be changed.

In any case, the game should never force a specific resolution on the player; you may want to offer the player controls to allow them to change the resolution for themselves within your game interface, though.

If a player wants to set a specific resolution, they can always just use the display settings control panel on their computer. If you want to provide an interface for this to them in your game, you can, but it’s a convenience or luxury feature, not a necessity. Supporting multiple resolutions means a lot of extra work and testing for a developer, so unless you’re a professional studio with the resources for this, it’s probably better to focus on supporting one resolution well.

Don’t worry about supporting every possible display size right away, the amount of work it takes to do it well will kill your project. Instead, focus on making the game as good as it can possibly be in one default resolution, and if your game ends up being popular enough to warrant it, you can build resources (primarily different sized rooms) to support other display resolutions better.

If you do change display resolution in the game, keep in mind a few things:

  • Always change it back when you’re done. Use display_reset() for this. Keep in mind if the game crashes, this doesn’t get called, though, and may leave the computer in a resolution the player doesn’t want. This can panic a non-technical user.
  • Don’t change display settings without first testing them. Use display_test_all() with the settings you’re about to set, before you actually set them. Be sure to have some fallback code that gracefully handles what takes place if the new settings don’t test OK.

You probably do want to know what resolution display the game is playing on, though. There are a lot of reasons to need to know this. Use display_get_width() and display_get_height() to detect the display resolution. Note this will return the current settings for the display, not what the display’s maximum or native resolution is.

You should decide the minimum display resolution you’ll support. GameMaker’s default room resolution is 640×480, which is the old VGA standard resolution. This is a very safe resolution to use, because just about any display will support it, but is also quite tiny these days. It’s still not a bad resolution to start out with, though. The smaller the minimum resolution you support, the more devices your game will run on.

It’s good to support larger resolutions, too, of course. Most people do have larger displays these days, and it’s desirable to utilize all that space effectively. Very large display resolutions can introduce performance issues, though, so test your framerates when running at maximum resolution, and make sure they’re acceptable.

If you’re targeting a specific mobile device, learn what its native resolution is, and use that. Read up on guidelines for Android and iOS development to learn the recommendations other developers follow.

To accomodate other resolutions, there are a variety of approaches. You can create a series of rooms and HUD graphics to provide a tailor-fit screen for every resolution you support. This is a lot of extra work, though. Scaling the game to fill the display can be an OK approach to take, and requires a lot less effort, but will result in a less attractive game with blurry edges due to the way the Game Maker runner handles scaling graphics. Another approach is to letterbox — draw the game in its standard resolution at a fixed 1:1 scale, and leave a black border around the edge of the screen, framing the game window. This can be good, too, but if you have too much black border it can be annoying.

Aspect Ratio

These days, you also have to consider aspect ratios, the ratio of the width and height of the screen. In the old days, computer monitors and TV sets in the United States all used 4:3.

Today, it’s a different story. On the desktop alone, people may have 4:3, 16:9, or 8:5 (16:10) displays. 16:9 is pretty quickly becoming the most common, particularly in 1920×1080 (1080p), and is also the ratio of HDTV, so if you have any desire to port your game to a game console, you may want to start out at 16:9.

And there are still others, albeit less common ones. If you’re planning on targeting a mobile platform, you’ve got even more possibilities.

If you’re building an HTML5 game, keep in mind that the browser window “chrome” (menus, toolbars, etc.) all take up space as well, which should be subtracted from the available display you have to run your game in, and this can change the effective “aspect ratio” of the web page unpredictably.

Enable/disable special effects which may affect performance (such as particles).

There are two main reasons for making these configurable: performance on slower machines, and user preference. Some players don’t like effects-heavy games, and prefer a sparse, cleaner visual experience without all the bells and whistles. Sometimes the screen can become so cluttered with particles that you can’t see the action, and it hurts your game rather than enhances it. So it’s nice to allow the player the option to not have these things in their game.

Refresh Rate and Color Depth

These settings are controllable in GameMaker, but there’s almost no reason for it. Most games shouldn’t have any need to mess with the color depth of the display.

In the 1990’s, it was more common to see variety here, but these days it’s pretty safe to assume that the computer will be running in 32-bit color mode. Oddball machines might be running in 16-bit or 24-bit color, and even more rarely you may encounter a display configured to run in 16-color or 256-color mode, but these are rare, and probably won’t have the necessary hardware to run a GameMaker game adequately anyway.

Refresh rate is probably also safe to leave alone. This setting is more pertinent to CRT displays, which are rapidly disappearing from the desktop computer landscape. Most LCD monitors use a 60Hz refresh rate, although there are LCD HDTVs that use 120Hz or 240Hz refresh rates. Older TVs used 30Hz.

Some people can notice a difference between refresh rates, and can tell you readily just by looking what refresh rate a monitor is using, especially if they are familiar with the display in question, but most people can’t, and don’t even think about such things if they’re even aware of them.

Some game developers will say that it’s a good idea to sync the room_speed of your game to the refresh rate. Keeping FPS and refresh in sync, or at least in a whole-number ratio, is not a bad idea. But the better way to do this is to set your room_speed to the display_get_frequency() or just assume a refresh rate of 60 and use a room_speed of 30 or 60. Keep in mind that regardless of what the room speed is set to, it’s fps that is the actual frame rate, and this usually fluctuates a bit.

Sound

  • Master volume
  • Music volume
  • Effects volume
  • Mute

Again, for the most part, these configuration options could be set by the user outside of the program, by using the volume knob on the speaker, or through the Sound and Volume control panel. But it’s a nice convenience to provide an interface to the user so they don’t have to leave your game to make adjustments. The nicest one is the separated music and effects volume. This will allow the player to adjust the mix to their taste.

One important thing to do is to remember the user’s preferred volume settings and automatically set them when the game runs, and set them back when the game exits.

The harder task will be to separate the volumes for the Master, Music, and Effects volume controls. Mute is actually very simple, and there are a few techniques that can be used. One way is to have a global variable called “mute”, and to set up a conditional before each and every sound function call. This is an inferior approach because it means you have to make sure you catch every single sound function call in all your code, whichis a pain to program. The other problem with it is that all those extra if (mute){} checks take processing power at runtime, albeit a tiny amount, it still adds up and could conceivably hurt performance.

The better way to handle mute is to simply setting the volume to 0. This is done with the sound_global_volume() function, which we also use for setting the master volume. The sounds still play, but at 0 volume, you don’t hear them. You don’t have to add code for every sound_play and sound_loop function in your code. And since the computer doesn’t have to ask every single time whether the game is muted or not, it’s a lot less processing. sound_global_volume(0) mutes your game, and sound_global_volume(1) restores the master volume to full. Use a global variable to store the setting for the master volume as well, so instead of restoring the volume to full blast on unmute, you set it back to the master volume value.
globalvar master_volume;
//master_volume is set in the config screen.
mute() {sound_global_volume = 0;}
unmute() {sound_global_volume = master_volume;}
You can put the Mute function into your game configuration menu, or you can make it more readily accessible to the player by creating a control for it that they can access while the game is playing.

Separate volume controls for bgm and sound effects will take a little more work, using the sound_volume() function to control the volume for each individual sound in your game, so we’ll cover that in detail later.

Note: GameMaker Studio 1.1 introduces an entirely new audio system. The above code samples work with the old system.

Controls

  • Provide the player with a screen showing the current settings, and allow them to set up their own custom settings.
  • Allow the player to save their custom settings as a profile, load from a profile, delete profiles.
  • Allow the player to reset the controls back to their default settings, or to select a custom profile (such as for different keyboard layouts, etc.).
  • Provide the player with options to use various input devices (keyboard? mouse? joystick/gamepad?)

Difficulty/Game Options

  • Difficulty (Easy/Normal/Hard)
  • Starting level
  • Enable/disable (or throttle) specific features
  • Number of lives
  • Text size/speed (if you’re displaying lots of dialogs)
  • etc.

This part is highly dependent upon your game. You can set up an interface to allow the user to set these things, but integrating them into your game will be highly dependent upon your game. Some things (number of lives, starting level) will be trivial to implement and integrate; others will take a great deal of design sense and playtesting.

High Scores/Achievements

An Achievements system, again, will be highly dependent on your game. But we can probably provide some abstractions that make it easier to implement your achievement system in a consistent way, such that the specifics may be different from game to game, but they way they are handled will be the same.

Some features we might like to see:

  • Record more than 10 high scores
  • Record other types of achievements
  • Record achievements per player account
  • Clear achievements
  • Upload scores/achievements to an online “Hall of Fame” server

Localization options

  • Language
  • Keyboard layout – keyboard layout could tie in well with the Controls. A user with a non-QWERTY keyboard could set that here, or have it be auto-detected from a system variable, and automatically update the keyboard controls with default keys appropriate to the layout map of the local keyboard. But then, the user should still be able to override these with their own preferences.

Save States/User Profiles

If your game stores user profiles or save state data, provide an interface to the user to do things with them. Common activities include:

  • Create new
  • Delete
  • Copy
  • Rename
  • Edit info (for user profile data, such as user name, password, and other profile data).

What’s in the save state file will be a bit beyond the scope of this series, and in any case should be highly dependent on your game. While I won’t tell you what to put in your savefile, I can tell you how to set up some file i/o functions that will enable you to read and write your savefile, and maybe some suggestions for how to protect this information, validate it, and format it.

It’s also a good idea to save the configuration settings themselves. Configuration settings (graphics, sounds, etc.) should be separate from game savestate data (My character’s name is XYZ, He is level N, his inventory consists of…, he has visited the following locations… he has achieved the following goals… etc.)

We have a few design choices for how we want to do the config save. The simplest would be to simply revert to defaults every time the game is launched (ie, not save anything, but remember a basic set of options that will definitely work on any system the game is run on.) From a user’s perspective, however, this would become annoying, as they will need to re-configure settings to their taste every time they quit the game. The next simplest approach would be to remember what the settings were the last time the user set them, and to remember the defaults in case the Last config profile gets corrupted.

This is probably as far as you really need to go; but once you are saving profiles, you’re not too far from allowing the player to save multiple configuration profiles, or per-user profiles. We’ll probably implement this later on as an advanced feature.

  • Other stuff

  • Network: These days, you may also want to have configurations options for network (TCP/IP settings, firewall/proxy server settings, etc.)
  • Social: Or you might want to have some kind of social networking features, such as sharing your game progress with your Facebook and Twitter friends, inviting friends to try out your game, or even send friends in-game items to help them, and so on.
  • Hall of Fame/Achievements: Or a “submit high score to server” feature. Or you might have a registration and payment screen.
  • Update Checker: Or a “check for updates/download/install” feature.

These things are much more complex to design and implement properly, and as such will be outside the scope of this tutorial for now, but it’s good to think about them!

Personally, I would like to see these type of features built in to Game Maker, and I hope that YoYoGames will incorporate features like this in time. When I say “built into Game Maker, I don’t  just mean having a library of available GML functions that one can use to build a configuration system out of. That is, after all, what we are going to do with this project. What I mean is, it would be nice if such a system existed as a ready-made component that you could just drop in to any project, and set up with just a few clicks or lines of code.

These features, and the interface the user will interact with to manage them, will be challenging and time-consuming to implement, and are not really “the game”. A good configuration system and interface is excellent polish for a professional-quality project. Game Maker’s purpose is to make game development easy by doing the hard technical stuff for you. So far, they’ve done that by focusing on the in-game building blocks that a designer would use to produce a play experience. Now that they’re turning Game Maker into a more professional tool, I hope that they’ll start thinking about including these kind of features, too.

Until then, we have to fend for ourselves. The above list of features represents a significant amount of work that we need to do. Setting up a system that is flexible enough to allow us to do this easily is no small task. If I’m lucky, by procrastinating long enough, I may find that they end up doing the work for me:) If I am going to do all this work, then I want to get the most return for that work that I possibly can by making a re-usable system that I can apply easily in any game. This means a de-coupled, generic system that can be adapted easily to a wide variety of projects. This is a good situation to create a Game Maker Extension (.gex). However, an extension will not give us a complete system — an Extension allows us to package a library of useful new GML functions that we write, but our built system will also need room, object, sprite, and sound resources, and a .gex cannot include those resources. Ultimately, this means that we may not be able to realize a dream of a drop-in system. But even providing better building blocks to create such a system would be better than nothing.

To begin, we’ll start small, and implement some basic things, and then iterate and refine our solution until we have something that hopefully works really well for a wide variety of games.

In our next article, we’ll discuss the code needed to make these configuration settings, as well as how to store and retrieve them.