JJSBlog

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.

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.