Category: games

GameMaker Tutorial: String handling and Drawing Text

[Editor’s note: This article was written primarily with GameMaker: Studio 1.x in mind. There have been some changes to the way GameMaker Studio 2 handles strings, mainly dealing with escaping codes, and this article has not yet been updated to reflect that. Refer to the official manual chapter on Strings for all the details.]

Drawing text to the screen is a basic part of most videogames. There are a huge number of useful applications for text. Just a few of the more common applications:

  1. Score
  2. HUD/Dashboard
  3. Menus
  4. Special effects
  5. Messages and dialogs
  6. Instructions/Story
  7. Debugging/diagnostics/benchmarking — it can be incredibly useful to draw the current value of variables to the screen when debugging, or performance metrics.

Things to know about drawing stuff in GameMaker

  1. Draw functions only work in Draw Events:  If you try to use them anywhere else, nothing happens. If you’re drawing in the Draw GUI Event, you’ll want to be familiar with the draw_set_gui_size() function so your Draw GUI stuff will be drawn to the proper scale if you’re using Views.
  2. Drawing directly to the screen (especially text) is slow. Draw a lot of text and performance will suffer.
  3. There are ways to improve performance when drawing text. The most important of these is to use Surfaces. Surfaces are not available in the free edition of GameMaker, and not all hardware may support them. Using surfaces properly is not that difficult once you understand them, but is generally considered to be an “advanced” concept in GameMaker, and is less straightforward than drawing directly to the screen in the “normal” way.
  4. But there are challenges. Setting up a Surface for optimizing text performance is tricky because it can be hard to know in advance how large the surface needs to be to contain the text you are drawing. Fortunately, GameMaker provides some useful functions which can enable you to get the dimensions needed for the surface: string_width() and string_height(), which give you the width and height, respectively, in pixels of a string drawn with draw_text() in the current font. If you’re using draw_text_ext() string_width_ext() and string_height_ext() are the functions to use instead. These functions allow you to create a drawing surface of proper dimensions, provided you know the string and font and can decide on a width prior to creating the surface. Keep in mind that the dimensions of a string depend on the font used to display it, so always use draw_set_font() to set the font to the correct one that you intend to draw the string with before using the measurement functions.
  5. Draw settings (for things such as color, alpha transparency, and font alignment) are global in GameMaker. That means that if you have multiple objects which draw functions, and if any of them changes the color, alpha, or font alignment, all objects will be drawn using those same settings. For this reason, if you are using draw functions in your objects, it’s best to set all the draw settings in the object in order to make sure they are what they need to be. If you never change color, or alpha, or font alignment, then you don’t need to set that property before you use draw functions — but if you do need to change them for one object, it’s best to set them to what they need in the Draw event of every object, immediately before calling the drawing routines.
  6. For serious performance optimization, you need to learn how GameMaker “batches” drawing operations, and organize your code to have the least number of drawing batches as possible.

Fonts

Everyone these days knows what fonts are, right? Fonts are like the clothes that text dresses up in when it wants to go out and be seen. In GameMaker, fonts are game resources, just like sprites, or objects, or other resources, and need to be added to the project — you don’t simply have direct access to the same fonts that are installed on the system, you have to explicitly add a font to your project. If your project has no font resources set up, text drawn to the screen will still render, but oddly and probably not consistently across platforms. So, always define a font resource and make sure that it’s used if you’re drawing text.

To save space, you can define a font resource to include only certain character ranges, such as number digits only, or alphabet characters only, or only the upper case or lower case letters in the alphabet. If you know you won’t be needing certain characters, and are concerned about the size of the game when it is built, go ahead and constrain the range. Otherwise, the default range of 37-128, covering A-z, 0-9, and special characters, is good.

For legal reasons, it’s important to note that fonts are copyrighted, and most need to be licensed for commercial use. There are free fonts out there (google for them) with liberal licensing terms that you may be able to use in your project, if the terms of the license allow.

Of course, you can create your own fonts. Creating your own font is outside the scope of this article, but there are tools you can use to produce your own fonts if you’re crazy enough. It’s probably easier to simply purchase a license for a professionally designed font.

Formatting issues

Alignment

Text alignment is set using the and draw_set_valign() functions. Use GameMaker’s built-in font align constants {fa_left, fa_center, fa_right, fa_top, fa_middle, fa_bottom} as arguments to these functions to keep the code readable.

New Lines

To signify a new line in a GML string, use the pound character (#). The GML code

draw_text(x, y, "Hello#World");

would be drawn like so:

Hello
World

You can also use a literal return in your string, but it’ll make your source code look yucky.

draw_text(x, y, "Hello
World");

Would draw to the screen exactly the same as “Hello#World”.

Escape characters

If you’re familiar with strings in programming languages, you know that it gets tricky when using certain characters that are reserved for program syntax or markup. Most languages allow you to “escape” the markup syntax so that you can still use characters normally reserved for markup purposes as literal characters in a string. GML is no exception.

#

What if you want to use a # in a string, and you don’t want it to signify a new line? Use the “#” escape character.

The string "We're \#1!" would be drawn like so:

We’re #1!

Quotes

A matched pair of quotes, single or double, can be used in GML to begin and end a string. If you want quotes to appear as text within a string, you can use the other type of quote to encapsulate them, like so:

my_string = 'This is a single-quoted string.';
my_string = "This is a double-quoted string.";
my_string = 'This is "an example" of a string including double quotes-as-text.';
my_string = "This is 'an example' of a string including single quotes-as-text.";

It gets tricky when you need to have BOTH types of quotes in the same sentence:

my_string = 'Bob said " We shouldn' + "'" + "t."+ '"' ; // Bob said "We shouldn't."

It looks like a mess, but you just have to do a lot of concatenation and quote your quotes with the other type of quote marks.

String concatenation

As with many languages, you can combine two strings together by adding them with the + operator. With number values + adds them; with strings, + concatenates the two strings together, creating a longer string made of the first one and second one stitched together. You can do this with literal string values, or with variables containing strings:

concatenated_string = string1 + string2;
concatenated_string = "Hello " + "World";

But if you try to add a string and a number, you need to tell the program to convert the number into a string. The string() function will convert numeric values to strings, which allows them to be incorporated into a larger string.

health = 100;
draw_string(x, y, "Player1 Health: " + string(health));

GML String functions

We’ve already introduced a few of the more commonly useful ones, but there are many other useful GML string functions. I’m not going to go into each one in depth, but review the official documentation and keep in mind that they’re out there, and can be useful.

One important thing to be aware of with GML strings is that, unlike most other languages, GML strings are 1-indexed, not 0-indexed. This means that when counting the characters that make up the string, the first character is character 1, not character 0.

GML text drawing functions

Mostly I have used draw_text() and draw_text_ext(), but it’s good to know that there are a few more variations on these basic text drawing functions.

  • draw_text
  • draw_text_color
  • draw_text_ext
  • draw_text_ext_color
  • draw_text_ext_transformed
  • draw_text_ext_transformed_color
  • draw_text_transformed
  • draw_text_transformed_color

It might seem like a lot to keep track of, but it’s pretty easy if you remember the following:

draw_text: basic draw text function.

_ext: allows you control over the line spacing and width of the draw area. This means you don’t have to manually handle line breaks by inserting # or return characters in your text.

_transformed: allows you to scale and rotate the drawn text.

_color: allows you to set a color gradient and alpha to the text.

Again, text is always drawn using the current global drawing color, alpha, halign and valign properties. It’s best to set these before drawing to ensure that they are the expected values, using draw_set_color, draw_set_alpha, draw_set_halign, and draw_set_valign functions.

Keep code clean by storing strings in variables

This is perhaps obvious, but it’s often useful to store a string value in a variable, to keep your code neater and easier to read.

draw_string(x, y, "Four score and seven years ago our fathers brought forth on this continent a new nation, conceived in liberty, and dedicated to the proposition that all men are created equal.##Now we are engaged in a great civil war, testing whether that nation, or any nation so conceived and so dedicated, can long endure. We are met on a great battlefield of that war. We have come to dedicate a portion of that field, as a final resting place for those who here gave their lives that that nation might live. It is altogether fitting and proper that we should do this.##But, in a larger sense, we can not dedicate, we can not consecrate, we can not hallow this ground. The brave men, living and dead, who struggled here, have consecrated it, far above our poor power to add or detract. The world will little note, nor long remember what we say here, but it can never forget what they did here. It is for us the living, rather, to be dedicated here to the unfinished work which they who fought here have thus far so nobly advanced. It is rather for us to be here dedicated to the great task remaining before us—that from these honored dead we take increased devotion to that cause for which they gave the last full measure of devotion—that we here highly resolve that these dead shall not have died in vain—that this nation, under God, shall have a new birth of freedom—and that government of the people, by the people, for the people, shall not perish from the earth.");

— is a lot harder to read than:

draw_string(x, y, gettysburg_address);

— and moreover, all that text gets in the way of comprehension of what your code is doing. So use variables to store strings, and keep your code looking clean.

draw_text_ext()

While we’re dealing with a very long string, it’s a good opportunity to talk about a function that makes drawing them much easier.

You could manually set line breaks in a long string by sprinkling #’s every N characters or so, but that is laborious and inflexible. It’s better to use the draw_text_ext() function, which allows you to specify a width for the line, and (optionally) also how many pixels should separate lines.

draw_text_ext(x, y, string, vertical_separation, width);

When drawn, the line will automatically break when it reaches the width provided to the function.

Formatting

GameMaker is rather limited in its typographical capability when drawing text to the screen. GameMaker Font resources, unlike an installed font on the system, are a specific size and style only. There’s no bold or italic or other style options available that you can use to modify the font resource. If you want bold or italic, you have to create a new font resource, and use draw_set_font(font) to that resource in order to use it.

This means that if you want to use bold text in a sentence, you need to create a second font resource for the bold font, draw your normal text, then switch fonts to the bold font, and draw the bold text, somehow positioning the two different drawings so that they look like they’re a single block of text. You have to leave a hole in your normal text where the bold word will appear. This is not easy, nor is it generally recommended. If you really want it, and are masochistic enough to put yourself through the trial and error to do it, go ahead. But before too long you’ll probably realize that it’s not worth the effort.

See this script draw_text_rtf which allows you to draw rich text format, originally written by Miah_84 and improved by me.

Special Effects

Scrolling text

Scrolling text is extremely easy to do. The draw_text function must be called by some object, and includes arguments for the x and y where the text will be drawn. Simply change the x and y over time, add you have moving text. The easiest thing to do is to set the instance that is drawing the text in motion.

Typewriter text

Another easy to implement technique is “typewriter text” — that is, displaying a string one character at a time as though it were being typed out.

First, let’s take a string stored in a variable, my_string.

string_length(my_string) will give you the length of my_string.

draw_text(x, y, my_string) would draw the entire string at once. But we want to draw it one letter at a time.

The GML function string_copy(string, index, length) comes in handy here. We can use this instead of string in our draw_text function:

//In the Create Event
typed_letters = 0;
//In the Draw Event
draw_text(x, y, string_copy(my_string, 0, typed_letters);
if (typed_letters < string_length(my_string)) {typed_letters++};

Note that this will type at room_speed characters per second, which at 30 fps is extremely fast. You may want to type slower, in which case you can slow down the function in one of several ways. You can use an alarm to increment typed_letters every N steps, rather than increment it in the Draw event. Or you don’t want to bother with an Alarm event, you could do something like this:

//In the Draw Event
if typed_letters < length {typed_letters+=0.1;}
draw_text(x, y, string_copy(my_string, 0, ceil(typed_letters)));

This would give a typing speed of room_speed/10, or 1 character roughly every 0.33 seconds for a 30 fps room, or 3 characters/second, which is a bit more reasonable. You can adjust this rate to taste.

If you want the text to reset and type over again when the message is completed, you can do this:

if typed_letters < length {typed_letters+=0.1;} else {typed_letters = 0;}

Additionally, you can optionally add code to play a sound with each letter, or start a sound when the typing starts and stop the sound with the full length string has been reached.

Marquee text

The Typewriter Text technique can be modified slightly to draw a scrolling marquee:

//In the Create Event
/*Hint: you may want to pad the end of your marquee string with extra spaces so it 
will scroll all the way off your marquee.*/
my_string = "Some text for your marquee "
start_letter = 0;
marquee_length = 10; // or however many letters in your marquee
type_rate = 3/room_speed; // 3 char per second
marquee_scrolling = true;
//In the Draw Event
if marquee_scrolling{
 draw_text(x, y, string_copy(my_string, start_letter, ceil(start_letter + marquee_length)));
 start_letter += type_rate;
 if (start_letter > string_length(my_string)) start_letter = 0;
}

Blinking text

Blinking is annoying in web pages, but can be a very useful effect in games. Blinking attracts the eye, and can get attention where it’s needed. Of course, blinking can be done with any graphical element, not just text.

Blinking is just turning on the drawing and then turning it off on a cycle, using a timer, such as an Alarm Event.

//In the Create Event
blink = true; //(or false, if you want the initial state to be off)
blink_steps = room_speed/2; //for a 1 second blink cycle. Set this value to suit.
//In the Alarm[0] Event
blink = !blink; //toggles the blink from on to off or vice versa.
alarm[0] = blink_steps; //re-sets the alarm so it keeps blinking
//In the Draw Event
if blink {/*do the draw stuff*/}

The above code gives a 50% “duty cycle” (the blink is “on” 50% of the time, “off” 50% of the time). It’s possible to vary the duty cycle in a variety of interesting ways…

//In the Create Event
blink = true; //(or false, if you want the initial state to be off)
blink_on_steps = room_speed/2;
blink_off_steps = room_speed/4;
//In Alarm[0]
if blink {alarm[0] = on_steps;} else {alarm[0] = off_steps;}
blink = !blink;

This blink code will result in a blink that stays on for 0.5 seconds, and blinks off for 0.25 seconds.

Even more sophisticated blink periods can be achieved using math functions rather than a static value. Setting alarm[0] = irandom(10) would result in a random flicker. Think of creative ways to use other math functions to create interesting effects. If you come up with a good one, share your code by posting a comment to this article.

Yet another way to flicker or blink text is through varying alpha. Or by switching colors. Or even size.

One last way to blink is to toggle the state of the visible boolean in the instance.

visible = !visible;

One thing to keep in mind, though, is that an instance that is not visible will not be checked for collisions. Also visible applies to the entire object’s Draw event, so it is all or nothing. Still it is a simple way to draw or not draw an object.

What next?

If you’re familiar with other programming languages, you may be disappointed at the limits of the built-in functions for manipulating strings. There are a lot of things you can do more easily in other languages than in GML, unfortunately. Since GML only has two data types, strings are extremely important, but because games tend to focus more on graphics, sound, and interface, the average GameMaker developer can get by with the string functions that do exist, for the most part.

There are a number of useful GML scripts for doing more advanced things with strings that have been collected at gmlscripts.com. Many of the functions built in to more mainstream programming languages can be found there.

Radar

I’ve been messing around with mini maps, and after a few different approaches, I have come up with a cool demo that simulates a radar screen. The screen even has a sweeping beam that lights up the blips, which fade over time. Only instances which inherit from an object called oMappable are drawn on the radar. The size of the blips is based on the width of the sprite of the oMappable child, so objects of differing sizes will be shown in scale relative to each other.

radar screenshot

It runs quite well, with up to 4000 simple objects (~30fps on a 2.0GHz Core2 Duo).

Demo (.zip)

Project Source (.gmz)

Stat-Driven Causality: Better than pseudo-randomness!

Watch this video on how the “random” loot drops in the original Legend of Zelda were actually determined:

I found it very interesting. In my game projects, one of the more difficult areas of game design is getting the frequency of the loot drops to feel right.

Let’s look at the ways in which the loot drops in Zelda are not random.

  1. Loot drops happen because of an event, eg defeating an enemy. They don’t happen “randomly” for no apparent reason. This drives a feedback loop of “kill monster, get treasure”.
  2. Which type of item gets dropped is actually not random. However, it’s important for the drop to seem random to the player, so they never can be sure of what they’re going to get. This keeps them guessing and curious: “What will I get if I kill this monster? There’s only one way to find out; better kill it!” invites play much more than “Ho hum, here’s another [enemy]; I know they only drop [type], and I don’t need that right now, so I’ll just walk by it.”
  3. It does seem that certain types of enemies do drop certain types of loot a bit more often. For example, in the overworld Tektites seem to be pretty reliable about dropping rupees, and tend to yield a higher proportion of blue rupees that are worth 5. They do drop other things, bombs and hearts, and fairies, but it does seem like they will drop rupees a bit more than other types of enemies. There may be a similar relationship between other types of enemies and other types of loot. This gives certain areas of the map, where these types of enemies appear, have strategic value for “farming” a given type of resource.
  4. It would make sense that more challenging enemies might yield more/better loot, but I don’t notice this so much when I play LoZ. It seems that as you progress through the game, the difficulty of the monsters ramps up, matching your own power increase, but that the reward remains more or less constant. Still, in many games, there’s a directly relationship between challenge and reward.
  5. By connecting the frequency and type of loot dropped to a complex conditional based on the internal state of the game’s various counts, it’s possible to tune the difficulty of the game to a far more precise degree than could be done through purely random loot drops. For example, if the player is low on hearts, you could use that data to drive a slight increase in the amount of health drops, to make the game easier. Or, to make the game more challenging, you could make health drops rarer when you’re low. This can be tweaked so that “easier” areas of the game have the more generous/forgiving drop rate, while the harder areas have stingy/unforgiving drop rates.

Up until now, I have thought of loot drops as something based on completely random chance, not influenced by various factors being tracked in the game. I had played with various stochastic functions to create what felt like “right” odds to give the game the right “feel”, and wondered why simple random distribution never felt quite right.

But what is “right” is highly subjective, difficult to define, and requires extensive time spent playtesting in order to gauge “feel”. But now, I see a much more interesting potential in tying the frequency and/or item dropped to causal relationships to various stat counters. What’s great about tying the loot drops to in-game stats is that it allows you to directly apply mechanisms to balance the game, based on how the stats reflect the player’s performance, their progress in the game, and the amount of difficulty you want at that point in the game.

Exactly how to do this will still be very subjective, and require extensive play testing, of course, but it will be tune-able and in the control of the developer, rather than purely random chance. I am excited by the possibility of using the stats model to drive feedback loops which can help to govern the game’s challenge level, or to provide certain items when they are more likely to be needed, or just to make the loot drop frequencies seem a little more interesting and less totally random. It seems like a potentially much more elegant way of distributing items in the game.

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.

The Space Invaders: In Search of Lost Time

I just watched The Space Invaders: In Search of Lost Time, a documentary about the golden age of video games, and the stories of a few collectors of arcade games who are keeping them alive in basements and garages and museums around the country.

A heavily nostalgic look at the games, people telling their stories and what the games and the arcade experience meant to them. It wasn’t as heavy on history, research, and data as I would have liked, and being an enthusiast who lived through this period I didn’t feel like I really learned anything, but I feel qualified to say that the film is accurate in its treament of what it covers, and it is quite enjoyable to watch if you love the the golden age of arcade videogaming, or if you want to learn about that period.

The film did focus mainly on gamers who grew up in the late 70’s/early 80’s, and did not seem to include any interviews with people from the industry — designers, programmers, company presidents, or anything (although, a number of the collectors they interviewed do work in the computer technology field in some capacity). So it’s very much a gamer/fan oriented story, and not an insider story. But you’ll come away from it with a good feel for what the games meant to the generation who came of age during their heyday, and a lot of cabinet envy, if nothing else, and perhaps a desire for more wall outlets in your basement.

Strangely, the actual game Space Invaders seems to have been largely ignored by the collectors who shared their stories. For serving as the inspiration for the film’s title, it’s a bit odd that they didn’t spend a little more time talking about the game somewhere in there.

It’s available as an Amazon Instant Video, and if you watch it through the link below, I’ll get a little compensation through their affiliate program.

The Space Invaders: In Search of Lost Time

Genes

I’ve created a demo for a genetics mechanic.

This is not a playable game, as it isn’t interactive. It’s just a demo of a breeding mechanic.

To explain what’s going on a bit: (more…)

Packt Publishing announces HTML5 Game Development With GameMaker

Packt Publishing has announced an upcoming new book, HTML5 Game Development With GameMaker, by Jason Elliott, tentative publication date in late April 2013.

I provided technical review/editing of the book, and so I can say that it should be a good book if you’re looking to get into the newer features of GameMaker Studio. While the book focuses primarily on HTML5, almost all of the book is generally applicable regardless of what platform you wish to target.

Highlights include:

  • Facebook integration
  • Pathfinding and Artificial Intelligence
  • State Machine design pattern
  • The new Box2D Physics system
  • Particle effects for any game
  • File I/O and HTML5 local storage.

GAME.Minder Expo 2013

Last Saturday, I attended and spoke at GAME.Minder Expo, held at Shaker LaunchHouse. after taking ill in January and missing the 2013 Global Game Jam, this was a great day to jump back into the Game Dev scene.

It was a relatively small event, but still probably the biggest local game dev event that I’ve been involved with to date. Organized by Handelabra to promote their studio’s mobile gaming efforts and the GAME.Minder podcast, and local area game developers in Ohio. Turnout was almost 40% higher than expected, with the official attendee count at 136. The Keynote talk was presented by Ian Schreiber, a co-founder of the Global Game Jam.

A bunch of us CGD people had dinner with Ian and his wife, and he said that we are getting big. It has been wonderful to see the local independent game developers organizing and building up our community and create a scene, and to be a part of making that happen.

Members of the Cleveland Game Developers meetup were well represented. I gave a brief talk on GameMaker, Jarryd Huntley talked about Construct2, while Brian Gessler and Justin Demetroff delivered a talk on Unity3D. Ian Faleer and Stephanie Frankiewicz gave a talk on the Art of the Game. And the folks from HashTag Nerd had a booth set up. There were a few other presenters as well. Videos are still being uploaded, but a number of them are already available on GAME.Minder’s Youtube channel.

The evening event was a screening of the Kickstarter-funded documentary Minecraft: The Story of Mojang. The movie was excellent and inspiring.

GameMaker: Studio Builds to Ubuntu

YoYoGames announced today that they have released a new build target for GameMaker Studio: Ubuntu Linux. It’s great to see YYG supporting Linux as a target platform, even if GameMaker does not embrace opensource principles. To add the Ubuntu build target to GM Studio Pro, it’s $99; if you have a Master Collection, it’s a free addition.

Master Collection is becoming an increasingly good deal with all the additional components provided and any new ones that come out entitled to Master Collection licensees.

Any time YYG releases a major new feature for GameMaker, I revise my wishlist for what I’d like to see from them next. Here’s what I’d like to see in future releases of Game Maker:

  1. An upgrade path for developers with Professional to Master Collection.
  2. Native IDE for Linux and Mac OS developers. The day a Native IDE comes out, I may not need to boot Windows anymore.
  3. Flash build target. (I know HTML5 is supposed to be the future, but Flash is still a relevant platform.)
  4. Support for other source control, especially git.
  5. Integration of some standard, cross-platform GUI widget toolkit like Qt or GTK to make creating user controls and forms easier.
  6. Native XML support (not relying on extensions)
  7. Project templates for common types of games, eg platformer, rts, etc. with library or namespace-like built-in classes for common objects already implemented

Game Jam 101 Lightning Talks

This Saturday, I’ll be at a Cleveland Game Devs meetup, where we will be giving lightning talks in preparation for the upcoming Global Game Jam happening later this month. I’ll be giving two talks, one on setting goals, and one on keeping the momentum. Following are my notes for the talks.

Game Jammer Goals

How to decide what to shoot for in your next weekend sprint.

A weekend is not a lot of time to make a game! To get the most out of your weekend, you need preparation and mental discipline. Having goals will help you focus and get the most out of your jam weekend.

So what should your goals be?

Have you made a game before, ever?

No?

Your goal should be to make a game! Easy as that.

Really, though, it is best if you have at least some game making experience before you try to fly solo. Do look for a team to join, and see what you can offer them. Focus on delivering a skill from your repertoire of strengths, and integrating well with the team. If you can get anything back from the team, hopefully it will be insights into skill areas where you are lacking, techniques that you can apply in those areas, or exposure to new tools that you can start to learn.

Yes… but never in such a short time!

If you have never made a game in a weekend before, likewise your goal can be to complete a game. It can be done, as proven by thousands of people. Before jams became popular, most people thought it took months or years to complete a game project. We know now that this simply isn’t so, and the amount of work that can be accomplished in a weekend can be incredible. Still, like running a marathon, it’s hard to believe until you’ve done it yourself.

It feels really good to have this accomplishment under your belt, so if you haven’t completed a Game Jam, this should be the only goal for you.

Even if you don’t make it this time, but still want to keep trying, then focus on learning what you can from the experience. If you weren’t able to complete the game you wanted to make, why was that? Did you lose track of time? Did you plan for more than you could possibly deliver? Did you struggle to implement something that you felt you could do, due to inexperience or pressure? If you couldn’t figure something out in the weekend, don’t give up – keep working on it after the jam until you figure it out. That way, at the next jam, you won’t be stopped by that failure again.

Don’t be afraid to fail, but try to fail early, and always fail at something new.

Yes! I’m a Jam veteran!

Then you can make a few more choices… completing the game may not necessarily be the most important thing once you’ve proven that you can do it. Be willing to take greater risks.

Once you’ve proven to yourself that you can do it, if you enjoyed the experience enough to want to repeat it, you should keep going on to bigger and better things. Participate in as many Jams as you can find time for, and make it a goal to do more with each new game, always improving on your last effort.

Where should you focus your goals?

This is a personal choice, and it depends a lot on where you’re at, where you want to go, and what your strengths and weaknesses are. Here’s a few areas to consider.

Learning/Experimentation. It’s only a weekend. If you fail, it’s no big deal. You only lose a tiny amount of time, and you can learn so much. So take risks. Try something you haven’t done before. Make your focus learning and experimentation.

Be willing to accept a failed concept, incomplete game, or failure to complete a submission. Ideally, you still want to make a game so you can show off what you learned and receive feedback on it, but it’s less important to have a good game than it is to learn from the experiment. If you want to have the best chance of having a finished game by deadline, limit your experimentation to one thing only. For everything else, stick with what you know.

I don’t recommend picking up a new tool to experiment with. Rather, do something different using a tool you know well. To complete a game in a weekend, you just don’t have time to learn a brand new tool that you’ve never used before. Using new (to you) tools won’t get much you recognition, but new game design concepts often do, even if they are not successes.

Still, if you really want to try a new tool, it can give you a taste of the tool, enough to give you a sense of whether it’s something you want to devote time to mastering.

Ideas for domains to experiment/learn with:

  1. Graphics
  2. Sound effects
  3. Music
  4. Controls
  5. Game mechanics
  6. Genre
  7. Setting
  8. Mood
  9. Story
  10. AI
  11. Level design
  12. Randomness
  13. Procedurally generated content
  14. Physics
  15. Particle systems
  16. Network
  17. Multiplayer

Each of the above is still quite broad – don’t be afraid to get much more specific when coming up with your ideas for experimentation. But do decide on the specifics late – once the theme is announced, and you are starting to come up with concepts for your game is a good time to narrow down the specifics of how you will experiment with in a domain.

Teaming. Step up and be a leader. Try to organize a team.

Or just be on a team. A team needs more than just leaders.

The thing a team needs most is do-ers, without ego, who can communicate. Never forget this.

Leadership does not mean making decisions for the group; it means helping the group to come to agreements about the decisions it makes together.

Community. When I say “community,” primarily I’m thinking of all the participants in the jam who are not part of your immediate team. This could be other groups at your location, or they could be other groups anywhere in the world.

The jam is when everyone comes together to make something and show off and share with each other. This is the best time to make new friends (or grow existing friendships), and get to know the community. Play and review games made by other groups – make note of who created them, and follow their projects. Make it a point to get to know the people and learn about them. Follow them on twitter, visit their web site, and learn about their other projects. Who knows, they may live nearby! Drop them a line and let them know you like their work.

The essence to community is giving. The community is indifferent to most of its members, but it recognizes their greatest contributions. To stand out, give the most. Exchange your knowledge and skill – be willing to sacrifice a little dev accomplishment for a little knowledge spreading. Make a game so you can get feedback from the other jammers. Give feed back on the creations of others. Write tutorials. Build and share your own tools.

Winning. If you’re a true pro, and your team is functioning like a well-oiled machine, this is what you should go for. Make the best game you possibly can in the time allotted. Go for it, try to win! Learn how the event is judged, and try to do well in those areas where you feel strongest. Focus on your strengths, or if you’re working with a team, let each team member focus on their strengths, once all areas of project have coverage. Your experimentation should be minimal – stick with what you know you can do well, and know will work. It’s all about coming up with a good design quickly and executing.

Take a balanced approach. Try to do a little bit of everything. After all, it’s pretty hard to complete a game without doing a little bit of everything. But still put an emphasis on one area or another.

For me, I try to take a balanced approach. I stick with what I know well for about 70-80% of the project, but try to make learning something new an important goal on top of simply finishing a game. I don’t care about “winning” the jam, but I want to do better than my last jam. I also try to be involved in the community in order to get inspiration from what other developers are doing, and to build reputation as a designer/programmer.

Be Flexible. The weekend will surprise you. Be adaptable to the surprises, because they offer you opportunities. The best things about a weekend jam are the things that you couldn’t have predicted beforehand. Don’t set out on a mission to complete a rigid list of goals, but have a number of potential goals in mind, and be willing to drop one in favor of another if the right opportunity comes along. If you try something and see quickly that it’s not going to work, or that you wouldn’t be able to finish it by deadline, it’s OK to drop the idea and go with something else.

Weekend goals vs. Long term goals

A very good use of your time in a game jam will be to incorporate your longer term goals when choosing your goals for the weekend. Successful people tend to set long term goals and work toward them by taking many small steps.

Use the SMART criteria:

http://en.wikipedia.org/wiki/SMART_criteria

  • Specific: Don’t be vague. Focus on a specific goal. If it is too general, you will rationalize and bargain with yourself that the goal has been met, rather than focus and work harder to achieve the goal. You can still be flexible with your goals while being specific, but if the situation dictates changing goals, try to change from a specific goal to another specific goal.I want to complete a game in the next 48 hours is pretty specific already. If you can, though, go further – I want to complete a game that incorporates teleportation. Or, Complete a game that uses the mouse for controls. Or, Complete a game that causes fear by imparting a sense of helplessness and sudden, surprise danger. You get the idea.
  • Measurable: If you can’t measure it, then you don’t know how well you did. Pick things that you can measure. This gives you something to aim for, and lets you re-calibrate as needed.Game design is hard to measure. How do you quantify fun? Still, there are things that are quantifiable. My goal is to rate 256 games for the compo. Or My goal is to place in the top 25% of entrants in the category of [x]. Or Create sprite animations for 8 different poses in the next 2 hours.But don’t try to make your goals based on arbitrary numbers. Try to pick numbers that are meaningful. It’s better to have a smaller number of well-done features than a larger number of weak features. What’s better, a game with 10 boring levels, or 1 really great one?Often, the easiest way to measure may be simple binary: either you achieved it or you didn’t.
  • Achievable: Don’t set yourself up for failure by picking something that you can’t hope to accomplish. You should have an idea of what you’re capabilities are. It’s fine to challenge yourself, but don’t set the goals unrealistically high. If you don’t have any clue at all how you’ll achieve a goal, step back and set a more realistic goal that you can achieve, which gets you closer to achieving the too-hard goal.
  • Relevant: Don’t pursue extraneous goals. Focus on what is most relevant to your larger goals.In a weekend jam, there’s just not a lot of time to waste. Focus on the essential features of the game you want to make. Don’t waste time on extraneous things.
  • Time-Based: Give yourself a reasonable window of time to achieve the goal. Assess yourself at that time and decide what to do next. But also check yourself before then to see if you’re on track.During a Jam, time is constrained as it is. You know you have 48 or 72 hours to build a game. I encourage you to subdivide this time and assess periodically where the project is at, and decide whether to drop or modify features in order to make the submission deadline.

 

Game Jamming 365

How to keep the momentum

  1. Be obsessive. Think about game development all the time. According to the Bureau of Unverifiable Statistics, men think about sex on average every six seconds. As a game developer, you should think about game development even more than this.
  2. Be persistent. Don’t give up. If you can’t figure something out, show off what you have been able to figure out and ask people for help.
  3. Set small goals. Pick small projects. Do things that are within your capability to complete quickly. Do simple, mini projects that aren’t full-blown games, but are good development exercises, or that can be useful reusable components in a game.
  4. Make time. At a minimum, set aside one night a week to be your time to devote solely to your projects. Arrange your calendar so that you can do this. Work over this minimum any time you can.
  5. Fill every possible moment. When you get into your project, you won’t want to stop. Find ways to put time in on your project. Carry a notebook around with you to draw and write up your ideas. Write yourself notes whenever you have a few seconds – at the bus stop, on the train, waiting for an appointment, in the elevator.
  6. Get back on track. Life will always intrude and take you out of “the Zone.” When that happens, figure out how to get back on track as quickly as possible. Deal with the distraction effectively and efficiently, and go back to development. If it’s a true life priority that’s calling you, then give it the attention it deserves, and resume your game projects when you can.
  7. See the Game in everyday life. Look around you, everywhere there are systems that could be seen as games. Teach yourself to recognize these patterns and then apply them in your projects. Art imitates life. Make up games about brushing your teeth, or walking your dog.
  8. Take a break. When you get exhausted, when you get stuck, when you’re not feeling it, when you’re wanting inspiration. Step back and give yourself time to recharge. Work on something else. Just relax. Meditate or exercise. Watch a movie. Hug someone you like.
  9. Play. Play games. Follow your favorite developers’ new releases. Return to your old favorites. Visit them with a fresh eye, think about what makes them successful.
  10. Release. Put your work out there for people to see. Give them easy ways to provide feedback to you. Use achievement statistics to collect data on how players play your game. Analyze the data to figure out how to make better games.