My thoughts from watching the YouTube encoding:
* Man, the bosses have too few hitpoints. Orange was a joke, and you didn't really get to see Seven Force's attack patterns. Of course, we got to see plenty of Black. :(
* Stylistically, I think I would have preferred less spazzing out during the waiting periods. There were a few where you were calmer, which was nice, but the rest of the run is basically nonstop "Hoo! Ta! Ya! Tep!" and it got pretty old when waiting periods had the same sound effects.
* Music doesn't hold a candle to the original. :\
* The technical execution was excellent, as we've come to expect from ComicalFlop.
On the whole, while I don't think this game makes nearly as nice of a TAS as the original, it's still excellent on its own. Well done!
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Ehh, full gun power for 5 makes it easy, but not necessarily fast. I don't know what the damage is for the max-power gun, but I'm almost certain it's still a lot lower than grenades.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Heh. I'd forgotten about the ?: operator, since it's not available in Python, which is my day-to-day working language these days. Similar constructs exist ("foo = 1 if probablyTrueBoolean else 0") but I still find such statements usually pack too much meaning onto one line.
I tend to opt for the second of my two posted styles, mostly because it bugs me to have a variable be uninitialized for any length of time. Paranoia, I guess, especially in situations like this where it literally cannot be read before it gets its value set.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
(Actually, there's a fourth type of "hacker optimization" which I forgot to mention: The negative optimization. In other words, something which might look like an optimization but that causes the code to actually be slower than the straightforward solution. Sometimes trying too hard to optimize simple operations can cause negative optimization because the only thing you are achieving is confusing the compiler.)
This is exactly why I said to use a profiler to tell what code needs to be optimized, and then verify after the fact that you actually made things faster. Optimizing is a tricky business, and it's easy to fool yourself.
Random question: which of these two do you guys prefer?
Case 1:
int foo;
if (probablyTrueBoolean) {
foo = 1;
}
else {
foo = 2;
}
Case 2:
int foo = 1;
if (!probablyTrueBoolean) {
foo = 2;
}
I'm not talking strictly in terms of execution speed; mostly in terms of readability.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
If I recall correctly, South Korea is locked into IE because they have a massive install base of ActiveX programs for banking and other vital infrastructure. Whoops.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
It's been awhile since I watched the old Blaster Master TAS (and I can't right now due to time constraints), but would it be reasonable to say "doesn't use the pause trick / doesn't use the backwards screen transition trick" for the old movie? Together those mean that
a) you can fly, and
b) you can bypass barriers that normally require beating earlier bosses
That seems to me like a fairly "objective" set of criteria to meet that would result in a movie like the old Blaster Master TAS (though I hear that apparently without either of those you can still skip most of stage 4 now). So I say we just slap those two labels onto the old one, and put the new one up as a movie that does use those glitches.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
n&1 is two operations: a bitwise and, and then a comparison of the result of that and zero.
n%2 == 0 is likewise two operations, but they're explicit.
(n>>1)<<1 is three operations: two bitshifts, and then the comparison with zero.
Of those three options, I'd go with the one that people are used to reading.
As for peppering your functions with inline assembler, I'd wager that the compiler can create more efficient assembler than you can in the vast majority of situations. If you're actually better at assembler than the compiler is, then go ahead...so long as you comment the assembler extensively, and it's only used where it actually makes a difference.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Your points are well-made, and my original maxims could have stood to be better-written. I was writing them as a reaction to the code I'm having to maintain (and which I did not originally write). It could be of better quality -- as an example, in the past week I've deleted over 2500 lines of outright dead code, out of a codebase that was originally about 16000 lines. Most of it was commented-out or unused functions.
Pretty soon I'm going to start to be able to set up some actual abstraction in there, and then I anticipate my life will get much better.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
My stance on repetition:
* The first time you write something, do it in-line. That is, don't make a separate function for it; just incorporate it into your program.
* The second time you write something, recognize that you're duplicating functionality. Don't make a new function yet, but also don't copy and paste your previous implementation.
* The third time you write something, it's time to refactor. Make a new function, and look at the previous ways you accomplished your goal. Pick the best approaches from each.
Sometimes, like with a "distance between two points" function, there's really only one good way to get the job done, so the "no copy/pasting" rule isn't really relevant. But I find the "refactor only on the third time" rule tends to strike a good balance between having duplicated code and having lots of functions scattered about that have only one or two clients. Lots of functions is bad largely because it means that when you're trying to figure out what a given piece of code does, you have to go bouncing about the codebase a lot tracking down what all of the functions the code calls do.
Other Derakon maxims for quality code:
* Use source control. Source control gives you the freedom to delete code you aren't using right this instant. Odds are you'll never need it again. Without proper source control, you become leery of deleting code, which causes your codebase to become filled with unused functions and large blocks of commented-out code.
* When you make a change to the code, describe the purpose and method for the change in the check-in description, not in the code comments. Your code comments should say what something does and why it's done, not when it was changed.
* Don't overdesign your code. Figure out what you need and write code that meets those needs. Recognize what you may want to do, and leave yourself room to expand in that direction, but don't write a function with the assumption that you will use it. Rather, find yourself in need of a function, and write it to meet that need. Code that you write in anticipation of future need will never be used, or will need to be rewritten anyway because of changing requirements.
* Conversely, don't start coding until you have a high-level design made.
* Don't optimize until you need the speed. But when you're writing new code, be aware of its algorithmic complexity. When you do optimize, use a profiler to figure out what in your code is slowing you down. When you make changes, verify that they actually sped things up.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
* There's a TASer working on the run right now. He/she has the energy and desire to improve it, and can do so more easily than anyone else at that time, having all the knowledge related to TASing the game fresh in memory.
Yes, and many don't want to go back and redo a lot just for a small savings. The odds of savings are more likely to be not near the end than near the end.
There's no requirement that the TASer go back and make suggested improvements, but in my experience, most do unless the improvements are minor compared to the scope of the movie (saving two frames is often worthwhile on a 5-minute movie, less so on a 30-minute movie). Some people aren't willing to touch the movie once it's submitted, of course, and they aren't required to do so. I don't see how that affects my argument, though.
My big concern here, though, is that we rush a movie to publication, an improvement is found, and the TASer complains that they didn't get the opportunity to incorporate that improvement before the movie got yanked out of their hands. The amount of effort involved in making a new publish-worthy movie to obsolete an old one is significant, since generally we frown on "this movie is identical to the previous one except at this point" submissions (And yes, there are exceptions to that; I'm making a broad generalization).
Nach wrote:
Derakon wrote:
* It encourages people to give the runs more scrutiny. Suggesting improvements is one of the best parts of member interaction here. If we don't give enough time between submission and publication for this to happen, we're discouraging that interaction.
I have no hard data on that. I think people can scrutinize a run after it is published just fine. In fact, even more people can do so.
Again, speaking just from my experience and without any hard numbers to back it up, I see a lot more scrutiny on movies before they are published, not after.
Nach wrote:
Derakon wrote:
* It's more satisfying for many of our members if the runs we publish are the best we are currently capable of producing. Publishing a run with known significant improvements, then, is a bit rankling.
We already do publish runs now and then are recognized not to be perfect.
At least in those situations that's an informed decision. It's not "Whoops, we published this and then an improvement was discovered right afterwards"; it's "Hey, there's an improvement, but the TASer is unwilling to incorporate it for whatever reason."
Nach wrote:
Even if we rejected all those, if you were correct, then why isn't every movie of at least of recent publication getting a perfect 10 in the technical ratings? We don't even have our NES SMB runs getting perfect 10s in technical when at the time of publishing, no one knows how to do it better, or even if they did, won't save more than a frame or two.
You'll note that I didn't say "perfect". I said "best we are currently capable of". The only movie I'm currently willing to accept as "perfect" is King's Bounty, since as I understand it all the possible shorter input sequences were exhaustively tried.
So I've made my case for giving a little more time to movies on the workbench. I'm still having trouble with the case for speeding them along as quickly as possible. What does it gain us?
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Hmm...you pause against the second angler fish for damage. At this point you could switch weapons again to Quick Boomerang, and kill the second two frogs with it, then pause later to switch back to Metal Blade. That should eliminate a pause, right?
Certainly looks better than last time, though. What's the frame improvement for this stage?
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
The MKV worked fine for me. Thanks for posting it.
It took me a bit to figure out the rules for the game, but what I saw was reasonably entertaining. I didn't watch it carefully for strategy, though. Still, good enough for me! Nice work.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
I'm leaning towards agreeing with Moozooh, for one big reason: the workbench is the point at which runs finally get significant public scrutiny. Even our highly-skilled TASers make mistakes or are unaware of potential glitches. I can't count the number of times when I've seen a run get lots of positive feedback on the workbench, and then someone comes along and says "Hmm, I bet you could do this segment faster by doing this" and it turns out they're right. Now, I haven't done any kind of formal study, but I wouldn't be surprised if at least some of these have happened more than two days after the run was submitted.
There's several reasons why it's desirable to incorporate these improvements into the just-submitted run rather than wait for the next run:
* There's a TASer working on the run right now. He/she has the energy and desire to improve it, and can do so more easily than anyone else at that time, having all the knowledge related to TASing the game fresh in memory.
* It encourages people to give the runs more scrutiny. Suggesting improvements is one of the best parts of member interaction here. If we don't give enough time between submission and publication for this to happen, we're discouraging that interaction.
* It's more satisfying for many of our members if the runs we publish are the best we are currently capable of producing. Publishing a run with known significant improvements, then, is a bit rankling.
I'm sure there's more reasons too, but this should be enough. For my part, if I were to look for a "minimum time on workbench", I'd say at least two working days and two non-working days, since many people get their internet access primarily only on weekends or only at work.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Real Programmers don't write in assembler. They write in machine code, because nobody who isn't using the One True Architecture deserves to benefit from their creations.
And they don't use keyboards, either; they solder bare copper wires to the motherboard and then chew on them to send the appropriate write signals.
(Real Programmer jokes are basically the original Chuck Norris jokes, only funny)
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
The webdev quickbar is also incredibly useful if you're a web developer. An outline mode that lets you visually see all the elements on the page and their bounding boxes, quick access to disabling cache/Java/Javascript/etc., the ability to edit the page-as-rendered (as opposed to the page-as-written on the server side), detailed image information, etc.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Here's how I differentiate my variables:
* Constants: in all caps. MAX_SPEED_X, NUM_COLUMNS, etc.
* Member variables: prefixed with "self.". self.velocity, self.animations, etc. This is Python; all member functions accept as their first argument the object they're operating on. I find this approach a lot more intuitive than the implicit "this" variable in C++.
* Globals: referred to by their module name (e.g. map.minUniverseWidth, physicsobject.defaultGravity). Or, simply by being names that are not declared in the current scope -- most of my functions are short enough that such are easily recognizable.
Not to say that "scope prefixes" are useless; this is just my approach to the same problem.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Given that I'm on a Mac, I can't buy most PC games at release. And my consoles tend to be out of date too (I got the Wii, but I haven't turned it on in awhile). So mostly I buy games when I hear consistent good reviews for them and they're available on a system I have.
I also tend to have only 0-1 games in my "now playing" list, since gaming isn't the only thing I do with my spare time. In fact I'd estimate I dedicate more money in a year to buying board and card games than I do to videogames.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Contra 3 does gain extra lives to save time -- the trick is to get the new life after losing your last one (via bombs), which causes the game to think that you've finished the level. Though, the extra lives are gotten through points rather than through pickups.
Also, IIRC the H weapon has been used in a Contra 3 TAS, in a situation where it didn't cost time to pick up and the TASer had a free weapon slot for it.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
I tend to err on the side of verbosity when it comes to variable names and the like. Not to the extent that it impedes readability, mind you, but I'd rather write e.g. "point" than "p", and better still "pointOnPlane" if, say, I'm doing a projection. Including variable names in functions is just a part of that.
Having recently had to maintain the code of someone who was absolutely in love with single-letter variable names and the abolishment of namespaces wherever possible, I'm coming to appreciate my own coding style more and more.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Functions, variables, constants, etc. can be assigned to namespaces, which among other things lets you unambiguously refer to whatever variable you're using and enables you to have multiple things with the same name (but in different namespaces) without having a conflict. Without adding "using namespace std;" to your code, you'd have to write e.g. "std::cout" instead of just "cout".
It took me a long time to realize how useful namespaces are. Their utility doesn't really show up in small programs, but they're a big help once you start getting more complicated programs with large numbers of source files.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Much thanks to Flygon for the encode.
I quite enjoyed the run, especially the way you made a complete mockery of the game's various puzzles and obstacle courses. Clear yes vote.
If I could change one thing about the run, it'd be waiting to start charging the sword throw until right before you need it. The charge sound is a bit grating, unfortunately. Still, that's a minor thing.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
It's the same reason hard drives are marketed using 1000 bytes to the megabyte but measured by the system using 1024 bytes to the megabyte.
(Even if "mega" as an SI prefix should always mean 1000, not 1024...)
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
