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. But maybe in a couple months, I'll have designed characters for a short film that I'm writing. Here's the screenplay for what it's worth.

Sure!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.

tepples wrote:

Here's the screenplay for what it's worth.

Is this an education program for feature recognition, object permanence, and awareness of what information a person would be able to perceive?

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?

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.

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 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.

The offer's still open for the free animation. I'd be happy to do one for Vigilante Ninja or any project if I get a frame to start with. I figure it's probably about an hour per frame, so an eight frame animation should be around eight hours work. I'll revise it too if people have suggestions.

Are there any good threads on this? I'd be surprised if it hasn't been discussed at length.

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.

darryl.revok : 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.

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.

Okay, here's the first draft of a flapping wing animation. This hardly took any time at all, so I plan to do a couple more, maybe a diagonal swooping attack? I can revise this too but I'm not sure if there's really anything I can add that would improve it.

Attachment:

bat.gif [ 617 Bytes | Viewed 5060 times ]

dougeff wrote:

I need 4-5 flapping wing animations.

I did a three frame ping-pong cycle and I don't know if it needs anymore.

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.

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.

This is pretty interesting. The game I'm developing is a bit of a hybrid fighter/platformer, with smaller characters.

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.

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).

Quote:

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.

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.

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.

Quote:

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.

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.

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).

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.

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).

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.

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.

Quote:

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.

That shouldn't be too hard. I'll let you know when I have time to do it.

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.

Quote:

There was even a discussion about making a collaborative fighting game, using various characters from all our projects.

This is really interesting. Do you know where the thread is? I'd like to contribute if this ever resurfaces.

Quote:

and we have to keep in mind some backgrounds should be also present above and below the fighters, and cannot overlap with them.

I guess this answers my earlier question.

Quote:

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.

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.

Quote:

And your bat animation looks very great, by the way!

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.

I'm curious, is the background character going to move via scanline splits?

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.

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.

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".

Quote:

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.

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.

Quote:

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.

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.

Making the character jump isn't going to be any trouble. The only real problem is that you've then got a solid color behind most of the playing field. You can do a scanline split above the character for a sky, and a ground texture below. There will be a pretty big amount of empty space in the middle though.

Quote:

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 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?

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.

Quote:

Personally my philosophy is to always use the simplest mapper possible.

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, 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.

Who is online

Users browsing this forum: No registered users and 2 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum