For those who haven't followed the
thread on title screen name table compression, my game is called
Bionic Commander. (To be honest, I'm surprised nobody's poked fun at me for the ridiculous parody, but I digress...)
In the title screen, the word "Bionic" is written with a metallic font. It's looking pretty good so far, but it could use a little more "oomph".
In order to make the metal look more reflective, I originally wanted to add white highlights along some of the edges. Unfortunately, since each 2x2 tile region is limited to 4 colors, I had no available colors left after drawing the sky and landscape gradients. I didn't want to compromise the quality of those gradients, so the highlights got the boot.
Then it occurred to me: what if I layered sprites on top of the background to get those highlights? Doing so would produce the result shown below:
What do you think? Does this seem like a reasonable way to go about it? Any other ideas?
Yeah, it does improve the metal effect. If you have the spare tiles to do it, go for it. There seems to be less than 8 columns of sprites, so the sprite limit won't be a problem.
Oh yes, you should do this. I use sprites + background to make the portraits in my game. In fact, a lot of those look like just straight lines. You could get away with using very little tiles to make these. I think it really does make it more metallic looking.
That's definitely a good way to do it. It does add some nice extra detail.
Thanks for the support! Cool, sounds like that idea's got the green light.
tokumaru wrote:
There seems to be less than 8 columns of sprites, so the sprite limit won't be a problem.
Good observation! I originally had the highlights running horizontally across the tops of the letters, but quickly realized the sprite limit would prohibit it. After switching to the vertical orientation, I think it looks much better. I love it when technical limitations foster creativity.
And yes, there are exactly 8 columns. If you look closely at the letter
B, you'll notice a missing column of highlights. I originally had additional highlights immediately to the right of the two holes, but removed them to stay within the sprite limit. I don't think the omission is very noticeable, nor does it diminish the overall look.
Looks nice.
I did the same thing for a competition hack of Atlantis no Nazo:
The dragon/eel thing on the right uses sprites for both the "mane" and the glowing red eye.
If you want some insane examples of sprite overlays, check out
the ending to Ninja Gaiden 3 (or any of the cinema scenes, really). It's mind-blowing.
SecretServiceDude wrote:
And yes, there are exactly 8 columns. If you look closely at the letter B, you'll notice a missing column of highlights.
Oh yeah... I counted 7 before, but now I see it. And I didn't even miss anything when looking at the B, it's perfectly fine.
I didn't catch the difference at first, but now it's really clear. It's a nice touch.
I think a nice example that really sticks out is in the Batman ROTJ intro sequence with Joker.
This is a good idea, and look better.
Also Bionnic Commander sounds really like a parody of Bionic Commando (#1 on gamefaqs top 10 today btw)
Bregalad wrote:
This is a good idea, and look better.
Also Bionnic Commander sounds really like a parody of Bionic Commando (#1 on gamefaqs top 10 today btw)
One of the only two side scrollers I know of where the player's character doesn't jump, the other being Lode Runner.
Wow, figuring out a good sprite arrangement for the highlights was a pain. After shuffling some pixels around and exploiting the sprite V-flip bit, I managed to cram all the highlights into 6 unique tiles. A more optimal arrangement might be possible, but considering that the per-scanline sprite limit prohibits me from layering sprites on top of each other, I'm pleased with the results.
The colored boxes on the right half of the image indicate where each sprite goes. (There are 38 sprites total.) The red boxes indicate sprites that are flipped vertically.
Also, I went ahead and made the highlights thicker so they'd be more noticeable. The NES ain't about subtlety.
Thin highlights look better.
Dwedit wrote:
Thin highlights look better.
Thanks for your feedback. I appreciate it.
Personally, I prefer the thick highlights, but of course it's hard to judge my own artwork objectively.
So, thick or thin? Could I get a quick consensus from you dudes?
It doesn't make that much of a difference to me but if I had to pick I think the thinner highlights are better.
Okay, it's unanimous: thin it is. Thanks for the responses.
Quote:
Personally, I prefer the thick highlights, but of course it's hard to judge my own artwork objectively.
Well, it's YOUR project or it isn't ?
When doing graphics, it's often really hard to make choises like that. But you can't ask someone else for each piece of graphics if it's better making this pixel lighter or darker, and so on.
I've had in my game a sky that looks green, and I thought it looked weird. So I changed it to blue, but then attribute clash would make the cliff before the sky look parially blue as well, and this was looking horrible. It's hard to chose, have a cliff looking blue and that doesn't look very good, or having the sky looking green. I still haven't decided definiteely, but oh well. I won't ask to everyone what the best is because it's my game so I can't ask to someone else each time I should take a decision.
It is my project, but I hope that many people will get a chance to play it one day. With that in mind, I ultimately want what's best for the game, not my ego.
In the case of the metallic highlights, I was biased towards the thicker ones because I was proud of myself for coming up with the idea of sprite overlays to solve the problem of insufficient background colors. (I now realize the overlay technique is commonplace, but I didn't know that at the time of the original post.) Because of that pride, I wanted to "show off" the effect. It's kind of like a chef who discovers an exciting new spice, but inadvertently winds up ruining his entrées by overusing it.
Since the responses overwhelmingly favored the thin highlights, I took another look at them. I must say, you guys are absolutely right. The effect isn't supposed to be "in your face". It's not supposed to glorify me as an artist. Its only purpose is to make the metal look a little shinier without distracting the eye.
I don't believe in design by committee, so by no means will I ask for input on every decision. And ultimately, I'm the one making the game, so of course I'll get the final say. Having said that, the posters on this forum are incredibly insightful, so I'm willing to consider suggestions and constructive criticism.
The game will be better as a result.
Yes you are right, it's good to be sure to not abuse a good idea you had. Asking to other people may not be that bad for sure, but when you write a game you often have to make choses that are hard to make, and you can't rely on other people to have an answer to all cases. It's really hard to make choises !
Personally I didn't think thick or thin highlight made very much difference. But highlights are definitely much better than no highlights at all.
Have you compared thick or thin highlights on a real tv-set? Since the picture always get a little blurry on those chances are the thin highlights will "disappear".
Anders_A wrote:
Have you compared thick or thin highlights on a real tv-set? Since the picture always get a little blurry on those chances are the thin highlights will "disappear".
That's a very good point. No, I haven't crossed that bridge yet. I'm doing all my testing on FCEUXD SP 1.07, and my friends are verifying that the game works on other emulators as well.
Fortunately, the choice of thin or thick highlights doesn't affect the code one way or the other. If the thin highlights don't look good on a real TV, I can adjust the tiles fairly easily.
It's a good thing to keep in mind, though. Thanks for the heads up.
SecretServiceDude wrote:
That's a very good point. No, I haven't crossed that bridge yet. I'm doing all my testing on FCEUXD SP 1.07, and my friends are verifying that the game works on other emulators as well.
Just out of curiosity, have you already started the game play and do you have already some footage? Since it seems to imply that it would be something related to bionic commando in some way, that would be nice to see what you have in mind. Always liked that game.
Banshaku wrote:
Just out of curiosity, have you already started the game play and do you have already some footage? Since it seems to imply that it would be something related to bionic commando in some way, that would be nice to see what you have in mind. Always liked that game.
I do have some gameplay, but not enough to show off just yet.
Currently, I have some basic controls (running, jumping, crouching, shooting) and collision with the environment; however, the only "level" I have so far is a single screen with no scrolling. There are no enemies and there is no way to die. I do have a "shooting" sound effect, which coincidentally sounds just like the shots in
Legendary Wings.
There are two songs in the game so far: one for the title screen and one for the main game. I still don't support any real instrumentation yet, but the songs already sound pretty cool even in rudimentary form.
I definitely do want to get this game out to people at some point, but it's still too early.
Alas, so many things to do, and so few of me to do them.
SecretServiceDude wrote:
Alas, so many things to do, and so few of me to do them.
That basically sums up my project at the moment. I have a bunch of things I have to do that take up most of my time. I wish there were a bunch of clones of me that would do all that while I work on my game, haha.
SecretServiceDude wrote:
I do have some gameplay, but not enough to show off just yet.
No problem them. Once you're ready it will be interesting to see the results.
Time is always an issue I guess, same thing here. For now I focussed on only something small so I could feel "productive". Now I want to try to make a demo level and start to write the engine but the problem is the artwork.. For now I will rely on extracted sprites from other games until I came make something acceptable, if it even happens -_-;;
You said that the character can jump. So this mean the bionic arm would be gone?
I tried to think of a way on how you could jump and have the arm at the same time and that would be hard with only 2 buttons.
Banshaku wrote:
You said that the character can jump. So this mean the bionic arm would be gone?
I tried to think of a way on how you could jump and have the arm at the same time and that would be hard with only 2 buttons.
The arm will definitely be there, and the player will have to rely on it extensively. But as much as I like
Bionic Commando, not being able to jump is lame.
The control scheme I'm considering is as follows:
D-PAD: Movement
SELECT: Pause/unpause the game
START: Toggle between gun/arm
B: Shoot gun/launch arm
A: Jump
Using the SELECT button to pause the game is somewhat unorthodox, but because the START button is located closer to the B and A buttons, it makes more sense to use that as a third gameplay button. That's what
Mike Tyson's Punch-Out!! does, and it works beautifully.
For people who prefer to use START as the pause button, I might offer a second control type that swaps the SELECT and START buttons. I'd never use that mode personally, but I don't see much harm in having that option.
EDIT: Come to think of it, I may go with the following control scheme instead:
D-PAD: Movement
SELECT: Pause/unpause the game
START: Launch arm
B: Shoot gun
A: Jump
The control scheme above gets rid of the toggle altogether. The player is likely to fire the gun much more often than he launches the arm, so I think it's acceptable to launch the arm using a slightly less convenient button. In that case, it would behave exactly like the star punch in
Mike Tyson's Punch-Out!!
You can also map the jump and the bionic arm to the same button, which means that the player will have to jump first before using the bionic arm. That's what Earthworm Jim 2 did with Jim's Snott Swing, which is like the bionic arm. Personally, I'd think that'd be faster than toggling between the gun and bionic arm with the Select button or using the Start button (especially on an NES controller), but that may not be much of a problem depending on the level design.
strangenesfreak wrote:
You can also map the jump and the bionic arm to the same button, which means that the player will have to jump first before using the bionic arm. That's what Earthworm Jim 2 did with Jim's Snott Swing, which is like the bionic arm. Personally, I'd think that'd be faster than toggling between the gun and bionic arm with the Select button, but that may not be much of a problem depending on the level design or if the bionic arm is also an effective weapon as well.
I do intend for the bionic arm to be an effective weapon in its own right.
By the way, I edited my post above to propose a different control scheme that eliminates the toggle. What do you think of that one?
IMO, I don't think the Start button is very convenient to use the bionic arm, especially on an NES controller, where it's usually harder to press that the B or A buttons. Most emulator control setups also isolate the start button from the A and B buttons; for example, I use the Enter key for the Start button and Z and X for B and A, respectively. I do think the switching between the gun and bionic arm is better if the arm's a weapon. But if it's used mainly for navigation, as is the purpose of jumping in platformers, it seems to me to be more appropriate to map it with the jump button. That's probably why it worked well in Earthworm Jim 2 (SNES and Genesis), since the Snott Swing is used only for navigation.
strangenesfreak wrote:
IMO, I don't think the Start button is very convenient to use the bionic arm, especially on an NES controller, where it's usually harder to press that the B or A buttons. Most emulator control setups also isolate the start button from the A and B buttons; for example, I use the Enter key for the Start button and Z and X for B and A, respectively. I do think the switching between the gun and bionic arm is better if the arm's a weapon. But if it's used mainly for navigation, as is the purpose of jumping in platformers, it seems to me to be more appropriate to map it with the jump button.
When developers implemented control schemes for NES games back in the day, they didn't concern themselves with emulator users and their keyboard configurations. I don't intend to either. For one thing, I have no control over how people configure their emulators. That's their business, not mine.
I dislike the idea of jumping before using the bionic arm because 1) it's an artificial contrivance, and 2) I intend to make extensive use of the bionic arm while on the ground, crouching, etc. Using the START button may not be completely ideal, but something's gotta give somewhere.
Out of curiosity, have you ever played
Mike Tyson's Punch-Out!!? The START button is an integral gameplay button in that game, and I don't find it inconvenient. Would you have done it differently?
Hrm. Both options are a bit awkward, but I think using Start as a toggle is the least awkward of the two. Batman uses Start to select weapons, and it works pretty well.
I actually was thinking the same thing about not planning based on what people will use as their emulator settings, even though I think most people will play this on an emulator. One major thing is that I'll be supporting a left-handed controller setup where the player can actually flip the controller upside down to have the D-Pad on the right and the buttons on the left. Though I may just allow for fully customizable controls, where if you want, up can be walk right, and B can be "access menu" instead of jump or attack, etc.
Programmers should absolutely avoid using start and select during gameplay if possible. It is extremely difficult to reach those buttons while playing on a real controller.
Select for pausing is a real lame. Start was the button meant for pausing in 95% of games, and still is today on modern PS2 and DS games (probably other modern consoles I don't have as well).
I hate how Batman have Start for switching weapons and Select to pause. They really should have made it the other way arround : "Start" is to pause and start the game, as the name implies, and "Select" is to select between different modes, in this particular case weapons (altough many games, including the one I'm programming, doesn't use that button at all).
Only A and B should be used for gameplay features. If that's not enough programm for another console, or make a special controller for the NES with more buttons that is included in your game pack (will be hard to emulate).
So in conclusion, I'd consider select for toggling between arm and gun may be allright, but will still be ackward. I'd recommand just B for gun and up+B for the arm. This should work the best.
Of course if up is reserved to climb ladders, this will make it impossible to use the arm close to a ladder, just like it's impossible to throw a special weapon near a stair in NES Castlevania games.
One idea I had but didn't know how well it would have bode is when you press select, you would activate the "bionic boots" (... kept the bionic commando theme in mind). When the boots are activated, the colors of the boots changes to tell the user that you're now in jump mode. In that mode, you can use the bionic arm and jump. If you need more precision, you just deactivate the boots.
It all depends how you would use the arm in the end thought.
SecretServiceDude wrote:
Out of curiosity, have you ever played Mike Tyson's Punch-Out!!? The START button is an integral gameplay button in that game, and I don't find it inconvenient. Would you have done it differently?
Yes, I have played that game; the Start button isn't too inconvenient because you can't pause the game, and the star punch itself is kind of slow anyway, so the awkwardness to press the Start button itself isn't much of a problem there. If you were able to pause, however, then I'd think the star punch should be mapped to the Select button, and pause should be mapped to the Start button. I think the convention to use the Start button to pause overrides the nearness of that button to the B and A buttons.
Now that you've mentioned that you'd need the bionic arm when crouching, I think toggling between the gun and arm with the Select button does seem ideal overall, but I still think mapping the arm to the A button would be much faster for the player if you're jumping and swinging. Earthworm Jim 2 doesn't have this crouching problem because the Snott Swing is only supposed to be used in the air.
I'm just wondering how your game is progressing.
I stumbled upon this thread, and I have a suggestion for the control scheme. I'd say take a page from the kunio games.
B = shoot
A = bionic arm
B + A = Jump
I think it would make the gameplay a lot sweeter to be able to do this on the fly without the need of a toggle...
Except you'd need to delay shooting/bionic arm by a few frames, or interrupt them if the other button is pressed shortly after the first.
Or in a platformer, you could have Up to jump like in Street Fighter and Smash Bros. Or neutral+B to shoot gun and direction+B to shoot hookshot. If you have a Wii, try some Brawl to see how it makes the most of the sideways Wii Remote, which behaves a lot like an NES controller.