LF2 GM Progress Thread

[Bamboori]

a-man got me rethinking.
the frames will look like this now:

Code:

case 0:     //standing
    {
        pic(0) state(0) wait(4) next(1) centerx(39) centery(79)
        
        wp_x=33
        wp_y=45
        wp_act=21      

        bdy_x=21
        bdy_y=18
        bdy_w=43
        bdy_h=62
        bdy_spawn()
        
        break
    }

most variables will have a default if not specified, for example dvx = 0 and wp_att (attacking) = 0

[A-Man]

Cool! I would suggest making the default value for "next()" to be (the current frame + 1); such that you won't have to write "next(5)" if you're in frame 4 and so on.

[Bamboori]

good idea!
this is how the standing frames look now:

Code:

case 0:     //standing
    {
        pic(0) state(0) wait(4)
        
        wp_x=33
        wp_y=45
        wp_act=21      

        bdy_x=21
        bdy_y=18
        bdy_w=43
        bdy_h=62
        bdy_spawn()
        
        break
    }
    case 1:     //standing
    {
        pic(1) wait(4) centerx(38)
        
        wp_y=47
        
        bdy_spawn()
        
        break
    }
    case 2:     //standing
    {
        pic(2) wait(4)
        
        wp_x=32
        wp_y=45
        
        bdy_spawn()
        
        break
    }
    case 3:     //standing
    {
        pic(3) wait(4) next(0)
        wp_y=44
        
        bdy_spawn()
        
        break
    }

because variables like bdy_x don't get reset every frame, you can reuse them in following frames if they are the same.
means: in every standing frame you have the same body area -> you only need to define the area in the first frame and respawn the bdy in the other frames.
this combined with lots of default variables will save lots of code lines!

[Silverthorn]

Something something polygons. For example, some characters have really well-defined bdy's (= 2 bdy-tags). I wonder if it was feasible to directly allow a definition of polys for such areas (could apply to itr's as well, of course).

Cool! I would suggest making the default value for "next()" to be (the current frame + 1); such that you won't have to write "next(5)" if you're in frame 4 and so on.

This. So much this. Coding a new sequence and have to track those pesky infinite loops is so infuriating.


Any known limit for tags so far? I.e. <10 itr's / frame or 1 opoint max.

Will you provide an app that lets you code the newly-styled DC? Maybe even code-suggestions and whatnot?

A new system that could replace id-dependent properties? For armor, fusing ability, hp/mp regen, ...

Ability to write your own functions? I.e. "effect=poison(20)" will look for a function called "poison" that fulfills the param-set (--> method overloading?). For example, this function attaches itself to the target and drains hp for 20 TUs, etc.

I personally feel like the last point would be the most innovative because it grants the user practically unlimited freedom (and is certainly a little more user-friendly compared to ASM-madness).

[Bamboori]

Something something polygons.

I'm sure I could manage to do that, but is that really necessary? technically there shouldn't be a limit of frame elements, and most popular fighting games use simple boxes for collision detection. for now i will stay with boxes as it needs less developing time.

This.

Done.

Any known limit for tags so far? I.e. <10 itr's / frame or 1 opoint max.

not yet, but the limit should be fairly high. since my engine will spawn bdy and itr objects, opoints won't really be different from that.

Will you provide an app that lets you code the newly-styled DC? Maybe even code-suggestions and whatnot?

yes. or i will add a tool in-game or at least make code highlights for notepad++.

A new system that could replace id-dependent properties? For armor, fusing ability, hp/mp regen, ...

aka new header tags, next to face etc. yup

Ability to write your own functions? I.e. "effect=poison(20)" will look for a function called "poison" that fulfills the param-set (--> method overloading?). For example, this function attaches itself to the target and drains hp for 20 TUs, etc.

well kinda. i don't think i will be able to make the engine that much customizable (and honestly i don't really want to), but new effects can be discussed with me and the other members and will eventually be added to the engine.

[Bamboori]

I'm done with most vital frames and their handling as well as the game physics!
Tomorrow I should be able to publish a pre-alpha (more like an engine test for you guys)

[AmadisLFE]

Cool, I am waiting for it .
Nice work Bamboori, Can I be a Beta tester?, :P.

[Bamboori]

TECH DEMO IS READY!

physics are almost the same as in original lf2.
in the controls, the number next to each button is the ascii value (gonna build a parser later).
vs mode doesnt to anything yet
and i have wait=0 after all, just realized that after testing against actual lf2.
but who cares :P

exe for Windows <-click me!
apk for Android <- click me!

the android app only works on devices with actual buttons and xperia play layout because i havent really done anything for touch yet.

also i just noticed that dash attack 2 stays in the first frame. thats merely a missing next, so i wont bother with that until the next tech demo

next up will be bdy and itr interaction and/or weapons!

everyone who bothers to download can be betatester

[A-Man]

Woh! Really cooL! I am not really sure since it has been a while since I last played LF2, but the gravity MIGHT be a little off/less. Keep this up!

[STM1993]

Controls for those too lazy to figure it out on windows exe version:
Arrow keys.
Backspace = Attack 1. Enter = Attack 2. Shift = Jump. Ctrl = Defend.

So far:
1) Character has no inertia. He will instantly stop on stop_run or stop walking instead of retaining that movement a little bit.

2) Character can't hold A during jump attack to use jump attack multiple times.

3) Character is 1 TU too slow, as you mentioned in your post.

EDIT:
Frame Rate number suddenly gets bigger for an instant when moving to top of screen.