Posts Tagged ‘GameMaker Studio’

Handy tutorials for GameMaker developers

Posted by (twitter: @csanyk)
Wednesday, December 11th, 2013 7:14 am

Once again, to help anyone who might need it, here are some handy tutorial articles I wrote up on using GameMaker, for anyone who needs to brush up on their skills or take a crash course:

  1. Leveling Up as a GameMaker dev.  A guide to your progress as you learn the tool.
  2. Position and Motion Tutorial.  The basics of moving objects around the room.
  3. Wave Motion Tutorial. Getting that nice sine-wave sway.
  4. String Handling and Drawing Text.
  5. Draw Rich Text. A handy script for more powerful formatting of text  you draw to the screen.
  6. Building a GameMaker extension. How to write your GML for reusability, and how to use the GameMaker Extension builder.

And, if you’d like a whole book on GameMaker development, I helped out with editing HTML5 Game Development with GameMaker, ©2013 Jason Elliott, Packt Publishing, and can recommend it as a worthwhile book that will teach you some useful things, particularly the new Box2D Physics engine features.

Day 2/3 Conclusion

Posted by
Saturday, November 30th, 2013 10:57 pm

I’m very pleased with where things are right now. Considering that much of yesterday was spent with family after Thanksgiving, I got started late today, and I took frequent, long breaks, I couldn’t be happier that the core game is basically completed after about 12 hours or so of actual work. It’s good to know that the game could be made and work well within a Game Jam’s time period, no problem. Take that, guys who said that Heartbreak couldn’t be made in GameMaker!

I’ve been keeping an ongoing list of my progress throughout the day, and I feel that having the work in a checklist aided in my productivity and concentration. I’ll have to practice this sort of thing more in the future.

Heartbreak, as of tonight

That leaves things like sound effects and music for tomorrow, but at least those should be fairly simple to do. There is an abundance of great music available on the ‘net, and I may simply record my sound effects from the Atari 2600 version of Heartbreak to use again, as they are perfectly serviceable and I would be looking for something similarly retro-synth-sounding, anyway.

I’d also like to experiment with different visual styles, such as a grungy pixel art look and/or some scanlines. Something so that the visuals are so overly smooth and clean. That said, I do like the pastel colors that I’ve settled on, and it all looks pretty slick on my phone. I’ll have to experiment tomorrow and see what I like.

In any case, I consider the mini-LD technically complete as of now, since the gameplay is implemented and fully functional. The only nagging point is a crashing bug that I experienced a few times that I’ve been unable to replicate and track down. Here’s hoping that it got smoothed out somewhere and doesn’t rear its ugly head. Or, if it does rear its ugly head, hopefully it rears it high enough that I can find the neck and give it a good chop.

That’s it for me tonight. Time to wind down!

P.S. Is it just me, or does the above screenshot have a bit of an optical illusion going on with the blue block on the far right? Try turning your head back and forth and looking at it out of the corner of your eye. To me, it’s like the blue block separates away from the rest of the circle.

Day 1/3 Conclusion

Posted by
Friday, November 29th, 2013 11:08 pm

Well, I think that it’s gone well so far. Using the template posted earlier, I built base sprites for each row of blocks, then created a script for creating and setting up individual blocks and a script to churn out full rows. Much like the original game(s), I hope that this version will do a decent job of teaching intuitively through level progression.

Also, the heart changes colors and has a simple beating animation (just scaling down for a frame).

Tomorrow, I’ll be adding the ball and controls. If I have time (which I expect I will), I’ll also add in all the core levels and the score counter. There should be at least 12 levels, each of which will introduce something new (an additional color or another row), plus a few different random mixtures for infinite play beyond that.

Here is a screenshot of where I’m at so far, with all the blocks being randomized into place. Seeing how it looks, I’m definitely going to have to figure out something different visually. I was shooting for something cleaner, but it just looks drab in the end, plus the blocks don’t fit together particularly well, so I will have to rethink that. Maybe a pixel-y art style will be back on the table, since it’s relatively simple to accomplish, but would add some visual grit and variety, if done well, so everything wouldn’t seem so bland.

Heartbreak v3, with randomized blocks

Time for a break, then bed.

My First Game – Then and Now

Posted by
Friday, November 29th, 2013 3:24 pm

Last journal post until I actually make some progress, I swear!

After making a long post about my choice in game engines and then another explaining where my original game concept came from, I’m going to, finally, explain the history of my first game’s development. In brief, I hope.

Heartbreak version 1: Unity 3D for Windows

Original Heartbreak game, made in Unity3D

As you can probably see, the game is very flawed. One major issue was with the controls, which were tied to the mouse, so moving the mouse left and right caused the ring to spin. Hitting left mouse button would fire the balls from the central heart. On top of that, the game itself is bugged. At the eleventh hour, we discovered a bug on the fourth or fifth level that would cause the score to reset to 0 after the player had progressed to the following level. Finally, at the time I made a big deal out of “elegance of design”, which I saw as every part of a game coming together to compliment everything else.

Don’t get me wrong–elegance of design is a good thing, but I may have taken it a bit too far by creating a menu system that you could literally “lose” at (by accidentally selecting the exit button), in the interest of turning even the menu screen into a gameplay tutorial. I think I had seen one too many episodes of Sequelitis.

After the 2013 Game Jam, I was excited to try my hand at game programming, since I’d been only the lead designer for the original Heartbreak. I wanted to learn the craft of programming for myself, in the interest of being more self-sufficient. To that end, I decided to start as “simple” as possible and got into programming for the Atari 2600. Yes, the real Atari 2600.

If it’s a bit debatable whether or not I technically “made” Heartbreak version 1, since I was really just directing a Unity 3D programmer in what to do, I consider my actual first game to be my first remake of Heartbreak for the Atari 2600. I used the homebrew tool Visual Batari Basic, which, when combined with Batari Basic, gave me a convenient and simple IDE with many helpful sprite and sound design tools, plus the ability to code in BASIC and use a pre-made kernel, rather than coding everything directly in 6502 Assembly. I was extremely grateful for that.

Heartbreak version 2: Visual Batari Basic for Atari 2600

Prototype Heartbreak game, made in Visual Batari Basic for the Atari 2600

It took me a couple months to actually make Heartbreak for the 2600, since I was learning along the way and frequently had to go back and reprogram bits of code here and there as I discovered more efficient ways to organize the game logic. Keep in mind this was all done for a system with a 1.19Mhz processor and 128 bytes (yes, individual bytes) of memory (only 26 bytes of which were available to me in Batari Basic, since the kernel I used consumed the rest of it to write the playfield to the screen).

In the end, it was again thanks to a more experienced programmer, who generously wrote a custom kernel for me, that Heartbreak was able to function well on the 2600. Normally, using Batari Basic’s standard kernel, only a single playfield color can be displayed on-screen per playfield pixel (those big, rectangular blocks), but the programmer managed to work around that limitation with some clever 6502 Assembly wizardry that I still don’t fully comprehend.

From the custom kernel as a framework, I was able to build the finished game. Some months later, I revisited my old code and cleaned it up, organizing everything into neat, clean functions that you can view here. I’m rather proud of how tidy and efficient it all is (relatively, keeping in mind that this is BASIC with 6502 Assembly calls in it, all programmed in non-object oriented in a language that relies on spaghetti code). The game itself only uses about 1000 out of ~3000 CPU cycles that are available with this particular kernel, and the game itself is under 4 kilobytes. And, yes, it works on a real Atari 2600. If you’d like to try for yourself, I included Heartbreak, with a few other small games I developed for the Atari 2600, in a 32k compilation ROM (along with an updated version of my previous LD, Ping) that you can get here (you’ll need an emulator such as Stella to run it, unless you have a real 2600 with a Harmony cartridge), and you can see the finished version of the game below.

There have been a number of gameplay changes since the Unity3D and earlier 2600 versions.

Heartbreak version 3: GameMaker for Mobile

Originally, the player had to hit a button (joystick fire on the 2600, spacebar or left mouse on Windows) to fire a new ball from the heart. The ball would take on the color of the heart and it had to either match the block’s primary color or be one of the primary colors that made up the block’s color, or else the player would lose a life (indicated by the size of the central heart). Hitting a wrong block three times meant game over, but the player’s heart would be brought back up to full size after every stage.

Once I’d finished the basic game on the 2600, I was seeking to program in alternative gameplay modes, since alternate modes were a thing with many 2600 games. One of those modes included a bouncing ball, so rather than the player having to spawn each ball (which would fire from the heart and then disappear once it had stricken a block), the player only had to press the fire button when they wanted to transfer the heart’s current color to the ball. This meant a lot less button mashing, and it was far more satisfying to just control the blocks to catch the ball as it bounced. This ended up being the only game mode in later versions.

With the block colors, I’d always intended the game to start with simple primaries–Red, Yellow, and Blue, and work up to secondaries–Orange, Green, and Purple–and finally to White and Black. White blocks would give you a heart back, but black would take away a heart if they were struck and had to be avoided, which was particularly challenging in the 2600 version, because the background is solid black as well.

However, this lead to the game becoming progressively easier, since an orange block could be broken by either a red or a yellow ball, a green with yellow or blue, and a purple with red or blue. Obviously, a game should get more challenging over time, not less. I fixed this in the 2600 version by having the ball remove a color from the block’s color, leaving the remaining colors in its wake. For instance, if a red ball hits an orange block, it bounces off and leaves a yellow block behind, which must then be broken by a yellow ball. And if the orange block was hit by a yellow ball, it would bounce off leaving the block red. Yellow blocks would need to be hit by all three primary colors before they would disappear.

Overall, I’m very pleased with how the game itself plays as of the final 2600 version, but a few things had to be sacrificed in the move to the 2600’s limited hardware.

For one, the ball will only bounce at a few pre-determined angles, as letting it bounce freely would result in the ball always getting lost, particularly since the blocks aren’t of uniform shape and they don’t fully encircle the central heart.

Additionally, there was no way to add multiple concentric circles to the game, so it always operates on a single ring. I would very much like the game to have up to three or four rings at a time, as in the original Unity3D version.

Finally, I always intended the game to be a musical arcade game, but having background music wasn’t feasible with the 4 kilobyte size limit of the 2600’s ROM. I would like to bring a musical quality back into the game, with the heartbeat matching the tempo of the current soundtrack, rather than set to a steady, heart-beating sound effect.

On top of all that, I’d also like to bring the game to a mobile setting, which I think would fit the gameplay very well, being a sort of casual game that works best in just a few moments played at a time. This would, of course, mean reconsidering the control scheme. I would like a simple swipe gesture to allow the ring to spin, perhaps with a simple tap used to set the ball’s current color to the color displayed by the heart.

On the other hand, I may modify that mechanic so that the heart does not change colors on its own, but instead must be tapped by the player in order to change the ball’s color. Or maybe the heart and ball always share the same color and, rather than tapping at the right moment to get the right color on the ball, the player would need to tap the heart to swap between its colors? We’ll see.

While I’m at it, I’d like to update the game’s visual style, maybe moving away from the direct pixel-art look into something a bit cleaner. And, who knows–if I find the time, maybe I’ll try implementing some kind of power-up system, similar to Arkanoid. I may have an idea of how it could work.

Now it’s (finally) time to get to started!

GameMaker and Why I Chose It

Posted by
Friday, November 29th, 2013 12:58 pm

Ah, it’s good to be doing a Dare again, even if this is just a mini-Dare.

Since my first LD, which was completed using Visual Batari Basic in order to create a game that runs natively on the Atari 2600, I’ve been experimenting with various engines and frameworks, including Construct 2, Loom, OpenFL/HaxePunk, LOVE, and, most recently, GameMaker.

I tried learning each of these engines by re-creating a Pony-clone of Tapper that a friend of mine made, since he gave me the already-made assets to ease development. Although progress has been slow because I’m sick of re-making the same game over and over, my experience with the engines was as follows:

Construct 2: Although I felt a bit patronized by the drag-and-drop coding interface, it did help to simplify the coding. In the end, I built in all the core functionality, but lost interest with Construct 2 when I attempted to export my game to mobile. Unlike Loom, OpenFL, and GameMaker, there is no direct push to mobile option, and instead I was just given a folder of assets that I’d need to manually compile using Cocoon Launcher… which never worked for me.

So I gave up on C2 pretty fast, though I can see the appeal of it for beginners who are looking to make games on Windows/Mac/Linux or HTML5. It compiled to those platforms very easily.

Loom: This engine was recommended by one of my game professors, as it’s a relatively new engine that is built for rapid app development, which is great because I was looking to make the game on mobile. The down-side is that the documentation for Loom is very sparse. For those familiar with ActionScript 3, LoomScript is heavily based on it, so I’m sure it would be a snap.

Unfortunately, I don’t know ActionScript 3, so I found it very frustrating to learn a language from scratch with little more than a handful of basic, outdated examples and an outdated API (because LoomScript is updating so quickly, much of the documentation is out of date). It was very good at live development on mobile, though. I just never got beyond building my game’s title screen.

OpenFL/HaxePunk: Initially, I was excited for this, as I saw it as an alternative to Loom. It’s a much more mature engine with better documentation and, while it doesn’t have live update like Loom does, it pushes to mobile just fine. Unfortunately, the language barrier of me not knowing ActionScript 3 again became an issue when I began to hit the limits of the tutorials and examples.

Unlike Construct 2 and Loom, HaxePunk can boast Papers, Please as a commercial product created using it. Once again, I didn’t get far beyond building a title screen before moving on to something else. As with Loom, I’d recommend it for those who are already familiar with making games in Flash, as I’m sure it’ll be fairly easy to pick up.

LOVE: This was my first time trying to program in Lua. Prior to this, my programming experience was only with C and a tiny bit of C++ (which I am currently taking a college course on). I immediately liked Lua’s dynamically-typed language and the flexibility of it. Tables are awesome! The only issue is that LOVE itself is very much a framework. I think it would be perfect for certain kinds of games, or for those who have experience with Lua. I, being a newbie to the language, had to rely heavily on plug-ins and additional frameworks to support animated sprites, object-oriented classes, and collision detection, which the engine does not come pre-packaged with (not completely true, as it does come with Box2D, but I didn’t require that level of a physics engine).

I got most of the framework of my Tapper clone built in Lua, but I was already nearing 650 lines of code by that point, just having laid the foundation for the game itself, but with no actual gameplay or levels implemented. On top of all that, LOVE does not have native support for HTML5 or mobile, and the plug-in support for both those platforms has been halted for at least a couple years.

In the end, I enjoyed LOVE, but I found making a game of this type from the ground-up to be frustrating. I think that I will return to LOVE if I ever have a game intended for desktop platforms that doesn’t rely much on object-oriented, but not until then.

GameMaker: It’s ironic that GameMaker was the first engine that I was ever introduced to, and yet the last I came back to. I never really did any programming to speak of (unless you count one mandatory C course and HTML/CSS) until I had an interest sparked by last year’s Game Jam. I wasn’t on as a programmer, but an artist (more because I knew nothing about programming, rather than because I was particularly adept at art). The game that I will be remaking, Heartbreak, was more one that I designed, rather than “made” per se, but it’s still the first (and only, unless you count Atari 2600 mini-games) original game that I’ve made, so it will be my focus of this Mini-Dare.

When I first designed Heartbreak for the 2013 Game Jam, I had a couple “programmers” who claimed to be decent in GameMaker. The first day of the Game Jam consisted of me designing the game’s mechanics in my head while I worked on simple (very simple) pixel art to build the game in GameMaker. I knew nothing of the engine at the time, but after an entire day of the programmers surfing the web and allegedly looking up tutorials, they claimed that the game simply could not be made in GameMaker. Since I had no experience with the engine, I was frustrated by this news. Luckily for me, another programmer stepped into the group at the eleventh hour to make the game in Unity.

With my sense of GameMaker having “failed” me, I begrudgingly avoided it as a useless prototyping tool that couldn’t make anything really “serious.” After trying all these other engines and frameworks, I find myself crawling back to GameMaker like the prodigal son. I’m aware that it still has problems, such as being very inefficient with its resources (according to the bitter folks over at the #GMC GameMaker IRC room), but I can’t sneeze at an engine that has been used to make awesome games like Spelunky, Hotline Miami, and, most recently, Hyper Light Drifter. If it’s good enough for games like that, it’s good enough for me.

In giving GameMaker a chance (I’ve been fiddling in it for about a week or two, whenever I can muster up the energy to go back to the Tapper clone that I’ve remade so many times, I hate its guts), I’m immediately drawn to how much it simplifies the organization of game code. I feel like I’m scripting more than “programming” per se… and I like it.

GML is very similar to C and it hides the annoying Java/ActionScript 3-inspired object oriented faffing that I had to deal with in Loom or OpenFL. Code is organized into easily-managed blocks within objects that are called from basic events, keeping it nicely organized into manageable scripts rather than giving me a 600-line file of code to just lay the groundwork for things. On top of all that, it has tons of tutorials, plug-ins, and shaders available online, AND it can push to mobile with the press of a button (if you have the Pro version, like I do).

I know that it’s not an end-all solution, but I think that it’s a great place to start, and even though I’ve only actually programmed in it for a whopping total of 10 or 12 hours at the most, I feel confident enough to try remaking Heartbreak in it, which is more than I can say for any of the other afore-mentioned engines and frameworks, aside from maybe Construct 2. The downside of C2, though, is the entire lack of the ability to write code. It forces the user to rely on its drag-and-drop system which, while powerful enough for basic game types, takes a lot longer than just writing raw code, lacks a lot of the flexibility of plain code, and it’s a pain to organize once the event sheet starts to get long.

I’m sure that someone with more programming experience will look down my choice of GameMaker, but I’ll say that I’ve only actually been programming for about six to nine months, and most of that was in a non-object-oriented language. The entirety of my non-Assembly/BASIC programming experience has come in the past two months, or so. I have to start somewhere.

Although this post was long-winded, I hope that some find it interesting or helpful in their own selection of an engine. Now to write a post about Heartbreak and why I am remaking it. Maybe after all this blogging, I’ll even have a little time left to make a game. Maybe.

GameMaker n00b? Level up!

Posted by (twitter: @csanyk)
Wednesday, April 24th, 2013 1:56 pm

Book for GameMaker Studio developers

Posted by (twitter: @csanyk)
Tuesday, April 23rd, 2013 4:45 pm

Hello, Ludumaries!

Those of you who use GameMaker Studio may be interested in a new book that was just published today by Packt Publishing. I provided technical review for the manuscript of HTML5 Game Development with GameMaker, and it will be useful for the beginner and intermediate GameMaker developer.

Much of the book is applicable for general GameMaker development, not specific to the HTML5 build target.  If you pick up a copy, please drop me a note and let me know what you thought.  While I’m not the author, I’m still interested in your feedback.

Bad Puppy: Tonight’s post-compo enhancements

Posted by (twitter: @csanyk)
Monday, December 17th, 2012 9:52 pm

Play Bad Puppy!

  1. Random sweater colors.
  2. Multi-barking.

These are just aesthetic enhancements, and do not affect gameplay at all from the previous post-compo build.

Bad Puppy: Postmortem

Posted by (twitter: @csanyk)
Sunday, December 16th, 2012 4:54 pm

Bad Puppy by Chris Sanyk for Ludum Dare 25: You are the villain

I think this one ended up coming together ok.  It’s not much of a game, but I was able to turn it into something at least playable in the last couple hours.

This was originally going to be called Puppy Hitler, but I ended up changing course, and spent most of Saturday in a reflective headspace, thinking about the decision, and as a result I was not very creative or productive on Saturday.

What worked:

  1. Humor: I think I had decent humor in this game.  The title screen and endgame are good.
  2. Animation:really like the animation for the petting and wagging dog.  I like the color effect I pulled off on the score.
  3. Sounds: I used Audacity and a bit crusher filter to do voice samples that hopefully sound like 8-bit voice chip synthesis.  This was used for the bark and the “Baaad Puppyyyyyyy!” and the panting and the “Good boy!” sounds.  I think the only sound I created with bfxr was for the Start screen when you press Enter to start the game.

What didn’t:

  1. Humor: I thought my original “Puppy Hitler” concept was funny, and I still kindof do, but I can appreciate that it’s not the sort of humor that everyone would like, understand, or appreciate.
  2. Animation: The walk animation for the person character is passable, but I’m not happy with it.  I had a very hard time creating an even halfway decent walk animation, and worked on this a ridiculous number of hours that I don’t even want to think about on Saturday, and scrapped.
  3. Music: I was going to try to do some kind of music, but I had no idea what kind of music would create the right mood.  It feels like something is missing, just a little, without any music, but I think the other elements still work to create a silly mood.
  4. Gameplay:  It’s a pretty shallow game with not a lot of replayvalue.  Still, it was pretty fun to make it, and once I got past the point of having a test level, and actually implemented the (admittedly quite rudimentary) AI, it became fun pretty quickly.

My base code declaration

Posted by (twitter: @csanyk)
Friday, December 14th, 2012 4:25 pm

Such as it is.  I didn’t have as much time this week as I hoped, didn’t build very much, didn’t finish, didn’t test, so don’t expect much.  I’m only declaring it because I intend to add to it as I work this weekend, and will be including what little is here in my project.

[cache: storing page]