JJSBlog

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.

Something a little different today. I wasn't sure whether to bother documenting this, but what the hell. I was showing off GameMaker to a friend of mine in person, showing how quickly one could get something simple with interesting effects going, and basing it loosely on some messages he'd sent me over Steam a few days before about transforming Zenzenzen into something called Pork Anus. So here's the rundown of how our Pork Anus ended up.

Player sprite is a straight-up Pac-Man ripoff with several frames of animation for mouth opening done roughly by me deleting parts of a circle. He moves in four directions by the arrow keys, with the sprite rotating for each. This does mean going left he appears to be upside down from the regular player's point of view.

"Pork Anus" object says that in text. Appears in a random location on screen, and every frame has a chance to move some a bit on the X and/or Y axis, which in practice means it moves in kind of a jerky diagonal. Whether he goes left or right, and up or down, is randomly determined at creation. Was having problems getting this to wrap around the screen edges correctly, so instead when it leaves the screen it gets destroyed and a new random one created. When Pac-Man collides with one of these he grows by a few percent, and a new random Pork Anus is created. Also when Pac-Man gets one of these a voice clip of me saying "Pork Anus" plays.

Second object is more of a graphical anus, but still very loosely. It is the more interesting thing in terms of trying out new ideas. It moves forward at a constant speed, with every frame a chance to alter its angle somewhat--in practice this means every several seconds it takes a slight turn and keeps moving that direction. When Pac-Man hits one of these he shrinks, but not evenly by X and Y, so he ends up more stretched with time. When one is destroyed by running into Pac-Man, one is always created to take its place, and there's a chance of a second--so as the game goes on they become more numerous and hard to avoid. Also, if they overlap with each other they start to grow. With increasing numbers and that, you get a situation where they start to get impossible to avoid, but this is not exactly a Balanced Game.

Working on that object actually did bring a lapse in my knowledge up. Instead of them growing, I originally wanted two that collided to become one larger one. However, since the collision event happened for BOTH of the colliding things, whatever I wrote in would happen twice. Destroy the other object? Both get destroyed. Grow large? Both grow large. I'm sure there are ways to work around this, and I can even guess at one. Instances of objects have a unique ID, so it should be possible to get those and declare the "greater" and "lesser" one to be treated differently, so even if the code ends up run twice they would both decide to resize A and destroy B. Hopefully there's an even better way I'll eventually learn, though.

Probably about an hour spent messing around with this.

I added a sound for asteroids breaking up, and similar to the joining event the volume it plays at varies by size. However, it seems like it's not possible for sounds to go over 100% volume? So currently breaking up an asteroid the mass of the ship sounds no different than breaking up one with 100x the mass of the ship. Not that being 100x the volume would be a good thing, but I wish it was louder. Might have to adjust things so it's a louder sound to begin with, and then asteroids the size of the ship are at 25% or 50% of that volume?

Implemented hit points system for asteroids. Ship bullet's power scales with mass, as do asteroid's hit points. So something with 10x the mass of the ship currently takes 10 bullet hits to destroy. This might be a bit much--it's feasible, and INTERESTING, to have the occasional giant asteroid, but needing to shoot it 1000 times or avoid it for a long time might be a bit much. I also wonder about the best way to display how much HP an asteroid has left? Temporarily I've got it sitting along the mass text at the top left, but something more immediately visual might be good. Like, if it's standardized that all asteroid shapes have a white border, implement some effect where the closer it gets to 0, the white shifts more to red?

I've adjusted bullet strength to 10x ship mass. So something with 300x ship mass now takes 30 hits.

Added in some interaction with larger asteroids. Whereas those 1/4 the mass of the ship are joined, now those greater than that but less than 4x ship mass will bump away. It's not exactly physics accurate or consistent, but it affects an asteroid's motion in vaguely the direction the ship is headed (slightly random) and adds to its speed by a fraction of the ship's speed (currently set to 1/3), with a speed cap the same as the ship's. At first it was making these asteroids fling away because the direction/speed alteration was happening repeatedly, but I added in a little timer with current_time so once it's had a "bounce" event it won't again for at least 2 seconds. Also added in a bounce noise, which again has its volume modified by asteroid size. Probably a good idea to have the ship's direction/speed affected too, but I haven't put that in yet.

Today was largely about sounds. Until now Zenzenzen was silent, so it felt a bit dead. I used a tool I learned about from the Asteroids tutorial, Bfxr, to make some simple shoot and join sounds. More than that, I learned to use audio_sound_gain to adjust the volume of a single instance of a sound--so when the ship joins with an asteroid, the smaller the asteroid is the quieter the join sound is.

Speaking of relative sizes, this is something I've been pretty unsure exactly how to handle. Like, at what size should asteroids join with the ship? Currently I have it at 1/4 ship mass or less. Secondly, how to handle mass in this game? So far I've been treating it properly three dimensionally, but I'm not sure how appropriate that is in such an obviously 2D world. That is, if an asteroid is 1/2 the ship in length and width, it is taking up ~1/4 the area of the ship on screen. However, I assume there is an equally valid third dimension at play, so its mass is actually 1/8 that of the ship. Maybe going straight out 2D would be simpler and better. shrug at this time.

I played a little with the "scan bullet" concept, but I'm not sure it can work as I initially thought. Really I was playing around with the speed of the regular bullet. However, I found that if I put the speed of the bullet too high, it will basically skip from point A to point B without hitting the spaces in between, and thus even giant asteroids will get missed. The entire point is to hit something and report on what it hits, so that's a no go. If I slow the scan bullet down it will have some slight lag time from leaving the ship, which is not preferable. Maybe if rather than treating it like a tiny bullet it instead creates a long thin item all at once, so it doesn't even really have to move to collide? But in that case it might collide with a bunch of objects simultaneously rather than just the nearest one. Maybe something in the middle--like a bullet 16 pixels long. Something that would be less likely to miss things altogether, not have noticeable lag, and if it does overlap a few items, they'll be in such close proximity that it won't make much difference to the player, especially since everything will have moved around very quickly.

I've worked a bit more on scan bullet, and have something workable though I think it could be better. To make no gaps, movement speed needed to be same as image size. 16x1 was a bit small, but scaling it up to 64x4 should do a decent job and with very little lag. I wonder if it wouldn't be better to every frame look at the ship image angle and do a place_meeting to see if there's anything there on a series of points between the ship and the edge of the screen. However, the necessary calculations to determine all those points in a loop seems More Trouble than I feel like getting into right now, so for now the scan bullet is Good Enough. When the scan bullet hits an asteroid, it's destroyed and a global variable "scanasteroidmass" is set to the asteroid's mass. The object that was displaying just the ship's mass now checks to see if there's a scanasteroidmass available, and if so displays it as well, then resets it to 0. This way whenever the ship angles away from the asteroid and scanasteroidmass stops geting that asteroid's data, it's cleared out.

Though it shouldn't be necessary for functioning, for testing purposes I've got the scan bullet visible, so I can show it shooting out and intersecting with something here.

The ship here is turning right, so you can see how the series of scan bullets deviates a bit from what is exactly forward from the ship. Each of those bullets is from a new frame and the game runs 60fps, though, so the lag from the ship to that asteroid is still a small fraction of a second. Iiiiimperfect, though.

Today I successfully made it naturally layer items. If an asteroid collides with a ship, it checks how its mass compares to the ship. Much smaller, around the same, much bigger? I only have code for the first case. In that case it flips a coin to determine whether to add the object to the front or back, and then does so with the code I previously established, scaling the existing front/back images by the change in ship mass. I do have a bit of a transparency problem, where if a black asteroid gets added on top it thinks that black area should also be part of the transparency in the end, so it's as if there's just a hole straight through the ship and everything on it. Probably making it start the surface with some other more obscure color and telling it THAT's the transparency will take care of it? But haven't done so yet.

Another thing that was in previously and I forgot to mention it is a mass indicator. Since the ship changes mass, it displays the ship's current mass. Currently it does so in two ways, simply because I was testing it and wanted to make sure the way I wanted was being created properly based on the first number. The second way uses scientific notation, which for a game in which a lot of growth might occur, or maybe have segments at wildly different sizes, is better than just giving some standard integer. I'm also wondering if it would be good to show the mass of the first asteroid (if any) directly in front of the player, and the best way to do so. To destroy an asteroid a bullet goes flying from the ship--to "scan" in front of the ship should I send out a sort of harmless invisible super fast bullet to see what it would collide with?

Testing a fix to the transparency problem: telling it to use built-in "olive" color instead of "black" took care of the transparency issue, but left some olive residue at the edges of things. Instead telling it to use a custom set not-quite-black color worked better.