Project NLFFG

[AmadisLFE]

Can I be the "Idea-ist" of this group? No? Okay, anyway, so I only have one serious question to ask, Do you have a pen and paper ready? Is the Data Changing going to be changed in any way? I mean like the Coding and such? if Not then I will join, if Yes I don't think I can join till I learn how to code.

( Considering Data Changing in LF2 isn't all that hard once you get used to it, I don't think NLFFG's Data Changing will be hard. )

[A-Man]

Can I be the "Idea-ist" of this group? No? Okay, anyway, so I only have one serious question to ask, Do you have a pen and paper ready? Is the Data Changing going to be changed in any way?
I mean like the Coding and such? if Not then I will join, if Yes I don't think I can join till I learn how to code.

( Considering Data Changing in LF2 isn't all that hard once you get used to it, I don't think NLFFG's Data Changing will be hard. )

Of course data changing is going to change. We want more mod-ability don't we? Well, we haven't decided whether the A-Engine will be used or will it be another engine (you guys will decide when I can show it), but if it is then:

A-Engine | LF2 General Comparison (Click to View)

A-Engine datachanging (a-engineering as called by @Dragon5 ) is often very analogous to LF2 (naturally, as LF2 was what insprired me to do this in the first place).
For example, here is a fairly basic frame in LF2:

DC-Code: <frame> 123 frame_name  pic: 1 wait: 2 state:3005 centerx: 39 centery: 79 next: 124 dvx: 10 dvy: -5  itr:     kind: 0 x: 0 y: 0 w: 100 h: 100 injury: 100 dvx: 30  itr_end:   <frame_end>

This is of state 3005 which gives the frame no shadows, and if used in a type:3 file, the ball will not fall by gravity. The ball also doesn't go to frame 10 when hit. But "state: 3005" doesn't really tell much about all of this, it just gives an object a bunch of preset properties.

A-Engine:

PYTHON-Code: [f=123] #frame name; not required as its just a comment |NOSHADOW|IGNOREGRAVITY|  img=1 delay=2 center=39,79 x_vel=10 y_acc=5  set_hitbox[x=0 y=0 w=100 h=100 damage=100 x_impact=30] [/f]

(Used a python lexer just to show comments)
Looks clearer I hope.
Instead of states, I let the a-engineers set the properties of their frames. Object types do not exist, and everything needs to be explicitly mentioned using "switches"; these statements surrounded by the "|" characters. There are 10s of these you can mix to give the frame or its components different properties. There exists tags with the name states (named "ai_states"), but these has to do with AI coding.

The 'goto=' tag (equivalent to LF2's "next:") is by default set to @current_frame+1 so that it can be left out in case one is working on a sequence of following frames.

'dvy:' in LF2 misleadingly accelerates the object up or down instead of set its value as a velocity; therefore the equivalent to it in the A-Engine would be "y_acc=" and not "y_vel=". Also, the A-Engine, by default at least, uses an upright y-axis for its coordinates; aka the coordinate system you use in the school's math class:


So to accelerate yourself up, you use y_acc=+5 and not dvy:-5 like LF2.

But in general it's very similar to LF2, and get's rid of the weird preset rules LF2 has. Don't worry ;), you will be able to help.

There are cases where A-Engine can get more verbose compared to LF2, especially when you try to implement a very specific thing in LF2, like hit_fa: chasing which you would achieve instead with the "track_target[]" frame component:

PYTHON-Code: [f=1] #Energy Ball 1 |IGNOREGRAVITY|NOSHADOW|NOBARS|  img=1 center=57,23 delay=2 goto=1  #store screen id of nearest object which isn't of your team and has an id less than 500  set_reg=$target, &get_nearest_obj{@id<500 && <DVZ_ME#2> != <DVZ_ME#3>}  track_target[ |FACEFORWARD| target_id=$target r_acc=2 max_r_vel=10 max_z_vel=3 ] [/f]

Of course this complexity pays off when you try to do something awesome and totally new, like maybe, use this component on a character to set up a z-targeting system ;D

I will try to show some stuff in a video or gifs this week.

[AmadisLFE]

I meant like, is it going to have serious changes, Anyway Looking at the LF2 and A-Engine, it doesn't seem to be too too hard, a few days like 2 or 3 could help me get used to the Dcing Style that will be used, .

[A-Man]

Hey just thought of one thing.
Dk if its not inplemented already though.
If the object is being hit with high position dvy it could bounce from ground and fly up a little leaving some spark for a ground hit .it would open new combo possibilities. Also it would be awesome to see charas being stroke down with fast moving ally falling corpses.

It's possible to do easily without any need of special tags. First, you have the "hit_ground=" tag with which you can set what frame the object will go to if it reaches the ground. In the frame where the character touches the ground, give it "y_vel=-@y_vel*0.75" to make him rebound by 75% of the velocity he had when he fell down.

Possible to do the latter too, by only enabling a hitbox in your flying knocked out frames if your velocity is higher than something:

Code:

#this is only enabled if the x velocity is more than 20.
set_hitbox[x=10 y=10 w=10 h=10 x_impact=10 enable=@x_vel > 20]

I will try doing gifs of the A-Engine doing things from what you asked in the first page.

@V:
Eh, why "however this project turns out"? This will hopefully turn out awesomely, and you'll get to enjoy it together with the A-Engine =D

[Jahvansi]

apart from however this project turns out I realy would love to get my hands on the A-engine, looks realy fun

[AmadisLFE]

Let me give some ideas too, hopefully you have a pen and paper ready will understand what I mean, because not everyone does...

1. Ceilings:
Explanation: This won't be like your Average ceiling which you can go through, it will be like a Solid Object which you can't go through until you break it, functions same way as the ground but it cannot be stood on. ( The Breaking part is optional )

2. Multilevel-Backgrounds:
Explanation: Backgrounds with stairs/ladders/elevators that allow you to go up to a new floor, technically it changes the background for whoever is in the top floor, could be used with the "Ceiling Break" Function to allow one to go up to the roof/different level.

3. Introduction ( Optional Idea ):
Explanation: Heh, did the title Confuse you? Now what I mean by this is like, the character does a small introduction of themselves, in LF2 the character directly goes into the Standing Frames, but the Idea is that the character says something/does something first before going into the fighting frames, kind of like in M.U.G.E.N.

4. Health, Armor, Mana/Ki and Stamina:
Explanation: Last idea that is in my head right now, I saw a small discussion of it, so I decided to extend it further, anyway, maybe we could make Health, Armor, Mana/Ki and Stamina all Configurable? I mean all of the characters will have 500 Health, 0 - 2 armor points, 500 Mana/Ki and I guess like 200 Stamina or so, maybe lower or higher.

The idea is to make it changeable, like a character will have 9001 health instead of 500, or it will have 1 health instead of 500, and or the character will have high armor but lower health or MP, I hope you are getting the Idea.

( I am expecting all those Ideas to be possible in like the A-Engine right now lol. )

[Rhino.Freak]

Let me give some ideas too, hopefully you have a pen and paper ready will understand what I mean, because not everyone does...

1. Ceilings:
Explanation: This won't be like your Average ceiling which you can go through, it will be like a Solid Object which you can't go through until you break it, functions same way as the ground but it cannot be stood on. ( The Breaking part is optional )

2. Multilevel-Backgrounds:
Explanation: Backgrounds with stairs/ladders/elevators that allow you to go up to a new floor, technically it changes the background for whoever is in the top floor, could be used with the "Ceiling Break" Function to allow one to go up to the roof/different level.

3. Introduction ( Optional Idea ):
Explanation: Heh, did the title Confuse you? Now what I mean by this is like, the character does a small introduction of themselves, in LF2 the character directly goes into the Standing Frames, but the Idea is that the character says something/does something first before going into the fighting frames, kind of like in M.U.G.E.N.

4. Health, Armor, Mana/Ki and Stamina:
Explanation: Last idea that is in my head right now, I saw a small discussion of it, so I decided to extend it further, anyway, maybe we could make Health, Armor, Mana/Ki and Stamina all Configurable? I mean all of the characters will have 500 Health, 0 - 2 armor points, 500 Mana/Ki and I guess like 200 Stamina or so, maybe lower or higher.

The idea is to make it changeable, like a character will have 9001 health instead of 500, or it will have 1 health instead of 500, and or the character will have high armor but lower health or MP, I hope you are getting the Idea.

( I am expecting all those Ideas to be possible in like the A-Engine right now lol. )

All these features are very basic and are available in A-engine since a long time

[MoragWan]

I can help with spriting, If this project is serious enough I'll do all I can for this.

[empirefantasy]

no shadow and no gravity

well pretty poor options. first there should be a tag called "shadow", so you can choose which shadow are you going to use or none. coz a big bug of lf2 is that knife have the same shadow with a big attack like fire explosion.

even thought there are y_acc and y_vel (if its not yet it must be), I think there should be values for gravity. well since there is an y_acc, we know that gravity is an acceleration. So in fact there is no need of such kind of tag. lets say we want to make 3 frames with gravity, so we just use the y_acc value. anyways maybe for higher acuity and easy-using putting making this tag more functional would be good.
Same applies for friction. As we know every object have it's own friction (lf2 object or bg area).


Now lets talk about priority. here you can think about parent-child object but I am first referring to global fields of the objects aka tags in bmp part (if there will be one ). So for high practically I suggest to put a priority level on tags such as gravity. So if I want to quick modify any object I can just put a gravity=0/no gravity with a high level and so the whole object become without gravity. or let's say in a system with 10 levels of priority 0 lowest, I can have frames with different gravity levels. say some frames with level 1 and some others with 4 and some other with 7. now if I want to quit grav in some frames (which I have consider that don't need that much gravity and have marked them low in priority) I just put gravity=0 with priority 6 on the top of the file and so only those frames with p7 will "survive" the change. Or maybe an advanced concept would be to write in which frames this priority tag will be applied. so lets give an example frames_where_apply= 10-12 14-20 220-500

how do u think?

[A-Man]

@empirefantasy (Click to View)

no shadow and no gravity

well pretty poor options. first there should be a tag called "shadow", so you can choose which shadow are you going to use or none. coz a big bug of lf2 is that knife have the same shadow with a big attack like fire explosion.

They're enough to cover what wasn't covered. I haven't got simple shadows yet (they're really just circle images which will be spawned on the nearest ground under the character) which WILL be affected by the "width" property of an object and probably other factors like how far the object is from the ground (the circle shadow should get smaller the farther you are). But what's more advanced than that, and what the A-Engine supports are dynamic shape-accurate shadows with shadowmaps. Now I am sure a knife and a big attack will have fairly different shadows .

even thought there are y_acc and y_vel (if its not yet it must be), I think there should be values for gravity. well since there is an y_acc, we know that gravity is an acceleration. So in fact there is no need of such kind of tag. lets say we want to make 3 frames with gravity, so we just use the y_acc value. anyways maybe for higher acuity and easy-using putting making this tag more functional would be good.

while gravity and acceleration are completely indistinguishable, they're different. I'd expect a tag called "gravity=" to overwrite the stage's denoted gravity value, so while what "y_acc=" can do is what "gravity=" can (with the help of variables), I am still keeping "y_acc=" for the sake of consistency (there is y_vel too, of course). I'll get a "gravity=" tag for frames per your request! Though the |IGNOREGRAVITY| switch shall remain because it can be used in the .a file's (== .dat file's) header to have the object ignore gravity in all frames by default which is very useful.

Same applies for friction. As we know every object have it's own friction (lf2 object or bg area).

Yes, sir!

in bmp part (if there will be one ).

lol, yes, there will be one. Though since the engine can load more than the .bmp format (.pngs and various other types I haven't thoroughly investigated), it becomes the "img part"

object .a files general structure (Click to View)

Code:

{pre} #optional stuff
{/pre}

{init} #more optional stuff
{/init}

{main_loop} #even more optionals for doing crazy awesome stuff
{/main_loop}

{info}
#walk speed ..etcetc
[img] # image files
 sheet[dir="filedirectory" rows= columns= width= height= color_key=r,g,b separator=1] #1 px separator (default is 0)
[/img]

[mdl] # 3d models
[/mdl]

[snd] # sound files
[/snd]
{/info}

[f=0]
 img=0 center=x,y delay=1 #..etcetc  
[/f]

[f=1]
 mdl=1 center=x,y,z delay=1 #..etcetc  
[/f]

So for high practically I suggest to put a priority level on tags such as gravity. So if I want to quick modify any object I can just put a gravity=0/no gravity with a high level and so the whole object become without gravity. or let's say in a system with 10 levels of priority 0 lowest, I can have frames with different gravity levels. say some frames with level 1 and some others with 4 and some other with 7. now if I want to quit grav in some frames (which I have consider that don't need that much gravity and have marked them low in priority) I just put gravity=0 with priority 6 on the top of the file and so only those frames with p7 will "survive" the change. Or maybe an advanced concept would be to write in which frames this priority tag will be applied. so lets give an example frames_where_apply= 10-12 14-20 220-500

Hey, that's not bad. It gave me a neat idea of implementing this. I will look into it and let you know of what I've done.
Though, I need to mention that what you said about gravity especially is pretty applicable using existing stuff. You can set a default gravity value for everything in a universal file called "system.a". Then comes the stage files, in which you can specify a new value of gravity that overrides the system.a file's. With the new "gravity=" tag you suggested earlier, one can override the stage's and the system.a's values if he wants to.

There is also the {pre}{/pre} tag which you can use (if you're careful) to set up nice hacks that makes changing overall properties of your character easier. That was actually inspired by the C-family languages' (though it's also available for some other languages too) preprocessor directives. For example, simply put, before the .a file is parsed, it can let you perform find-and-replace text operations in it, even allowing regular expressions for smarter use .

how do u think?

Good ideas!

I was wondering, for spriters willing to contribute, if this style is manageable or not. Faker is sticking to his vow and is not posting here, but I've got his word that this is what's manageable for him.

Edit: Do you mean you condemn the pixel art style altogether, or do you mean to say you just hate working with it?