Nobody said anything about any console or console game *requiring* mouse+keyboard. I only wondered why no consoles and console games offer it as an *alternative* to playing with the gamepad. If someone wants to play with the gamepad, then he is free to do so, but if someone would want to play with mouse+keyboard, why not offer him the chance?
I covered this in my list of options. Any additional input device you support requires extra coding on your end. And while coding in support for keyboards may not be much extra effort, remember that game developers are always under the gun as it is. For the time being, mouse+keyboard users have been able to get by just fine with the standard controller, which makes mouse+keyboard a "nice to have" feature - that is, one that quickly gets cut when the developers are in crunch mode. Not only that, but adding in a new input method might have balance implications: as you've noted several times, the mouse allows for faster turning and tighter aiming, which creates an imbalance in gameplay. Games that are designed with a console controller in mind would be a bit easier for mouse+keyboard users, and gamers with console controllers playing against gamers with mouse+keyboard would, all else being equal, be at a disadvantage.
Besides, the keyboard would allow hardcore gamers a lot of additional possibilities, especially for online gaming (such as sending messages and outright chatting).
These would also require extra coding.
Modern consoles are also starting to offer features where the mouse could be very useful, such as web browsing. Why not offer it? An USB port wouldn't raise the price of the console much, and adding support for USB mice to the console OS is trivial (if not actually already there).
This is just another version of the game argument, writ large. How much extra does it cost the console developer to add a USB port? Not much, but there is extra cost, not just in the hardware but also in the drivers and API. How many extra game sales would that port enable? Is it enough to justify the cost? If not, then there's no USB port.
Don't think for a moment that the keyboard/mouse combination is intuitive. It took you years to learn to use it fluently.
There's a difference, though: Most people already know how to use the mouse and the keyboard (and the latter doesn't need almost any practice at all to be used as a game controller). Also, when you get proficient with the mouse+keyboard, your gaming will be much more fluent than when you get proficient with the gamepad.[/quote]
Again, this is true for you but is not true for a vast number of users. You don't encounter these users on a regular basis because they inhabit different social circles, but they do want to be able to use computers and play games and they have very little experience at either. Keyboards are a slow input mechanism for these people. If they even know about copy+paste, it's through the Edit menu. Internet Explorer is the Internet, and they type through hunt&peck. They need many attempts to hit the close box on a window. And so on.
The thing about these people is, they still want to use the computer! They still want to play games! But it's very discouraging to play games with controls that require mastery of the keyboard, because they don't have it.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
according to the FAQ they are: "Video game consoles are computers."
somewhere it also says that computers are calculators. i think that's interesting, and funny.
Strictly speaking this is true - people have even done things like install Linux on a Dreamcast, and the Wii's web browser is really blurring the line. However, I'm speaking in terms of what the device is typically used for. Consoles are used for playing videogames (and, secondarily, for watching movies). Computers are much more general-purpose. Even though consoles are capable of many different things, because they were designed with games in mind as a primary purpose, they were able to make decisions that computers, which must be general-purpose by default, cannot do. This includes things like assuming that the CD/DVD/cartridge in the slot is a game and loading it on power-on; expecting inputs via console controllers; having a fixed set of hardware (no mucking about with device drivers), and so on.
A new user who turns on a computer is confronted with a vast selection of choices. This is very intimidating (and studies have been done on choice paralyzation). A new user who turns on a game console, in contrast, has very few choices, and they're all well-defined.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
That's assuming that you're trying to improve on the old game as a primary goal, as opposed to making a TAS at all (even if it doesn't get published) as a primary goal.
Yes, there's a lot to be learned by watching TASes of the game you're TASing. But, as pointed out earlier in the thread, you can also get blinded to possibilities. For example, a lot of the Super Metroid frame wars work on a room-by-room basis, which meant that a lot of savings that required looking across multiple rooms (e.g. if I take the time to set up a faster ground speed in this room, then I can get through the next room faster) were missed for quite some time. They required a more holistic perspective, which wasn't there when the players were obsessing over minutiae.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
I wouldn't be too certain of that. Yes, practically everyone you know has tons of experience with the mouse and keyboard. Intuitively, it makes sense to extend that level of expertise to the general population. But unless you can cite a study that shows that there's a negligible number of people who are console-literate but not computer-literate, I'll continue to believe that targeting your game at the keyboard and mouse crowd shrinks your potential market.
I grant that I cannot, in turn, provide a study that shows that there is an appreciable population of people who are console-literate and not computer-literate. Still, I've learned, over the few years I've done website work, that there's a lot of people who just don't know what they're doing when it comes to computers.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
I'm not a huge fan of Crash Man, Quick Man, Wood Man, the boss theme, heck, even the item-get theme. There's probably a few more but I can't bring up all the MM2 themes on-demand.
Even the songs that I like reasonably well don't feel as epic as the themes in MM3.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
I honestly wonder if consoles aren't doing that already, and if not, why not. What's the big deal? Almost everyone nowadays has an usb keyboard and mouse. And if they don't, they are really cheap.
Because consoles aren't computers. A lot of people out there find computers really intimidating. Consoles are comparatively pick-up-and-play. You still have to learn your way around the controller, though, and modern controllers have gotten really expensive [ed: meant complicated]. IIRC this was part of the motivation for the Wii - Nintendo was trying to find a controller that was both expressive and intuitive.
Don't think for a moment that the keyboard/mouse combination is intuitive. It took you years to learn to use it fluently. It's powerful, yes, and many people do know how to use it effectively...but many do not. Fundamentally this comes down to a tradeoff:
* Require keyboard and mouse. Now your game has strong controls, but players must either purchase an additional set of input devices or re-use an existing set (and most people do not have spares lying around). Your game is now moderately more intimidating to people who are computer newbies.
* Allow for keyboard and mouse, but support the default controller as well. Your game has the potential for strong controls. Multiplayer between keyboard users and controller users is unfair. Assuming you have a singleplayer campaign, odds are good that either mouse users will find it too easy, or controller users will find it too hard.
* Require the default controller. Your game is now stuck with what the controller can provide. It's not intimidating, requires no additional purchases, and only the niche FPS adepts will complain about the lack of a keyboard/mouse.
Looking at this, my choice would be for the third option. The second looks good, but there's too many balance issues to sort out and I assume I wouldn't have that kind of time or budget. If I were doing the first, I'd make a game for PCs instead of for a console in the first place.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
So you're saying that with emulation, a game's odds COULD be put in a player's favour (ie. something like changing the enemies' AI or causing basic enemies from not appearing at all), but it's something that people who make TASes here don't do as it's against the rules of this site or not possible?
"Changing" enemies' AI and other parts of the read-only code is impossible. However, if (by the game's design) all that is required to abuse their behaviour algorithms is player's input, it is strongly encouraged to do so.
Y'know, like if you're supposed to be attacked at a certain point, you could somehow confuse the game's AI not to do so. I'm sure I've seen that a few speedruns thought I can't remember if they were emulated or not or even how they did it.
AI and luck manipulation are major parts of many TASes on this site. But they work through playing the game, not (as a general rule) through glitches.
For example, say you want to manipulate Metal Man, in Megaman 2, into jumping over to the other side of the room. You do this by walking towards him. If you stay over on the left side of the room, then he won't jump at you - he'll only jump straight up. That's an example of very basic AI manipulation. The AI is manipulated by knowing how it reacts to different situations and taking actions to ensure that the situation causes the behavior that you want out of the AI.
Luck manipulation is a different matter. Say that you're playing an RPG with random encounters. The random encounter code might look something like "Roll a random number between 1 and 255. If that number is less than 16, cause a random encounter." What you want to do is ensure that the random number generator makes a number greater than 16 when the game checks for random encounters. Many random number generators simply spew out a fixed series of numbers (for example, IIRC the Final Fantasy 6 RNG is simply a table of numbers that it cycles through). If you can force the RNG to engage in a situation where you don't care about the result, then you can "advance" the RNG towards a favorable value. In our hypothetical RPG, there might be a random chance to generate a puff of sand when walking on the beach. Thus, by walking on the beach at certain times, you could ensure that, when it comes time to check for a random encounter, the result is always favorable.
In some cases the RNG draws its values from theoretically uncontrollable things, like exactly when the player presses certain buttons. Since in a TAS we have precise control over that, manipulating the RNG becomes very easy. Other times, the RNG depends only on what frame it is; then, to get a good result, we just have to wait for the right frame. If you watch the Final Fantasy 1 TAS, there's noticeable pauses in combat while the TASer waits for the right frame to get a critical hit, or to force the enemy to miss (or both!).
Make sense?
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Metroid Prime also, while a FPS in the sense that it was a First Person Shooter, wasn't an FPS in the traditional gameplay sense. That is to say, the focus wasn't on the combat, but on the exploration. In that context, using snap-aim is not really a big deal.
Frankly, the latter two Prime games, which tried to include more involved combat, weren't as good in the exploration front. Prime 2 didn't have as tightly-integrated of a world, opting instead for the old hub/spoke system (which makes backtracking to previous regions a real pain), and atmospherically, half the game took place in a murky purple place. Prime 3 never let you get more than six or so rooms away from your spaceship, which robs the game of a lot of tension.
But all of this is completely beside the point. I just like being argumentative.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
I don't get it. There is rarely a time in any 3d game where I need to choose between more than 8 different directions. This is my issue with analogue pads.
You're welcome to try to play Ocarina of Time without using the full 360° range of motion you have. Again, I've tried playing Alundra 2 (which is functionally a 3D Zelda clone without analog input). It is seriously a royal pain. Worse than playing an FPS with a console controller.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
I'm generally of the opinion that if it's entertaining to a significant subset of the population, then it should be published. Or at least "made available" (as alden would put it) on the site.
So if you think this would be fun to watch, by all means, make a video! I'm not certain I get it myself, but I'm willing to be proven wrong.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
For the Megaman series, 3 has the best music, no question.
Naaaah. 2-4 all have a lot of great tunes. (2 exceptionally with the first stage of Dr. Wily, 4 with Skull and Pharaoh stages, Cossack 3/4)
I'm not saying that 2 and 4 were bad. Just that 3 was best. 3's music quality was consistently high, not having a few bum tunes like 2 did (or a lot of bum tunes like 4 did). Probably the only tunes I'm not really fond of in 3 are Gemini Man's stage and Shadow Man's stage. All 19 other tracks are good.
3 also has the best Robot Master boss theme, which never hurts.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Try playing Alundra 2 sometime. It's a 3D Zelda-style game which is controlled with the D-pad, and the controls are terrible for that very reason.
D-pads would also make FPSes harder to play, true. But that wasn't the point.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Another vote for Einhänder, which would certainly be better than the R-Type TASes we have at the moment. An Einhänder run should try to get as many kills as possible while getting all of the special bonuses. Should it also get the secret weapons? On the one hand, it'd be amusing to show the Ptyhon [sic] to viewers, but on the other hand, it'd take up a gun slot...
Speaking of R-Type, there's R-Type Delta for the PSX, right? Never played it myself.
The Playstation was also the first console to get DDR games. >.>
Alundra would be a long TAS, and I'm not certain that its puzzle-centric gameplay would be particularly interesting. For people who haven't played, imagine 2D Zelda with every dungeon being the equivalent of the Water Temple from Ocarina of Time. It's a great game, but it's not remotely short.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Why in the hell has no one mentioned Castlevania: Symphony of the Night> I'm disappointed in you people. :(
SotN had some decent tunes, but something like 60% of the second castle all used the same bad theme, which is a major black mark there. My favored Castlevania games for music are SCIV and Dracula X.
For the Megaman series, 3 has the best music, no question.
There's tons of good RPG scores out there. Y'all should check out Grandia II sometime.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
I can't really see a multiplayer-based game being very impressive when TASed unless it's being done as a performance and not for speed (see also: tool-assisted SSB 4x matches). This is especially true for FPS games, which tend to be very hard to watch since your field of view is so limited.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Good point on the system resources. I hadn't thought of that. Maybe if you ran the whole shebang in a VM, you could just do RAM tricks.
As for the RNG, I don't personally like the idea of using a special-purpose RNG that magically always gives us the values we want. If we don't have a well-defined RNG to use with the game, then we should pick some generic implementation (the Mersenne Twister is generally considered to be strong, if not overkill, for example) and just use a vanilla version of that. I can see the counter-argument, though - we're going to get the results we want anyway; why not make it easier?
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
I don't know how the implementation of the RNG system calls in WINE works right now, but whatever would be used for a TAS would need to be written to be completely independent of other processes on the machine. The only way to update the RNG should be by calling RNG functions from within the game you are TASing. Anything else results in a non-reproducible movie.
Edit: note that the standard RNG implementations depend solely on the starting seed and the number of times an instanced RNG is called. Thus normal RNGs are already process-independent. This is necessary for debugging of programs that include random behavior (which is, basically, very similar to TASing). For example, I wrote a little pseudo-fractal image generator which accepts an RNG seed. As long as I feed in the same seed (and don't change the code of the program), I get the same result.
I had an assignment in college once where we were required to achieve the optimal number of RNG calls for an evolutionary algorithm. Reason being, if we had more calls, then we'd get slightly different (if still reasonable) results, which meant that the automated grading program wouldn't work right.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Well, there's 1186 published movies. Seems like that should be enough to make something reasonably neat-looking. Obviously the more images you have the more likely you are to have the one that works just right for that segment of the final image. Also, the Game Boy screenshots are unlikely to be very helpful. Monochrome and all that.
There's the small problem of resolution; generally in a mosaic every input image has the same resolution, whereas different consoles have differing resolutions.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
The RNG needs to start from a fixed seed so that when you play the movie back, RNG calls made at the same point in the movie give the same results. You shouldn't otherwise mess with the RNG because that would mean you weren't playing "pure" Diablo 2 any more. I don't know what causes D2 to invoke the RNG, but I'd guess it's dependent largely on what dynamic objects (creatures, spell effects, rats/scorpions/fluffy rabbits/etc.) are in-frame. It almost certainly doesn't directly depend on use input.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
The suggestion was made earlier in the thread that something might be possible using WINE. Here's how I'd envision this working:
1) Hack WINE to wait for user input after a system call that is made every frame (e.g. the draw-to-screen function -- though this would skip lag frames). This gives you frame advance.
2) Hack the get-current-time system call to return times based on the current frame. This stops D2 from trying to compensate for perceived slow frames because of (1).
3) Use a utility to read the memory being used by D2 and save the relevant parts to disk. This gives you save states, and is also almost certainly the hardest part of this whole thing.
4) Figure out how to read those saved states back into memory. If (3) isn't the hardest part, then this probably is.
5) Hack the RNG to start from a fixed seed.
The rest is just a matter of figuring out a good format to store inputs in, and implementing all the useful UI widgets. And then, y'know, actually making the TAS.
Annoyingly, (3) and (4) would probably have to be done on a game-by-game basis, which prevents this approach from scaling well to do general-purpose Windows game TASing.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Does SSB have a tournament mode like Melee and Brawl do? If so, I think a good way to TAS the game would be to do a tournament with all the different characters and just do a playaround that way.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
