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 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.

To start with I basically recreated some of the Asteroids game with slight modifications. Ship movement is similar, though a reverse thrust was added.

Ship design looks a little like a side view of a TIE fighter, though that was coincidental. An octagon shape seemed cloes enough to a circle for good collision detection purposes, and having lines that come from every corner to meet in a smaller octagon in the middle was basically a simple way of having a sort of "net" design. For the most part it is transparent, with the idea being that something could be attached to the net ship on either side and be visible--though realistically I imagine it will be hard to see much of the far side with the near side in the way.

For testing purposes I've just got one Asteroids-style "asteroid", with several palette swaps. Realistically having enough sprites for objects of different sizes will be a limiting issue for a non-artist like me, but I'll get back to that another time.

In testing how I could layer objects onto the ship, I learned a bit about GameMaker surfaces. Basically a surface is something that things get drawn to. The image that gets output to the screen is the default surface, but you can create other ones to do more complicated effects before bringing things back to the main view. I've had some dumb problems trying simply to copy the ship shape and get it 100% perfect, but for now I'm willing to live with 90% perfect, especially since with things being layered all over each at various scales the little details are probably not going to be very easy to see anyway.

The ship has a mass, as do asteroid objects. As the ship gains mass, asteroids scale down. When the ship grows it stays the same size on screen--having a giant ship on screen would not be very manageable, though it won't look as exciting for the player. I've got a test button to change the ship's mass, at which point asteroids automatically scale down.

Shooting an asteroid creates two or three smaller asteroids, which will have mass totalling 60-100% of the original one. As previously stated for now everything is just the one shape; in the future I'll have something like an array so it will check what kind of sprites are allowed for an item that's supposed to be a certain size. Initially when setting this up I forgot to make the bullet disappear, which meant it kept shooting the newly created asteroids and I ended up with little rocks all over the place!

Any asteroid that's sufficiently small disappears. I think I currently have it set to 0.1% the ship mass. This should help prevent an overwhelming number of little specks flying all over the place.

Though nothing yet naturally attaches to the ship, I have a layering testing system in place. I have a separate sprite for things on the back side and on the front side. If I press one button, the back sprite shrinks a bit, then has a new farthest-out item layered at a semi-random location on the far side. Another button shrinks the near sprite, and adds a new asteroid on top of it. A third button then layers the back, ship, and front in that order, and saves the result to a new sprite that becomes the new look for the ship.

This basically brings us up to speed on the current state of Zenzenzen. Probably the next thing I want to work on is having things naturally layer onto the ship when it collides with a small enough object, rather than just happening at the touch of a button.