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.

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.

Just wrote an email to a friend about this game, and decided to share it here too:

Played some River City. Pretty cool.

Controls much like on NES, except Jump gets its own button.

Stat progression is different--you straight up gain levels by experience. Restaurant food just seems to heal or revive your CPU ally. I did once earn a special item that gave me permanent Agility +1 boost. Characters can also wear three pieces of equipment to boost various stats.

Special moves are still bought from books. If late in the game for some reason you want them off, they can each be toggled once learned.

You can attack people in the non-fighting areas. Some just have a funny response, but one girl's yakuza brother and his friends arrived and kicked my ass.

The world is interconnected, but differently. There are many neighborhoods which will loop through 3-4 screens each, and you take a train to travel between them.

Graphics kind of mixed. They use retro sprites, and during story scenes they look exactly right. Once fighting starts they zoom in slightly for some reason, and the sprites get blurry.

Clearly meant to have elements that play on nostalgia, not just from RCR but also Super Dodgeball and other games in the series, including ones never released internationally.

When you buy a free smile, it says you get one but doesn't graphically show it. Cut corners!

Story mode doesn't seem to have multiplayer, but other modes do. One is dodgeball, the other a versus fighting mode. Haven't really touched either.

The leads never talked in RCR, but here their characterization as sort of do-gooding delinquents comes across pretty strongly.