Posts for Derakon


Experienced Forum User
Joined: 7/2/2007
Posts: 3960
Noob Irdoh wrote:
Then someone should unreject that Metal Slug X submission. In that case the "2 minutes of constant shooting" which are skipped do not apply to a boss, but to some underground trains, but the point stands. I prefer to see the continue screen rather than bangbangbangbangbangbangbangbangbangbangbangbangbangbangbangbang for no entertainment reason.
So you don't think it's amusing to watch a couple of soldiers shoot down a train with handguns? Tough crowd. ;)
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Experienced Forum User
Joined: 7/2/2007
Posts: 3960
If I recall correctly, the use of the door warp in the Maxim no-warps run basically served to avert a lot of otherwise not-very-interesting backtracking. The authors recognized it as being a bit inconsistent but felt that the use of the door glitch made the run demonstrably more entertaining without seriously breaking their rules, so they went with it. Given that the run was published, presumably the judges agreed.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Experienced Forum User
Joined: 7/2/2007
Posts: 3960
I suspect at this point the best way to decide is to post a short test video for both run types and see what people think. Sonicpacker's generally right that with speed comes entertainment, but that isn't always the case, and if this is one of the exceptions then it'd be better to find out sooner rather than later. Not that I think a speed-only run would be rejected; it just might not be as entertaining as a score-only run would have been. Or maybe it would be; I don't know. Hence the suggestion for test runs.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Experienced Forum User
Joined: 7/2/2007
Posts: 3960
I don't object to paintball mode, personally. As you say, it won't really show up unless you're intentionally shooting the wall, and at those points it should be an improvement over using standard bulletholes. Good luck with the remake!
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Experienced Forum User
Joined: 7/2/2007
Posts: 3960
My only question is why in the labyrinth levels, sometimes you stood on the floor and shot upwards, and sometimes you jumped upwards and shot in mid-jump. Given that you say that jumping causes the bullets to hit instantly, why wouldn't you always jump? Otherwise, looked good. Nice work!
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Experienced Forum User
Joined: 7/2/2007
Posts: 3960
I have difficulty coming to a firm decision on this. So in lieu of actually voting, I'm going to present some case studies: * Contra DS. The player dies routinely to skip even very short pauses, since dying lets you "jump" over long gaps. * Gradius. A death is used here because the fully-powered-up ship prompts the game to make a boss fight last longer; dying and resetting the ship to baseline is faster than the longer bossfight. * The current Metal Slug runs. Deaths are used to restore the players' grenade supplies, to spawn heavy machineguns (available when the player continues), and to change the active characters (purely cosmetic change). Additionally, dying in Metal Slug X allows a few segments where the players must shoot down an incoming train to be skipped. I'm fine with the deaths in the first two, but not so much for the last, and I'm trying to rationalize that. In Contra, the deaths don't stop the action at all; the player dies and almost immediately respawns, so things keep moving. Moreover, all of the deaths look intentional, e.g. jumping out into open space when there's clearly nothing in range to land on. Thus the issue that dying usually looks "not skillful" is averted. In Gradius, the death is a very WTF moment for anyone remotely familiar with the game. By all rights, dying and having your ship get downgraded should not make the run faster! Here it's the counterintuitive nature of the speedup that makes the death entertaining. And though it's harder to make an intentional-looking death in Gradius without losing time, the player dies to something that could have trivially been avoided had they been trying at all. In the Metal Slug games, in contrast, the deaths don't look intentional. They look like the player was too focused on attacking to notice an incoming bullet until it was too late. Obviously it's difficult if not impossible to make an intentional-looking death that doesn't lose time here, but that, combined with the lengthy delay before the player respawns, combine to make the deaths look bad strictly from an aesthetics standpoint. Add in the fact that the deaths make the player more powerful as opposed to less (Note that dying in Contra reduces you to the peashooter) and the whole thing just leaves a bad taste in my mouth. Does this generalize to some kind of arcade vs. console rule? I don't know for sure, but I'm leaning towards no, despite that earlier I was pushing for the judges to come out with an official rule. Sorry guys! I'm sure there are console games (that aren't ports of arcade games) where dying restocks your supply of smartbombs or gives you a limited-time power boost. Would we frown on a player who makes use of deaths to speed up bossfights? What if they used a continue to "restock" their deaths? I think we'd run into the same entertainment vs. speed debate without even having to consider the coin issue that arcades add in. So in short, I'm on the side of entertainment, wherever it happens to lie. I suspect that in most cases arcade games will be more entertaining to me if they don't add extra coins; so far that's proven to be the case (barring obvious exceptions like SDR's excellent fighting game runs) but we have a very small sample size as yet. That doesn't mean they'll be more entertaining for everyone, though; entertainment is a fairly personal thing. Which is a big reason why I'm having trouble voting; it feels like my trying to dictate to other people what they should enjoy.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Experienced Forum User
Joined: 7/2/2007
Posts: 3960
It's been awhile since I played the game, but isn't each level basically endless play-until-you-die style? The fact that the player has no control over how quickly the difficulty ramps up is a problem, too. I'd suggest doing a test run of a couple of levels and posting it for feedback before you spend much time working on a full-blown TAS. It's entirely possible the game just doesn't work well for TASing.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Experienced Forum User
Joined: 7/2/2007
Posts: 3960
I didn't mean to say that you hadn't planned out your runs. I think it's clear you put a lot of thought into them. It's just that, for me, the deaths hurt entertainment a lot.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Experienced Forum User
Joined: 7/2/2007
Posts: 3960
In X I think there's plenty of entertainment to be had watching the players shoot down an incoming train with their pistols. And would the rest of the stage really be that much slower? You replace your weapons when you enter the area after the trains, and the Slug's twin machineguns should be only slightly less powerful than grenades against the boss, right?
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Experienced Forum User
Joined: 7/2/2007
Posts: 3960
I suppose such a thing would be possible, but I've not heard of a game doing it. It would seem excessively paranoid given the ready availability of basically random data in the form of uninitialized memory. Googling about tells me that the expansion slot in the NES was used for an aborted gambling peripheral but otherwise ignored.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Experienced Forum User
Joined: 7/2/2007
Posts: 3960
I think the difficulty here is that discussions that involve you, Warp, never end. There is always some minor detail that requires multiple paragraphs of detailed discussion, or some trivial miscommunication that requires you to restate your entire thesis all over again. Nobody else is interested in these things to that level of pedanticism, so when you try to direct the conversation in that direction, people get irritated. You're bringing legalistic levels of precision debate to a casual chat; can you see how that would aggravate people? Certainly you're not always directly responsible for taking the conversation off the rails; I'll freely accept the brunt of the blame for this particular instance. However, you are absolutely responsible for keeping it off the rails. You need to try to read between the lines of the responses that other people make to you; if you're getting "I'm done with this line of conversation" vibes, then it's time to stop, by either saying "Okay, I recognize what you're saying even if I don't agree with it" or simply not responding at all.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Experienced Forum User
Joined: 7/2/2007
Posts: 3960
Apparently Blades of Steel reads uninitialized memory to set its RNG state, or something along those lines. There's a thread around here somewhere about it being "impossible to accurately emulate". I'd assume that any TAS of the game would therefore not play back correctly on an actual machine.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Experienced Forum User
Joined: 7/2/2007
Posts: 3960
Yes, I got that the first time you said it. In fact, I knew that before I even posted my second set of results. I'm assuming that the non-constant density does not have a significant impact, without any basis for that assumption other than gut intuition. As I said, if you feel that strongly about the matter you're welcome to modify the script to use non-constant point masses or a variable distribution. Or to solve the triple integral.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Experienced Forum User
Joined: 7/2/2007
Posts: 3960
Yes, I'm fully aware of how this isn't an even distribution, as well as the limitations of having a low-resolution approximation of a torus. I don't really care though; the goal was to get an approximate idea of the gravity gradients at various points and I think this simulation is entirely adequate for that purpose. If you'd like to tweak the point distribution or the mass of the points, I can send you the script I wrote.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Experienced Forum User
Joined: 7/2/2007
Posts: 3960
How does SIMG differ from IMG?
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Experienced Forum User
Joined: 7/2/2007
Posts: 3960
Yeah, here's a first pass where the density is higher inside the torus than at its surface. I did this straightforwardly by basically generating several toroidal shells of linearly increasing minor radii. I won't post the code since it's basically the same as before; just a different point generation system and some wrapping to let me generate results for a range of toruses. Instead of printing the gravity vector for each location, I'm just printing the nonzero components and doing some comparisons.
Maj:Min        Outside        Inside     %diff  Top (down)  Top (side)       %diff
     2:  -133512202244  133510309361  0.001418    -3534338    -2075398  170.296849
     3:  -133541279537  133538514912  0.002070    -5137163    -2517325  204.072277
     4:  -133580064941  133576592488  0.002600    -6791485    -2824321  240.464353
     5:  -133628128862  133624080942  0.003029    -8501253    -3060182  277.802171
     6:  -133685051107  133680523323  0.003387   -10271707    -3251503  315.906413
     7:  -133750427257  133745490644  0.003691   -12108348    -3412102  354.864742
     8:  -133823872250  133818581320  0.003954   -14016465    -3550125  394.816060
     9:  -133905021656  133899419410  0.004184   -16001018    -3670786  435.901660
    10:  -133993531696  133987652844  0.004388   -18066655    -3777623  478.254572
    11:  -134089078624  134082951730  0.004569   -20217761    -3873142  521.998938
    12:  -134191357819  134185006772  0.004733   -22458518    -3959180  567.251772
    13:  -134300082732  134293527796  0.004881   -24792956    -4037120  614.124794
    14:  -134414983810  134408242377  0.005016   -27224981    -4108031  662.725640
    15:  -134535807417  134528894576  0.005139   -29758393    -4172760  713.158392
    16:  -134662314799  134655243760  0.005251   -32396896    -4231991  765.523572
    17:  -134794281098  134787063523  0.005355   -35144080    -4286293  819.917793
    18:  -134931494419  134924140682  0.005450   -38003416    -4336144  876.433269
    19:  -135073754959  135066274347  0.005538   -40978236    -4381961  935.157304
Some takeaways from this approximation: * Thickness of the torus has little impact on absolute gravitational pull; the difference for the "inside" values between the thickest and thinnest toruses is only 1% * As the torus gets thinner, the downward pull at the "inside" location becomes stronger. As expected. * The same thing happens to a very slightly greater degree at the "outside" location. * As the torus gets thinner (larger major:minor ratio), it becomes easier to stand on top of the torus as the sideways pull is weaker relative to the downwards pull.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Experienced Forum User
Joined: 7/2/2007
Posts: 3960
Oooh, good call on the hollow vs. filled. My bad. Perfect evenness isn't strictly necessary IMO; I'll see what I can whip up.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Experienced Forum User
Joined: 7/2/2007
Posts: 3960
Thanks for volunteering your carts, dballin. Please disregard our tendency to get into horrible pedantic arguments. SDA is clearly not going anywhere anytime soon.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Experienced Forum User
Joined: 7/2/2007
Posts: 3960
I just want to say that it continually amuses me that the first games to get TASed on our bright and shiny new 64-bit console emulator are intentionally limited to look and play like 8-bit games. Good luck with the TAS!
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Experienced Forum User
Joined: 7/2/2007
Posts: 3960
Here's my numerical approximation approach. It's assuredly buggy it minor ways (don't try to stick the point you want a force for directly on the torus's surface since you end up with zero distance leading to massive absurd gravitational forces), but I think it's otherwise basically accurate.
Language: python

## Torus major radius majorRad = 10 ## Torus minor radius minorRad = 1 ## Number of rings of the torus to create circumDivisions = 1000 ## Number of points in each ring ringDivisions = 100 ## Mass of a point on the torus # (so total mass = torusMass * circumDivisions * ringDivisions) # Compare Earth at ~10^24kg torusMass = 10 ** 19 ## Mass of the point we calculate gravity for targetMass = 1 ## Gravitational constant G = 6.67428 / (10 ** 11) ## Point to calculate gravity for targetCenter = (0, 8.9999, 0) import math points = [] for i in xrange(circumDivisions): theta = i / float(circumDivisions) * math.pi * 2 for j in xrange(ringDivisions): phi = j / float(ringDivisions) * math.pi * 2 temp = majorRad + minorRad * math.cos(phi) x = temp * math.cos(theta) y = temp * math.sin(theta) z = minorRad * math.sin(phi) points.append((x, y, z)) gravyVector = [0, 0, 0] for point in points: delta = [point[i] - targetCenter[i] for i in xrange(3)] distanceSquared = sum([d ** 2 for d in delta]) force = G * torusMass * targetMass / distanceSquared distance = math.sqrt(distanceSquared) # Normalize delta to get direction direction = [d / distance for d in delta] for i in xrange(3): gravyVector[i] += direction[i] * force for i in xrange(3): gravyVector[i] = gravyVector[i] / len(points) if abs(gravyVector[i]) < 1: # Cleaner display gravyVector[i] = 0 # Approximate gravitational force on Earth's surface is 5.5 * 10^9 newtons. print "An object at",targetCenter,"would experience a force of",gravyVector,"newtons in X, Y, and Z"
I made the torus have approximately the same mass ratio to a human as the Earth has. Some sample output was here, but I redacted it after realizing my positions were all off ([9, 0, 1] is not on the torus). Here's some updated results:
An object at (0, 0, 0) would experience a force of [0, 0, 0] newtons in X, Y, and Z
An object at (0, 0, 0.001) would experience a force of [0, 0, -672.48108917887703] newtons in X, Y, and Z
An object at (0.001, 0, 0) would experience a force of [336.24055346705705, 0, 0] newtons in X, Y, and Z
An object at (8.9990000000000006, 0, 0) would experience a force of [6681569642.6716862, 0, 0] newtons in X, Y, and Z
An object at (11.000999999999999, 0, 0) would experience a force of [-6687714835.3757915, 0, 0] newtons in X, Y, and Z
An object at (10, 0, 1.0009999999999999) would experience a force of [-4100004.7859800849, 0, -6685114396.9591808] newtons in X, Y, and Z
Thus, the center point is stable in Z but unstable in X and Y -- no surprises there. Also, no matter where you stand on the ring, the primary force will be "down" to the ground. When standing on the "top" of the ring there's a horizontal force pulling you towards the torus's center of mass, but it's ~1500 times weaker than the downward force. Overall the downward force only varies by about a tenth of a percent for this torus.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Experienced Forum User
Joined: 7/2/2007
Posts: 3960
It might be easier to just fill up a toroidal volume with voxels of equal mass and then calculate the summed gravitational pull from all of them at various points -- roughly equivalent to numerical calculation of your triple integral, but easier for me to wrap my head around at any rate. :) You probably wouldn't need more than 10k voxels to get an adequate approximation.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Experienced Forum User
Joined: 7/2/2007
Posts: 3960
In other words, remember that TASes work with only the standard inputs available to any normal player of the game. Game genies, AR devices, and the like effectively add extra inputs that are not part of the standard game and therefore break that standard. They are in a completely different category from push-button codes, which anyone can input if they want to.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Experienced Forum User
Joined: 7/2/2007
Posts: 3960
Kuwaga: that depends entirely on if the zero point in the center of the torus is stable or not. If it is stable, then yes, over time the torus would fill with random debris, assuming you didn't clean it out from time to time. Niven's Ringworld was famously unstable, so he had to retcon attitude jets onto the perimiter of the world. How valid a comparison between the Ringworld-Sun system and a torus-debris system is, I don't know.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Experienced Forum User
Joined: 7/2/2007
Posts: 3960
Kuwaga wrote:
Wouldn't gravity make the torus collapse into a sphere unless you make up some forces that prevent it from doing so?
Forces like rigid structural forces? Donuts don't fall in under their own gravity because the strength of the baked batter is stronger than the gravitational force; just upsize that to larger sizes and you're good to go...assuming, of course, that the rigid strength needed is actually possible. Niven's Ringworld had to be composed of unobtanium for similar reasons; the centifugal stresses involved in spinning a torus with radius 1AU fast enough to simulate 1g were tremendous. In this case, though, the gravitational force of the torus itself was ignored, I think; in any event it paled in comparison to the rotational forces.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Experienced Forum User
Joined: 7/2/2007
Posts: 3960
rhebus wrote:
Derakon wrote:
Doesn't that crash only kick in once you fire your beam, though?
You'll fire your beam if you're holding all the buttons, unless you are in ball form. QED.
Oh, dur. Thanks. That makes sense. (As for why the code then gives you all weapons instead of just not giving you spazer: the game testers would have had to verify that none of the beam combinations cause problems when used against GT)
Pyrel - an open-source rewrite of the Angband roguelike game in Python.