Zinac
301
Sonic_Reaper, thats your original sprite. You can only specify 1 color of transparencies in gif, so converting was an issue. I’ll try to figure it out.
Nice, is that shadow done in realtime? If so, these shadows > 3s shadows, haha
Zinac
303
http://sweb.uky.edu/~rclaca2/shobu_screen2.jpg
Fixed, it was just a conversion issue.
Yes they are done in real time. I forgot to realign the sprite properly, so thats why the sprite is slightly off.
Update:
Fixed alignment
http://sweb.uky.edu/~rclaca2/shobu_screen3.jpg
Another update;
The first frame doesn’t have a black outline and the suitcase isn’t shaded at all. Besides that it’s more or less good to go. Started work on the punch.
http://img.photobucket.com/albums/v176/Sonic_Reaper/standip.gif
http://i45.photobucket.com/albums/f67/Grave450/3.png
http://i45.photobucket.com/albums/f67/Grave450/2.png
http://i45.photobucket.com/albums/f67/Grave450/1.png
Made a backround, based off of ignatz’s bg. Still super WIP but the modelings done textureing just need to be finished up. Sorry its not amazing i suck at bg’s.
Zinac
306
I want to make a decision about special and super activation. How much do you guys actually want charge characters? I’m thinking of just implementing simple combos like, QCF, QCB, HCF, HCB, 360 motions, etc. Also I’m thinking characters should not have “button-dialing” combos like some KOf character supers, where you must time a sequence of attacks after activation of a super in order to get the full amount of hits for that super.
Tell me what you think.
Xiii
307
I honestly think that charge moves only really work if they are like how they work in 3S. SF2 and back the moves are either not really used or have high priority and enforces you to just play defensively the whole round. After Super dialing combos is kinda iffy in that Geese’s of KoF can be stopped midway for more damage, but it’s not that big of a deal. Though it might just be another issue with programming, could you program in follow-up supers like Iori’s flame cannon super thing he does at the end of his combos in some of the past KoF games? As in allow for there to only be a certain window of time to do a super, otherwise you can’t.
Zinac
308
For the Iori super thing. It won’t be difficult say if you’re just checking to see if it’s in a certain state, his super state, or have the condition based on the current frame of the sprite. Anything else could get more complicated. Any values that are in memory at the time of the super execution can be easy to test against. I guess for now I’ll implement very simple conditions though. “Is this button pressed? Is the frame timer higher than the count to activate this special/super ?”
I hate saying this again but … keep it simple D=
qc, hc and regular charge moves are fine with me. I agree that 3S did it best. It actually made charge characters useful since everyone had universal super motions instead of that f,b,f or f,b,u+f nonsense.
I’ve always thought the button dialing in snk games is weak sauce. It’s a gameplay device that serves no purpose other than to artificially increase the difficulty of the game. All they do is make the learning curve of the game steeper.
yea i generally agree with sonic. I think keeping things very organized and universal to start would be good then as we go on fine tuning and nitpicking at weird technical. Oh and i never use the button dialing style supers i think their a good concept but hard to put into practice.
personally i’m not big on huge supers though. I like sf3’s concept of choose a super but keep ex’s
im curious are we gonna do some kinda low end gatling system. less ridiculous then gg, or staying like sf2 where if two normals combo its basically by luck?
That’s not bad for a start. Just a few suggestions to make it better though. I don’t know whether you planned on following these suggestions before my mentioning but I’ll just say them anyway…
- Apply bump map on floor and the walls.
- Add some light effects, you’ll most likely would want to use ambient light to keep the effect that you wanted to start.
3)Show some imperfection with your torch posts (i.e. make them looked chipped, broken or knocked down or add some moss or rust texture regarding what it’s supposed to be stone or metal), and judging from the appearance that it looks abandoned, try not to make the formation of the posts look symmetrical.
4)This is merely extra but it could be cool. Add a particle system, whether rain or snow, doesn’t matter. I’m pretty sure at this point the bg would be suited better as some sort of sequence or a highly compressed QT movie.
I also would like to know whether you used 3D Studio Max or some other 3D program.
The button dialing style supers don’t seem like they’d be a special case for input handling anyway. They are the same as any other move, certain sequences trigger them and they can only be triggered in certain states. Its just that usually, for like the Geese button dial super, each state can only be triggered in the proper window of time during a specific previous state. It would probably be best to build an optional list into each state’s definition that dictates what states the character can or can’t be in to trigger a change over to this state.
I did something along these lines for handling MK3 style autocombos, but found it also is necessary for things like Gen’s gekirou because of the different windows for hitting the next trigger button and the fact that it ends with a different hit. It also plays a role in programming moves like Karin’s different dashing attacks (forget the names)
You could do something like that by using a player finite state machine. The player has a list of states and messages. Depending on the current state and the message recieved, the character goes into a different state. For example, if the player is standing and recieves a fierce message, the character goes to its high kick state, but if the player is jumping and recieives a fierce message, the character goes to Jump kick.
Basically, instead of having the move returned from the input tree put the character directly into a move, have the move returned sent as a message to the state machine.
Finite state machines are pretty easy to implement too. It’s just a 2d array with a row for each possible state and a column for each possible message. When it receives a message, lookup the row of the current state and the column of the message recieved and set the current state to that entry.
Hi, not only am I a lurker on the boards here, but also quite new at doing sprite art, nevertheless I thought I’d share my sprite.
I’m not much of an artist, but I wouldn’t mind making in-between animations from keyframes, and I’m pretty good at converting drawings into sprite, nevertheless, just tell me what you guys think of my sprite anymation. It’s supposed to be an evil pink bunny of some sort 
he fights with his ears.
http://members.home.nl/marijnvanputten/bunjmp2.gif
Yeah, the finite state machine concept was what I was referring to when I was talking about changing the characters state. I have my own state system built already. Its a little different from the prototypical FSM that you described because it doesn’t deal with messages that have to be received and processed but instead deals in pointers to objects that have the code necessary to achieve the end task built in. Its pretty quick.
And also, its more in tune with the engine I am working on now. Since I’m modeling it after UMK3, there are a lot of times when the move trigger Does directly change the current state instead of pushing a message to the state machine. Its just how the game works and it basically creates a system that allows for a bit more damage to be done by characters with containment moves and for some offensive blocking if you have the extremely precise timing to do it.
You see in UMK3, for each game tick, it first checks for input and if a move dictates an immediate state change, that occurs (a lot of moves don’t but containments usually do). Then it checks for collisions. This means that if on the exact same frame, a punch connects against an opponent in the air, and something like Sub Zero’s freeze is triggered, the move is triggered before the punch collision is handled. That means that moves like Sub Zero’s freeze that only allow 1 hit before it disables can have 2 hits before hand because the move triggers before it processes the collision. And also, if say you are Sindel and you do her scream containment, she stands there with a giant hit box in front of her. You can fire a projectile through, but if you have precise timing you can run in and tap the block button on the frame the scream should get you. It will detect that you are hitting block first and then detect the collision, so you will basically run forward into a hit box and block it the frame you touch it.
Gotta have those tiny details worked out before the machine can be made.
Looks like a companion/familiar that a character would use in combat. Good though.
This thread’s far too big to read. Could someone give me an update on what you guys are actually up to? Where are you up to?
ignatz: as i said the textures are unfinished and im not really trying to make it look 3d so i don’t plan to use 3d lighting or particles. i just suck at backrounds so i used 3d for perspective. Once its a little more done i’m gonna just finish it ps to get back to a more “hand-drawn” look. I used Lightwave, aka high end 3ds max ripoff.
Demon: um well the programmer side seems to have a engine with some kind of combo and input system working. Animation side hasn’t gotten any finished characters yet but 2 in the works.
Wow! Sounds great. I might have a go at sprite design, even though I’m a complete noob and it would be an MS Paint job.
