Replay Limit Hacking

[Sai Winner of Games]

I've been wondering exactly what the problem is that required the replay limit to be only 3 minutes. The game runs at 60 frames/sec. Let’s say you can have one input each of those frames, so it should be possible to estimate how much space we need to store a certain time of game data by determining how many unique inputs are possible at a given frame.

If you look at a classic controller, there are 12 buttons + 2 control sticks that you could press at a given time. Let’s say the control sticks have around 360 degrees of possible inputs each. So theres are about 750 possible single button actions. There are a many actions that require 2 simultaneous button presses in Brawl, but let’s say we can press 4 different ones at any given time, so the actions are not underestimated. Since the order of the button press does not matter at a given instant, and you cannot press the same button at a given instant, that gives us (n choose k) = n!/(k!(n-k)!) = 750!/(4!*746!) = 13078382625 possible inputs at a given frame. Notice that not all these possibilities will perform different actions in game, so the real number will be much less.

These possible inputs (13078382625) will fit will fit in 5 bytes (1099511627776 possibilities). So to recreate a replay we need 5 bytes/frame, which is 300 bytes/second. For 10 minutes (600 seconds) of game play, you would need 180000 bytes (180 kB). I'm not at home anymore (thus Wii-less ), so if someone wants to make replays of different times and check to make sure the resulting size is less than 300 bytes/second, this could be verified.

The Wii has 64 MB of main memory, so 10 minutes of game play would need less than 0.3% of the Wii's memory from my rough overestimated size requirement for storing a smash game. I highly doubt brawl uses 99.8% of the main memory at a given time or even close to it.

I don't think saving this data uses additional too much processing power either, because most of the input data needs to pass through memory anyway, so enough memory should really be the only issue. Converting this input data it into the Brawl replay format is probably done at the start screen after the game. To me, it sounds like the 3 minute limit was placed arbitrarily for no reason.

The good news is, if the Wii really has the hardware to store more than 3 minutes, if someone hacked the limit by editing the game disc or using an action replay, in theory, it should not cause any problems.

There may be up to 2 times the game checks for the game time to make sure it is less than 3 minutes. The first could be during the game, when it stores the data and then at the end when it gives you the option of saving the replay. The second one seems the easiest to target. If this check can be replaced with a higher time value, we may be able to make full replays. If it also checks during the game to store the data, it will require editing both check values.

I think it just might be crazy enough to work. Feel free to point out any issues there are (I threw this together somewhat quickly).

 

[MookieRah]

Man, I just want to say that every thread you have made since your first post here has been incredibly amazing. You are possibly the single greatest new member this place has seen in years.

I can't really say much about this topic, as I don't have much knowledge on coding and how much space and memory this stuff would take, but it sounds feasible to me. Hopefully an AR will be out for the Wii soon so we can start experimenting.

 

[Falco&Victory]

umm... you do realize that brawl doesn't save button inputs.... it saves objects and their events, so random events can't be repeated differently >_>

Needs way more memory dude, and needs to be encoded

 

[Sai Winner of Games]

I thought about random events also, but I figured that it would be easier to save the inputs and throw in a few extra conditions for the randomness than saving every event for every object, so thats what the developers did perhaps. Now that I think about it, what you said may be right. I don't see why they would want to do that when they are limiting the replay feature so much. It could be they just don't realize it, I suppose.

Also, I should mention that each player should add additional 300 bytes/second if this works. The point is still that the size of the file is small compared to how much memory the Wii has if it is stored this way.

@Mookierah: I just have too much time without my Wii around.

 

[Fugue]

Falco&Victory, why wouldn't they just include the initial value for the random seed? They'd presumably only need to store one extra value to handle any 'random' event in an entire match.

 

[WarxePB]

What about the coordinates of the players? It needs to save those for every frame as well. As well as any items that spawned, when environmental effects took place, any sprites/effects that appeared, etc.

 

[Fugue]

Assuming the data for initial random seed and match rules are recorded (and they'd need to be recorded either way), matching the controller inputs will be enough. The random seed value would take care of 'random' events like items and A.I. reactions.

 

[Supax]

Wow you must have put a lot of time into making this thread. Mad props. You probably could have got the same point across with a much shorter post, but the more evidence the better. I see what you are saying about the replay, but I think the reason they did it was because they concluded that a majority of the people on brawl would play with the standard 2-3 minute time limit games with no stock. This is also proven with the poor online play where they only allow you to play standard 2 min. games of free for all unless you are hosting a room to play with your friends. I think these are just some of the things that should have been changed about the game before it was released. The actual gameplay will change over time, but in order to change the amount of film that can be saved would require action replay or something of a similar aspect unless some sort of glitch is figured out. Until then, it doesn't affect me too much because I don't use the replay system all that much Good post though.

 

[Egaseci]

It only needs to save the button input and the seed for the random number generator. It would be a waste of resources to save all events/objects separately. Sai's estimate seems realistic.

edit: Looks like fugue already pointed this out, oh well. :-P

 

[LouisLeGros]

I thought this would be about using replays to catch and thus limit hackers.

However, your idea for a possible way to "hack" the game to allow for longer replays sounds great. To bad the tools to do this don't seem to be available at present time. Kudos to you for thinking this up though.

 

[TK Wolf]

Very interesting. A few things to add:

I agree with you said that the issue is memory, not diskspace. I think they are saving data a little differently from how you imagine it, though you aren't far off if I'm correct. (And yeah, taking a look at the data would reveal a lot. I have an SD card, so I might test a few things out)

In terms of what needs to be stored, there are probably 2 different methods they can use. One is event driven, where every input goes along with a timestamp for when it occurred, the other is contant-input, where the status of each input (each button, etc) is recorded per frame.

I'd guess that they went with the 2nd method, since the first would rack up a lot of wasted data with all those timestamps.

Now don't forget that we're not dealing with buttons, but what the buttons map to! It doesn't record 'A' or 'B', it records what your control scheme translates 'A' or 'B' into. So what are the actions one can take at a given moment?

x-axis is a value from -1.0 to 1.0 (probably one byte, 256 different values)
y-axis is a value from -1.0 to 1.0 (probably one byte, 256 different values)
attack - pressed or not pressed (one bit)
special - pressed or not pressed (one bit)
jump - pressed or not pressed (one bit)
shield - pressed or not pressed (one bit)
item - spawn location (some default value = no spawn) and item type. (an x-coordinate, y-coordinate, and item type, probably can all fit within 3 bytes at the very worst)
Luckily for items, I think we can assume they'd optimize it and not waste the space for the data if an item isn't spawning. That makes the space taken negligible.
Alternatively, they probably just stored the seed for the random number generator which would also make item and stage randomness all summed up in a single number. (It's commonplace to use one of these in a program. A seed is the first number used in the generation function. With most generation functions, if you use the same seed you'll get the exact same results every time.)

Note that using the c-stick actually translates to direction+action, so it shouldn't take up more space. (As probably but not definite proof of this, you can sometimes jump in the air with the c-stick. Probably because it translates to up+attack or special. Speaking of which, an interesting experiment would be to try to jump in the ait with the c-stick with tap-jump off)

Each character probably needs at most 4 bytes of data per frame. (4294967296)
Up to 6 characters (don't forget, this must work for things like multi-man brawl) brings us to 24 bytes.

The rest of your math works out, so we have 60 frames per second, times 60 seconds per minute, that brings us to 86400 btyes (84.375kb) per minute. After 3 minutes we're at roughly 256kb.

If they have 64MB to work with, I don't really see why they couldn't spare some more, but if they're pushing the hardware to the limits as is (could be... might not be) then they'll have little to spare.


Here's the potential flaw I see in this plan. At some point in the code (when loading a stage/level?) they'll need to explicitly allocate memory to be used for replay data. There are probably multiple instances of this number in the already-compiled code, so changing it won't be easy at all. If it is possible, then since all memory is probably allocated to begin with, allocating the additional memory could cause the game to crash.

It's worth exploring, but I only know about programming, not hacking. ^^;
I'd be happy to help if there are more places where I'd be useful.

 

[Fugue]

We're not completely certain about how inputs work yet. RAR'ing (setting B-button moves to the C-stick, then jumping in one direction and C-sticking in another) implies that there are some quirks to the input system. Still, those are details to worry about later.

I doubt the AI would be stored based on input. Assuming they have the random seed, their AI should respond to a specific situation in exactly the same way every time. It'd be a tremendous waste of space.

 

[Sai Winner of Games]

If we go buy Wolf Pup TK's math, and then say we have 4 people playing, it uses less than 1% of the Wii memory at most to store the input data (562.5 kB).

In the game disc, there are two locations where the stage data is stored (../stage/melee/*.pac and ../effect/stage/rantou/*.pac). For Orpheon, for example, has STGORPHEON.PAC (2670 kB) and ef_StgOrpheon.pac (1 kB). Thats 2671 kB total that would need to be stored in memory perhaps. Then we have New Pork City with STGNEWPORK_ja.PAC (4056 kB) and ef_StgNewpork.pac (303 kB). Thats 4359 kB total. The difference is 1688 kB between the two stages, which is about 2.5% of the Wii memory (I think there might be more, but the difference is still there). Meaning if you are playing on Orpheon or an other small stage, there should be at least that much memory free.

On more minimalistic stages with up to 4 people there should be enough memory to store more replay data. This is how a large part of battles are done also, so its convenient.

Now the trick is finding the value to edit. We do have the tools that let us do this. I have not looked into it much, but a quick look at the files shows some that deal with managing replays.

(from ../modules/sora_menu_replay.rel)

Replay__snap_PhotoMat___/menu/collection/Replay.brres___/menu/common/Wait.brr
es_/menu/msg/replay.msbin__/menu/msg/save_load.msbin___/menu/msg/stage_name.m
sbin

A good target will probably be the file that manages the "The winner is..." screen at the end of battles, instead of the above, I am not really sure which one that is.

 

[Tristan Fattest of All Kids]

Why are all your posts so long and meaningful? Gosh, you make me look bad!

 

[J18]

sai, lemme just say one thing:
me no understand teh maths.

 

[Bud]

i don't speak nerd, but if you pull it off then kudos.

 

[Bluebottel]

Here's the potential flaw I see in this plan. At some point in the code (when loading a stage/level?) they'll need to explicitly allocate memory to be used for replay data. There are probably multiple instances of this number in the already-compiled code, so changing it won't be easy at all. If it is possible, then since all memory is probably allocated to begin with, allocating the additional memory could cause the game to crash.

I like your logic, programming is art :]
However, are you certain that memory allocation must be performed on starup? They could just as well create pointers and only allocate memory when needed. If it is true it could prove troublesome since hacking in-game, so to speak, usually means finding a value and altering it.

If we could flush the replaydata out from memory, save it to disk and force the recording process to continue it would solve the problem. We would end up with a bunch of files that, by themselves, are useless but stitching them togheter will gives us the replay.

Another thing to try out is simply finding the variable that tells how much time it has passed. It would be interesting to see what effect it would give by reseting it, say, every 5 seconds.

I dont think we will be able to solve this one out...
On a computer we might just be able to do it because we have a pletora of tools to tinker with the memory, but on a wii? Options are limited :/

 

[SFJake]

My thoughts was :

Their system is too bad, they limited it. Its very easy to get a broken replay. Longer the replay, higher the chance to get one, so they could've put a limit for that.