JJSBlog

So I wanted to continue working on the system of different asteroids for different sizes. My thought is I'll have an array (or series of parallel arrays) which will have information like minimum mass, maximum mass, sprite used, name of object. Then given a certain mass it can pick only from valid options. Both a minimum and maximum are because I figure it's more interesting if there's some overlap between types of objects, rather than a flat cutoff. Or it could even be possible to have rare objects that only exist in a very narrow range. Whatever. But before doing this I needed to see how arrays work in GameMaker, and it seems... kind of stupid. More a pain to use than in other languages I've dealt with.

Thing 1: Initializing arrays. In some languages, you can just give a specific size for an array. In other languages, it doesn't set limits, and you can even use words as keys for the array rather than just a series of integers. In GML, you need to initialize every spot in the array similar to declaring a variable, before the program is allowed to do anything with it. Like for Zenzenzen purposes if I wanted to keep track of the last 10 asteroids I merged with for whatever reason, I'd first have to do some sort of loop and set lastmerged[i]=0 as a default value or whatever.

Thing 2: Initializing the data in arrays. In PHP which I've used the most in recent years, if I want to set up an array with multiple values it can be as simple as $Names = array("Josh", "Zach", "Austin", "Luke"). In GML that isn't done. I'd need to have a line for name[0] = "Josh"; and another for every other value. It seems like unless you're dealing with a very small set of data it will be the sensible thing to set up a file with the data (or a string which can be made to be treated like a file) and read that into an array with a loop.

Asteroid types

One of the plans from the beginning was that as the player grew, they'd see different types of objects, while thus far I've just used the one asteroid shape. Well today I've added two more. Still crude placeholders and the code working them is also basically a crude placeholder, but now that the crude way is up and running I can replace bits of it at a time.

I added in new sprites for circle and diamond asteroids, each with the same number of color variations as the original. When an asteroid is created it checks its mass. If it's over 10000, it's a diamond. Otherwise if it's over 100, it's a circle. Otherwise, it's the regular asteroid. Regardless of sprite, behavior remains the same. Also added in that pressing X creates a random asteroid at a random location on the screen, with possible mass ranging from 1/10 to 100x the current ship mass.

Here's a shot from early on, with a few large circles in play.

And later having built the ship up, things look like this. If you look closely at the ship, you can see now-small circle asteroids layered on it.

So I previously described my "scan bullet", which I thought was a pretty interesting way to get the results I wanted, but obviously flawed. With a bit of advice from folks at NeoGAF's GameMaker thread, though, I learned of a few tricks to do it better without an actual scan bullet object. As I said there, GameMaker's help system is very nice, but it can still be trouble to find if a certain type of function actually exists if you don't know quite what to search for. In this case I learned of a few important things.

The collision_line function can take a start point and end point, and return whether there would be a collision with a certain kind of object anywhere along that line segment. The problem is, if it would collide with multiple things along that line, it seems to just return information about one of them at random. So not perfect by itself for determining what is right in front of the ship.

Lengthdir_x and lengthdir_y are used for finding points a certain pixel distance away from a point at a certain angle. So knowing where the ship is located and what its angle is, this can check for what's 1 pixel in front of it, 2 pixels in front, and so on. So it's easy enough to do a loop of this and return information on the first asteroid (if any) it comes across.

It might be the case that there would be some computational savings from doing collision_line to see if there's any collision at all, then using a lengthdir loop to make sure the closest is found... but I'm not sure how much of a savings, and for my simple project where it's only being used to check one thing probably not worth the hassle, so I'll just put collision_line back on the shelf for now.

I know it wasn't a serious project, but I wanted to compile Pork Anus for Android so my buddy could see it run on the phone. However, keyboard controls are pretty much a no-go, so this did involve a little extra coding to add mouse/touch control. Pac-Man doesn't move any faster, but now if there's a mouse/finger press on the screen he moves directly towards that point, and is himself angled appropriately toward it. Also added in a Game Over for the unavoidable eventuality of getting 50 green anuses on screen at once, rather than just letting it freeze.

If you want to try the new and improved Android Pork Anus, here's the APK.

Away from home today, so I decided to try something mostly unrelated to what I've done before--loading files from the Internet. Since online databases are one of the things I do, I think it might be interesting to draw info from them into a program made with GameMaker, either as a way to make a sort of custom app for accessing the information, or just pulling live information as an alternative to only using whatever data the game has been built with. In this case I used files from the DohBell database. Since the cover thumbnail images are stored in one directory with standardized naming and each single/album is guaranteed to at least have a Regular cover, then it is easy to get a valid cover image URL from a random number.

So I made a simple sprite and object for a button inviting myself to Click. When it's clicked it picks a random number from 1 to 600 and tries to load the regular cover JPEG for that number. When that's done it goes to a new image loaded event (since to just wait for it would cause the program to pause indefinitely) that assigns that loaded image to a new "rect" object. Then to make things a little less boring and more like some kind of screensaver, I made the rect object so it picks things like a random size (from quarter-size to full size), a random speed (1-3 pixels diagonal per frame), and made the images bounce off the edges of the window.

Result: it works. Though you'll just have to trust me that things were actually moving around.