Re: SMASH help much appreciated
Sam, on host 98.216.121.131
Thursday, May 3, 2012, at 10:40:05
Re: SMASH help much appreciated posted by RyaCAM on Wednesday, May 2, 2012, at 14:46:16:
With regard to move counts, my advice is not to worry about them at all. Almost nobody plays AGL games to optimize move counts -- they just want to experience the game and world without worrying about that.
But if you do care and are really keen to have a fair move counter, and the automatic move counter (the "Moves" column in the Hall of Fame) doesn't work for you, then I would suggest starting an up-counting timer in start.sma and then leaving it alone most of the time. Whenever you have an action that *shouldn't* cost an action, do a "t << 1" command.
But it sounds like your question is more along the lines of *when* you should do this, rather than how. There's no one right answer, but I would recommend rewinding the timer for any moves that don't result in something actually happening within the game world. That is, if you take, drop, eat, spit on, or punch something, it costs an action. If you examine it (such as by clicking on it in the inventory), it probably shouldn't -- because you're just receiving information about an object that, were you in the game world, you'd have gotten anyway. For example, if I pink up an apple in real life, I don't need to take extra time to determine that it's red. I'd know anyway. But in a game, it's often better from a usability standpoint to just say, "You pick up an apple," and only supply other information if the player asks for it, rather than burdening the player with all that extraneous information right off the bat and say, "You pick up an apple, which is red, smallish, fresh except for a wormhole near the top, has a broken stem, feels firm, and has no slugs on it whatsoever."
Similarly, if the practical effect of choosing an option (whether from your inventory or in one of the proper menus) is just that it brings you to another set of options, then this obviously takes no in-game time either and thus shouldn't be counted as a move.
Now, a couple of the AGL games use the inventory options almost exclusively for passive item examination -- which shouldn't count as a move -- but with exceptions. That is, while examining most items is always passive, at one point you do have to examine one particular item to advance through the game. Because, I don't know, examining a clock reveals to you that there's a note hidden inside. In these cases, you can have only those examination options count as a move, or you can be consistent and allow those too to be free moves. It really doesn't matter that much. Again, I would honestly recommend NOT being too particular about this in the first place, especially for a first Smash game. It just adds another level of headache and challenge. Or at least try to get a non-move-counting version of the game working FIRST and then go back and add move counting.
The other reason it's not so important is that move counts only ever matter relative to each other. So, great -- you beat the game with three fewer moves than someone else, or in your last playthrough of it. The number that matters is that difference of three -- not that the absolute move count was 546 instead of 549. What I'm getting at is that it's much more important to count moves the same way each time (which would be the case by NOT having your code do anything to count moves and just letting the automatic move counter do the work) than count moves in any particular way.
> > 4. Character profiles / situation summaries. Looks like it's quite doable with virtual locations*, but I can't save the current in-game location. The following does not work: > > v loc1 = S:loc > > g loc2 > > .... > > g {'loc1} > > (I tried several combinations of {}s, ''s, c: and S: operators. No luck.)
What RyaCAM suggests will work, of course, but I'm kind of confused that "g {'loc1}" didn't work. It should have! In fact, some of the existing AGL games do this very thing.
Is your location name longer than 8 characters? Because S:loc only evaluates to the last 8 characters of the location name. But assuming 8 characters or fewer, it really should work. I guess I'd have to see more of the code to figure out why it's not working.
|