GameMaker: Day 5 - Persistent Persistence!

TL;DR

GM has awesome features, but it's arrays aren't exactly fun normal. Neat project today. Tomorrow I start my 2 day re-build of Samsara!

What I Did Today

I've wrapped up Shaun Spalding's Youtube video series on GameMaker Studio today.  Pretty informative. He touched on some topics today that I wasn't sure he would. One such topic was basic error/bug fixing and tracking. This is an amazingly useful skill for anyone doing anything related to software development.

There were quite a few topics covered today specifically about GM Studio. The first I want to talk about is changing rooms. Seems like something simple, but it was something I hadn't done just yet. Gm has two ways of changing rooms, by either specifying the name of the room you want to load, or by loading the "next" room. GM decides that the next room is going to be the one below it in the Rooms folder on the Resources tab/explorer which is on the left of your GM Studio window. This allows you to go between menu screens, switch to a game screen, and go between different rooms/screens in the game (think Zelda on the Super Nintendo, how when you walk to the right off the screen, you appear on the left side on a new map!). This brings up the next topic, persistence.

Persistence is the ability for an object to stay 

Then I started seeing where some of the limits to GM are.

Arrays. Arrays suck in GM Studio. There's no way to sugar coat it. The arrays themselves don't know how long they are, or there isn't a way for them to find out. There is supposedly a function you can pass an array to which will return it's length, but when I used code from Google'ed examples, hell even the documentation example, it would error and say that it wasn't a method. ( EDIT::9/5/2013::This is not true, just update GM Studio to 1.2 and the documentation example stops throwing errors) This can be a huge turn-off to many people with a programming background already, because we love arrays. They do one thing, and do it well, at least they do normally.

A solution to this problem that kept popping up online was to use GameMakers build it data structures. Let me preface this next part with this, "Data Structures solve the array problem posed above". Ok, now that that's cleared up, I'm not really fond of I hate data structures. Why? They're a memory leak just waiting to happen. For those of you unaware of what a memory leak is, let me explain. With most things in memory, when you're done with them or cannot see/access them anymore, part of your program called the garbage collector comes around periodically and collects these things in memory (variables, images, objects, ect) and destroys them to free up that space. Sounds great, no? Well with data structures, if you don't explicitly say to GameMaker Destroy data structure 'X' when you're done using the data structure, it stays in memory, FOREVER until your program ends. It doesn't sound too bad at first, but it's a real problem. It's not just when you're done using it, it's anytime your program will stop seeing it, so anytime you destroy an object with a data structure, or switch rooms, ect, you have to make sure to destroy that data structure. If you don't, even though specific version of your room is gone forever, that data structure lives on in your memory. Do this enough, and with enough different data structures, and you could literally fill up your computers memory (though you would have probably stopped playing by them, it can still slow you game down drastically).

"But Nick, why can't you just remember to destroy them?"

Oh, I can, that's not that hard. But it's part of the reason I'm trying GM Studio, is to get away from all the pesky gotchas and tedious code of programming everything by hand. I'm probably just overreacting because of the array thing, but it's still a valid concern.

On a positive note, you can make extensions/plugins for GameMaker, so I think I'll look into making an FULL array extension!

Today's project isn't truly a game, but it looks like one! It starts with a title screen, which you press space to load another room! This puts the penguin in a blue room, with some snow particles. You can move with W, A, S, D, and the other thing you'll notice is the pads marked "WARP". They allow the penguin to go to the other room (red/blue). What's cool is you have penguin and snow particles in each, but technically they're the same objects, they're just persistent, so they carry over to every screen, until I change that.

Here are some screenshots

 

Time coding was about 15-20 minutes.

Source Code

The source code/GM Project file is zipped and available HERE, from my website.

Conclusion

Despite the array fiasco, GM is still pretty awesome. What I made today took about 15-20 minutes, and would easily have taken me an hour-ish or more to do by hand. Besides the array deal I don't have much to complain about today.

On another note, tomorrow is day 6, so I'll start trying to rebuild Samsara! I'll be rebuilding the entire game in 2 days, so it will be just like the Ludum Dare where I made it, except I expect to get more done, with less time to work on it.

EDIT:: 9/5/2013
It has come to my attention that updating to GM Studio 1.2 solves the problem of the method shown by the documentation throwing an error. So it's not that bad anymore. Still gonna try to add a full array, because passing an array to a method to get it's length feels dirty. :/