YesNoOk

Show content

This section allows you to browse the content for this member. Note that you can only see content for which you have sufficient viewing permissions.

**
3 is Offline
Contact 3:

3

User

Messages by 3

Page 1 of 41 2 3 4 > Last →
    

Re: Using frame data to balance your game +neat excel tool.

 August 18, 2012, 08:33:25 am View in topic context
avatar  Posted by 3  in Using frame data to balance your game +neat excel tool. (Started by Liero August 11, 2012, 01:04:14 am
 Board: Development
Just No Point said, August 16, 2012, 04:38:28 am
^I don't understand how his approach makes any of that stuff not possible?

It doesn't. I just don't want some naive person coming in here and thinking they've discovered the meaning of life by learning how to read frame data. (Guess I'm the one being naive, eh?)

Liero said, August 16, 2012, 07:24:39 am
If you're just throwing numbers around, you lose these subtleties.

Right, and I agree. But the point is that these are subtleties; subtleties to the extent that I doubt they were ever considered at first. They were part of that organic process I mentioned. An analogy: strongly exaggerated characters often show up either at the top or the bottom of tier lists. Obviously this is because some of them are capable of taking advantage of a given game's mechanics and others aren't. Why would anyone possibly design a zoning character in a game where zoning's impossible or a character with useless normals in a footsie-based game? Evidently somebody didn't think things through. But did they not think things through because they didn't understand their own game, or did they just want to see what players could do with unsuitable tools? I wouldn't be surprised if the former was true more often than you think. Often it’s the players who work out what actually works and what doesn't; right down to the subtleties. And when all the subtleties are figured out, a game based on them becomes sterile; just routine vs routine. That's why it's important that you keep your design as open as possible.

Liero said, August 16, 2012, 07:24:39 am
Actually, that is PRECISELY what it is.  Have you played SF2HD Remix?

Yeah, I think that, if we didn't have one before, we definitely have an impasse now.  It's become a chicken-and-egg argument. You use HDR as an example of the typical design process; I say the opposite: the only reason Sirlin made the changes he did was because of the game's totally unaccommodating base design. Why else would Capcom experiment with Alpha Counters and parries and whatnot (and hell, even the SF3 priority system) all throughout the series? I think (however misjudged they might have been at times) they wanted to make their games more robust and totally avoid the matchup-specific nonsense that had to be dealt with in ST. If they'd have added some mechanic to HDR it sure as hell wouldn't be ST any more, but it'd fix the dumb things. I mean, to make my argument sound ridiculous, what would happen if every character had an anti-Guile move? And every character had an anti-Balrog move? Maybe SFII's a bad example...

Look, all that I was trying to say by that is that you should never be in a position where you have to go "character x has a move that totally shuts down character y, we need to specifically deal with this move". Your system - and the basic design of your character, way beyond specifics like frame values - should be flexible enough to deal with that eventuality, and anything related. Doing things the other way is a mark of desperation; a sign that you haven't accomodated for some cruical possibility and need to fix it by any means. If you run on that philosophy, the game'll just turn into counterpick vs counterpick and nobody'll ever be doing anything interesting. I may as well be playing one of those degenerate AoS games.

And yeah, I've noticed as well that trying to change people's mind on the internet never works. Apologies for being so exasperating. I'm glad we had this conversation, even if you aren't.
    

Re: Using frame data to balance your game +neat excel tool.

 August 16, 2012, 03:20:06 am View in topic context
avatar  Posted by 3  in Using frame data to balance your game +neat excel tool. (Started by Liero August 11, 2012, 01:04:14 am
 Board: Development
My argument isn't about balance and accuracy and such. It's that I disagree with your apparent design approach.

The fundamental point I'm making is that I disagree that manipulation of frame data should be used for much other than general tweaking purposes. A character is not rendered interesting because it can, say, link a strong to a forward or it has frametraps. All you're doing by making that the case is obfuscating the autopilot button-pressing players end up doing anyway.

I mean... is there some important difference between landing normal one and landing normal one followed by normal two? It might be shoving the character up and down in the tier charts, but is it actually giving them any new options? Is any of this making the player think? If the player isn't thinking, they're not playing a game: they're going about a routine. Every time a player tries to do something - be it getting in or stopping a jump-in or landing a clean hit or whatever - they should be faced with a dilemma. They should have to weigh up their options and think.

As I'm sure you're aware, a lot of this is different when it comes to 3D fighters because those games are mostly based around mixup offense and as such figuring out the proper response to move x or y is a large part of the gameplay. But in 2D games 90% of a matchup can revolve around whether a character can zone or not or footsie or not or whatever, so it's things like that designers should be focused on making entertaining. The fun part of play isn't mashing a sequence of 20 button combinations with precise timing into your muscle memory or following blockstrings, it's dealing with the issues your character has and the strengths of the opponent. Don't rely on frametraps to make the game entertaining because - so long as you're dealing with a reasonably traditional 2D fighter - frametraps aren't the core issue people will be dealing with.

What I was trying to say by mentioning CvS2, Jojo etc. is that those games have all sorts of odd crap that goes beyond the stated design. Roll cancels, kara cancels, walk cancels, maha tandems, unblockable setups, ground resets, OTG combos... nearly every game has something like that, and they'd be less interesting without it. Does it affect balance? Sure. Does it completely break the game? Most of the time, no, because the players figure out ways around it. Did the designers anticipate it being possible? Did they buggery.

Design isn't about ticking boxes and going "how can a character deal with this or that" ("we want to give Protoss a new anti-Mutalisk unit"). It's about creating challenges and giving the player the tools and letting them figure it out. To generalize the argument further and make another example, I have this same issue with the status quo of combos in most fighters. If there's a "best" option that everyone's going to use, should I ever have to consider my approach? Surely I can just do the most efficient thing every single time and never have to try. What's the point of there being combos at all? Now, if I had to make a choice between hard knockdown and low damage or long knockback and medium damage or a total loss of momentum and high damage, it'd be better, because I'd have to keep reconsidering what's important in the match.

Maybe I've got you wrong and you already get all this. And yes, I know this is a hyperbolic and reactionary way to respond to someone talking about using frame data. But I think it's incredibly important that people - especially those in hobbyist circles like MUGEN - understand that they should be making brave design decisions and making sure that they're not getting trapped in the semantics of the established genre. Push things forward, don't copy things that already exist.
    

Re: Using frame data to balance your game +neat excel tool.

 August 15, 2012, 06:05:10 am View in topic context
avatar  Posted by 3  in Using frame data to balance your game +neat excel tool. (Started by Liero August 11, 2012, 01:04:14 am
 Board: Development
I think you've kinda misunderstood me here; I don't have anything wrong with frame data being used. I'm trying to illustrate a principle.

What I'm trying to say is that you shouldn't be overengineering things. Players can do amazingly creative things with well-designed systems - and badly-designed ones too - but if you make it so that the only things that are possible are the things you want to be, you stifle that creativity and end up with a sterile game.
     Posted: August 15, 2012, 06:22:51 am
If you get things right at the fundamental system level, give your characters options, and fix things that are causing trouble, the specifics won't matter anywhere near as much. There are plenty of games around with weird quirks that haven't suffered from them (Jojo, CvS2, the more adventurous KoF games...).

(character limits, heh)
    

Re: Using frame data to balance your game +neat excel tool.

 August 13, 2012, 06:29:41 pm View in topic context
avatar  Posted by 3  in Using frame data to balance your game +neat excel tool. (Started by Liero August 11, 2012, 01:04:14 am
 Board: Development
While considering frame values can be very helpful, don't forget that many games have means of avoiding infinite combos/infinite pressure/etc. that go beyond tweaking numbers. I agree that it's a necessary process to an extent, but there are more sound ways of going about things at the structural level.

The best example I can think of is GGXX. Loops are always eventually cut short because the longer your combos get, the more pushback you get. Even if an infinite were to exist in that system - which is unlikely barring totally incompetent design (FD cancels, lol) - proration and bursts means you'll have a chance of getting out of it. Smart design fixes the problem before it exists.

(GGXX also has a bunch of other cool esoteric things about it, which may or may not be complete accidents of design, like the relationship between meter gain and FD cancelling, SB and IB encouraging fake mixups, burst-unsafe combos vs burst baiting vs burst throws... but that's another subject entirely)

Of course, a given designer might not like the idea of a long combo shoving you out of the corner, but there are other options. Complex juggle systems are perfectly viable in MUGEN if one's willing to be a little ingenious with the implementation (The_None's patent juggle system is a familiar example).

Besides, frame data can be misleading. Taking it for granted can sidestep issues of pushback, cancels, execution time, psychology... there'll always be trial and error involved, no matter how good things look on paper. If numbers were the be-all and end-all of balancing theory fighting'd actually be viable.

But that said, I'm of the opinion that the best systems come to light organically; the best games are the ones where players have pushed the boundaries of the system and relative balance has arisen naturally. As for the problems designers face, well, we always have the failings of previous games to learn from. The key is making sure you understand what went wrong, and what effect changing things will have.
    

Re: A vaguely complicated system idea

 August 06, 2012, 03:52:01 am View in topic context
avatar  Posted by 3  in A vaguely complicated system idea (Started by 3 August 03, 2012, 04:31:10 am
 Board: Development
Even if a single-helper approach is more elegant, surely it'd be easier to just use a hitoverride on the nodes themselves? As I said earlier, the nodes can be destroyed if they're placed in an obsolete location or too close to an existing node, so the chances of them getting out of hand are slim.

My plan as it stands is something like this:

Root: Free vars bitshifted to bools. Bools used to construct array made of cells. Array can be updated in -3.

Node = Helper, is destroyed when hit by non-projectiles (to avoid accidentally blocking projectile helpers) via hitoverride. Can be placed freely. Makes sure it's within the bounds of the array when created, otherwise it's destroyed. Does nothing else.

Controller = Helper. Runs a loop through three states:
1. Get position of any helpers within the array, and check if they're nodes. If they are, destroy them if invalid, then check if they're over x ticks old and spawn influence in the nearest cell if they are.
2. Spawn influence in cells nearby to nodes and existing influence, but not too far, and not overlapping cells influenced by the opponent (if applicable).
3. Update graphics by spawning explods in filled cells and (maybe) explods in cells adjacent to filled cells (edge effect).

This should allow some compatibility with characters not coded to fit the system.

Thanks to the both of you for the help so far; it's made at least the theoretical part of this idea go by a lot faster.
    

Re: A vaguely complicated system idea

 August 05, 2012, 09:28:10 pm View in topic context
avatar  Posted by 3  in A vaguely complicated system idea (Started by 3 August 03, 2012, 04:31:10 am
 Board: Development
I like it. I can work with things resetting round to round, but the players' influence overlapping is more of a problem. I'm guessing it lies in not being able to properly redirect to the equivalent enemy helper?

There could be a couple of other possibilities. One way of getting around the reset might be to purge all root vars and use them as temporary storage for the helper's vars until the start of the next round, preserving the matrix. Obviously that might cause other issues.

The other idea is a combined approach, using multiple helper nodes and explod influence. A controller handles the influence growth; meanwhile, each node checks around itself for enemies in the appropriate anim, and removes them if they're too close. The positions of each node are stored in the root player (and it might as well be the player comparing node positions, not the nodes themselves). This may result in a no-man's-land of sorts between p1's nodes and p2's nodes, but it'd stop them from overlapping, simply because they couldn't actually be placed close enough to overlap. Or is there a functional issue with using helpers at all for this?
    

Re: A vaguely complicated system idea

 August 05, 2012, 05:33:32 pm View in topic context
avatar  Posted by 3  in A vaguely complicated system idea (Started by 3 August 03, 2012, 04:31:10 am
 Board: Development
I had a related, although really dumb practically speaking, thought about how one could implement this sort of thing more neatly. Basically it'd involve each node being made up of a bunch of connecting pieces (say center, edges and corners). You'd have a different state and a different anim for each of these, plus a set of "joined" pieces. Initially a node would just be the center, and as it reached different stages in its anim, it'd spawn the other pieces around it.

The crux of the idea is that each individual piece would check on contact with another piece (via the aforementioned ReversalDef) the state of said piece and spawn the appropriate "joined" piece, then both pieces would destroyself (I guess MoveReversed would work for the passive piece). If that sort of thing could work out, it'd be totally possible for there both to be cohesive, non-overlapping graphics, the potential for nodes to spread influence in any and all directions, and a limited number of helpers (since they'd constantly be "merging" into a smaller number of individuals). On the logic side of things, you could have a heirarchy: the smaller pieces are always overridden and absorbed by larger ones, and "equal" pieces just sit next to each other and do nothing.

I don't know if it's the sort of thing I'd be willing to implement as far as my plans go (too much boilerplating) but it might be of use to an unconventional character. Better here than in my head.

On the bitshifting front, I was trying to figure out a way of forcing each node into one var. Mixing positive and negative values in a single var is problematic to say the least, so accounting for negative pos values might be an issue. But if I deliberately give the pos values a larger address space than they need, I can translate. For instance:

var(whatever):
12 bits <- 12 bits <- 5 bits <- 1 bit
x pos <- y pos <- node stage <- existential doubt

If the x/y value is negative when recorded, it's flipped to positive and has 2048 added to it. When the system replaces the nodes at the start of a new round and it finds a value >2048, it'll take the 2048 off and flip it to negative. I essentially have four addresses; positive y, negative y, positive x, negative x, even though all the values are actually positive. I think that'll work.

12 bits should be enough for safety's sake, especially if I do something hackish with y values (like destroying any nodes placed above the character's jump height, in case something puts you into a falling state off the top of the screen).
    

Re: A vaguely complicated system idea

 August 03, 2012, 04:55:35 am View in topic context
avatar  Posted by 3  in A vaguely complicated system idea (Started by 3 August 03, 2012, 04:31:10 am
 Board: Development
Yeah, I was planning on it being a per-match thing. But I forgot that helpers are cleared between rounds, and I forgot that MUGEN had proper bitwise operations, as well, so that's all helpful. If only it had actual arrays things'd be a lot simpler...
    

A vaguely complicated system idea

 August 03, 2012, 04:31:10 am View in topic context
avatar  Posted by 3  in A vaguely complicated system idea (Started by 3 August 03, 2012, 04:31:10 am
 Board: Development
So after playing a whole bunch of RTS games, I thought it'd be interesting if fighting games had the same element of progression. I'm a relative novice to MUGEN scripting, and chances are someone has a better idea of how to implement the sort of thing I'm gonna propose, hence this post.

A description of the system:
The character has a "tech" meter, which gradually fills over time. The character can trade power for tech via a charge anim, or can increase the general rate of tech growth by controlling the screen with "nodes"; the more space you control, the faster tech grows, but nodes can be destroyed by being hit. Node influence doesn't overlap with existing influence, as the point is to cover the screen with influence, not spam nodes on top of each other.

When the tech meter is full, you can level up your character; doing this unlocks a previously locked move (which you select right there, although your choice is concealed from the opponent), increases your max power by 1000, and increases your base attack/defence values slightly. There are 5 levels in all, and each one takes more tech to get to.

tl;dr IaMP spellcards meets Zerg creep

Thoughts on how to implement this system:
A node is a helper in an arbitary state (10000 for example purposes). When placed, the node goes into anim 10000 which shows a visual representation of how far the node's influence has spread, has clsn2 at the center, and has clsn1 slightly smaller than the space it controls. The node's contribution to tech is simply AnimElem or floor(AnimElem/10)*10 or whatever works out best (the anim loops at the end obviously).

State 10000 will have a ReversalDef that triggers only on collision with another node; this freezes its animation via putting it into anim 10000+AnimElem, said anims just being static versions of the regular one at different sizes (so anim 10001 = 10000 AnimElem 1, 10002 = 10000 AnimElem 2, etc.). This way I can stop node influence from overlapping. It's not perfect; ideally I'd be able to make them not overlap but still extend in areas they don't overlap... I guess I could do that by placing an utter fuckton of helpers at different intervals and removing the ones that overlap, but that's ridiculous. There has to be a better way.

Also the node states'll have a HitOverride that forces it to kill itself if its clsn2 is hit by anything, so the opponent can get rid of them, and also so they can remove themselves if they're placed within existing influence or obsolete (obviously I want to limit them as much as I can).

Thoughts? Could I do this with explods or something instead? Will it interfere with AI even if the states are idle? Am I missing something critical?
    

Re: JoJo's Bizarre Adventure

 April 07, 2009, 04:09:44 pm View in topic context
avatar  Posted by 3  in JoJo's Bizarre Adventure (Updated April 7, 2009) (Started by Kung_Fu_Man April 02, 2009, 09:38:29 pm
 Board: Your Releases, older Mugen
c001357 said, April 07, 2009, 12:16:55 pm
ko sound plays twice.

This happens on and off for me.
Generally there's a lot of slowdown in the pause between the final hit(s) and the KO text (particularly if I KO with a multi-hit super), and this tends to get the screenpack text/sound out of sync. Perhaps there's a more efficient way of doing things...?
    

Re: JoJo's Bizarre Adventure

 April 06, 2009, 02:49:23 pm View in topic context
avatar  Posted by 3  in JoJo's Bizarre Adventure (Updated April 7, 2009) (Started by Kung_Fu_Man April 02, 2009, 09:38:29 pm
 Board: Your Releases, older Mugen
This is brilliant.
    

Re: Adding more keys?

 March 31, 2009, 08:52:02 pm View in topic context
avatar  Posted by 3  in Adding more keys? (Started by Dark_Force9999 March 31, 2009, 12:32:24 am
 Board: M.U.G.E.N Configuration Help
Generic problem with keyboard software, can happen a lot for some people.

You can't add any more buttons to MUGEN, but you can use unused ones. If you're playing with a 6-button character you'll be stuck.
However, if you're playing with a character that uses less than 6 buttons, you can open the character's .cmd file with Notepad (or another text editor) and change the commands to use a spare button instead of two buttons at once.
Example:
Let's say you're using a 4-button character (x, y, a, b)
The move you're trying to perform involves qcf+x+y (or +y+z, or +x+z)
Press Ctrl+F and look for "D, DF, F"
Find the command.
Change "+x+y" (or whatever alternative) to "+b".
Now the move is performed with a press of C instead of two buttons at once. You can repeat this for whatever other moves.
    

Re: where can i find mugen characters?

 March 31, 2009, 08:46:24 pm View in topic context
avatar  Posted by 3  in where can i find mugen characters? (Started by Evangle March 31, 2009, 03:34:40 pm
 Board: Introductions and Guides
    

Re: Imbalance in M.U.G.E.N.

 March 30, 2009, 03:50:36 am View in topic context
avatar  Posted by 3  in Imbalance in M.U.G.E.N. (Started by c001357 March 29, 2009, 03:39:57 pm
 Board: M.U.G.E.N Discussion
Due to MUGEN being nearly entirely open in its content matter, there's no standard on what consitiutes "cheap". Characters can only either be compared to against all of the other characters that exist (vast diversity), or against the other characters in each user's own, personally selected, roster.

Therefore there's nothing to call any character "cheap" as such, because it's always potentially balanced against something, and vice versa.

So whether or not a character is cheap as such depends on the characters it's paired against.
    

Re: worst, stupid,ridiculous characters names..

 March 30, 2009, 03:45:33 am View in topic context
avatar  Posted by 3  in worst, stupid,ridiculous characters names.. (Started by Jessy March 28, 2009, 07:19:35 pm
 Board: Gaming
Remember that in the manga it's supposedly known as "The Spirit Of Emptiness" but nobody actually calls it anything. I wonder when the "switch" took place... can'tve been long after that volume was written.

/offtopic
    

Re: worst, stupid,ridiculous characters names..

 March 30, 2009, 03:35:31 am View in topic context
avatar  Posted by 3  in worst, stupid,ridiculous characters names.. (Started by Jessy March 28, 2009, 07:19:35 pm
 Board: Gaming
"Cream" is a music reference on its own.

Vanilla Ice + Cream == Not a music reference, but a pun.

Mind you, jokes like that do tend to show up a lot in odd places in JJBA.
    

Re: worst, stupid,ridiculous characters names..

 March 30, 2009, 03:18:59 am View in topic context
avatar  Posted by 3  in worst, stupid,ridiculous characters names.. (Started by Jessy March 28, 2009, 07:19:35 pm
 Board: Gaming
I don't care if he's manly, he has an inappropriate referential name (compounded by the name of his Stand, which not only is the only Stand in that game with a music reference for a name, it makes for a silly pun as well).
    

Re: worst, stupid,ridiculous characters names..

 March 30, 2009, 03:08:36 am View in topic context
avatar  Posted by 3  in worst, stupid,ridiculous characters names.. (Started by Jessy March 28, 2009, 07:19:35 pm
 Board: Gaming
    

Re: rate the signature above you

 March 30, 2009, 02:59:31 am View in topic context
avatar  Posted by 3  in rate the signature above you (Started by c001357 March 15, 2009, 03:29:53 pm
 Board: All That's Left
The Black Prince said, March 29, 2009, 12:55:06 pm
Guise maybe you should stick to only posting once in this tread (max twice) since hur hur rating the same sig over and over makes an awesome thread.

Some people (ie, me) like to critique other people's sigs as well as get theirs rated, ergo reason to keep posting (providing the sigs being rated change).

As for yours:
It's not bad. The standard Photoshop-filter-shininess is evident, but this isn't a bad example. The render is clean.
Imo, top font == good. Other fonts == poor(ish). They're boring and don't fit in with the feel of the first. Two fonts is fine if it adds to the effect, but three/four strikes me as overdoing it a bit.
Borders are good, but square is boring. I also think you should add center tags, at least to the image.
7/10
    

Re: Simple sound problem

 March 29, 2009, 09:29:21 pm View in topic context
avatar  Posted by 3  in Simple sound problem (Started by Djedah March 29, 2009, 01:23:58 pm
 Board: M.U.G.E.N Configuration Help
What sound format are you using?

Try setting the sound plugin you're using for music to looptype=1 or looptype=2 (in mugen.cfg).

mugen.cfg said:
  ;List Winamp-compatible plugins here.
  ;Specify the filename of the plugin and the list of file types to
  ;use the plugin for. One plugin per line.
  ;Example: plugin = plugins/my_plugin.dll, mp3, mp2, mpg
  ;
  ;If music is not looping with a particular plugin, you can try an
  ;optional first argument looptype=1 (seek to zero; may stutter)
  ;or looptype=2 (reload plugin; slow).
  ;Example: plugin = looptype=1, plugins/my_plugin.dll, mp3, mp2, mpg
Page 1 of 41 2 3 4 > Last →