About Cybearg


Ludum Dare 28
MiniLD 47
Ludum Dare 26

Cybearg's Trophies

Cybearg's Archive

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.

Better Game – Knight Game 2600

Posted by
Sunday, April 28th, 2013 7:59 pm

I came up with another game. It’s better than the first one.

Knight Game 2600


Download It Now!

Note: This is a real 2600 game, which means you’ll need a real 2600 emulator like Stella to play it.

Ping – Game Complete!

Posted by
Sunday, April 28th, 2013 1:05 pm


PlaySourceAtariAge – Game Page
Note: Requires an emulator like Stella to play on computers.


For a small bat like Ping, the world is a big, dangerous place. Will little Ping make it in her new home?


Move using joystick (arrow keys or mouse with Stella), ping using echolocation with joystick fire (spacebar or left mouse click in Stella).

Pinging costs 25 points. You gain points by making progress to the right and by eating bugs. Try to ping as few times as possible to maximize your score.

Avoid owls and walls, eat bugs, and get as far as you can!


Supports AtariVox high score saving. Requires an AtariVox/SaveKey module to be plugged in to controller port 2 (or emulated in Stella).

Clear your AtariVox high score for Ping with select + joystick fire while in game.

Mute the pinging sound by setting Color/BW to BW (F4 in Stella).

Have fun!


Posted by
Sunday, April 28th, 2013 10:35 am

Well, the game’s done. Time for polishing! I’ll be adding an intro cutscene (hopefully I’ll have enough space–I’m down to ~340 bytes left) and have already added AtariVox/SaveKey high score saving support. And on top of all that, the nice folks at AtariAge pointed out what that bug was. Evidently, I need a bit of code to account for the length of my game, see below:

if ( (<(*+7))
repeat ($100-<*)
.byte 0

Hopefully getting that help won’t disqualify me for anything.

Oh, and I decided on the game’s name. Initially, I was going to call it “Batty,” but instead I settled on “Ping.”

Excellent Progress – Also Bugs

Posted by
Saturday, April 27th, 2013 11:44 pm

I’m very pleased with where I’m at. I just need to add sound effects and see what I can do in the way of a title screen (if I can’t do much there, I’m not too worried). The game works and has enough randomization to keep it interesting for a little while.

In the video, you can see the bug. Specifically, it’s a bug bug. The insects (which are power-ups that give you a life, some points, and a free echolocation pulse) seem to screw up the playfield when they’re around, though I have no clue why. I’ve had the same issue earlier, but with the owls (enemies). Somehow, it went away for the owls and was doing fine, but now it popped up again. There must be some bug in the standard kernel. I’ll be leaving a tech support call on the AtariAge.com forums and hopefully someone can tell me what the issue is before the game is due.

If not, I suppose I can live with it.

Well, that’s a wrap for tonight!

Sprite Woes

Posted by
Saturday, April 27th, 2013 5:42 pm

Since, without some Assembly wizardry that the standard batari basic kernel does not allow for, the Atari 2600 only has two–count ’em, two–sprites available, I’ve been spending the past few hours fighting to find a way to fake up to three with flickering, but in the end, I gave up because of all the trouble with collisions on a flickered sprite. It’s just a mess.

So I’m rolling back to the last fully working version (as seen in the video in my previous post) and I’ll go at this again, but this time with the intent to only have ONE possible sprite on screen at once, either an enemy (an owl) or a power-up (an insect).

If I hadn’t spent so much time trying to get two sprites on screen at once, I’d probably be done with the game by now. Ah, well–still plenty of time left!


Posted by
Saturday, April 27th, 2013 11:08 am

I’ve got 16 playfields that are randomly swapped between. It’s going well so far, I think. It’s playable and even kind of fun. It definitely needs some balancing and I’ll need to do something about the score, which seems to sometimes break during pulses.

But next thing is to add randomly-spawned enemies/power-ups. I’ll probably just set two or four possible spawn locations per each level, since making it completely random could result in a lot of mess.

Demo video (wish I knew how to embed these just use embed in brackets, apparently):

Oh, 6502 Assembly…

Posted by
Saturday, April 27th, 2013 8:20 am

So after banging away at the keyboard for an hour or so, trying to elegantly create a routine in Assembly that would, based on a randomize index, load the appropriate cave playfield through a series of data sets, I ended up getting it to work with a simple on…goto command. It’s a bit less elegant code-wise, since there will be a bit more redundancy for each new cave playfield added, though I suppose it’s actually fairly negligible.  An extra 9-10 bytes or so, but I’ll take that if it means that it will work.

So now the game will set a random cave for the playfield and keep it until the player reaches the far right wall, at which point it picks another random playfield. I added a variable to remember which the index of the last cave is so the player never plays the same cave twice in a row.

Now time to crank out n^2 playfields for some variety!

I’ve been pondering the intention to use a ball to bounce around as part of the pulse. Considering how much code it would take to make the ball bounce in a useful way (I’d have to monitor which of the 8 directions the player was facing, then copy it to a variable for the ball, then randomize an inverted direction based on the ball’s current trajectory when a collision occurs), I may just stick with the visual pulse. The effect is pretty nice and it’s challenging. I don’t know think that the bouncing ball would really add anything.

So I just need to finish up these playfields and then add in something for randomized, moving enemies to add some extra challenge now and then. This game may well fit in a 2k cartridge, as I have 2076 bytes to spare but haven’t even used a custom include to cut out all the unnecessary assembly routines that I won’t be using, like playfield drawing.

Signing Off

Posted by
Saturday, April 27th, 2013 1:31 am

I’ve made some great progress and I’m satisfied with where I am for now. I think it’s time to hit the hay.

After some testing, I realized that, although randomized, the same patterns seemed to show up over and over, even when running on a real Atari 2600 (courtesy of a Harmony cartridge). So even if I had a means of randomizing a semi-decent cave, it would appear more pattern-based than any designed cave.

In short, instead of scrolling the playfield at the mid-way point as initially intended, I’ll allow the player to hit the far right wall and will then load in a random map and set the player sprite back to the far left side. It doesn’t have the visual elegance of a constantly scrolling background, but there was something I neglected to consider:

Each of the playfield blocks are 4 pixels wide, so they can’t smoothly scroll in. Either I wait 2-4 loops before bringing in a new playfield block (which means the player’s sprite would just be hovering statically in the center of the screen until then) or the playfield will scroll by too fast for one to reasonably be expected to react.

At least the use of multiple playfields solves that problem. I’ll need to make up a couple dozen modular sections that can be randomly fit together. Hopefully the modularity doesn’t become distractingly noticeable.

Ah, well. That’ll be for tomorrow! Then, once I have playfields loading in correctly, I’ll finish the bouncing missile part of the echolocation and add in random enemies to mix things up a bit.


Posted by
Saturday, April 27th, 2013 12:44 am

So this is what a randomized playfield looks like:


I think that I’ll need to stick to pre-made playfields unless I can come up with a really clever way to make the game randomize cave-looking areas with enough space to maneuver so its’ not completely unfair like this.

The upside of having the stages pre-planned is that they’ll generally be of higher quality because they were intentionally designed to be a certain way. The downside, of course, is that they come to an end, and so does the game.

In a Flash

Posted by
Friday, April 26th, 2013 11:33 pm

So, currently the player could spend all their points on sonic pulses and then fly left and right again to gain back any loss within that window. I’m not sure if this could be considered an exploit or not. To prevent it, I’d have to monitor continued player progress and only award points for new pixels explored, but that means a running tally. While that is impractical for a single byte, since one could get to 255 within just two screens, using two bytes would fix that exploit. For now, I think I’ll leave it as is, to see where it goes. The advantage of being able to grab some 30 or so points by flying back and forth is negated by a little addition that subtracts points when you fly backwards.

The lives and pulse all work. Now to take a bite out of the tough part: the Assembly to scroll the playfield and create randomized caves. If I can’t find a good way to build challenging caves randomly, I’ll have to design ’em. I would prefer randomization, since it allows for infinite replayability.

Once I get the Assembly working, I’ll need to add in the bouncing ball, which may take a bit of a trick as well. Hopefully I don’t start overdrawing cycles. The game logic is pretty simple so far (or so it seems), but the Assembly routines to scroll the playfield can gobble up cycles fast.

At least debug cyclescore reports I’m never going under 2300 remaining cycles, so I should be in the clear.


Time to stretch my legs a bit!


Posted by
Friday, April 26th, 2013 11:03 pm

I added a life system using pfscore1. Currently it doesn’t really do much, but I’ve set up the movement so that a collision with the playfield (based on the ball, which is in the center of the player sprite and rendered in the layer below so it’s not visible) causes the playfield to turn red and the player loses one life of three.

A bit it set to ensure that the player doesn’t continually lose lives. This means that a player could “abuse” the system by hanging on a wall to memorize the layout of a screen, but since that knowledge will only help them until they’ve gotten to the edge of the screen, I don’t consider it a problem. If the player really wants to make that sacrifice, why not?



I got around the loss of missile0 by having player 1 (the second player) be the player that is actually being controlled. This should work fine, since there will only be a single enemy on screen a a time, and it can just as well be player0 as it could have been player1, but since the enemy won’t have any attack, there’s no real cost in losing missile0. Thinking outside the box. :)


Posted by
Friday, April 26th, 2013 10:31 pm

Note to self: don’t use spaces before/after the equals sign in a def statement.

Also, for some reason, batari basic doesn’t like me to use the name “pulse” on its own. *shrug*

Anyway, got the basic pulse working. It fades the playfield (currently set and not randomly generated yet) to an increasing color, then fades back out to black. I’m using the standard batari basic kernel, since I’ll need working collision detection.



I may invest in no_blank_lines, though if I recall, that may mean losing my missile 0, which is out of the question. May just have to deal with those obvious batari basic lines.


Posted by
Friday, April 26th, 2013 9:58 pm

At first, I was going to try making a game in Gamemaker. I set it up to create different shapes of random colors, but I abandoned the idea I had been going for since I don’t know Gamemaker well enough to confidently spend time building a full game in it yet.


I’ve instead decided to do a game for the Atari 2600, since that is where my experience lies.

The theme is “minimalism,” so I was thinking of what would be fitting. I decided on a game where the player is a bat and needs to navigate invisible tunnels using echolocation.

I have a couple ideas for how echolocation could work. Either the playfield pulses a visible color for a split second or the player shoots out a missile in whatever direction (s)he is facing, the missile bouncing and growing darker with each bounce until it vanishes, like a sound pulse.

Though, as I ponder it more, I think that I may do a combination of the two. An attempt at paper prototyping proved that I have a very poor memory and I don’t want it to be too difficult to be fun.

Hitting the trigger will release the pulse. Each pulse will reduce the player’s points by a certain amount, while moving towards the randomly-generated cave to the right will score constant points. So the idea is to balance pulses against blind movement to create an overall point surplus. Balancing may be difficult. There will likely eventually be enemies that move around and must be avoided. Hitting the walls or enemies will lose a point of health out of three. There may be some way to regain a point of health after a certain number of points or for some kind of pick-up (that can only be seen with the echolocation pulse).

Programming progess is nil for the time being. Since I’m already three hours in, I need to get crackin’. Here’s the bat sprite against a blank playfield:


[cache: storing page]