I've been doing a lot of animation lately, and for fun and practice, I want to offer to do an animation for somebody's NES project.
The first person to post a sprite of their character in this thread will get the animation. I don't want to design a character though, so you have to have at least one sprite.
Specify what you'd like me to animate the character doing, how many frames, and tile limitations if any.
You'll get full rights to the animation; you don't even have to credit me. The only caveat is that I want to post it here for feedback, since I'm doing this for practice.
Sure!dougeff wrote:Do you want to do 1 or more bosses for Vigilante Ninja 2?
For right now though I plan to just do one animation, so it would be like, a walk cycle, or an attack, or something of that nature.
I usually do about 8 frames for an animation on my characters. If you want something 4 frames, then I'll do two.
As said in the first post, post a sprite and you've got it.
Is this an education program for feature recognition, object permanence, and awareness of what information a person would be able to perceive?tepples wrote:Here's the screenplay for what it's worth.
There were a couple things that seemed a little confusing and I don't know if it's just me. Why does Bidge say, "I guess you can keep it for a while", giving Mel permission to have her own ball back?
Also, am I understanding this incorrectly or does it rewind to an alternate timeline in which Bidge is aware that Mel had kicked the ball into the toy box? Is it just me or would this be confusing for children?
Same here. In all cases I'd be more interested in being teached how to do great animations, rather than them being done for me.I'd love to take you up on that offer, but I don't have a project at that exact stage of development as of today, unfortunately.
I really wish someone would offer "free enemy/boss AI" instead, because that's the part of my project that has been preventing me to complete it for years. I know I want enemies to attack the player, I just don't know how.
I have been suggested by a member on here that this book: http://www.amazon.com/The-Animators-Sur ... 0571202284 is the resource for learning how to do great animations.Bregalad wrote:I'd be more interested in being teached how to do great animations
Are there any good threads on this? I'd be surprised if it hasn't been discussed at length.I really wish someone would offer "free enemy/boss AI" instead
I haven't got to the point of programming serious AI yet, but for what you're describing, I was thinking of basically having the enemy object test the conditions of it's attack vs. your player data. Specifically position, but you could use things like player velocity as well to make the enemy smarter. If the enemy finds that it could launch an attack that could land, issue that command.
What kind of game are you making?
The boss of level 3 will be a bat.
I need 4-5 flapping wing animations.
Max tiles for any animation is 20, but I prefer closer to 12 (4x3 -ish).
I haven't designed the level, but the background is going to be very dark, black dithered with one of the 0x colors.
- bat.png (3.06 KiB) Viewed 6671 times
The demo I have coded so far is extremely ugly, minimalistic and lack animation, so maybe you'd be interested to work on some animation for that. It's not typical NES graphics however, since those would be of large, probably 5x10 tiles (40x80 pixels) ,etasprites. They will have restrictions similar to BG when it comes to usage of coulours (every 16x16 block will have to use 1 palette, no tile overlapping (or maybe a little overlap just for the face)). It would also require more animation frames than a typical 2-3 animation frame on the NES, although this is not a requirement.
Don't expect a full game to come out with that anytime soon though, so if you are interested you can just tell me, but if you don't I fully understand.
I did a three frame ping-pong cycle and I don't know if it needs anymore.dougeff wrote: I need 4-5 flapping wing animations.
Since the actual animation time for this one was so quick, I was planning to spend a little more time revising it to minimize the number of tiles used. If the bat was symmetrical then that would halve the number of tiles used but could potentially look generic. I'm thinking if I reuse the tiles that are mirrored, and allow some of them to overlap, I can bring this down to a very small number of tiles.
This is pretty interesting. The game I'm developing is a bit of a hybrid fighter/platformer, with smaller characters.Bregalad wrote:One thing that could be interesting was that I was trying to code a small demo / proof of concept, of a NES fighting game with two oponents, one sprite and one BG.
I've considered the possibility before of using background tiles for characters and didn't think of a good way to make it worthwhile. Are you going to use CHR-RAM?
After I do a few graphics for Vigilante Ninja I might try coming up with some basic graphics for placeholders for you if that helps. The problem is that seems like a really big project, and I've probably got a couple thousand hours on animations I want to make for my game. I definitely couldn't do a major animation role on a project lke that.
With that being said though it sounds cool and I'd like to help, if doing a few frames helps. I haven't done anything that size yet, so I'm just guessing being over four times the size of my game characters, a frame could take four times as long. Might be good practice though to do something more detailed than what I'm used to.
No. As long as the demo/proof of concept is simple enough so that a character fills a page (256 tiles or 4kb) it doesn't really matter, and I just use plain NROM right now. If this should one day turn into a fully playable fighting game then I'll most likely need more than one 4kb page for one character, and the only way to switch quickly from one page to another is CHR-ROM. Doing it Battletoads style is unthinkable with large characters. We could use multiple buffers (Prince of Persia style), but then it would limit the rapidity of animations, for example changing from one animation to the next might take a minimum of 5 frames. I believe this would be way too limiting for a fighting game, but I might be wrong.Are you going to use CHR-RAM?
So yeah, CHR-ROM is really the only option here. (Assuming I do not want fancy mappers mixing CHR-ROM and CHR-RAM, or bank switching CHR-RAM).
It really isn't even a project, just a tech demo that is low on my priority list. Just a single fighting character performing a punch, a kick a crouch and a jump animation would be more than enough. Also an advantage of very large sprite is that there needs less to be attention to detail, if a single pixel is wrong it won't make all the difference anymore.The problem is that seems like a really big project, and I've probably got a couple thousand hours on animations I want to make for my game. I definitely couldn't do a major animation role on a project lke that.
If I'd want to turn this into a full-sized game one day, I could always inspire myself from your animations for the first character if you did them. Maybe even re-use tiles. There was even a discussion about making a collaborative fighting game, using various characters from all our projects. The project was given up but it might resurface who knowns.
I am still unsure about what size the fighting characters should be. My current tech demo has a 4x8 tiles (32x64 pixels) metasprites (so about twice as large as your typical NES sprite), but supports 8x10 tiles. I believe using all that space is a bit overdoing it, and we have to keep in mind some backgrounds should be also present above and below the fighters, and cannot overlap with them. This is actually the most limiting factor, combined by the aspect ratio of those characters, obviously.With that being said though it sounds cool and I'd like to help, if doing a few frames helps. I haven't done anything that size yet, so I'm just guessing being over four times the size of my game characters, a frame could take four times as long. Might be good practice though to do something more detailed than what I'm used to.
So I believe a size of 5x10 tiles (40x80 pixels) would be the upper limit on a still standing fighter's area. I could easily expand my current sprite to become a bit larger, and it respect the very standard 1:2 aspect ratio. Some fighters could be smaller than others, to be more realistic, however that would seriously limit the re-usability of thier respective graphics.
I doubt that drawing large characters is necessary orders of magnitude time consuming than drawing small ones. If you get the overall body shape right, then I believe it is quick to make a convincing animation frame, since there is no such need to look at small details. However, I have still trouble doing that right.
So yeah, it's really as you want. I don't want to steal an opportunity for someone else, as this is really a low-priority side-side project of mine. But if you're bored and skilled with animations, and are interested to do something very different, then why not? Who knowns maybe your animation will be so awesome it'll inspire a whole game from my side (of from yet someone else on this board).
Interesting! I don't know how I could get this book in real life, because I don't use amazon. And your bat animation looks very great, by the way!I have been suggested by a member on here that this book: http://www.amazon.com/The-Animators-Sur ... 0571202284 is the resource for learning how to do great animations.
That was a good suggestion about adding another wing flap frame. I also took out one of the frames on the downflap to give it more lively timing.
Yeah, I know what you mean. CHR-RAM is neat for a lot of things but big detailed animations need bankswapping. I definitely need to be able to bank swap for my game engine.Bregalad wrote:So yeah, CHR-ROM is really the only option here. (Assuming I do not want fancy mappers mixing CHR-ROM and CHR-RAM, or bank switching CHR-RAM).
On the other hand, on the quest to find a way to get more than 256KB CHR I came across the Coolboy, with 256KB bankswappable CHR-RAM registers. While I don't know if the Coolboy itself is ideal for production of a final game, I do tend to think bankswappable RAM will be the way of the future of the past of mappers if there are customers interested in high-end mappers.
That shouldn't be too hard. I'll let you know when I have time to do it.It really isn't even a project, just a tech demo that is low on my priority list. Just a single fighting character performing a punch, a kick a crouch and a jump animation would be more than enough.
I'm curious, is the background character going to move via scanline splits? Otherwise it would be difficult not to have them move in a grid. The downside to the scanline splits is that you end up with a blank background behind them.
I'm sure you've thought about all of this stuff. I'd like to know what your thoughts are. Feel free to PM me if you want to keep some stuff non-public for now.
This is really interesting. Do you know where the thread is? I'd like to contribute if this ever resurfaces.There was even a discussion about making a collaborative fighting game, using various characters from all our projects.
I guess this answers my earlier question.and we have to keep in mind some backgrounds should be also present above and below the fighters, and cannot overlap with them.
Have you ever tried drafting your frames first with just the shapes of body parts to get the animation timing right? That's what I do.If you get the overall body shape right, then I believe it is quick to make a convincing animation frame, since there is no such need to look at small details. However, I have still trouble doing that right.
Thank you. I tend to think it needs a little extra flavour. It does look a little better now though. Any critiques would be appreciated.And your bat animation looks very great, by the way!
Yes. At least horizontally for sure, but vertically too probably, unless characters aren't alowed to jump, but that would reduce the fun of fighting. So very likely it'll be scanline split in both axises, with a limited range for vertical scrolling.I'm curious, is the background character going to move via scanline splits?
Another viable option would be split scroll horizontally only, and make the character jump only through different animation frames that would make it effectively look like going up and down. This would then allow an arena consisting of horizontal lines instead of a plain colour but honnestly... I don't think it's worth the bother, especially considering those horizontal lines would share the BG character's palette.
The screen layout would be like that :
Code: Select all
**** STATUS BAR ***** **** ARENA TOP ***** **** FIGHTERS ****** **** ARENA BOTTOM ****
Personally my philosophy is to always use the simplest mapper possible. If I'd go for a high end mapper, then I'd rather go all-out and do 3D rendered game with many co-processors, so the project is still a technical challenge.While I don't know if the Coolboy itself is ideal for production of a final game, I do tend to think bankswappable RAM will be the way of the future of the past of mappers if there are customers interested in high-end mappers.
Yes. I usually draw by hand before I draw on the computer, and also I keep an armless body available as a basis for other animation frames.Have you ever tried drafting your frames first with just the shapes of body parts to get the animation timing right? That's what I do.
I wouldn't sweat the extra scroll split at all. Once you get far enough to have one, making another isn't any trouble. Are you using MMC3?Although I am not even sure if I'll include "arena bottom" at all, maybe just simulate it with a few sprites and/or horizontal lines, in order to free CPU times and stop the scrll split between "arena top" and "fighters".
I have a scrolling engine that can do all of this stuff. It's for MMC3. I'd use horizontal mirroring, then you only have to draw columns to scroll left and right. Your playing field will be a little less than two vertical screens due to overlap from your character BG scroll split. I've also been able to swap as many as two CHR banks as well as a horizontal/vertical scroll split in one IRQ without glitching. If you wanted to use 1KB CHR banks and swap all four it would take two IRQs, however just two 2KB banks can provide infinite tiles onscreen.
Honestly I'm a little surprised how many people say they're sticking with NROM. I mean, I'm not surprised that people use it at a restriction, to say, I'm going to make the best game I can with NROM to push my skills and give the project a feasible scope, I'm surprised that I feel like most people have this perspective.Personally my philosophy is to always use the simplest mapper possible.
Personally, I want to use the simplest possible mapper that will make a game the quality I want. For the animations I want I need 1KB CHR bankswapping and I can't really get around that. A chainable IRQ timer and above all big CHR. 256KB is even a little small for me but I think I can make a program small enough, so that if I use CHR-RAM and compress, I'll leave enough space to fit more than 256KB CHR, with my game, in 512KB. I'm HOPING. That would leave needing larger CHR-RAM than was used during NES's life for bankswapping as the only requirement. That doesn't seem too far for me. It's not putting new hardware in a game to make it work, just a little more of the same stuff that was originally used.