The Mugen Fighters Guild
M.U.G.E.N Central => Inactive Projects => FullGame development => xnaMugen => Topic started by: Sepp on January 26, 2009, 10:01:38 pm
-
One point that will be brought up about any NewMugen Project is compatibility, and how far it will go in making sure existing MUGEN chars and stages work just like before.
Most of the points I could think of right away are mentioned in this discussion from a few minutes ago:
<[Sepp]> and there will be conflicts of what to drop in order to make it better and not just copy mugen's mistakes.
<[Sepp]> anyway it looks like a good project so far
<Donuts> he'll probably need to decide that for himself
<Donuts> unless he can get ppl to discuss it in a proper manner
<[Sepp]> XD
<Donuts> im not even at all sure of where normal mugen has problems
<Donuts> apart from crashing after a while
<Donuts> he only annouced the projecty recently?
<[Sepp]> well i would be for going his own way whereever possible because nobody needs a second mugen. it only makes sense if we get a better mugen in the end. even if that means that only a few or maybe no MUGEN chars will work on xnaMugen without updates. that would be okay for me; i suppose some people would become updaters and update a lot of creations. and a lot of authors would update their own things. and for the rest, forget about it and mo
<[Sepp]> ve on. but i'm sure a lot of people would also love to see a 100% compatible new mugen where their 200 char select screen works just like before
<Donuts> of course
<Donuts> if all creations had to be updated or recoded that would be a bummer
<[Sepp]> yeah, he annonuced it only 8 days ago [correction: more than 8 days, but still!]
<Donuts> only 8 days ago huh
<Donuts> seems its quite far ahead
<[Sepp]> but, you see, mugen is very very very lax in its behavior. it allows a lot of things to work. even wrong things that shouldn't even work at all. it's kind of like Internet Explorer. it displays even the most broken webpages. =)
<Donuts> hahah
<Donuts> this project should fix things
<Donuts> would be excellent to get a new improved mugen
<Donuts> that allows much more
<[Sepp]> Yup.
If you have another perspective or point to add to the discussion, feel free!
-
It should be just like the dos mugen days, if people wanted to keep their old characters collections to keep on working they should use the old mugen executable.
The thing that calls my attention more on the quote is the "we don't want a mugen clone, we want a better mugen", but it seems like "we" is a very small amount of people, as several well known creators would rather have a clone than a better engine, judging by several points that come out in discussions. IIRC; that is why some of the old clones decided to competely drop mugen compatibility.
-
Agreed, new engine is the way to go that has the functionality but does not necessarily have the same character coding.
I mean at certain point, if more features are added, then old characters won't work.
Can you say dos mugen?
Sucks for old creators, they will have to relearn some stuff.
-
Exactly how big was the change between DOSMUGEN and WinMUGEN? Any way I could see this for myself?
Also at this point, I believe compatibility is the first step. Then measures can be taken to deprecate old syntax.
-
hey corner push !
-
Yes, I agree that the cornerpush should eventually be changed to something that makes sense, like what Capcom and SNK games do. The way MUGEN handles cornerpush now is retarded.
-
Exactly how big was the change between DOSMUGEN and WinMUGEN? Any way I could see this for myself?
- DOS Mugen allowed BMP files in the SFF.
- Some new triggers and sctrl added in Winmugen
- Many SFFs weren't working correctly on Winmugen, and had to be reordered.
- Some CLSN syntax in the AIR file made winmugen crash whereas it was working fine on DOS Mugen.
- IIRC, Winmugen makes a difference between time=0 and !time, or am I mistaking with something else ?
- Winmugen especially allowed graphical updates, with nice transparent FX and FX with unshared palette.
Personally, I'm for a Mugen clone which is compatible with old chars to some extent (à la DOS -> Win). People should be able to fix chars on their own, without spending too much time. Of course, if it's just a clone, it's pointless, which brings us to the things to add :
- new sctrl/triggers. Cyanide and some others already named some.
- Customizable screenpack.
- Interactive stages
etc.
-
Old rare chars shouldn't get in the way of making things better, never ever. Sorry guys!
-
some stuff that allows the opponent body to be easily manipulated after defeat would be great and ease up on the creation of winposes.
also , some kind of function that allows for transformations, perhaps something that replaces the transformed character internal ids, so that when they try to walk it goes automatically to the new sprites for walking, when he is thrown it goes automatically to the new hurt sprites.
-
also palette manipulation midfight, and sorta easy palette cycle thing
projectile reflection handled with more options/possibilities to choose from
P1 using P2's files
palfx a la kof
horizontal envshake
zoom in zoom out a la samurai shodown
more palette selection range(z+a, b+c, start+b+y etc...)
...
-
See i don't want to go that far right now. I think cloning and improving on mugens current code parsing and syntax is more important than thousands of new features. Obviously new features can be added, but i wouldn't like them to get in the way of sctrls and triggers and parameters that currently exist, and work as intended.
Exactly how big was the change between DOSMUGEN and WinMUGEN? Any way I could see this for myself?
That? That was tiny. Added some of the functions from linux mugen like the AD256S256 thing in the air file. Few things in the screen pack. 2000,01,01 to the next update was a far bigger change
Dos mugen required everything in the same pallete and was far stricter on your sff. Winmugen is pretty lax really. BMP wasn't an option
Commands and name strings HAD to be enclosed in quotes. This meant everything had to be updated, no question. system.def changed as a whole. No screenpacks would have worked.
Basically everything needed to be updated. This meant we got a better mugen. Disabling and forcing things that are done badly to be redone properly is not anti compatibility. It's anti sloppyness. If something is shitty. Force it to work as required and people can update for a properly formatted character.
-
See i don't want to go that far right now. I think cloning and improving on mugens current code parsing and syntax is more important than thousands of new features. Obviously new features can be added, but i wouldn't like them to get in the way of sctrls and triggers and parameters that currently exist, and work as intended.
I agree.
Exactly how big was the change between DOSMUGEN and WinMUGEN? Any way I could see this for myself?
That? That was tiny. Added some of the functions from linux mugen like the AD256S256 thing in the air file. Few things in the screen pack. 2000,01,01 to the next update was a far bigger change
And what about that one? =P
-
I would agree if this wasn't in the .net format. Being that we won't see this on other platforms, I'm just thinking that, maybe it should be adding more functions.
Each to his own though, ya know?
-
Exactly how big was the change between DOSMUGEN and WinMUGEN? Any way I could see this for myself?
That? That was tiny. Added some of the functions from linux mugen like the AD256S256 thing in the air file. Few things in the screen pack. 2000,01,01 to the next update was a far bigger change
And what about that one? =P
That was this
Commands and name strings HAD to be enclosed in quotes. This meant everything had to be updated, no question. system.def changed as a whole. No screenpacks would have worked.
Every single character in existence was broken. Absolutely everything had to be updated. I was in the middle of creating my first character at this point, so i'm not sure of all the details but it caused more of an uproar than the winmugen update.
I certainly don't want to start cloning features like that time = 0 in the common states not working when read by state -2 thing. Or the way nothitby currently works, don't want to clone that either. I would prefer that we temporarily lose some characters to make things better rather than keep everything + the bugs just for compatibilities sake.
Adding new features i am happy with, but only after the old stuff that we KNOW functions properly, is functioning properly. Getting MAF- or AF+ working in the hitdef should take priority over stagevar(pos)
-
dos mugen supported 16 bit pcx files, that must be what cybaster tried to remember. Also 01 mugen did NOT support any type of expressions whatsoaver, hence why some triggers look like elecbyte was on drugs (animelem) when they made them. not to mention that there was almost nothing on documentation so a lot of triggers were added (see support for expressions).
-
Now of course, there are shitloads of things i DO want.
rootvarset
rootvaradd
sprexist(grp,img)
hitoverride allowing damage from p2stateno attacks. Not the state change just the damage
reversaldef functioning alongside a hitdef
a guarding movetype
defencemulset working properly, not as part of a combo
attack and defencemulset should be asserted, not permanent. Changing them back to normal when the effect wears off is annoying
Modifyexplod overwriting everything you insert. If i have bindtime = -1 on the original explod and i specify bindtime = 2 on the modifyexplod i want that to take effect thanks. Not this pick'n'mix thing it does.
A horizontal envshake
Being able to redirect to the thing that's actually attacking you. Enemynear and so on is alright. But so often i want to use something that's ranged without doing a load of shit to prevent it breaking in teammode.
A distortion effect managed via sprite. If i put in a circle and type = distort. The circle is invisible but everything under it is kinda magnified.
Inbuilt management of stocks rather than a constant powerbar.
F and D hitflags not BOTH being required for hitting a D opponent. If it's D it should hit D, not D and F.
I probably have a longer wishlist. But those are some of my biggest annoyances and desires. And i'm happy for them all to take second string to having most of mugen's current functionality recreated. Aside from the shit stuff. That can bugger off. You seem to be doing an excellent job removing some of it, please continue.
In terms of helpertype = projectile. All i can really think of as important pieces of functionality here are inheriting the parents juggle points, and not increasing the opponents hitcounter if hit.
-
hey corner push !
Yes, I agree that the cornerpush should eventually be changed to something that makes sense, like what Capcom and SNK games do. The way MUGEN handles cornerpush now is retarded.
Beat me to it. :P
-
dos mugen supported 16 bit pcx files, that must be what cybaster tried to remember. Also 01 mugen did NOT support any type of expressions whatsoaver, hence why some triggers look like elecbyte was on drugs (animelem) when they made them. not to mention that there was almost nothing on documentation so a lot of triggers were added (see support for expressions).
Heh, that was even worse with the early mugen releases... do you still remember when characters had only 256 life points? I remember several people complaining on Bravenet about the fact of being forced to update creations and make them compatible with the new 1000 points lifebar system
-
If you want to make mugen better, one of the things you can do is add elements from fightermaker (seriously) . . . i can make a whole topic out of it if you're interested.
-
Like?
-
I guess he's talking about all the customizations possible in a fullgame point of view : storyboards, better interactions between chars, high-res menus, intros, etc. As well as save option to unlock chars and the such.
Clearly not a priority in a char creator point of view, but something to think about once (and if) everything is implemented correctly.
-
STOP SCARING THE CODER!
you will make him run away like that.
-
this shouldn't be seen as a burden of living up to the expectations of people, for now it's just some brainstorming that isn't supposed to make anyone feel like they are forced to do things, more importantly just some sort of reminder in order to make current progress modelable with future content/feats, sorta insight in the future to prevent conflicting decisions and overhaul/recoding of stuff with each new version of the software
hell I couldn't say it any better atm, you get the idea
-
It's brainstorming that has been done dozens of time before, so let's keep it elsewhere and concentrate on mugen bugs that are better not being duplicated.
-
STOP SCARING THE CODER!
you will make him run away like that.
I don't scare off that easily.
My long term goal for xnaMugen is too get it to 99% WinMugen compatability and then use the experience & knowledge I gained to create my own fighting game engine.
-
I think a big thing would be to fix up the glaring flaws along the way, points where the docs say one thing but mugen does another...but possibly allowing for some flexibility and improvement on the documentation where this isn't an actual "glitch"
Case in point, animtype for hitdefs. It never states in the docs that this parameter only checks the first letter of the string, meaning that for it "Hard", "Heavy" and "Hamburger" are all treated the same way due to the H in the front. That's something that should be fine to leave.
On the flipside, stuff like animelem as pointed out should be fixed. DefenseMulSet is a big offender too.
-
STOP SCARING THE CODER!
you will make him run away like that.
I don't scare off that easily.
My long term goal for xnaMugen is too get it to 99% WinMugen compatability and then use the experience & knowledge I gained to create my own fighting game engine.
Interesting. Not making use of what you've already achieved in this situation? I mean, fighting game engines are great, but if your new one worked in a lot of what already exists in mugen you'd get an instant fanbase. What would you do differently?
More on topic. What do we have as bugs so far?
animelem
defencemulset
nothitby
hitby (probably)
cornerpush
modifyexplod
reversaldef
hitoverride+p2stateno
time = 0 + common1.cns + -2 and -3 states
Sloppy parsing
Anything to add? A listing would be easier to read than picking bits out of posts.
-
What's wrong with ModifyExplod, ReversalDef, and HitOverride?
-
reversaldef, cannot be active alongside a hitdef
hitoverride disallows damage from p2stateno attacks (for that matter the docs list these as issues)
modifyexplod
I have had times where it won't rebind. And there was something in tips and tricks recently where you couldn't make the explod move faster, after being sped up once already via state -2. I've had my own series of stupid issues with it not quite acting as expected. How hard is it really to specify a new position and have it take. Modifyexplod should be overriding the original explod settings. Not taking bits and pieces dependant on what was set in the explod ctrl in the first place.
-
My long term goal for xnaMugen is too get it to 99% WinMugen compatability and then use the experience & knowledge I gained to create my own fighting game engine.
So you want 99% working clone ? It means it will be no new features (besides fixing/improving/finishing current ones) [size=5pt]like Online Mode[/size] ?
-
With ModifyExplod, you can't change the explod's velocity, which I was trying to do for Barns' intro. >:|
I think you should make every value of Explod work for ModifyExplod.
-
the -2 state thingie should not be changed as it might break some other stuff, at much a -4 state should be added that is run after regular state code is run.
[EDIT]
also, we have to think on a way for stuff to be done "after the frame has been logically rendered" so helpers can be re-bound to a parent that got hit/moved.
-
I personally would like to see stages get clsn boxes.
-
My long term goal for xnaMugen is too get it to 99% WinMugen compatability and then use the experience & knowledge I gained to create my own fighting game engine.
:thumbsup:
-
I personally would like to see stages get clsn boxes.
Would be easier to say let them be able to spawn helpers.
-
Good point, I'm still thinking inside the mugen box.
-
Also you can do something better with the select screen
-
Character features first! As far as i'm concerned the screenpack can die for the moment and we'll do it over in a different way.
-
Folks, this thread was about focusing on getting a mugen clone and fixing or not the current bugs. This is not a wish list, so if you want one, create a new thread for that.
-
I guess you're right . . . i'll come back later in the future :sneaky:
-
When we're talking about reversaldefs not activating, you mean at the same time correct? i.e. A red collision box cannot reverse an attack and hit the opponent at the exact same moment, but rather that it will choose the first of the two actions (hit if hit activates first or reverses if reverses activates first). I personally like that. I think both at the same time should be an option, but not the only way reversaldef would function. Like adding a line that states something like reversaldefattack = 0 or 1. More user friendly than having to find a work around.
-
hitpauses lose a tick to what they are supossed to be, at least to what the documentation says. I mean if you have an element that last 5 tick and a hitpause that last 10 tick, the element won't be shown 15 ticks but 14, if the element last 10 ticks and the hitpause is set to 0 the element will last 9 tick, the only exception is the obvious one.
-
If we're talking about wants in a new engine... all I want is to be able to have better control over my helpers, to be able to hit them, them to hit me and so forth.
-
WHat I want tis to be able to encript content, that way people who complain about other people taking stuff from them will shut up.
-
WHat I want tis to be able to encript content, that way people who complain about other people taking stuff from them will shut up.
For MUGEN code? No way in hell. xnaMugen reads .cns files & creates data structures for use in its state machine. To go from those data structures back to .cns files, perfectly readable by anyone, is easy. With what I have now, I could write a state file cleaner in about a hour.
-
Uh yeah too bad the project is open source. ::)