Back up!
Entry posted by Guest
1,833 views
So, I've been playing a lot of Juno First lately, since I'll be making sprites for it.If you haven't checked it out in MAME, you should. It's a really challenging and fun game. Although it looks like a standard vertical shooter, there's more to it than that. By controlling forward/reverse movement of your ship, it adds a completely different dimension to the game. For about the first three waves, it doesn't make much of a difference.But then... they break out the homing missiles.These little buggers track you like the Swarmers in Defender. To escape them, you often have to back up - fast - then swing around them, and lose them off the bottom of the screen.While still avoiding all of the rest of the bad guys, and their "normal" shots.Seriously - you have to back up a lot in this game.Sprite-wise, it looks like there will be seven enemy sprites to make, plus the player's ship. It looks like each enemy has four (or five) sizes. It doesn't look like there's much if any animation on the enemy sprites, other than the size changing.
Whether or not there are more sprites in the game... I haven't found that out yet.Attract screens like this one (which show all of the enemies) sure make my job a lot easier. Usually, I have to capture a movie of the game, then manually create animated GIFs of all of the sprites for reference. (One of these days, I'll have to find out how to extract sprite data directly from ROMs. I know there's a way to do it, but I have no idea how.)So that brings up the matter of... The list.Here's a list of things that sprite artists need to know, in order to be able to create sprites for an Atari 2600 game. (I'll eventually include this in a "How to" about making sprites.)In general:
- Number of sprites (preferably with names and/or descriptions). This includes multiple instances of the same character. For example, a running and jumping version would be considered separate. Or a flying ship and an exploding one.
- Are they conversions of existing sprites, or originals?
- File format you want the graphics provided in (what I've been doing lately is creating a color animated GIF for previewing, then monochrome .bmp files for conversion)
Then, for each sprite:
- 1LK or 2LK?
- Multi-color or Monochrome?
- Single, Double, or Quad Width?
- Number of animation frames
- Number of different sizes (if sprite needs to be scaled)
- Number of rotation positions (if applicable)
- Does the sprite need to be animated at the different sizes and/or positions?
- Maximum Height
- Maximum Width
Other things to consider:
- Will the game need a title screen?
- Will it need fonts?
- If a sprite is running, can it leave the ground on some frames?
- Can the colors of each scanline change on a per-frame basis? Or must they remain consistent?
- Will playfield graphics be needed? If so, what are the requirements for those?
- Do you want TIA colors indicated? NTSC and/or PAL?
So the sprite list for Ladybug would look something like this:
All sprites are 1LK, monochrome and single-width.Bug sprites must be animated in horizontal and vertical positions. (3 frames each.)| name | w | h | frames | rotation--------------------------------------------------------------------------------------Ladybug 8 14 3 yes - h,vLevel 1 bug 8 14 3 yes - h,vLevel 2 bug 8 14 3 yes - h,vLevel 3 bug 8 14 3 yes - h,vLevel 4 bug 8 14 3 yes - h,vLevel 5 bug 8 14 3 yes - h,vLevel 6 bug 8 14 3 yes - h,vLevel 7 bug 8 14 3 yes - h,vLevel 8 bug 8 14 3 yes - h,vSpare ladybug 8 11 1 noCucumber 8 11 1 noEgg Plant 8 11 1 noCarrot 8 11 1 noRadish 8 11 1 noParsley 8 11 1 noTomato 8 11 1 noPumpkin 8 11 1 noBamboo shoot 8 11 1 noJapaneseRadish 8 11 1 noMushroom 8 11 1 noPotato 8 11 1 noOnion 8 11 1 noChineseCabbage 8 11 1 noTurnip 8 11 1 noRed Pepper 8 11 1 noCelery 8 11 1 noSweet Potato 8 11 1 noHorseradish 8 11 1 noLadybug death 8 14 6 no
Also, for the Ladybug death, it needs to tie into both the horizontal and vertical versions of the Ladybug, since there isn't enough ROM space for two different deaths. So things like that are important to note.Related to that, for games with multiple animations for a single character, is to have each animation listed separately.For example:
Louisiana Larry2LK, multicolor, single-width.| action | w | h | frames-------------------------------Running 8 16 6 Jumping 8 20 4Climbing 6 18 4Swinging sword 8 16 8
Now... the question here is, does 2LK mean that 16 pixels height is really 8 pixels that are 2 scanlines high each?Or, does this mean that it's 16 pixels high, and each pixel is 2 scanlines high (resulting in 32 scanlines on screen)?That's an important distinction.Also, something that came up regarding Stellar Fortress, is that for animated (or rotating) sprites, can the position of the sprite change for each frame in the animation? In the case of Stellar Fortress, this helps to make the ship rotate around the cockpit, which looks much better than rotating around the center of the sprite. This effect could also be used in other animation too, such as someone swinging a sword around, but needing to keep their feet "planted" in one spot.Generally, the more frames and pixels you can give the sprite artist, the better things are going to look. The same applies with colors, too.While working on Reindeer Rescue, Bob was able to change Santa so he could have black boots. This wasn't originally going to happen, but I showed him what it would look like, and he liked it enough to make it happen. As a happy side-effect, the height of the ground sprites also changed from six to nine pixels, allowing for much better looking sprites (especially the milk & cookies).
(Notice Santa also packed on an extra 50 pounds somewhere in there.) :)So, for Juno First, the first step is to identify the sprites. So I had to dig up images of the arcade sprites, and identify them somehow. (Actually, it's probably better for the programmer to do this, since he's the one who has to decide what is going to go into the game.)
Assuming that's all of the enemy sprites, the list would go something like this:
| name | w | h | sizes---------------------------------Player shipAlien 1Alien 2Big AlienSmall UFOLarge UFOSphereAstronautHoming missileTitle screen
And then Chris would fill in all of the necessary information. The "sizes" column indicates how many different sizes of each sprite are needed to give the illusion of them moving towards or away from you. If each size required different dimensions, then those would need to be listed as well. Plus I'd need to know if this was 1LK or 2LK, monochrome or multi-color, and so on.(Meanwhile, while you're waiting for the 2600 version of Juno First 
, here are some links about the arcade version: )
- My review of Juno First for The Games That Time Forgot
- KLOV entry
- Arcade flyer (Konami)
- Arcade flyer (Mylstar)
In other sprite news:John has released another work-in-progress build of Ladybug. He's making remarkable progress on the game. There are a couple of bug sprites I may go back in and re-work, but I think other than the title screen, the game is pretty much done, graphics-wise.Also, Manuel has released a build of Colony 7, that shows everything blowing up. 
It also shows all of the game sprites flying around, and you get to shoot them down. Well, until your cannons get destroyed.Both games are coming along great, and already look like they're going to be a lot of fun. One interesting side-effect of creating sprites (at least for arcade ports) is that I end up playing the original games in MacMAME a lot. It's easy to see why the programmers chose these games (I'm still hoping for Bosconian someday, personally ).Also, Chris posted a build of PoP that's really amazing. After some of my other projects are out of the way, I may take another look at the sprites for this one.Label fun:I started sketching out the Four-Play label this weekend. I'm still trying to figure out where to go with it, but at least I'm putting some ideas down. 
Finally:The Seahawks lost. They started out really well, but just couldn't take advantage of enough opportunities. Plus, there were a couple of really bad calls in there, but in the end, it wouldn't have made much of a difference. They had their fair share of chances, and blew it. It's too bad, because the Steelers really didn't play all that great either. The Seahawks only had to play a little bit better than they did to win. Or perhaps, play the way they did at the beginning, for a longer period of time.Oh well.Say... isn't it about time for spring training to begin?
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
17 Comments
Recommended Comments