JJSBlog

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.

These links maybe should've been in the first post, but here are some of the end results of that spinny face "game" I made early on.

HTML5, earlier version
Windows, earlier version
Android, final

These are just sitting in a temp directory, so no guarantees any future people peeking this will still find them there.

Faces spin. Holding finger/mouse button on a face applies a reverse spin. Double click/tap on a face makes it stop. If they stop mostly upright, they're happy. Otherwise, mad. As you go on the rate of faces appearing and their initial spin goes up. There's no end state, just quitting when you get bored or the game becomes an impossible mess of faces popping up. Not all of the above will apply to the somewhat earlier versions. The earlier versions also use more complicated background images from H!P Wiki, because I needed something that would seamlessly tile and they were at hand. Since they ended up saved as a large PNG file in game resources, though, I made a change.

Also here's my end result from the Asteroids clone tutorial. Arrow keys to move, space bar to shoot.

Windows, final

This isn't directly to do with using the GameMaker program, but the pre-pre-production of my current project. Before starting to use the program at all I was wondering what sort of thing I could make that would be all of interesting to me, maybe interesting to others, not just version 5000 of something very common, and actually feasible for a beginningish game project. Upon seeing that the First Game video series looked to be about Asteroids, a very simple concept came to mind: Katamari Asteroids. If you're familiar with both games you've probably already got the gist. In Asteroids you destroy asteroids into nothing and try to avoid smashing into them. In Katamari Damacy you roll around attaching smaller objects to yourself, slowly growing larger. So in Katamari Asteroids you still try to avoid smacking into big asteroids, but try to shoot them into smaller pieces you can attach to yourself.

I thought it might help my own thinking a little if I came up with a name more fun and more actually useable than Katamari Asteroids, so brought Google Translate in to help. At first I was just trying variations on Katamari Damacy. That means more or less "Clump Soul", so I was just tossing in variations and alternatives. Spirit, asteroid, mass, growth. But I wasn't coming up with anything that sounded good, wasn't a mouthful, and was still close enough to Katamari Damacy for the reference to be fairly obvious. So I went in another direction.

With a game involving changes in size it should go beyond "asteroids", so I was also trying for words that meant all, everything, entire, things like that. One such word I was already familiar with was Zenbu (全部). The first character of that, Zen (全) means more or less the same thing. While checking on that, I ran across several other Zens. It is a property of the Japanese language that many kanji characters share the same reading, so I was looking at other characters that can also be pronounced Zen, and found a few that would work well together.

Zen 漸 = Gradual progress

Zen 全 = All, entire

Zen 善 = Good, virtue

Zenzenzen 漸全善 = Gradually All Good (more or less). For something where the goal is theoretically to attach everything to yourself, works well enough.

So we've started to get fairly consistent rumors about what the Nintendo NX is. And if they're still on track for a March release, we should see the official version any time. So before that I wanted to get my take on these rumors down for posterity.

Prior to the Wii U's reveal when we started hearing about it using a controller with a screen, I was pretty skeptical. Not skeptical that it was possible, but skeptical that it was the right move. It seemed to be trying to take the DS's two screen feature and replicate it at home, just not as well--with the newly introduced Remote and Nunchuk methods of play left unimproved. I think history has born out that the Game Pad was not something that many people gave a shit about. The one thing I thought it would be really good for was everyone having a personal view and touchscreen in multiplayer, but they went and made it impossible to use more than one on a system, so not even that was doable.

So the big rumor about NX is that it is not a normal home console, but a portable hybrid that can plug into the TV. At first hearing this, I wasn't very happy about it. It used to be the case that portable game machines were essentially like home machines of the past in tech and control. Game Boy like a cruder NES. Game Boy Advance like an SNES. PSP like... well, Dreamcast more closely than either PS1 or PS2. But that changed with DS and Wii. DS's dual screens and touch screens was something that couldn't be done at home, and the Wii Remote + Nunchuk was something that couldn't be done on the go. Finally they'd diverged to something unique. So when Wii U tried to be a Home DS, I felt this was a move in the wrong direction, making them again less unique. So why don't I feel NX, which would flat out combine them into one machine, is a similarly bad move?

The other big thing being bandied about is that though the NX will have a wide design more or less like a GBA or PSP style system, the controller segments at either side can be disconnected and used separately. If they actually pulled this off well, this means that though a hybrid, they managed to retain almost all of the uniqueness of the home and portable lines. The DS's touch screen is represented, and so is the dual motion control. The biggest loss from either line seems to be the actual dual screen clamshell design of the DS machines, which I will miss. But a new and improved type of wiimote/nunchuk already make this seem like a more interesting home machine than Wii U from a control standpoint to me.

Another thing we've heard is that the d-pad may use a split design, more reminiscent of traditional PlayStation d-pads than Nintendo's. If this is true, there must be a good reason for them to go against 30+ years of their standard design, and the best guess of the crowd is that it's meant that they could double as face buttons. Some DS games that had you play with just one hand on controls and the other on stylus allowed for this more or less, but a regular d-pad just isn't quite the same thing as buttons. And why would they do this, beyond an extreme attempt to be left-hand friendly? Again the crowd speculation is that perhaps each controller half can be used separately, similar to how the Wii Remote was used sideways. Perhaps what is usually one main control configuration for NX can be used for multiplayer for games with simpler controls. If each half had an analog stick, four face buttons, and one or two shoulder/trigger/something buttons, that would be plenty for games like Smash Bros. or Mario Kart. I think this is a pretty interesting concept. When playing games sidways remote style on Wii, the nunchuk just became useless. But if the wiimote and nunchuk weren't so different, that wouldn't need to be the case. And though it would be a more limited form of control, it would make it a lot easier to get multiplayer going. You'd only need two full sets of "proper" controls to get a four-player match going, or maybe even when in portable mode if you could find a place to prop up the screen you could play a little two-player with a friend.

I haven't touched yet that this machine is supposed to use game cards like DS/3DS, rather than discs. If it's portable, this is really no shock. Sony tried discs with PSP and even they backed off from that with Vita. And though theoretically discs could hold a lot more now, since we so rarely get a new disc standard it's no stretch of the card technology to reach current Blu-ray sizes or beyond. Rumors specifically say launch games will use cards up to 32 GB, which I find totally believable. I can buy rewriteable 32 GB microSD cards for less than 10 bucks; I'm sure Nintendo mass-producing a more read-only card is able to do much better than that. And if need be who knows how big a game card could be in 2020 or beyond.

Now, speaking personally... I think this is a machine I'd be pretty excited for. Nintendo's long abandoned the major graphics race, and as a guy with an expensive PC I've already got something that beats the current higher tech consoles. So exchanging "behind" graphics for "slightly more behind" graphics but with the ability to take them on the go, that is a trade I'm willing to make. With a Windows tablet I've tried to do a bit of sharing some games at home and on the go, but between bothersome Bluetooth and exchanging save files back and forth it's not very seamless. With effort I can get Fallout New Vegas with low graphics settings running decently. But a new open world Zelda that I can play portably, then just sit in a dock at home to play on a 42" screen instead, with graphics at or above that of the Wii U? I can live with that very much.

A combining of the lines means that games that traditionally stuck to one side will suddenly get a spot at the other. A major example is Pokémon, which has been around for 20 years with all of its most major games on Nintendo portables, while the home consoles get various types of spinoffs or pure battle games that just connect to the portable game. But now a new Pokémon going to the NX also means for the first time a major Pokémon game on a "home" system, unless you want to count things like playing Game Boy games on a Super Game Boy as a legit home console experience.

One thing I am curious about is how game series will be handled that had a sort of split. In many cases the home and portable games were much the same and wouldn't be much affected. NSMB2 and U. SM3D Land and World. Rhythm Heaven Gold and Fever. But for something like Zelda, over the last 15-20 years we've seen the home games try to give an epic scope, while the portable games are somewhat smaller affairs, more retro (or straight up remakes of old games), and of course a lower price as is the norm with portable games. In a combined world, what happens? Do they release both Giant $60 Zeldas and $40 Boutique Zeldas?