Similar to OSS projects, Adelikat puts his WIPs in a googlecode SVN. I *think* that's what you're basically trying to get at in this thread, but nobody has brought it up yet. Maybe you'll find the concept useful?
I've played the game, but not recently. From what I recall, "level" is the enemy AI strength, so you should set that to "super".
Attack makes the enemy stronger, so increase it to max, but leave your own attack level at the default.
Leave HP where it is. Increasing it will only draw out the battle unnecessarily. You should decrease your own HP if you think it will make the run more entertaining, but I don't think you really need to.
edit: J'aurais essayé de traduire ce post, mais... Google translate probably makes more sense than I would. :p
I looked it up on Youtube, and am inclined to agree.
It was designed with human limitations in mind— you can only do the platforming or the tetris at any given moment. If a TASer were doing it, they would have a pointing device to control the tetris pieces while doing the platforming, and the pace could be much quicker.
There's also the randomization, which sucks the interest out of it. The viewer won't wonder "how is the player going to solve this problem?" but rather, they'll know that all the challenges in the game can be overcome by dropping pieces until they've built a staircase or whatever.
Instead of infinite pieces, the player should have a store of tetrominoes to use, which would be collected as consequences of route choices, or some other conscious decision on the player's part.
It occurred to me at some point that a judicious mix of features from RCR and Secret of Mana could have all the good points of both games, and none of the crippling flaws. RCR's plot and characterization were vacuous, and its difficulty scaling was broken.
SoM on the other hand had battle mechanics that rendered the bosses trivial. Y'know— magic spam, or that charge glitch. Kind of like bringing a bazooka to a knife fight.
I could actually imagine building "River City of Mana" explicitly for the purposes of TASing. It could be visually stunning to see a tool-assisted performance, and non-trivial to plan and execute.
I think you're right about that. I meant to speak broadly about how we might take advantage of how processing power has scaled since the days of our currently TAS-able systems.
I remember seeing a game review show on TV in the 90s, where a Nintendo dev was bragging in an interview about being able to render some then-large number of bats in Majora's Mask. To do the same thing now would be trivial, but games don't seem to take advantage of it in any meaningful way. At least, none that I've seen.
River City Ransom allowed only two enemies at once, and there would be lag. It only got worse with weapons and a second player, which is ironic considering that the best thing about that game was how frenetic the action was. So, how much stuff can we have happen on screen now, I wonder? Four players? Ten enemies? It would be nuts!
The worst thing to do is design a game that does nothing beyond the things we've already seen. We're accustomed to limited AI complexity idiotic and helpless AI because good AI is either not feasible or not cost-effective. These are the kinds of limitations we don't have to design around.
We should definitely try to invent some new gameplay mechanics— ones that make sense in the context of a TAS. Melding two disparate genres into one game, for instance, could be interesting.
Look at the demo in the "Hatsworth" thread in the DS Games subforum. It's a platformer in one screen, and Panel de Pon in the other. Taking that further, how about a platformer where the level is constructed during play, by falling tetris pieces controlled by the player?
Again, the purpose wouldn't be to subject the player to randomness that we already know they could just manipulate away. Rather, the point would be in allowing them to create things and solve problems using a novel and intricate system, hopefully so that the result is as interesting to watch as it is to produce.
Hypothetically, you could convert both the uncompressed and "lossless" compressed to raw, and see if the checksums of the raw images are the same.
I guess I could test that hypothesis instead of just talking about it, but... eh. Effort. :P
Apropos of what DarkKobold said, I think we should try to implement that bounty idea where the bounties pay toward the site instead of the runners*.
The idea of the site getting an upgrade from doing a TAS people wanted to see is surely more appealing than getting some tiny amount of money for oneself.
* Edit: that is, if we're going to do anything that involves money changing hands. It might be better not to do anything of the sort.
It would certainly seem that way. That April Fools thing was apparently to draw attention to the need for freshness here— what would be more unique to this site than something where we can not only do a TAS of something that is essentially a classic DOS game, yet have the ability to generate our own levels?
I kind of have to facepalm at my asking the question earlier. The fact that emulators can do rerecording and work cross-platform is proof enough that a non-emulator program could work just as well once the randomness is made deterministic, anyway. I guess threading might also pose some unique challenges, but anyway...
Thanks for the youtube, Antoids!
If that was dull, I can't wait to see more.
Not that I could offer any useful assistance on a system I can't emulate, but care to elaborate?
What about demo formats in OSS games? If you have a game like Quake 3 Arena that has built-in support for recording and replaying input, then you'd think the only other fundamental requirements are savestate support and a means of controlling the framerate very precisely.
Are there caveats I'm not thinking of?
I can hardly say no to bust a move, no matter how poor a clone. I also found the technical competence convincing, and even a bit surprising at a few points. So, yes vote.
I don't know the game well enough to comment on the route, but it definitely sounds promising.
To display a value we only need this snippet of Lua code:
while true do
gui.text(0,0, memory.readbyte(0x7e2fXX))
emu.frameadvance()
end
To get the display to line up with an enemy, we can also substitute the "0,0" with a memory.readbyte() of the enemy's X and Y coordinates, respectively.
Getting coordinates is tricky sometimes— they're often two-bytes long, meaning that we'd need to call readword instead of readbyte. In many cases, the raw coordinates also need to be offset by the "camera" position in order to print the value on-screen. You might also have to add guards so that gui.text doesn't try to write offscreen if the enemy data is invalid.
Probably not worth the trouble in a game where there are only ever a few enemies on the screen at once.
Edit: and if all you're doing is drawing a memory address to the screen, then you should be able to use a button in the Snes9x cheat search dialog marked "watch", rather than use Lua.
My first (and I think, only) rom hack was a simple text-replacement. I used translhextion. I think text hacking has the lowest barrier to entry, so you might want to start there. I think that— just playing with tools, I mean— would give you a foothold to learn about pointer tables, compression, and how ROMs work in general.
Also, it's ridiculously fun to make characters talk about dicks instead of the plot.
Did you try a disassembler? I don't know how much you know about this kind of thing, but It basically translates the hex digits in the ROM into something more comprehensible to humans.
My suggestion is to do this in a command prompt, substituting "disasm" for whichever disassembler executable, and the .gb's with actual roms:
$ disasm rom1.gb > rom1.disasm
$ disasm rom2.gb > rom2.disasm
$ diff rom1.disasm rom2.disasm
...And hopefully you'll get a small set of functions in the code that differ. That would be useful, since you could then could breakpoint those functions in a debugging emulator, step through the code to see which memory addresses they use, and then pin the values of those addresses with whatever cheat tool in the emu to get an idea of what they're for. You wouldn't even really need to understand the ASM output from the disassembler— the memory addresses themselves might tell you as much as you'd ever want to know.
Though, whether you'd find exploits from doing that is anybody's guess.
I was actually going to pick up at the end of Neophos' WIP. My plan was to write an input macro in Lua, have that do the luck manipulation in the King battle, and then post it back to the thread.
You can map joypad 5 to your hotkeys, and then define the behavior you want by hand:
hotkeypad = joypad.get(5)
if hotkeypad["X"] then doRewind() end
It doesn't run while the emulator is paused, but it's better than nothing.
You can also find sample scripts with the other emulator packages that are (more or less) portable.
As for the rewind script... yeah, someone should probably do that. Hopefully so that it would work reliably for this platform. I suspect there are (or at least, were, the last time I wrote a rewind script) issues in the emulator itself, since rewinding would throw userdata errors for no discernible reason.
I've been tinkering with Snes9x lately. Maybe I should do something about these problems... :/
Some hex editors do that. Couldn't name one offhand, though. I used to use one called "hexplorer", though you'd probably find something better googling "binary diff hex editor".
More to the point of what you want to do, you might also run a disassembly tool on both roms, and then use the UNIX tool "diff" on the outputs.
Not sure where you'd get diff for windows, if that's your platform, but I know it exists and shouldn't be hard to find.
Necrobumping is better than making a duplicate thread on this forum. It keeps all the information reasonably centralized, and then future runners know where to find it.
I for one am definitely still interested in seeing this game finally completed. In fact, I'd been planning to beat the king myself for about a year and a half. Never got around to it for a bunch of lame reasons. :/
Keep us posted if you decide to take this up.
The "console customization" seems like the kind of thing where you leave it alone unless you know why you need to do otherwise. Sort of like the dipswitches in MAME ROMs.
Meme of the year, right there.
The left+right thing has actually been done in realtime. It's on youtube, though I forget where.
Notwithstanding, I don't see how this finding would "invalidate" TASes, anyway. If I understand right, it means that we start with clean state and the realtime runners are using leftover bits from previous games, kind of like dirty SRAM. I figure that's part of the joke.
Also, I have to change my entertainment score on this fiasco to 9.5— I hadn't seen the "community of lies" remark until a minute ago.
I give the wildly overblown reaction a 8.7 for entertainment, and a 4.5 technical score for the three month gap between Dwedit's thread and this one.
See you next April!
I wanted to do a GTA run about a year ago, so I grabbed Bisqwit's patch and tried applying it to DOSBox 0.73. Spent about a week tracing through the code trying to figure out why it wouldn't initialize the video before giving up.
I was lazy as hell in my attempt, but I don't think getting a game running properly, much less stabilizing the emulation and making the recording bulletproof, is going to be child's play for anybody.
Though, I've been playing XCOM: TFTD, and would like very much to see a lone gunman going rambo on a sub...
Preliminary effort: I found the 0.70 source on sourceforge, which I had thought would mean that the source would be identical to what the patch expects. There are still some discrepancies, so who knows if it'll work this time or not. If it doesn't then obviously I'll have to dig a little deeper to actually understand the program.
Again, that takes time, and probably a lot of it in this case.
Edit: Sure enough, it's giving me a black, unscaled rectangle and no sound, nor any sign of an error.