Experienced Forum User, Published Author, Player
(26)
Joined: 8/29/2011
Posts: 1206
Location: Amsterdam
Mothrayas wrote:
The rule is written and enforced exactly as intended, you don't need to put all the emphasis on "interpretation".
That's not a surprise: the rule was written by you and is being enforced by you. So clearly it is doing what you intended.
The question is how many people actually agree with this rule. I have so far been unable to find any discussion on this rule from before it was added (then again, such discussion may have been on IRC instead of in the forum). I don't see any problem with getting some more input on this.
Experienced Forum User, Published Author, Player
(26)
Joined: 8/29/2011
Posts: 1206
Location: Amsterdam
Mothrayas wrote:
But the choice as to whether a game is educational or not is more than just a label on the box. It's a key facet behind game design decisions, behind visual appearance and prominence decisions, behind what the game designer wants to show to the user in order to make them absorb their educational contents as best as possible to the best of the designer's ability. There's a whole science behind this sort of design.
I seriously doubt that most (or any) makers of educational games consciously use any kind of science behind their design :)
Alyosha wrote:
Yeah, I just don't agree that there should be a blanket ban on games with those design asthetics. I don't see a need for it and don't see it as desirable.
The existing rules regarding non-games seem sufficient to me to cover non-game educational content.
I concur. Aside from that, "no educational games" was not part of the original Vault rules, but added in 2015; this edit doesn't specify the reason for the change, or where discussion about it took place.
I think this would be a good time to open a thread in the General forum to see if there is support for removing this restriction.
Experienced Forum User, Published Author, Player
(26)
Joined: 8/29/2011
Posts: 1206
Location: Amsterdam
Warp wrote:
(Personally I would have interpreted the rules mentioning "educational games" as being a typical example of a "non-game", because such educational games seldom have progression and an ending in the same way as typical games do. I wouldn't have interpreted it as a hard rule that if a game has any "educational" aspects to it, it's banned period.)
I agree with this. If we'd interpret "educational" as a hard ban, then we get into all kinds of slippery slope arguments on how to exactly define "educational" (as already seen in this thread). It makes more sense to look at why this is listed in the vault rules. That's apparently because most educational games either don't have an end goal, or are so lacking in gameplay that a TAS is indistinguishable from a human speedrun.
But not all of them. For instance, [2171] NES Where in Time is Carmen Sandiego? by Bobo the King in 2:01:54.05 and [3212] NES Bible Buffet by Invariel, Spikestuff in 03:33.28 are published and those are clearly educational, too. So it strikes me as going against site precedent to reject this game, which contains actual gameplay, just because it has the word "education" on the box.
Experienced Forum User, Published Author, Player
(26)
Joined: 8/29/2011
Posts: 1206
Location: Amsterdam
Does the run sync if you change the RTC time value? That may be the easiest way to adjust the Arnoid. I think that anything randomized before that is only cosmetic.
Experienced Forum User, Published Author, Player
(26)
Joined: 8/29/2011
Posts: 1206
Location: Amsterdam
FractalFusion wrote:
I used Cheat Engine on SQ3 in DOSBox to find out how the RNG sequence works for this game. The sequence is given by:
x←31821*x mod 65536
I note that this is exactly the same as the random number generator in AGI, except using 16-bit variables instead of 8-bit. Given that both engines were made by basically the same people, that should be unsurprising.
I'm willing to bet, then, that the initial seed is also the same, based on the time after midnight.
AGI's initial seed is (time in seconds) * 20 + ((time in milliseconds) / 1000) * 20, calculated when the random function is first used in-game (and note that creating the seed will immediately advance it once).
Experienced Forum User, Published Author, Player
(26)
Joined: 8/29/2011
Posts: 1206
Location: Amsterdam
No luck so far in finding out the randomness algorithm for SQ3. Unlike for AGI, the reverse engineering for SCI appears to be incomplete, and the sole new implementation I've found (FreeSCI / ScummVM) implements its own randomness.
Experienced Forum User, Published Author, Player
(26)
Joined: 8/29/2011
Posts: 1206
Location: Amsterdam
Speaking of which, it may be nice to state in the rules that the "initial RTC time" in JPCrr's config may be set to whatever value you wish. Several published runs already do so.
Experienced Forum User, Published Author, Player
(26)
Joined: 8/29/2011
Posts: 1206
Location: Amsterdam
Minor note - the Arnoid robot is chasing Roger because of vending machine fraud (says so on his visor), i.e. the whistle in SQ2; not the slot machine in SQ1. Breaking the slot machine is optional, anyway.
During the wait time on Ortega, you could do something funny with the mouse cursor, perhaps. Such as around the 30 second mark in the SQIV run, https://www.youtube.com/watch?v=qKm42lwk0JM
And I agree with c-square that your first run is probably publishable; just because there's a known improvement doesn't mean you have to redo everything.
Experienced Forum User, Published Author, Player
(26)
Joined: 8/29/2011
Posts: 1206
Location: Amsterdam
DrD2k9 wrote:
Ok, throwing another wrench into the discussion....
What about total memory settings? They shouldn't affect speeds other than loading/lag, correct?
Many DOS games store graphics in memory because from there they can be accessed faster than from disk. Throughout most of the DOS era, a game will require an exact amount of memory. If your system has at least this amount, the game will run; if less, the game will not run (i.e. either it aborts on startup, or it crashes mid-play with an "out of memory" error). Note that the DOSbox default memory settings are way above any of these requirements. Confusingly, some of these older games will not run on a machine with too much memory; this has something to do with integer overflow, causing the game to detect a negative amount of memory.
Some late-era DOS games will check how much memory you have and use basically all of it as a graphics cache. Generally this means that there's a threshold below which the game technically runs but becomes sluggish, and above this threshold the game runs fine but still becomes a bit faster if there's more memory. This threshold is usually 4Mb or 8MB, so DOSbox's default of 16Mb is again well above that.
I'm not aware of any DOS games requiring more than 16Mb of memory, so this default should be fine for all DOS games unless you can prove from game documentation that a game actually requires more than that. JPCRR defaults to 4096 pages, which also equals 16MB of memory.
HTH!
Experienced Forum User, Published Author, Player
(26)
Joined: 8/29/2011
Posts: 1206
Location: Amsterdam
Wow, that was fast! Congrats!
DrD2k9 wrote:
But how did we know the calculation? I've been looking everywhere i can think of and searching online and can't find anything.
How did you find it for SQ1?
By reading the source code of the engine, not of the game. I can find out as needed when it becomes relevant for other SCI games.
Experienced Forum User, Published Author, Player
(26)
Joined: 8/29/2011
Posts: 1206
Location: Amsterdam
Right. So the point shouldn't be whether somebody calls it a cheat mode, but what the option actually does. For instance, site precedent shows that cheat codes that unlock a higher difficulty mode are perfectly valid for a TAS.
Because instantly skipping to the last level or getting permanent invincibility (both common codes in Apogee games) are a whole different cup of tea than spending two seconds and one hit point to launch an energy bolt.
Anyway, I would be interested in hearing slamo's assesment on whether these codes would be a time saver in the first place (because it appears they require you to stand still for two seconds). That may make the issue moot without setting precedent against secret special moves in other games.
Experienced Forum User, Published Author, Player
(26)
Joined: 8/29/2011
Posts: 1206
Location: Amsterdam
DrD2k9 wrote:
There hasn't been much response on the CPU speed topic.
That's possibly because nobody much ever reads or posts in the "computer emulators" subforum; you might want to try crossposting or getting the topic moved to this one.
That said, I agree that for SQ3 in particular, keeping the 20 MHz speed setting is a good choice.
Experienced Forum User, Published Author, Player
(26)
Joined: 8/29/2011
Posts: 1206
Location: Amsterdam
Ok, this game isn't popular enough to have a lot of FAQs and materials about it on the internet, but for what it's worth, one out of two walkthroughs I've found considers these special attacks to be cheat codes and the other does not. Also, speedrun.com has decided that they're not. Again, for what it's worth.
More to the point, according to the manual, they are "secret moves which give Snake valuable added weapons". The plasma bolt and fireball are balanced by costing one hit point per shot. The shield and invincibility are balanced by the fact that the manual doesn't tell you how these moves work, either, and recommends that you figure it out yourself during gameplay. The shield prevents you from moving while it's active, which makes it basically useless in a TAS. The other three moves require you to stand still for about two seconds while you activate them... which would make them interesting in a TAS to see if they save you enough time.
Pretty much every Apogee game has cheat codes, which are printed in the manual and described as "cheat codes". These four "added weapons" are not; however the manual on Bio Menace does contain something else which is explicitly labeled a cheat code, i.e. a keyboard combination that gives you maximum ammo and grenades. Using this code in-game also shows a message box reading "Cheat Option", whereas the four "added weapons" do not do this.
So it's pretty obvious to me that the developers consider the max-ammo to be a cheat, and do NOT consider these four special moves to be cheats.
Experienced Forum User, Published Author, Player
(26)
Joined: 8/29/2011
Posts: 1206
Location: Amsterdam
slamo wrote:
I know about the secret moves, and I talked to Mothrayas about whether they would be permissible before I started the run. We leaned towards calling them cheats because they certainly resemble them (obscure button combinations giving you an advantage), despite not being listed in the cheats section in the hint manual.
If they are outright listed in the manual, you can hardly call them secret moves. They're an incentive to buy the game (since the free first episode doesn't come with the manual) but I don't really see how they can be considered cheats. I think they're intended as the fireball/dragon punch in the first Street Fighter game.
Well done on the run, but I don't find this movie very interesting to watch. To be fair, part of this is because of the bland level design (apparently the best designers worked with id, not Apogee). I'd call this prime Vault material, so I'm going to vote meh on entertainment.
Experienced Forum User, Published Author, Player
(26)
Joined: 8/29/2011
Posts: 1206
Location: Amsterdam
DrD2k9 wrote:
I understand that perspective, but what about games that were released after processor speeds in excess of 20MHz were available.
This is not a hypothetical. According to Wikipedia, commercial games for the DOS platform were released as late as 1998. Processors with a clock rate higher than 20 MHz were available to the general public nine years before that, in 1989. As a result, they were common in the early nineties, and more to the point, downright required by numerous games released in the early nineties.
So while I do agree that there should be a default speed for DOSbox games, it is not realistic for this speed to be capped at 20 MHz for all of them. However: almost all PC games from the nineties link the gamespeed either to real-world time or to the monitor refresh rate. This was basically required because in the early nineties, CPU speed varied a lot between PCs. As a result, these games will not go faster if the CPU is set arbitrarily high. However they will go slower if the CPU is set very low (e.g. at 20 MHz), because of lag.
Conversely, both the game Fog mentions (CD-Man) and the one currently under discussion (Space Quest 3) do not tie their gamespeed to either the clock or the vsync. This was possible in the late eighties because at that point, CPU speed did not vary a lot between PCs (e.g. the difference between a 16 MHz and a 20 MHz CPU is comparable to that between a 50 Hz and a 60 Hz monitor, and at that point many developers just ignored the difference; a few years later a common difference was between 33 MHz and 200 MHz, and that's much more of a big deal).
So arguably it makes sense to have a 20 MHz cap for games that run arbitrarily fast without a cap, and probably all those games are old enough that they run fine on a 20 MHz CPU. Conversely, games that cap themselves (e.g. by monitor rate) arguably do not need a 20 MHz cap, and many of these games simply cannot run on a 20 MHz CPU anyway.
Experienced Forum User, Published Author, Player
(26)
Joined: 8/29/2011
Posts: 1206
Location: Amsterdam
We have strong precedent that switching from an English ROM to a Japanese one for the sole purpose of text speed does not count towards obsoletion. That is, if the J-ROM is five seconds faster but this is because showing the text takes six seconds less, then the overall run is counted as one second slower than the current run.
It stands to reason, then, that switching to a faster (virtual) machine for the sole purpose of speed should likewise be discounted for the purpose of obsoletion. Clearly redoing the exact same run with a faster CPU should not count as an improvement.
Experienced Forum User, Published Author, Player
(26)
Joined: 8/29/2011
Posts: 1206
Location: Amsterdam
c-square wrote:
I'm not sure what "u<" does,
Unsigned comparison, so instead of the regular scale of -32768 to 32767 it considers all integers to be on the scale of 0 to 65535.
The apparent point of this code is to remove certain slow operations, like big animations, on slower systems. Of course lowering the CPU speed will make the run longer, but there is one trick that may make it worth manipulating, and that is the turbo button.
In the mid '80s, many PCs had a button on the box that switched between full clock rate and a lower clock rate (generally either half the full rate, or 4.7 MHz). The intent of this was compatibility with older games, since some games have an uncoupled framerate (meaning they'll simply run as fast as the system allows, or way too fast on newer systems). Of course, many other games couple their framerate either to the system clock or the monitor vsync rate, so this doesn't always apply; turbo buttons were phased out in the late '80s when most or all games had figured out system-independent timing. Dosbox supports this feature, I'm not sure if JPC-RR does.
Sierra games actually have a coupled framerate, which is 12 FPS in AGI games. I think it's the same for SCI although I haven't found specifics on that. This means that the only thing a slow processor can do is cause lag frames. I find this unlikely because Sierra games newer were very graphically intensive in the first place. But it is a remote possibility that starting the game in slow mode (of 4.7 MHz) then switching to turbo after this check will set global124 to zero and lead to a faster run.
Experienced Forum User, Published Author, Player
(26)
Joined: 8/29/2011
Posts: 1206
Location: Amsterdam
That's a cool find. My first thought was that it looks like a debug code, but given how Sierra's (very extensive) debugging system works it absolutely does NOT look like a debug option but an actual glitch.
I'd have to check but I'm pretty sure that once you're on the other planets, the game doesn't check any more whether your ship is repaired.
Experienced Forum User, Published Author, Player
(26)
Joined: 8/29/2011
Posts: 1206
Location: Amsterdam
DrD2k9 wrote:
I have version 3.0.1.7 and it still won't decompile, but does disassemble. The vocabulary files are also visible. They're not quite as 1:1 as with AGI Studio's words.tok editor, but SCI recognizes MANY more words than the older AGI systems.
Yes. I've recently realized that the SCI engine has a horrendously complicated semantic parser system that is completely ignored by all the games written in SCI.
Anyway, SCI studio has a radio button somewhere that picks the SCI version of the game. Try fiddling with that.
Apparently, blowing up the shield generator on Ortega allows you to access Pestulon even if story-wise you have no reason to go there. So yes, you should be able to skip the whole McDonalds sequence.
Experienced Forum User, Published Author, Player
(26)
Joined: 8/29/2011
Posts: 1206
Location: Amsterdam
FractalFusion wrote:
By the way, SCICompanion isn't able to decompile the scripts, at least on Version 1.018. The disassembly still helps though.
There are tools that do that; I'll go check. It may help to do that to find out what the parser commands are, because
In most cases, if the first and last words are correct, it will work.
that's not actually how the parser works. Of course, Sierra games very rarely require any commands that aren't exactly one verb and one noun, so it is usually how it works in practice. But sometimes there's a one-word synonym for a three word phrase for no gramatically obvious reason.
So while I do agree that there should be a default speed for DOSbox games, it is not realistic for this speed to be capped at 20 MHz for all of them. However: almost all PC games from the nineties link the gamespeed either to real-world time or to the monitor refresh rate. This was basically required because in the early nineties, CPU speed varied a lot between PCs. As a result, these games will not go faster if the CPU is set arbitrarily high. However they will go slower if the CPU is set very low (e.g. at 20 MHz), because of lag.
Conversely, both the game Fog mentions (CD-Man) and the one currently under discussion (Space Quest 3) do not tie their gamespeed to either the clock or the vsync. This was possible in the late eighties because at that point, CPU speed did not vary a lot between PCs (e.g. the difference between a 16 MHz and a 20 MHz CPU is comparable to that between a 50 Hz and a 60 Hz monitor, and at that point many developers just ignored the difference; a few years later a common difference was between 33 MHz and 200 MHz, and that's much more of a big deal).
So arguably it makes sense to have a 20 MHz cap for games that run arbitrarily fast without a cap, and probably all those games are old enough that they run fine on a 20 MHz CPU. Conversely, games that cap themselves (e.g. by monitor rate) arguably do not need a 20 MHz cap, and many of these games simply cannot run on a 20 MHz CPU anyway.