Posts for Ramzi

1 2
10 11 12
18 19
Posted: 12/22/2005 7:29 PM
Quote
Ramzi
Experienced Forum User
Joined: 3/25/2004
Posts: 459
Now imagine a game where your favorite Nintendo characters fight each other... in real time! That would be a lot more fun.
Posted: 12/22/2005 7:09 PM
Post subject: Look at what I just found in my basement.
Quote
Ramzi
Experienced Forum User
Joined: 3/25/2004
Posts: 459
It's an AoL Link action figure. Sorry but I only have a blurry webcam. [URL=http://img423.imageshack.us/my.php?image=picture0028qu.jpg][/URL] [URL=http://img423.imageshack.us/my.php?image=picture0037fp.jpg][/URL] [URL=http://img423.imageshack.us/my.php?image=picture0047ml.jpg][/URL] On his back it says: (c) 1989 NOA Applause TM Made in China
Posted: 12/21/2005 7:03 PM
Quote
Ramzi
Experienced Forum User
Joined: 3/25/2004
Posts: 459
Wow. Very impressive videos. Good work.
Posted: 12/21/2005 6:53 PM
Quote
Ramzi
Experienced Forum User
Joined: 3/25/2004
Posts: 459
I recall there being a time when the Princess only run was the fastest SMB2 completion on the site.
Posted: 12/21/2005 3:35 AM
Quote
Ramzi
Experienced Forum User
Joined: 3/25/2004
Posts: 459
I'd like a small run. There's been talk about it at SDA and I've been waiting forever.
Posted: 12/11/2005 6:50 PM
Quote
Ramzi
Experienced Forum User
Joined: 3/25/2004
Posts: 459
We don't have a swordless run yet.
Posted: 12/8/2005 10:23 PM
Quote
Ramzi
Experienced Forum User
Joined: 3/25/2004
Posts: 459
What counts as 100%?
Posted: 12/8/2005 4:23 PM
Quote
Ramzi
Experienced Forum User
Joined: 3/25/2004
Posts: 459
I thought it was very creative. But the physics REALLY sucked. I made it to Boo but couldn't jump high enough on the springs. So I quit and I'm never playing it again.
Posted: 11/30/2005 10:11 PM
Post subject: Let's Choreograph UT 2004!
Quote
Ramzi
Experienced Forum User
Joined: 3/25/2004
Posts: 459
In the time I've spent playing UT, I've seen some truly remarkable things. I think it would be very entertaining to watch videos of those things. I want to replicate some, and choreograph new ones. I already have ideas floating around in my head. However, I need other people to work with me on this. UT2K4 has a demo recording feature, and allows that demo to be converted to avi. The demo itself would have all the mistakes and retakes, until we finally get it right, in which case we'll edit the video and keep only the good parts. Each video should be pretty short. A few seconds to a minute. I'm not asking to create a video of a game being played, because to win in a really "amazing" manner would require really bad opponents, which is not entertaining to watch. Rather, I'm looking for stunts. Air combos, head shots, long range goop kills, that sort of thing. You don't have to even be good at the game. I think I should be able to pull off even the hardest tricks, given enough tries. What I need other people for is to, basically, move in a preplanned way. Would anyone here be interested in working with me to make these videos?
Posted: 11/22/2005 8:42 PM
Quote
Ramzi
Experienced Forum User
Joined: 3/25/2004
Posts: 459
It's good to see that you're interested in the tool-assisted aspect of GoldenEye. I believe I can help you with the technical aspects of making a TAS. Most of the information you need is already in the FAQs on the main page. The problems preventing a GoldenEye TAS right now are: 1) unintuitive inputs, and 2) a lack of a save state. I found a controller setup that would make GoldenEye play like Quake or Unreal Tournament. As of now, it's the best setup available. However, it does not have the N64 controller feel, which was so essential for playing GoldenEye. To make a TAS of this game, one would have to be really patient in regards to movement, as something that could easily be done with a 64 controller would take a couple of attempts on the keyboard. The other problem is a savestate. I looked and couldn't find one. I even tried hexeditting, but didn't succeed very much. Simply, you cannot do a TAS of a level if you haven't reached the level yet. If someone could beat the game on the emulator and post the savestate, or if someone could hex edit up a savestate, then we can start working. The first video I would like to see if Train DLTK. I think it would be the easiest of the four levels left.
Posted: 11/19/2005 4:54 AM
Quote
Ramzi
Experienced Forum User
Joined: 3/25/2004
Posts: 459
I'm going to agree as well. If physical manipulation was allowed, I would crack open my Zelda 1 cartridge, replace the chip with a Mario 1 chip, and then beat Zelda 1 in 5 minutes. We should consider beating a game as fast as possible as: Okay, we have all the source code, now, within the theoretical framework of this video game universe defined by this programming code, what is the fastest way to beat the game based on some defined parameters, such as, from the moment of first user input to the last required moment of user input. What we do is a) try to learn and understand the universe as well as possible when the code isn't given to us, deriving its laws, and b) based on our understanding of all of its laws, beat the game as fast as possible. b) has proven very difficult because the problems are often chaotic.
Posted: 11/15/2005 1:52 AM
Quote
Ramzi
Experienced Forum User
Joined: 3/25/2004
Posts: 459
There are different symbols to represent numbers, but the underlying concepts are the same. So, if there is a methodology of manipulating symbols in one representation, there is a methodology in another. Consider counting. We, as children, memorize 10 shapes and learn how to form all (positive whole) numbers from those shapes. Those shapes are 0,1,2,3,4,5,6,7,8,9. Then consider adding. We learn 0+0, 0+1, 0+2... 0+9 (10 shapes.) 1+1, 1+2, 1+3...1+9 (9 shapes). 2+2, 2+3, 2+4... 2+9 (8 shapes.) ... 9+9 (1 shape.) 10+9+8+7+6+5+4+3+2+1 = 55 shapes. From these 55 shapes we can do all addition. Then we memorize up to our 9's multiplication tables. Another 55 shapes, and you can do all multiplication. These can be reduced to 45 if you accept a little rule. "If one of the numbers is 0, and you're adding, then the answer is the other number." It can be reduced to 45 for multiplication also. "If one of the numbers is 0, the answer is 0." More rules added may reduce some operations. 14*11 = 154 Take 14. Split it up. 1 ______ 4 Put the sum of those number in the center 1 5 4 Rather than doing 14 x11 ------ 14 +140 ------ 154 Notice in this way, you need to do one addition; namely, "1+4" In the traditional way, you need to do 3 additions: 4+0, 1+4, and 0+1. The largest set of rules to memorize would be to memorize the addition and multiplication of all numbers. The smallest set of rules would be unary (just chalk marks), but it would require many operations. Think of 5 * 5 in marks. It would be ||||| ||||| ||||| ||||| |||||. Counting by one, this is 25 operations. 5*5 = 5+5+5+5+5 is 5 additions. 5*5=25 is one step, if you have this memorized. What would be the most efficient system to have? That is, which system would yield the smallest sum of (number of things to memorize + number of operations.) within a given range of whole numbers. How can you prove it?
Posted: 11/9/2005 3:43 AM
Quote
Ramzi
Experienced Forum User
Joined: 3/25/2004
Posts: 459
We would also need to know: the blast radius of a bomb, the enemy dynamics upon being hit, the velocity of Link's sword, and the range of pixels each enemy can be hit upon for them to take damage. Maybe doing all of this math would be harder then doing a brute force with pruning.
Posted: 11/8/2005 12:38 AM
Quote
Ramzi
Experienced Forum User
Joined: 3/25/2004
Posts: 459
Do you think with enough experimentation and data collection we could dervie the rules oh behavior for, say, darknuts? If so, would we be able to mathematically compute with given initial conditions, the fastest method of beating the room without having to resort to brute force?
Posted: 11/7/2005 6:20 PM
Quote
Ramzi
Experienced Forum User
Joined: 3/25/2004
Posts: 459
Boco wrote:
..but he also thinks "push the 'B' button repeatedly" and "walk into a wall" are viable strategies for some reason, instead of behaviours to be avoided (and those paths containing them to be purged immediately).
They are. Imagine a Patra fight. What if you press A but the sword doesn't hit the Patra. You may think it was a wasted move. But if it causes the Patra to move closer to the door, you may save more time in the end. Then people who are watching the supposedly "perfect" run will wonder why Link missed a swing, and we'll be smiling. We have to first know what influences randomness before we can decide what to prune. Do you think we can convert it to ASM and study the code? Or is that too impractical? Just saying, if we know that pushing the B button does not affect randomness, we'll be confident when we prune it.
Posted: 11/5/2005 6:18 AM
Quote
Ramzi
Experienced Forum User
Joined: 3/25/2004
Posts: 459
Gah, okay. Imagine you need to collect 7 rupees. Imagine that to collect 1 rupee a room would require the second fastest route for that room. Imagine the difference from the fastest time is 28 frames because you lose 4 frames each room to pick up the rupee. Now imagine, in any of the 7 rooms, 6 rupees can be collected with a 15 second delay. Now there's the 4 frames for the last rupee, and we have 15+4 = 19. We should go with the longest delay in one room because it leads to a shorter time over all, by 28-19=9 frames. Now, if we know all of this, we can compute what we should do for each room. However, if our actions in one room influence our actions in another room, then we're screwed. Imagine that 6 rupee pick-up could ONLY happen if we took the second fastest route in room #1. In short, to calculate what we should do REQUIRES a full game tree which is incalculable. We could just use my little formula and brute force as we go, which would still be faster than a human run, but technically not perfect. I'm wondering, also, maybe all of this thought is merely mathematical/theoretical, but pointless for Zelda 1. Perhaps the rupee quota will be meet itself just by Link walking over rupees on his shortest room path. If not, we're just going to have to go with our human intuition as to which routes we want to take for a room depending on how important picking up that rupee drop is. For some reason, I believe that the intuition of someone like TSA would be better than any mathematical formula we can come up with, because he's been perfecting the formula in his head for years.
Posted: 11/5/2005 6:06 AM
Quote
Ramzi
Experienced Forum User
Joined: 3/25/2004
Posts: 459
Michael: What do you think of this? d = distance to rupee drop D = distance to shop r = value of rupee drop R = Rupees left needed d / [D/(R-r)] If less than 1, pick it up. If greater than 1, don't pick it up. Problem is knowing D at any given point. Picking up a rupee drop based on the point system would affect the randomness of a room. I think we must find the best medium between 1) the fastest room completion, and 2) the most rupees collected (if we pick up all rupee drops.) This could be done by plotting the line functions of each and seeing where they interect. |\ / | \ / | \/ <--- point of intersection | / \ -------------- I am too sleep deprived and too shitty at math to think of this stuff now or ever. Good luck working with my half baked thoughts.
Posted: 11/4/2005 8:59 PM
Quote
Ramzi
Experienced Forum User
Joined: 3/25/2004
Posts: 459
In the Patra rooms, you can only use the sword to kill it. So the room time is from when you enter, to when you leave. What the bot can do is find the means of killing the Patra. Then we can very easily calculate the time to walk to the door. Perhaps we would go with the 2nd fastest Patra kill if the walk to the door is shorter. There is no need to press start, select, or B. Darknut rooms are a concern, because bomb conservation is important for later Darknut rooms. However, bomb drops are frequent. We should make sure to pick-up bombs even if they take longer because bombs are so necessary for destroying walls and killing bad guys later. I'm unsure if your actions in one room affect another room's enemy layout. I'm sure that brute forcing rooms individually would still give a faster time per room than a human, but we would not be able to claim that it is perfect. When discussing perfection, we should only consider brute forcing game events which are completely isolated from other game events. If we're talking about just improving what we have now, and arriving slightly closer to perfection, then brute forcing is very reasonable for Zelda 1. There aren't that many fighting rooms to consider, and if we do them all individually, there is no doubt a (noticeable) amount of time will be saved. I also really like Michael's point system idea, but I think that for Zelda 1 we couldn't program something to do what a human does. Many items drops are situational things. Depending on how soon you need an extra rupee, you may walk an extra distance that you wouldn't even consider when you don't need any rupees. Simply, we would have to program every instance of what should be done for a program to possibly get a faster time than a human. We should also do candle boosts when we know we have little/no reliance on the sword's beam. If we can figure out fairy manipulation, life and the sword beam can become less of a concern. We need to do some tests on how much time the candle boosts can save us.
Posted: 11/2/2005 2:44 AM
Quote
Ramzi
Experienced Forum User
Joined: 3/25/2004
Posts: 459
For those who want to try, I just found this http://members.chello.at/n-rage/dinput8/index.html : I think the newest one is a different version that comes pre-packaged the the mupen64 re-recording package. Under downloads, there is a controller profile for GoldenEye. It plays very much like UT, or any other PC FPS. Up and Down move you forward and backward, representing the up and down of the analog stick. Left and right strafe right and left representing the C-left and C-right buttons. Turning left, right, pointing up, and pointing down, are all down by the mouse. The mouse covers the left and right of the analog stick, and the C-up and C-down buttons. This makes emulating GoldenEye feel very much like playing GoldenEye, it just takes a little bit of getting used to in the beginning. It emulates it very accurately. I thought I found an error, but the same thing occurs on the actual console. If you hold right, then hold left while still holding right, Bond stafes left. If you hold left, then hold right while still holding left, Bond stafes LEFT. The same with on the N64. If you're holding C-left and then hold C-right, he'll continue going left. But if you're holding C-right, and then hold C-left, he will go left. I don't know why this is. One aspect of the game is better emulated in 1964 then Mupen. This is... If you're aiming (with R) and you put the crosshair to the far left or right of the screen, Bond will begin to spin counterclockwise or clockwise respectively. This happens in 1964. In Mupen, the crosshair keeps going back to the center, making spinning counterclockwise/clockwise very tedious. Another thing I noticed in both 1964 and Mupen is: The crosshair can reach the far end of the screen on the left, right, top, and bottom. On the console, the crosshair can only come within about an inch of the edge of the screen. I don't know what causes this difference. Lastly, the scrollwheel is set as the A button. Scrolling forward or backward still cycles Bond's guns forward. In the game, it is possible to cycle backward by pressing A and Z simultaneously. I was not able to replicate this. Also, remote mines can explode by pressing A and B simultaneously. To do this with the current control profile would require spinning the scrollwheel and pushing it down simultaneously, which is tricky. If anyone can develop a better profile based on these observations, it would be k-rad.
Posted: 10/30/2005 4:29 AM
Quote
Ramzi
Experienced Forum User
Joined: 3/25/2004
Posts: 459
ok
Posted: 10/29/2005 12:32 AM
Quote
Ramzi
Experienced Forum User
Joined: 3/25/2004
Posts: 459
Hmm... The thought of not being able to place a bomb on a specific frame is something that didn't even occur to me. I wonder why it didn't, it's obvious, and I should have realized it sooner. Or Link changing direction. But why 16? Maybe he can't change his direction every frame, but maybe he can change it every 7 frames. Or every 20 frames. Where did you get 16 from? Also, n^30 is huge. Too huge to calculate. We should find the largest reasonable number of frames and number of inputs, where we can brute force something. And then, we can try to find the rare moments in games where we can apply that brute force. If our computers can do 1000 steps per second, and we can test a route in 1 step, then if we have 1billion routes, we could find the fastest in about 11.574 days. Let's see when brute forcing is possible. (#inputs)^(#frames) = #steps 2^30 = 1,073,741,824 3^19 = 1,162,261,467 4^15 = 1,073,741,824 5^13 = 1,220,703,125 6^12 = 2,176,782,336 7^11 = 1,977,326,743 8^10 = 1,073,741,824 I think I calculated 58 different inputs from the NES controller. God. We would have to really know the right conditions to use a brute force.
Posted: 10/28/2005 11:36 PM
Quote
Ramzi
Experienced Forum User
Joined: 3/25/2004
Posts: 459
Bisqwit wrote:
Ramzi wrote:
In Zelda 1, we could brute force specefic dungeon rooms, particularly those with the blue darknuts, or those with the Patras.
What is the average time required to complete one such room? Can we assume a bomb will only be placed at frames that are evenly divisible by 16? Can we assume Zelda will change facing only at frames that are evenly divisible by 16? Can we assume that two different directions (up+down, diagonals) is not useful to be tried?
My times are conservative. (I added a second if I thought I looked at my system clock late.) I used Sleepz's original run. I timed from the time Link enters the room to the time Link leaves the room. This means, the time to push a block and walk to the secret staircase is also included. 1st blue darknut: 9s 2nd blue darknut: 11s 3rd blue darknut: 6s 4th blue darknut: 7s 1st patra: 12s 2nd patra: 8s What's the significance of it stuff being divisible by 16? And I assume you mean Link. What is the maximum number of frames we can have and still brute force the best route? We should have up, down, left, right, a (for Patra) and up, down, left, right, a, and b (for Darknuts.) There's no need to include Start or Select, as we don't need to change items (if bombs are already set, which we'd do before we enter the room.) This doesn't seem possible at all. In 6 seconds there are 360 frames. 5^360 is too huge to calculate. With our computing capabilities, we can only brute force like 10-12 frames, max.
tool23 wrote:
Forgive me if this has already been mentioned or considered, but I just wanted to make clear: if you have 3 inputs for 5 frames isnt it 8^5 input combinations rather than 3^5?
JXQ said it. Three inputs altogether, not 3 buttons.
JXQ wrote:
As far as physics / brute force, an example of something that could throw it off is Mega Man 1. Before discovering all the ways to zip through the game, the solution of a room based on physics may not be even close to fastest. Another small example would be Chip & Dale's apple-glitching, which gains a bit of horizontal forward movement. Anyway, my point is that trying to lower the amount of search space and still have "trust" in the new narrowed brute force algorithm would require extensive game knowledge. Of course, this is the site for that :)
A long time ago, whe Mario 1 was done in like 5:07, I thought it was perfect because the shorest path was taken and Mario kept max velocity. Certain glitches, such as being able to travel through a wall, allowed this time to be decreased. When I say "physics," I mean all the behavioral rules of the game. I'd say being able to go through the walls is part of Mario physics.
Posted: 10/28/2005 1:02 PM
Quote
Ramzi
Experienced Forum User
Joined: 3/25/2004
Posts: 459
Boco: The crazy number of combinations was something I didn't realize until I was back in bed. (I typed my OP at, like, 1:30 in the morning.) What inspired me to make the post was the realization that some game events in no way affect other game events. This means we only need to solve segments of the game at a time. But, alas, this is unrealistic also. Another thing I thought up in bed was... Imagine something very simple, like a screen where Samus runs from 1 door the the next. We needed even do brute force, because the optimal path can easily be deduced with mathematics and video game physics. Here's my dictum: "physics" is great when brute force is unrealistic. Brute force is great when "physics" is incalculable. The game I was thinking of last night was Arkanoid. This is definitely a non-liner, maybe even chaotic, game. To solve a level with physics, you would have to calculate the projection of the ball based on the angle, and the resulting consequences. After the ball elimates a block, the whole system has to be reconsidered. Now, if you're working with 2 or 3 balls, you would need to find the right time to optimally hit them all (or some of them) to result in the fastest completion of the level. If brute force were possible, the solution to a very complex physics problem could be solved. In Zelda 1, we could brute force specefic dungeon rooms, particularly those with the blue darknuts, or those with the Patras.
Posted: 10/28/2005 5:22 AM
Post subject: The Technical Aspects of Game Causal Connections
Quote
Ramzi
Experienced Forum User
Joined: 3/25/2004
Posts: 459
The number of routes can be represented as: (the number of inputs)^(number of frames). For example, if you only have 3 inputs, after five frames you'll have 3^5 or 243 different input combinations. I was under the impression that the only way to develop a perfect TAS would be to brute force. Imagine a game of Mario 1 where Mario sits still for 3 minutes, and then on the 181st frame you push A and the game glitches to the ending. Of course, this is not the intended means of playing it, and "Mario physics" is irrelevent. The only way to find this very obscure glitch would be through brute force. Now I'm beginning to question this rationale. Of course, a stoned programmer may have added some code to make this strange "teleport to the end" glitch possible, but it's highly unlikely. On the assumption that we have a perfect understanding of the game's code, we would know that this glitch won't occur without even having to test it. But this isn't the reason why we still discuss brute forcing, which leads me to the main point of this thread. In what way are game events causally linked? "P................................................. Q" Imagine that P is a room full of bad guys in Zelda 1, and so is Q. The dots are all the events that occur in between. If we wants to brute force the fastest way to complete room P, we may find that we can save 20 frames by using an extra bomb. Then, when we get to room Q, we brute force that room as well. But, what if it was the case that if you had one extra bomb for room Q, you would have saved 30 frames. Had you known this in room P, you would have chosen the second-fastest route for completing P. I could say that Q is directly related to P. Some aspect stayed (# of bombs) with you which affected the game later down the line. But imagine a game now where each level you start with initial conditions that are uninfluenced by the level before it. (Like, in Mario 1, if you are Super Mario at the end of level 1, you will be Super Mario at the beginning of level 2. Imagine that, regardless of your being Super Mario at the end of level 1, you would begin level 2 small.) ".......P...................|.................Q......" P represents some point in level 1, Q represents some point in level 2, and the | represents the game resetting the memory values to start a new level with some pre-defined initial conditions. Is there anything you can do in level 1 that can affect level 2? I think the only way two events in a game can be causally linked is if there is some shared memory value between the two. If there's not, you can do level 1 as slow as possible, and still be able to do level 2 optimally, even though the start of level 2 begins at a different frame. In other words, regardless of you start level 2 at frame 300 or frame 350, it will still take the same amount of time to complete level 2 optimally. Now, for the roundabout conclusion. We'll call the number of frames from the start of level 1 to the end of level 1 n. We'll call the number of frames from the start of level 2 to the end of level 2 m. Let's presume that this game as only 2 levels, and at the end of level 2, you've beaten the game. Altogether, the number of frames to complete the game is (n+m). Given my introduction, the number of different combinations of inputs would be (number of inputs)^(n+m). However, based on the body of this thread, we could do [(number of inputs)^n + (number of inputs)^m]. This means, rather than having to test ALL possible routes, we only need to test all possible routes for level 1, and then all possible routes for level 2, and then add the shortest route from each together to get the fastest time. This number of combinations is considerably less than doing a brute force of the whole game. Because the number of combinations increases exponentially, doing the brute force of a 5 minute game (like Mario 1) would take a ludicrous amount of time. But, if due to the game's programming elimating any connection between levels, all we have to essentially do is a brute force for every |. This leads me to believe developing the perfect Mario 1 run is achievable without the aid of quantum or relativistic computers. Now, there are some links between levels. Mario's lives, number of coins, and high score, are all variables that transcend levels. However, aren't we fairly certain -- based on our understanding of the game -- that these variables are inconsequential to the behavior of the game? Based on our understanding of the game, we can prune many branches of the gametree. For example, the route which involves Mario dying immediately need not even be considered, because our understanding of the game -- and trust that there were no stoned programmers -- will tell us there's no way for that to result in a faster outcome, so we don't even need to test it. In conclusion (for real), some events in games are not causally connected to previous events do to pre-defined initial conditions of levels and such. To do a brute force, we need only brute force the levels individually, which is a realistic possibility.
Posted: 10/27/2005 8:54 PM
Quote
Ramzi
Experienced Forum User
Joined: 3/25/2004
Posts: 459
Uh... Just include the data's file.
1 2
10 11 12
18 19