kayin's Forum Posts

  • I'd think this would be doable in a different way due to the fact all images are pngs. I'd really love being able to just be able to edit and load up different pal files for sprites. That would be hella super lovely.

  • Loki, I am filled with BILE on your behalf. I would love to publically slander this man for his transgressions.

  • FYi, HD Remix has bigger sprites then Blazblue. HDR meant for 1080p. Blazblue runs at 720p and scales the sprites. That said, Blazblue's giant sprites at least don't look like ass, so who cares.

    I've actually worked on a fighting game engine for a side scroll platformer so I have some experience here. It all depends on how complex you want things to be, but if you're doing a true 3D fighter, the first thing I'd say is to work with arrays to store data. There is a lot of actual databits for each individual move. I wouldn't even use the construct built in animation system (it's keyed for time delta and you need moves to be super consistent, animation wise). Anyways.

    So you'd need a ton of enteries per move. Just for a normal you'd need the command, the damage done, the hit stun caused, the block stun caused, the recovery time for an anti air hit, the velocity changes for the opponent for an AA hit (probably two variables if not more for time/velocity), jump cancalability, gatlingability, proration, special traits, hitboxes(both attacking and vulnerability based) and animation. You can do hit boxes several ways. One is just the basic animation overlay (good enough for me), where you have two objects that animate in sync with the player. But if you want to get awesome, you can define hitbox points in an array relative to the center of the player and then use string functions to split them out and form various boxes. Of course this makes it a pain to properly align hitboxes. If I were doing a serious fighting game, I would probably make an editor to handle all this and then compile the information as data. Granted, this is involving.

    You can do the same with animation. Frame name, wait time, frame name, wait time, blahblahblah.

    A command reader is something I've had a hard time with. I have a solution that works sufficiently well, but for a serious fighting project, thats something you'd have to work on. Maybe we can convince one of the better programmers to tackle this. I'd like to see a system implementation that allows for various input rules and nuances found in other fighting games.

    As for how to program events and stuff, I don't think thats too hard.

    Check Commands

    Advance Movement

    Render hitboxes

    Check for collision

    Set Final animations and positions

    Resolve frame

    I have a pretty basic gatling system already worked out for my game that could be possibly shared, but I think it needs a lot of improvment. I think the important thing for anything like this it to work things out on paper first! An engine as complex as a fighting game engine needs to have a defined structure, or else you are going to waste a LOT of work.

  • I agree with this. Legacy support killed MMF2. But I think you guys know that.

  • This is a silly question and fair in the future, but would it be possible to import 1.0 caps 'to the best of 2.0's abilities'?

    I wouldn't mind importing something thats totally broken and then fixing it -- compared to say, working completely from scratch.

  • Yeah, the timescale event is just to emulate LOZ style scrolling. It's not critical but it matches the style.

    I love the 1 event solution, David. That was way simpler then what I thought was necessary.

  • Thats actually normal. That happened in IWBTG as well I used big platforms like that because MMF2 tended to fail hard at detecting. Construct allows me to do a much thinner platform, so thats not particularly an issue. a 1 or 2 pixel beam will be quite fine.

    As for the platforming issues with the edge, that seems a tad bit weird to me.Once I tested it I adapted right away. There might be a hair bit of an input lag on jumping for some reason? I'll have to look into that further.

    Edit: Simple answer just came to me. The original cap ran at fix framed 50 fps. This runs at whatever FPS (probably 60). Technically speaking you have a 20% larger window for 'jumping at the last minute'. Like how if the game ran at 30 FPS, you'd have twice as much time to hit the button as someone playing at 60.

    Granted in practice I just press jump a hair earlier now it seems. Also, Tte thing that always throws most people off is the kids hitbox is relatively narrow. compared to his boxy build..

  • I whipped together a little zelda scrolling example. I'm betting someone could bust this down into 2 events instead of 5... Heck, now that I think of it, I bet someone could even make this 1 event. While I'd like to see that out of curiousity, here it is, in all 5 events of granduer. 1 and 2 event would really push the bounds of 'human readable'.

    I had to make this for a friend. so I figured I'd share.

    http://kayin.pyoko.org/zeldascrolling.cap

  • heh, cool. My brother and I can't get past Dracula in the first game. And I think there is moving platform support now. Also, what's the red line detector at the bottom of the guy for?

    Well I'm in to that whole custom movement thing, especially back in my MMF2 days (where you basically HAD to, to get something nice done). So thats a floor detector... Though I believe now I could check instead by using 'collision at offset', but this started as a pure code port. In fact, with custom collision masks I can probably turn the kids 3 objects into one -- but I think 2 is fine, just in case I need to do anything that would require them being split.

    Yo kayin welcome back

    ~Sol

    Thanks, boss!

    Anyways, I got I v-sync build up. platform logic runs at 150 ticks, 3 times the original speed. This is the same solution was using for Brave Earth. So a v-synced, time deltaed game that is 100% pixel perfect.

    For things like some enemies and events, I'm probably just going to use normal time delta.

    http://kayin.pyoko.org/iwbtgconstruct3.exe

    Next thing to do is to simplify some code and then add moving platform support and wall jumping... and then for some NEW stuff.

    Also whats this custom movement behavior? I haven't found any real description of it on the site and it sounds like the type of thing thats targeted to me. I don't think I'd use something like that for IWBTG (which I want to of course feel like IWBTG still, so the closer to the original code, the better), but it might be useful for Brave Earth when the feature enters a stable build.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • Since Brave Earth is going to take forever, I decided to mess with some side projects. One of them will be an IWBTG mini sequel with some newer gameplay elements. But the first order of business is to make the old platforming engine work.

    http://kayin.pyoko.org/iwbtgconstruct2.exe

    I think the animation time is off (I almost know for sure it is), and theres no moving platform support yet, nor wall jumping, but it, according to my crazy IWBTG experts who know the game way better than I do, is pretty much 'damned accurate'.

    What amazes me is how much neater the code came out in construct, since I didn't need so much redundant code. Right now it's also accurate in the sense that it is 50fps and fixed frame. Obviously not at all desirable in the long run. I'll be trying to implement my older delta time setup for high accuracy time delta movement. I'll keep this thread updated!

    Mostly wanted to say hi again. It's been awhile! I might not have been posting but I've been checking in occasionally. Problem is I've been doing more animation then coding, recently.

  • Alright, that still sounds nice. Yeah, the detectors solutions are fine, but built in integration with the object would be nice. Ah well, something I can easily live without! Thanks for the answer.

  • Hey kids! Long time, long time!

    [quote:295k2rpu] Another new neat feature which probably won't make 0.99, but will follow shortly after, are custom collision masks, which can be drawn via the picture editor.

    This makes me very interested and I'm extremely curious as to what this entails and might have some feature requests based on how close or different it is to my expectations.

    So I'm a big fighting game guy, to the point where I'm using aspects in it for the game I''ve been working on, so custom collision masks make me automatically think of fighting game hit boxes. Granted, I know the intended basic functionality (just defining a simplier shape for a complex object), I was wondering if the feature would have more advanced functionality?

    What I was imagining was to ability to have collision "layers" on an object have have the abilitity to add as many as you need (terrain collision box, enemy collision box, head collision box, attacking hit boxes, ETC) and be able to adjust them per-frame. This may be way more complicated than planned or only useful to people like me (who can get by with multiple objects for collision), but the concept sounds neat and useful to me if taken to that sort of level.

    If this sounds good and more than your intended functionality, I'll submit a decent feature request. If it sounds silly and to complicated, I won't bog up the tracker. I am very curious to hear how much functionality the feature will have though.

    Thanks!

  • This sounds really interesting. Sadly I don't think I can preempt any shortcomings without say, trying to implement it. It'd be nice to get some of the advantages of behavior with a custom movement engine though!

  • I like that solution. I got lots of old backup caps that I'd like to retrain access to.

  • I'd be 'effected' but what would happen? I assume the events would just be gone? I really don't care, but technically something will happen!