video games, programming, the internet, and stuff

Category: games

Game design evolution during the cartridge era of consoles

Someone asked a question on the AtariAge facebook community:

For those of you that grew up on the 2600, you know that the system was constantly improving.

Did you ever look for any benchmarks in games, improvements that let you know the “next big step” had occurred?

For me, I always thought that games with any sort of text were huge back in the day (like the Activision logo at the bottom of the screen), as were multi-segmented, multi-colored humanoids in games (such as Pitfall Harry).

This became very important for playground bragging rights as the Intellivision became more and more popular and us VCS acolytes had to ‘defend’ our system.

As a kid, were there any big “steps” you guys used to look for in your 2600 games to know Atari had reached its next level?

This is an interesting question.

I got an Atari 2600 when I was in first grade, in 1981. By that time the console had been out for 4 years already. We played it until the Atari 7800 came out, in 1986, but then switched over to NES, about a year later.

There wasn’t much in the way of a “bragging rights” war on the playground where I grew up.

Most kids who had any video game system at all had an Atari 2600, and we were happy to have them. I think many of us didn’t have anything (apart from arcade coin-ops) to compare with. I knew one or perhaps two family friends who had an Intellivision, and one family friend who had a Colecovision. I knew a lot of kids who didn’t have any videogame console at home. And I knew a few kids who had a home computer of some type (PC, Apple ][, Commodore 64, Atari 8-bit).

And some kids just had those little handheld LED games made by companies like Coleco, that weren’t quite videogames, but pretended to be.

We played all of them, although the LED handhelds were obviously inferior, and we grew tired of them quickly. Everyone just thought that video games were cool and fun, and we didn’t pay much attention at all to whether one system had better graphics. It was enough that it existed at all, and if it was available, we played it as much as we could.

The Intellivision households had a console that offered better graphics, but had awkward controllers and a smaller library. Colecovision had the Atari 2600 adapter and slightly less awkward controls compared to the INTV, but still a far cry from the simple, rugged Atari 2600 joystick. It also had a 10-second delay when booting, which we found annoying. We maybe noticed that the graphics were a bit better, but overall it didn’t matter as much as you might think. Graphics were important, but gameplay was by far the most important quality.

And of course we were well aware that the original arcade game always had much better graphics than an Atari 2600 port of the same title. That was understood, to be expected, and forgiven, most of the time (Pac Man and Donkey Kong not so much). But also the arcade games were harder, and were designed to suck quarters out of our pocket, while Atari games were designed to be challenging without being too frustrating, and to give hours of enjoyable play.

Bottom line: If a game was fun, it didn’t matter if it didn’t have the best graphics, but a game with amazing graphics that wasn’t fun to play was something we looked down upon. This has always been true, and always will.

Since the 2600 had been out a few years before my family got ours, I wasn’t all that aware of the release date of different games. Games existed, and when I learned about them for the first time I wasn’t even thinking about whether the game had just come out, or if it had been out for a while, and I had only just heard of it. Games existed; they just were.

I paid a bit more attention to publishers, and liked games by Atari, Activision, Imagic, and M-Network, and Parker Bros. the most. But even the publisher didn’t matter so much as the quality of the game. I would play anything and everything I could get my hands on, and continued to play what I liked, and returned to re-play games that I enjoyed frequently.

That said, we did take note of certain games that seemed to evolve through sequels, such as Pac Man > Ms. Pac Man > Junior Pac Man, Defender > Stargate, and Pitfall > Pitfall II.

Sure, some games did have poorer graphics, or simpler play, or just sucked, but aside from the direct sequels where it was obvious, we weren’t all that aware that one game was older or newer, or that one game had extra chips inside the cartridge that enhanced the circuitry inside the console. That was something that I learned about much later, when I was old enough to appreciate the technology and understand it a bit better.

But for the most part I didn’t think of game technology improving over time, I just thought “Hey this game is better” or “They really packed a lot into this game” or “This game is very sophisticated compared to that game.” In other words, to me it felt more either a design choice to make a game more or less sophisticated, or a matter of the developer’s skill or work ethic to make a game better or worse, than what the technology allowed.

It only became apparent to me that newer hardware could do stuff that simply wasn’t possible on older hardware when the Atari 5200 came out. I don’t remember when I first played the 5200, but my cousin had one, and I got to play on it a number of times when we’d go over to visit. He was the only kid I knew who had one, and its graphics were amazing compared to the 2600, but again the library was limited and the controllers weren’t as good as the 2600’s joystick. We speculated at the time that the 5200 games could have better graphics because the cartridges were physically bulkier, but the reality was this had nothing to do with it. Although, reinforcing this errant belief, NES cartridges also were bulkier, and had better quality games overall. We would have been very surprised back in the day to see just how much empty space was inside those plastic shells.

It still didn’t occur to me that there could be extra chips inside certain carts that made them capable of more sophisticated graphics and game play within the Atari 2600 library. It was certainly one of the factors that enabled a popular, older 2600 to continue to stay relevant in the market years after newer consoles had been introduced. But it wasn’t like we knew why the games that came out in 1982-84 often had better graphics than games that came out in 1977-81; we just knew they were good games and it seemed like maybe the developers were getting better at making them as time went on, but it wasn’t like the best of the old games weren’t still great. And there was certainly a lot of titles that were released on the 2600 late in its life cycle that were inferior to games that had been released years earlier. What was possible continued to improve over time, but actual quality varied quite a bit over the life span of the system, and seemed to have more to do with how much the developer cared (or had budget for) than with the year the game was produced in.

When the 7800 came out, we felt that it was the best Atari to have, as it had backward compatibility with the old 2600 library (that was still every bit worth playing) plus decent joysticks (at least they centered automatically!)

Of course when the NES came out, it was obvious immediately that it was a quantum leap over even the 7800, due to its vastly superior sound capability, which allowed all games to have a musical soundtrack to it that could not be equaled on any Atari console. At first I didn’t care for the NES gamepad, which didn’t have a joystick, but instead featured this odd thumb-cross we didn’t yet know to call a D-pad, which at first I found very uncomfortable and even painful to use, although my hands quickly adapted and got used to it. Again, the quality of the game play was what hooked me and got me to play through the hand cramps and blisters until my hands developed the stamina to hold the uncomfortable little rectangle. NES games didn’t just offer superior graphics and music, but more sophisticated types of play, where exploring and adventure became the dominant style of play, ascending to on par with twitchy hand-eye coordination skill and action. When the NES came out, everyone knew that a new age had dawned, and that the venerable Atari was obsolete. Most of us moved on, but a few never forgot.

Nintendo announces Switch launch date, price

Yesterday, Nintendo had their big announcement about their new console, Switch. It will be $299 on March 3, region free, online play will be paid, launch titles have been announced. The Joy-con controllers are more sophisticated than initially shown in the teaser video Nintendo released a few months ago. Joy-con have motion control and “HD” vibration features, and even a camera on the right side. Onboard there’s only 32GB of storage, which is expandable with SDHC the built-in screen is “only” 720p (which to be fair is plenty on a handheld screen, and should help with battery life to a degree) but does support touch.

The new Zelda title looks amazing. New Zeldas always do, but this one really does look very impressive. The new Mario looks a bit weird, like they put Mario in a GTA world, or that Halloween episode of the Simpsons from years ago, where Homer went through some dimensional warp and ended up in the 3D world. But also amazing. It won’t be out until later this year, unfortunately. There will be other sequels — surprised? Splatoon 2 is happening, as expected. Mario Kart 8 is being revised somehow and brought along for the Switch. Surprisingly, no word on whether Super Mario Maker is going to be ported as well. It really should be.

The biggest criticisms of the announced launch titles are how few they are, and that not enough Big Names have been announced. It seems Nintendo may be playing a game to maximize sales by spacing out their major releases so that each gets full attention.

I have some new questions. Because the Switch hardware is so reconfigurable and flexible, how will games adapt to it? Will Switch games be designed with the intent that the Switch be in one particular configuration in order to play them? Or will they have multiple modes, which can be played depending on which configuration you have your Switch in at the moment? I imagine it will probably be a bit of both. Although, if it drives costs up to make the software flexible enough to handle whichever mode the Switch is currently in, that could end up backfiring as developers target one specific mode only per title. How will supporting all of these different modes with one game work for developers?

There’s been a certain amount of WTF and ridicule following the announcement among Nintendo naysayers. Accessories for the Switch seem to be pricey. Over the last few months, since the initial announcement, there’s been a considerable amount of second-guessing among gamers. Initially the Switch seemed very exciting and innovative, a do-it-all, go-anywhere console with loads of innovative features and potential, but that initial impression wore off quickly as gamers wondered just how good the graphics and battery life would be, and what sort of capability the hardware would have relative to the competition.

Does Switch offer enough to get me to buy one? Maybe… Zelda: Breath of the Wild is the most attractive draw to the new console for me, by far. If they had Super Mario Maker, and maybe a new 2D Metroid game, that might be all it takes for me to put it on my want list. Hmm, how about a Super Metroid Maker? Or Mega Man Maker? Or literally any 8-bit franchise maker for that matter? I’d buy Switch in a heartbeat if they had something like that in the works. The small number of titles at launch isn’t that small, although the number of games that actually interest me is.

That’s a concern, but I’ve rarely been an early adopter when it comes to videogame consoles. My first console, the Atari 2600 had been out for several years before I was old enough that my parents bought one. I had no input into that decision, but it was a happy one. I think we got our NES in 1987, after a year of the Atari 7800, maybe we got a SNES the year it came out, the N64 came out when I was in college and my brother had one but I didn’t play it all that much compared to when I had free time.

I wouldn’t have bought myself a GameCube, which came out when I was probably the least interested in videogames that I’ve ever been in my life, but I received one for Christmas one year, 2002 or 03, I think, and didn’t buy a Wii until they stopped instantly selling out of stores…

I still haven’t, and likely won’t, buy a Wii U, ever, despite how much I’d like to play with Mario Maker.

And while I thought the Switch had an exciting design when I saw the trailer video for it a few months ago, I don’t feel all that excited about it. It’s capability as a mobile game platform doesn’t do anything for me — I’ve never been into mobile gaming. Its reconfigurable controllers are clever, but I don’t know that they truly offer anything new. And the multiplayer aspect, which seems to be another big part of Switch’s appeal, doesn’t do much for me, because I’ve always been more of a solitary gamer. For much the same reason, I haven’t been very into network games, either.

I just haven’t found much compelling about AAA games, really, for many years. A few exceptions, to be sure, but probably not even 1/year. I’m pretty deeply rooted in the old school, you might say. These days, I’m much more into retro-styled indie games, like Shovel Knight, Hyper Light Drifter, and Daniel Linssen’s brilliant Ludum Dare platformers, and classic 8- and 16-bit era games.

These days, I find I just don’t care as much for 3D games, analog joysticks, and voice acting and cutscenes in videogames. These things can be done well, but are so hard to do well, and age so poorly, compared to 2D games with low-res graphics, which seem timeless. Truthfully, most modern 3D games either feel crude and lacking in polish, or else cookie-cutter affairs lacking in soul, offering little that their predecessor didn’t also.

As such, I don’t feel that Switch is necessarily aimed at me. That’s fine. I’m pretty niche in my interests, and am served well by my existing library, as well as by the indie market. And I don’t know that that’s a miss on Nintendo’s part. I expect that if the exclusive titles are there, Switch will be a hit. But if Nintendo don’t get a lot of great first-party hits, and attract a strong lineup of 3rd party developers to release games on their platform, it could be a repeat of the Wii U.

I fully admit I know nothing about videogames as a business. I really liked the Ouya, and I still do. Time will tell.

Getting ready for Game Jam Weekend, part 2

Take inventory

Ahead of the weekend, it’s good to take a personal inventory. Conceptually, I like to break this into three main areas: Skills, Tools, and Supplies.


Skills are your personal abilities, your strengths that you will bring to the project. Are you a good designer of rules and systems? A good programmer? Visual artist? Audio designer? If you don’t really know what your strengths are, it’s time to reflect on what your capabilities are, and think about how they might be applied to the project. Even if you think you know what you’re good at, or what you’re going to be doing, it’s good to review everything you know how to do, just in case you might have overlooked something or taken it for granted.

Really, just about any skill can be useful in game development. It’s not just design, programming, art, audio, and project management. Things like math, physics, psychology, humor, and acting are all important skills that have obvious application to different parts of game development. Be open minded and creative, and ask your friends what they think you’re good at or what your strengths are. You might be surprised by what they see, that you wouldn’t have thought of.


What are you working with? If it’s equipment, get it all together before jam weekend and make sure it’s in good working order, that any cables or accessories that you need are not lost, and so on. Musical instruments, microphones, game controllers, and any other hardware that you can think of should be on a list, and packed up ahead of the Jam weekened. Do you need batteries? Are they charged? Do you have enough of them?

If it’s software, check for updates and make sure it’s installed and launches, that the license is activated, and so on.

Are there other things you can set up ahead of time, like your version control repository, project website, mailing lists, etc? Get it together ahead of time.


Supplies are things that you’re going to need for the weekend that are consumable. Things like food, sleeping bag/blanket and pillow, toilet paper, etc. Or things like paper, pens/pencils/markers, and post-it notes. Or game pieces like dice, pawns, cards, and so on.

Make a list, and get everything together ahead of time. If you’re running around last minute, you’re going to forget something, and at the very least you’ll be more stressed out than you would be otherwise. Preparing everything ahead of time means you can relax, clear your mind, and focus on having a productive weekend.

Set goals

Although I said in my previous article that you should approach your physioligical preparation for Jam Weekend like you’re gearing up for an intense athletic competition, a Game Jam really isn’t a competition. The experience is what matters, not just the outcome. Failing is fine! It’s only a weekend, and part of the reason it’s only a weekend is to set the stakes low enough to allow you to take risks. So take them! Do something that might not work, or that you’re not good at, or that you haven’t tried before.

My first Global Game Jam, I wanted to simply complete a project in a weekend that was playable. I didn’t care how good or bad it was, although obviously I wanted to put my best effort into the project, and did. But my main goal was to have something to show for the weekend that I could call “finished” and show to others. That was a fine goal to have.

But there are other goals that you could have. And it’s entirely up to you what those are. Just think about them, and let them guide you. Your goal could be to work with or learn about a specific tool or technique that you have never used before. Or you could make your goal be to make the best game you know how to make, and so focus on execution rather than learning or experimentation, sticking with what you know and what you do well, and simply be as productive at what you’re already good at as you possibly can.

Your goal could be to focus on team work and collaboration, or on being a good project planner/coordinator. Or your goal could be to have a good time, or to ensure that someone else has a good time with their first jam experience, by creating a positive atmosphere and giving encouragement. Maybe your goal is just to find out whether this is something you can really do.

There are many, many dimensions to a game jam, and you can set goals respective to any of them. It doesn’t matter what your goals are, it matters that you have them.


I see basically three approaches to participating on a project: solo, on a team, or as a freelancer.

Solo developers, do everything for their project themselves. This works well if you’re well rounded enough in your skills inventory to handle everything yourself. But most people are strongest in one or two skill areas, and are weaker or nonexistent in other areas. It can be limiting to work alone, or it can be liberating. But it all falls to you.

A Freelancer is a jammer who focuses on a particular skill, and provides services to as many teams as need it. This often works well for musicians or artists. Rather than remaining a dedicated resource for a single team, they will work on several projects. This keeps them busier than they might otherwise be. Oftentimes the artists are idle in the early stages of a project, prior to the game design being at a point where it’s ready for the artists to start working on things. And often they can finish the assets for a game quickly, and then have little else to do, and so are able to provide assistance to other projects.

Teams are when a group of people work together on a project. If you’re teaming, either you’re aware ahead of time who you plan to work with, or you’re not.

If you know your team members ahead of time, that’s great, because you can plan and coordinate and prepare ahead of the jam. Just knowing what your capabilities and skill levels are helps, but it’s also good to know what your goals and tastes are. Get together and go over your skill and tool inventories and figure out what your team’s strengths, weaknesses, goals, and interests are.

Get an idea of what role each team member will play, and then each team member can focus their preparation more narrowly in support of that role. If you have more than one programmer, make sure they’re on the same version of the tools that you’re using, and that you all have access to the version control repository that you’re using. Pre-jam is a great time to do stuff like set up your web site, your version control repository, Trello boards, Slack channels, and so on. Make sure that everyone on the team has access to any common tools that they will need to function on the team, and that they have at least some familiarity with them.

If you don’t know who you’ll be working with, and just go into the weekend intending to work with whomever has an interesting project and needs help, you can still prepare by getting to know the people who’re going to be at your jam site ahead of time. Make friends, and see who you might feel like you can work well with.

You can also prepare inwardly, too, and work on your presentation skills, and social skills. Practice pitching ideas, focusing on being brief, interesting, and persuasive. It can be hard to articulate ideas and explain them to other people, but practicing doing that can help.

A good exercise is to think of a game that is familiar to you and that you like, and describe it in less than a minute to someone who has never seen the game before in a way that would give them an understanding of the game and make them want to play it. Or focus on one aspect of a game and explain why it is successful at what it does. Being able to clearly describe a thing that does not yet exist is a critical skill in the early stages of developing a game. If you can do this clearly, succinctly, and compellingly, it’s more likely that you’ll be able to get others on board and aligned with your ideas.

It’s equally important to be good at listening to the good ideas of others, and to be able to negotiate compromises. Think about what it means to be a good listener, a good mediator, and a good conflict resolver and problem solver.

Another critical skill for teaming is managing the team and the project. How do you keep everyone on track, keep tabs on what each member is working on, and ensure that what they’re working on will integrate with the other pieces the team is working on? Communications should be ongoing throughout the weekend, with frequent check-ins to report status, verify that everyone understands what is needed and who’s responsible for it. How do you like to hear feedback? How can you help someone to understand what you’re telling them when they’re not clear?

In short, think about all the interpersonal dynamics of working with others, and ask yourself what kind of person would you want to work with. Remember that when you’re working with your team, and be that person! Thinking about it ahead of time will help you hit the mark, and avoid getting caught up in being short sighted in the moment.

Getting ready for Game Jam Weekend, part 1

Global Game Jam 2017 is coming up soon. I’ve been talking with my fellow game developer friends about how to prepare. It seems like a good topic for a blog post or two.

Preparing mind and body for the game jam

In this article, we’ll cover the mental and physical preparation you should think about doing ahead of time, and during the weekend, to maximize your performance and your potential.

Approach Jam Weekend like you’re getting ready for a major athletic competition.

(Normally this means a season’s worth of training on specific skills and physical conditioning, but we only have a few days, so I’m going to skip that part of it. It is what it is.)

A game jam is more a mental activity than a physical one, but the same ideas apply. Just as you would prepare for a chess or poker tournament, or a triathlon or ultra-marathon, you should strive to enter Jam Weekend at your peak. That means healthy, well rested, energized, and in top condition.

Be well rested and well nourished. Jamming for a whole weekend is seriously taxing on the mind, and the brain needs energy and rest, just as the body does.


DO count on getting good sleep during the weekend.

Some people will stay up all weekend, but I don’t recommend it. You’re more productive when you’ve gotten adequate rest. If you can’t sleep well at the Jam site, and it’s pretty unlikely — there’s a lot of noise and chaos and activity going on at all hours — I recommend going somewhere you can get good sleep when it’s time, and if that means off-site, then so be it.

“Crunch time” is a common anti-pattern in software and game development, and is almost always unnecessary and detrimental in the long run. In the short run, people can and do get away with it — mostly when they’re young enough that their bodies and minds are able to withstand such stresses and recover from them.

Because it’s only 48 hours, a lot of people treat Jam weekends like they’re crunch time, and will stay up 36 or even 48 hours. I did that during my first Global Game Jam (in 2011) and learned from it that I wasn’t a 20-something college undergraduate who could pull consecutive all-nighters anymore.

My brain was determined to complete a project by deadline, and due to buggy beta software corrupting my project files, I ended up having to start over twice, redoing my entire project, which really sucked, and meant I basically had no choice but to stay up all weekend or else drop out, and I elected to stick it through to the end.

I finished my project, but my mind was not working anywhere near optimally during the last 12 hours or so, and at times I could’t keep a train of thought going. I’d stare at the keyboard trying to remember what I was trying to do, and what the next step was. If I’d just taken a couple hours for a power nap, I probably would have been better off, made fewer mistakes, and gotten more done. Although my project compiled and ran, I discovered that it was buggy and unwinnable, and had to fix it after deadline. Every project is likely to be buggy, of course, but working under extreme sleep deprivation is only going to make that worse.

Still, some people do seem to thrive on short term sleep deprivation, and become more creative, more focused, or just more crazy, and if that’s you, and you know what you’re capable of, do what works for you.


Eat good food beforehand, and bring or order good food for the weekend.

At my local Global Game Jam site, there will be food provided, and probably they’ll take orders for delivery from somewhere, but a lot of it is junk food or comfort food, and not necessarily what’s best for being well nourished. So consider doing better by yourself.

Preparing a healthy balanced meal is a lot better than eating convenient junk food and caffeine. I wouldn’t dream of specifying a recommended diet, but if you don’t know what’s healthy, look at physical trainers and what they recommend for athletes. A lot of starchy food like pasta or potatoes can be good for storing energy. Fresh vegetables and good lean protein is also an excellent choice.

You don’t want to spend a lot of time on prep and cleanup during the jam, so if you don’t have non-jammers supporting you with food service, then either order out for yourself, or prepare meals to bring that you can reheat easily.

No outside distractions

It goes without saying, perhaps, but try to have your outside life well in order so that it doesn’t intrude on your weekend. Anything can happen of course and if you have to bow out due to some family emergency or something, well, you do what you have to do. Always have your priorities in order, and follow them. If something comes up, hey, that’s life. But plan ahead, and do what’s necessary to keep your plate clear so you can focus on the one thing, and keep yourself free of distractions and other responsibilities as much as possible.

Galaxian is a triumph on the Atari 2600

As a child of the 1970’s, I’ve been attracted to arcade video games since I was tall enough to reach the controls. This was 1981-84, during the heyday of the arcade’s Golden Age, a time when games like Pac Man, Dig Dug, and Galaga were new, hot, and everywhere. Grocery stores, gas stations, seemingly anyplace people might spend time, you’d find a couple of arcade games, ready to suck the quarters out of anyone who passed by.

Just slightly older than these games were the ever-popular Space Invaders, and its evolutionary next step, Galaxian. Although these titles were top shelf games in their day, I found that I didn’t enjoy them very much.

Space Invaders was just frustratingly slow at first, but then sped up to an unfair pace by the end, and I could never manage to destroy that last invader on the first wave. You had to have perfect aim to hit it, and it moved so fast it was seemingly impossible to track, so you had to be lucky. If you missed, the slow-moving missile took forever to disappear at the top of the screen, and you couldn’t fire again until it did. Usually this delay meant your death, as the hyper-paced final invader would reach the ground, ending your game. Plus, it was black and white. It felt old. I respected it — even then I could tell that it was a important game — but grudgingly, I had to say that I just didn’t enjoy it that much, although I wouldn’t have admitted it to anyone back then.

Galaxian, too, was a game I found too slow and frustrating to play at arcades. It seemed like the next step in the vertical space shooter. Graphics were now in color. A formation of aliens marched back and forth across the screen, but this time instead of descending toward the earth, they stayed at the top of the screen, while one by one, or in pairs, individuals would peel off from their formation and dive bomb you. Their bullet patterns and flight paths seemed to make it all but certain that they would hit you if you didn’t hit them first. I could usually survive for a while, maybe clear a screen, but it never failed that if I happened to miss a dive bombing enemy, it would corner me in the side of the screen and crash into me, or hit me with too many bullets to dodge. You could always dodge one, but there’d always be another one following up, and your first dodge would put you right in its path. It seemed unfair, and so, not very fun. I always gravitated toward the games that I could last a bit longer on, so I could get my money’s worth out of my quarters.

I had a cousin who owned an Atari 5200, and played Galaxian on it once or twice while visiting them. The 5200 port was a very faithful reproduction of the arcade experience, not exactly arcade-perfect, but nearly so. I still didn’t care much for it, because it suffered from the same shortcomings. It wasn’t as bad to lose at home, since it cost nothing, but I still preferred to play games that felt fair.

It never entered into my mind that maybe I just wasn’t very good at Space Invaders or Galaxian. But probably, I was. Ok, not probably. I sucked. But in my defense, I was like 6, and just tall enough to reach the stick and see the screen. But back then, I blamed arcade games for being “greedy” in contrast to home consoles, which seemed to reward players with longer games that were still challenging, but more fun because they weren’t so brutally ass-kicking hard.

I never played Galaxian on the Atari 2600 back in the day. I’d played the 5200 version and was impressed with its arcade-quality graphics, and I remember seeing the pictures on the back of the box on the 2600 version, and being unimpressed. Since I never particularly enjoyed the game, I didn’t have any interest in owning it on the 2600, never knew any kids who had it in their collection, and so never played it. At some point, we had an Atari 7800, which had Galaga, the sequel to Galaxian, and one of my very favorite games, so I played a lot of that.

I’m not sure when exactly, but at some point I picked up a copy of the 2600 port of Galaxian, probably a few years ago. I recognized it was a significant title in videogame history, and so I wanted it for my collection, despite not having favorable memories of it from its heyday.

I finally got around to playing it today, and came away very impressed. Here’s a video review so you can see what it’s like:

The 2600 port plays much better than I remember the arcade. The motion is extremely fluid, which, considering the limitations of the Atari 2600 hardware, is nothing short of amazing. Maybe I’m just better at videogames than I was at ages 5-8, but I found that the game felt very fair, with divebombing enemies that are actually dodge-able. I’m sure, the horizontal aspect ratio of the screen plays into this somewhat, as you have more room to dodge, and also your shots that miss take less time to leave the screen, meaning that you can fire follow-up shots that much faster.

I was always a fan of vertical shooters of the Atari 2600, my favorites being Megamania, Phoenix, Threshold, and Tac-Scan, and Space Invaders. Galaxian is every bit as good as the best of these, and is still fun to play even now.

Playing Galaxian tonight, I found that my strategy was different from how I played the arcade original some 35 years ago. My old strategy was to try to shoot the enemies still in formation. They were easier to hit, since they didn’t swoop or shoot at you, and it seemed to me safer to eliminate them before they could turn into a threat. I’d try to shoot the divebombing aliens as they flew over me, and dodge out of the way of them and their shots, but mostly I concentrated on blowing away he ranks of Galaxians in formation, much as I approached Space Invaders.

My new strategy was much more successful, and rewarding: I ignored the galaxians in formation, since they don’t do anything that can hurt me, and focused on the divebombing aliens. It turns out, this has many advantages. First, by focusing on the divebombers, you are focusing on the only thing in the game that can threaten you. Shooting them is a much more reliable way to avoid them than dodging. You will need to dodge sometimes, but if you focus on developing skill in shooting the moving enemies, it gets pretty easy to pick them off before they can collide with you. The green Galaxians are simple, slow moving, and easy to hit. The purple ones are harder to hit, but with a little bit of practice the timing becomes easily mastered.

Hitting divebombing enemies in mid-flight makes you safer in two ways: enemies are destroyed before they’re low enough to collide with you, and they can’y get all their shots off. Typically, you’ll hit them as they cross ahead of you, and so you’ll be moving in the same direction, to track them, and the shots they do get off will fall harmlessly behind you, and by destroying the alien as it passes directly above you, you prevent it from getting ahead of you where it can drop bombs that would be dangerous to you.

Additionally, by hitting them as they’re diving toward you, your shot has less distance to travel, which means that you can get off more shots — since you can have only one shot on the screen at a time, when they hit something low on the screen, the shots don’t have as far to travel, meaning they hit the target sooner, meaning that your bullet is consumed and you can then fire another shot more quickly. If you miss one of the bombers, you might still end up hitting one of the galaxians still in formation, especially early in the stage, which isn’t so bad either. But the lower your shots are when they connect with an enemy, the faster you can shoot.

This in turn sets up a rapid flow of firing, hitting a dive bomber, then hitting the next dive bomber with a rapid follow-up shot. Once mastered, you can mow through the entire formation in quick succession in this manner. This turns out to be very enjoyable. You feel more skillful, since you’re targeting the fast-moving enemies, getting more points for them, and it looks more risky, since you’re often hitting the enemies pretty low on the screen, when it looks like they’re most dangerous — but at the same time you’re actually playing the least risky style of play. Of course, that’s what skill is — finding the right pattern of actions to minimize your risk, while doing what looks the most daring.

It’s clever, because the more intuitive way to avoid risk would be to try to avoid the dangerous enemies and attack the enemies that aren’t a threat. But counter-intuitively, when you focus on the dangerous enemies, and take the aggressive approach of destroying them rather than running from them, it minimizes the risk they pose to you, while the enemies that aren’t a threat remain a non-threat.

At this point, I recognized what a truly well-designed game Galaxian for the Atari 2600 is. I’m curious to see whether this strategy applies to arcade Galaxian. Since I don’t have ready access to an arcade with Galaxian in it, the next best thing is to watch a YouTube video of a skilled player.

And it looks like this is indeed the strategy to employ, although this player also has enough time to target plenty of enemies still in formation. I think the 2600 and arcade versions are different enough in their game play that they feel like different enough that while the basic strategies are more or less the same, the specifics are different. In the arcade, there’s much more space between the bottom of the screen, where you are, and the top of the screen, where the enemy formation is. But ultimately, I think the Atari port gives you less time to target the enemies in formation, forcing you to spend most of your time focusing on the swooping divebombing enemies.

In any case, Atari 2600 Galaxian is a fantastic game, and if you’re into vertical shooters is a must have, being one of the finest examples of the genre on the Atari, as well as an outstanding port of a historic and classic game.

GameMaker Studio 2 impressions: Object editor

The most notable change in the Object Editor is that sub-windows are “chained” to the main form, in what YoYoGames is calling “Chain view”.

GMS2 Object Editor

The idea is that different parts of the Object editor should all be visible, not overlap each other, connected visually.

The main Object window shows the object’s basic properties: the Name, Sprite, Collision mask, and Visible/Solid/Persistent/Physics properties, as you can see. Chained to it are the object’s Events, and the Code Editor (or DnD Editor) will be chained off of the Events sub-panel. If your object happens to be a Physics object, or has Parents or is a Parent, then the Parent and Physics sub-panels will also chain themselves to the main Object editor form.

GMS2 Object Editor chain

This takes some getting used to, and occupies quite a lot of space on screen, which for users with smaller displays can make it a problem to work with Objects inside of a Workspace.

Fortunately, Object Editor windows, like any other window, can be broken out of the main GMS2 window and maximized, to fill up the entire screen if desired. Users will either love or hate Workspaces and Chain View windows, and if you’re one of the ones who hates them, you’ll need to get used to breaking the editor out into its own window and maximizing it, as this seems to be your only recourse for now. There’s a few Preferences in the Text Editors section that will make this easier for you, should you want to configure them:

GMS2 Text Editor Preferences

The GameMaker Community Forums have been very active in discussing the UX issues created by the new UI, though, so don’t be surprised if YYG do make a few changes in future updates.

DnD or GML?

The Object Editor comes in two flavors: Drag-n-Drop (DnD) and Code Editor (GML). Which variant you get is currently determined when you create a new Project, but you can switch at any time. Most users will probably prefer to create GML projects and work in the code editor, but beginners, younger users, and non-programmers may prefer the DnD option.

Probably the most important feature of either variant is its interface for defining actions in your Object’s events.

I’ll be focusing mainly on the GML version, since that’s what advanced users will use. But briefly, Drag-n-Drop has been completely overhauled in GMS2.

The new Drag-n-Drop system

Vastly expanded in GMS2, there are now DnD equivalents to just about every function in GML. Unfortunately, this means that there are vastly more icons needed to represent all of these new DnD actions, making them harder to learn. Similar to Chinese or Japanese, where every written word has its own symbol, there’s a DnD icon for every GML function. While it’s reasonably easy to pick up a DnD library with a small number of actions, this quickly becomes unwieldy as the number of actions grows. Unfortunately I expect this will have the undesired effect of making DnD too complex to use for beginners and non-programmers, making it questionable how valuable the DnD system will be in the future. Learning to code by typing out instructions isn’t that hard, and is arguably the better way to learn in the first place. But it’s nevertheless true that for certain people, they feel intimidated by programming or typing, and an intermediary step of using DnD like “training wheels” until the new user has an understanding of GameMaker’s fundamentals and is ready to move on to GML, has been one of GameMaker’s defining features.

In GMS1.x and earlier, DnD Actions were iconographic representations of special GML functions that started with action_ for example, action_set_hspeed(number). These functions were mostly redundant, being equivalent to other GML functions and expressions, for example hspeed = number;

The action_ GML functions are obsolete in GMS2, and are no longer needed. DnD Actions can convert directly into GML with a single menu command. This is a one-way conversion, and should help users who want to “graduate” from DnD programming to GML programming. Formerly, in previous versions of GameMaker, there was no way to convert DnD to GML code, other than to manually re-write everything. If you try to convert GML into DnD, rather than a sequence of DnD actions, you’ll get your GML code wrapped up in an Execute Code DnD Action, and the Object Editor will switch to DnD mode, allowing you to continue programming with DnD actions. While not particularly useful for advanced GMS users who are already familiar with programming in GML, it’s a nice improvement to the way the DnD system works.

GML Code Editor

The new GML code editor is still somewhat rough, but shows promise of numerous improvements. Indenting is standardized, to 4 spaces per tab by default, although this is configurable, and there are subtle guidelines showing where tabs will align to in the background. Row lines are numbered, again configurable if you don’t want to see them.

GMS2 Code Editor

The most obvious difference is the new color coding for syntax. This may take a bit of getting used to, but at first I found that my code looked very rainbow-y, and I found this to be somewhat of a distraction at first, but after a few days I found that I had adjusted. Every color is customizable, if you want to bother with that.

Auto-completion and hinting is improved in the new editor. All project variables, macros, etc. are included, not just the built-in GML keywords.

GMS2 Code Editor AutoSuggest

The completion hints at the bottom of the Code Editor window are very helpful to remember all the arguments that must be provided to a function, in the right order. And for any scripts which you author, if you use JSDoc commenting, you can provide hints for your own functions as well.

GMS2 Code Editor Completion Hint

Rough Edges

Cursor navigation keys are either different from standard Windows text editors, or else not yet fully implemented. I’m accustomed to, and very reliant upon, using Home|End|Page Up|Page Down|Shift|Control|Arrows to move the cursor about the window, to select text, and for copy/pasting. In the GMS2 code editor, these keyboard shortcuts do not all work as expected, which can be pretty annoying.

In most text editors, Home and End keys will make the cursor jump to the 0th or last position in a row, or if Ctrl+Home|End is pressed, the 0th or last position in the file. Presently, Home and End do not appear to be supported at all in GMS2.

The Arrow keys move the cursor around the document one character at a time, and if Shift is held down, the characters that the cursor passes over are then selected. Holding Ctrl down will speed the cursor up, moving it a word or a paragraph at a time.

For some reason when selecting text using Ctrl+Shift+Arrow, with the horizontal arrows, the selection gets “stuck” at the beginning/end of a row, and will not advance beyond that unless Ctrl is briefly released. This is a relatively minor annoyance, but should nonetheless be corrected. Normally, Ctrl+Shift and the Left or Right Arrow key will select to the next word, and will wrap lines if it reaches the end of a line.

Up or Down Arrow will move the cursor up or down a row, and with Ctrl+Shift held down, should move up/down to the next blank line. This is standard behavior in pretty much every text editor I’ve used in Windows, or Mac OS for that matter, but it is not the behavior in GMS2 at the time of this writing. I am hopeful that this will be addressed before the end of the Beta.

But by far the biggest thing that users are complaining about in the Community Forums has been the way the IDE wastes space in its default configuration, due to the way Workspaces and the Chain View UI work. Fortunately, breaking out the Code Editor into its own, maximized window is an easy workaround to this problem, and largely addresses it to my satisfaction.

Apart from these issues, I like the new UI for the Object Editor, and the Code Editor very much.

GameMaker Studio 2 impressions: Preferences

Looking at the Preferences in GameMaker Studio 2 for the IDE, we have a lot of them, and they are logically grouped, and well-organized. Most of the preferences allow customization of cosmetic look-and-feel and UI behavior options.

GMS2 Preferences

The IDE is very customizable. Most of the configurable preferences come pre-set to defaults that make sense, and I don’t see much need to change them, but it is good that you have the control to change them if it suits you. I’m sure YYG anticipated that users would have countless nitpicky complaints about anything in the IDE that they couldn’t configure, and so wisely saw fit to give us the option to make ourselves comfortable. These options are by and large very straightforward and fairly dry to drill through, so I don’t see the need to go through them in depth here. The online manual has all the detail you need.

One very notable change from 1.x does merit mention, however:

  • There is no longer a backup folder. The old “save the n most recent backups” method of source control that was the only option available in GM8.x dsays, and carried over to GMS1.x, is gone completely from GMS2. Using a real version control system, such as git, has long been available, and is what everyone should use, but this does make version backups a bit more advanced for complete newbies. Nevertheless, it is now the only way to go.
  • Source-control integration doesn’t appear to be enabled yet in the GMS2 beta, or if it is I haven’t found it, so if you do want to use version control during the beta, you will have to manage the repository management and file check-in externally to the IDE.

With regard to GMS2’s default preferences, I found very few things that I wanted to change. But there were a few that were important to me:

  • One of the changes that I made was to set “Disable IDE transition animations” to true. While the IDE transitions are nice eye candy, I prefer things to be as fast as possible, and watching the Object editor open up and seeing the Workspace scroll to its location is time wasted, to me. Others might find it helps them to remain visually oriented to leave the animations on.
  • Another was to enable “Automatically Reload Changed Files”. If I work on an sprite sheet using an outside editor, or edit a code file in notepad for some reason, I want those changes to be reflected in GMS2 automatically.
  • The other thing I did was disable showing the background image in workspaces. While pretty, I prefer a plain, uncluttered background of solid grey. You can also set a different background image if you so desire.


There are two IDE skins, Dark and Light. Dark is the default, and I find that I do prefer it. Light is a bit too light for me, as it has a pure white background, rather than a light grey.

If it were light grey, I might prefer it over the Dark skin. One thing I did like about the Light skin is the code editor’s colors for syntax highlighting, which feels a bit more muted than the bright, rainbow-y colors in the Dark theme.

Fortunately, these colors are all customizable individually, if you want to tune them.

Will we have the capability to author our own skins, or add additional skins? I don’t normally want to spend a lot of time on cosmetic customization, but it might be nice for some to have the capability.

Room for improvement

It would be nice if the code editor settings could be saved collectively, to a profile document, and then loaded, so that you could export them and share with other users, and so you could avoid having to carefully re-set every setting one at a time if you need to reinstall or something.

Indeed, it would be nice to save the entire IDE’s configuration options as a profile, so that I could then switch between different IDE profiles as desired, allowing me to rapidly reconfigure GMS2 for different types of projects, for example I might find that if I’m doing a game that uses 3D graphics, I would want different settings for the Room Editor than I would want to use in a 2D Isometric game, and so on. I can see myself wanting to set up specific settings for grid sizing and snapping in both the Room Editor and in the Image Editor for different types of projects. If I’m maintaining multiple projects, switching back and forth between them, this would be a must-have.

The preferences you set are stored in %appdata%\GameMakerStudio2\[user id]\local_settings.json — this file is human readable, easy to backup, edit, share, and swap if you so desire. This has to be done manually, for now, but it’s my hope that YYG would give us some UI in the GMS2 IDE to save/import/manage preferences as a profile.

Game Options and Configurations

Outside of the File>Preferences dialog, we also have Game Options and Configurations, which is where we find settings that are project-specific. If you’re not sure where to look for some setting, ask yourself: Am I trying to change something in the IDE, or in the game I’m building? If it’s the IDE that you need to change, look in File>Preferences. If it’s some game setting, look at the Options or Configurations branches of the project resources explorer.

A few important things to point out with the project specific Options and Configurations, especially for users coming from GMS1.x:

  1. Room_speed is no longer a thing in GMS2. Instead, there is a setting under Main Options – General, for Game Frames Per Second, which is a global replacement for the old per-room speed. The default is 30.
  2. The default draw color for the project is also configurable here. I’m used to setting this in GML using the function draw_set_color(). To be honest I don’t know why YYG decided to make this a setting, perhaps just to make it simple for Drag and Drop users to find it, but whatever the reason, it’s here.
  3. Interestingly, there are some timekeeping settings here, as well, that allow you to automatically keep track of the Project Start date, Project Use Time, and the DateTime when the Project Last Changed. Potentially, this could be used for billing users for the use of GMS2, if YYG decided to change their business model to something subscription-based, or metered. It’s also neat for if you are trying to track how many hours you have put into a project — although, the time tracked is simply how long GMS2 has been running, not necessarily how long you’ve been actively using it — if you went away for a break and left it up and running, the meter is still counting.
  4. You can find settings for project GUID and author here as well.

In addition to General options, there are also platform-specific options for your game project. In the GMS2 beta, we only get to see the ones for Windows, but I expect users who have purchased additional build targets will find options for each of them here.

For Windows, we can set our display name, project name, version number, company, copyright statement, Graphics options for interpolation, fullscreen, window and mouse cursor, and a few other options. These are much as they were in GMS1.x.

GameMaker Studio 2 impressions: IDE/UI

The biggest change in GMS2 is the new IDE. Completely re-coded and largely re-designed, it has some things in common with the old IDE, but overall it has been re-organized and updated in many ways.


Every form in the UI is dockable, and can be moved around into whatever layout works best for you. This is great. Even better, you can pop out any part of the IDE into its own window, which means that you can spread your IDE out over a few display screens if your computer is set up this way. GMS1.x didn’t play nearly so well on multiple displays.

The resource tree is probably the most familiar element of the new IDE. By default, YYG have positioned it at the right side of the screen, presumably to follow other development environments such as Microsoft Visual Studio. It’s a simple matter to drag it and dock it to the left side of the window if you prefer the GMS1.x way.


Probably the biggest change to the IDE is the introduction of Workspaces. These are tabbed regions where you can dock different forms, so you can organize your project in a way that makes sense to you. For example, if you have a set of objects that are related to each other, you may want to set up a workspace where those objects can be arranged together. You can have as many workspaces as you wish, and you can name them something meaningful. This helps greatly to reduce clutter, and should improve productivity as you can leave workspaces set up and switch between them at will, without having to re-arrange windows and forms all the time.

I love the idea, but after using them for a few weeks, I’m convinced they have some serious issues that need to be addressed.

Workspaces can get very spread out, and this implies scrolling a lot. There is a new shortcut, ctrl+T, which will help you navigate the project more quickly than scrolling:

Another navigational shortcut is to middle-click on a resource name in the code editor. Doing this will take you to the resource’s editor window.

A major problem with Workspaces is that the Workspace region only fills a small section of the GMS2 window. Dockable regions at left, right, and bottom make the Workspaces area relatively small compared to the size of a maximized window.

Inside the Workspace area, you have (potentially) multiple Editors open. Certain Editors use Chain View (see below) which spreads out the sub-editors visually, in a way that takes up quite a bit of space, and will all but certainly require you to scroll, both vertically and horizontally, in order to see the whole thing. Vertical scrolling can be done by mouse wheel, but horizontal scrolling is done by CTRL+Clicking in an empty region of the workspace and dragging, which is slow and awkward.

Another problem is the Dockable areas in the GMS2 window. These do not update contextually according to which Workspace you’re in, or what Editor you’re in. If you open the Room Editor in one workspace, the Room Properties will appear in the Dockable area at the left side of the GMS2 window. Switching to another workspace and opening up a Sprite, the Room Properties are still there in the left Dock, where they are useless for the current context, and serve only to distract and confuse, and take up valuable screen real estate that could have been used to present the Sprite Editor UI and/or provide a larger portion of the screen to display the sprite canvas. Fixing this should be a simple matter of showing/hiding the appropriate panels in the Docks for the current context you’re working in. Whichever editor has focus, its Dockable panels should be the only UI visible (apart from the Menu bar and Resource tree).

Maximizing an Editor should make it fill out the entire visible area of the Workspace. And whenever an editor has focus, its entire form should fit on one screen/workspace area without the need to scroll the workspace. I’m fine with a scroll bar within an Editor, for example if I’m in a really long code file in the Code Editor, or if I’m zoomed way in on an Image in the Image Editor. But I don’t want to have to scroll about the Workspace just so I can see from one end of an Editor to the other. I really don’t want to scroll around looking for different editors that are floating about in the Workspace. I would much prefer a tabbed interface where I can easily switch between tabs. Workspaces could be better implemented as groups of related tabs.

The worst part is when you go to open a code editor. The code editor is used in three situations: 1) when working on a Script resource; 2) when coding Events in the Object Editor, and 3) when editing Room Creation code in the Room editor. In the Object and Room Editor use cases, the Code Editor is chained to its parent editor. The code editor is almost never entirely visible in the visible area of the Workspace pane, meaning that very often the right and bottom of the Code Editor will be out of frame, and necessitate scrolling to see. So you’ll often be unable to see the ends of your longer lines of code, and the helpful code tips that appear at the status bar area in the bottom of the Code Editor will also be out of view. This is awful, and needs to be addressed. Code Editing is a primary activity in GMS2, and when doing it, the Code Editor deserves a maximized view, with minimal distractions surrounding it.

I believe the issues with Workspaces are fixable, but as they are now, they’re a bit of a disaster. I find that they make it easier to get lost, and I spend a lot of time flipping between them and scrolling, hoping to find what I’m looking for. They navigational shortcuts may be helpful, but they don’t come second nature to me, and so far I find that they’re so unfamiliar that I have to shift my mental focus form the programming task I’m working on to “how do I navigate to the bloody resource I need to look at?” which takes me out of “The Zone.” They make a 2048×1152 screen seem small and cramped.

Chain view

Another major new feature is called “chain view”. This is a new view for forms that have several sub-forms. For example, the Object editor has a main form that allows you to set the Object’s properties, and then if you add Events to an Object, these are managed in a sub-form that is chained to the main form. From there, Actions are in a sub-form that chains off of the Events sub-form, with a separate tab for each Event’s actions. This keeps related forms together, making it easier to see relationships between different open windows, and reduces clutter. They do spread out more, since the sub-forms do not overlap each other, and this takes some getting used to.

Menu and Tool bar

One thing that can be a little weird, and takes some getting used to, is the Menu bar. Depending on what form you have focus on, the Menus that appear in the main window’s menu bar will change.

For example, if you’re in the Image Editor, the main window will receive some Image Editor menus, to the right of the Help menu, and not in the Image Editor form.

Open the Image Editor, and some additional menus will appear in the menu bar.

Open the Image Editor, and some additional menus will appear in the menu bar.

This felt weird to me, at first, when the Image Editor is sharing the main window with whatever other forms you have open — I expected all controls specific to the Image Editor to be contained within the Image Editor’s form. However, if you break the Image Editor out of the main window and into its own window, it feels right.

Quick import your Asset files

Importing sound and image files into GMS2 is easier than ever. Just drag a file icon, or even a folder, into the resource tree, and the file will automatically be imported into the project, and a resource created for it.


There is a lot more to cover in the IDE, but rather than make this article too long, I will be covering them separately in future articles focusing on the various Editors: Sprite, Image, Object, Room, etc.

Keyboard shortcuts

I won’t list them all (look in the manual, under Quick Start) but these are some of the most important/useful shortcuts, which everyone should know and use.

  • F5 – build and run the project.
  • Ctrl+T – Opens the Goto window to search the workspaces.
  • F2 – In the resource tree, rename the selected resource.
  • Ctrl+K – In the code editor, comments out the selected text. (Ctrl+Shift+K to un-comment.)
  • F2 – In the code editor, opens the code snippets menu.

UPDATED – YoYoGames Marketplace EULA now allows Creative Commons licensing

Update: It turns out that it has always been possible to link a Marketplace asset to another EULA; I had never noticed this before!

YoYoGames apparently has added Creative Commons licensing to their standard EULA for purchases made through their Marketplace with the Creative Commons Attribution-ShareAlike 2.0 Generic license.

The old GameMaker Marketplace EULA is still in use for some assets:

GameMaker EULA (old)

Assets sold under the Creative Commons license show a different EULA:

YoYoGames now uses Creative Commons licensing on the GameMaker Marketplace

Oddly, though, YYG have set up the checkout so that people purchasing assets for GameMaker Studio can make a donation to Creative Commons during checkout. At first, I thought that this was a donation to the asset maker, which would effectively allow a “pay what you want” model for free assets. But after clicking the Donate Now button, it became evident that it was for donating to Creative Commons, the organization that created the Creative Commons licensing. While I’m glad to see the Creative Commons organization getting support this way, it’s a bit confusing at first to someone who just wants to pay for their marketplace purchase.

Creative Commons licensing is a great idea and is exactly the right fit for the purpose here. I’m thrilled to see YoYoGames using CC licensing as another option in addition of their own license.

GameMaker Studio 2 impressions: Pricing

[Rather than posting a long article that takes days to organize, I’m opting to do short-form posts that focus on a narrow aspect of the new GameMaker. This means more frequent, smaller posts, which will hopefully be more timely and more digestable for readers. For more articles in this series, just follow the GameMaker Studio 2 tag.]

This is all very early to talk about, and I recognize this, but a lot of people are talking about how much GameMaker Studio 2 will cost.

YoYoGames have put out their “prospective” pricing out on their website:

Currently, it looks like this:

GMS2 pricing GMS2 upgrade pricing


First, I am very happy that YYG did not try to go with a subscription-based model with their pricing. This shows that they have listened to their users, nearly all of whom despise the idea of paying a subscription on an ongoing basis for software. For hobbyists and occasional users, it’s not a good deal to pay for a subscription if they’re not going to use it all the time and really get the value out of it.

I find that the costs are basically in line with what I was expecting. Sure, Master Collection is a few more dollars than it was when they released it 6 years ago, but guess what, that was 6 years ago. Stuff gets more expensive as time goes on. That’s how it’s always been

The upgrade discounts are reasonable. 40%-50% off is not bad for an upgrade.

I do question why certain modules are so much more expensive than others. I would rather see the Android/iOS bundle and HTML5 bundle cost the same as the Desktop bundle. The UWP an Console bundles, I can understand somewhat more, as those build targets are of prime interest to commercial game developers who, it’s understood, make money from the games they produce, and it makes sense that they should be willing to pay more for those tools, and if by paying more for them, it helps subsidize the other users, then great.

I’m sad to see no free edition, apart from the Trial edition. Depending on the limits of Trial edition, it could still be viable for hobbyist developers, but it sounds like it’s more intended as an evaluation edition to allow people to decide whether they want to pay for a real edition that can actually build games.

Community Chatter

So, predictably, most people who are talking about it are complaining that the cost is too much. That’s a subjective judgement, and of course everyone wants to pay as little as possible, and get everything for free if that were possible somehow.

Some people think that all software should be free (as in beer). Mostly, these people just don’t have enough money to afford to pay for software. They spend as much money as they have on just getting a new computer, and then they can’t believe that the cost of the software they need to run can more than double the price of the system. I sympathize, because when I was younger I was definitely one of those people, and if it wasn’t for deep discounts on student licenses, bundles that came with new hardware, and so on, I couldn’t have afforded to buy much software.

Fortunately there has always been a lot of good quality, low-cost or free software available, as well. Different products are aimed at different markets. Companies that sell to big businesses charge a lot of money for their software, in part because they can, but also because they need to, because in order to develop they need big budgets and a lot of employees. But some software is the product of a single developer, who doesn’t have all the overhead that a large company has, and they can afford to sell for a cheaper price, or even give away if they feel like it. Additionally, there are developers who feel that they get paid to program, not to sell copies of software, and they can get funded to do a project that someone who has money needs, but then turn around and give away the software as a public good, and as long as the cost of development is met by a few, everyone benefits from it.

GameMaker’s history started out with a single developer, who sold the software very cheaply at first, and always had a free edition, and a paid edition that cost $20-25. Later, as GameMaker grew, it became too much for one person to maintain, and he sold it to YoYoGames, who are a larger company, and who therefore have more overhead and need to charge more in order to cover their costs, pay salaries, continue R&D and support, and turn a profit.

YoYoGames initially raised prices, from $25 to $40, around the time of GM8, and users howled that it was too much. And we can see in retrospect what a bargain it was, and how childish people who complained back then were. GM:S has been considerably more expensive, anywhere from $70-200, although they have continued to provide a free edition. YoYoGames can’t continue to exist if they just give away software for nothing.

And YYG charge more for extra GM:S features, up to $800 for their “Master Collection” bundle which includes everything, including stuff they haven’t come up with yet, later for no additional cost. $800 is very expensive for most people, and unless you’re making money with the software, or are wealthy enough not to care, it’s probably not for you. It’s aimed at companies that can look at the purchase of software as a capital investment that is part of the cost of doing business. And if by charging more to these customers, it enables YoYo to keep costs lower for individuals, students, and hobbyists who otherwise couldn’t afford to buy what YoYo would have to sell it for, I think it benefits everyone.

Maybe low-budget amateurs will gripe about not being able to get all the features, but they do get something.

You also have to compare GameMaker against what else is out there. And there’s a lot else out there. There’s stuff that’s completely free, like vi + gcc, which is very high quality and extremely powerful, but that isn’t necessarily the best option for everyone, because it requires a huge amount of learning and knowledge and work to create games with. In more direct competition are tools that are geared specifically toward game development, such as Unity3D (which is more expensive, and uses a subscription model now) and Construct2, and free tools such as Godot, Love, and Defold, which may not be as well supported, well documented, or easy to use. And many others besides these. The bottom line is, if you don’t like GameMaker because of what it costs, you have plenty of options to choose from, many of which are very good.

So for people who are complaining that it’s too much, I don’t have much sympathy for you. It’s very likely that at various points YYG will have sale events, as they’ve had in the past. If you don’t want to pay the release day price, you can probably wait a year or two and hit a Steam sale or a Humble Store sale and get it at a pretty good discount then. By that time, it will be even better, with more polish and more features. In the meantime, if you have GM:S1.x you can continue use it, it will continue to receive support and bugfixes, and 2.x will be ready for you when you decide you can afford it.

csanyk.com © 2016
%d bloggers like this: