1 2
13 14
Editor
Joined: 3/10/2010
Posts: 899
Location: Sweden
Jetpack is a great game. It is a platformer that only has one fixed screen at a time. The goal is not just to reach the goal, but to grab all the gems in the level first. What makes it interesting is the combination of what the player can do and the variety of enemies. The game is named after the key feature in the game, the jetpack. By collecting fuel, you can simply fly wherever you want in the level. But there is a secondary gameplay element, the ability to phase some types of blocks in the level. By phasing a block for some time (short or long depending on the block), you temporary make the block act as an empty space, allowing free passage for you. You can use this to trap enemies. There are some normal platforming fun tricks too, expect ice floors, teleporters and a few toggleable walls. The enemies are a varied bunch, there are a ball that runs along the floor, a rocket that turns right, a bouncing thingy and some other misc stuff. But there is also an enemy that uses pathfinding to track the player down. What most people don't realize at first is that enemies will use teleporters too. With all this in mind, it is very well suited for tasing. JPC runs the game perfectly. The game is also freeware since a number of years. Some advice for tasers:
  • Teleportation grants you temporary invincibility.
  • Enemies has no choice if they want to teleport, they will always do so.
  • There are random powerups that spawn during gameplay. They include invulerability, freezing enemies and free fuel. Naturally, this should be exploited heavily.
  • The game speed is adjustable and varies depending on the number of enemies on the level.
  • If you hold down while flying, you will keep your height.
  • Teleporters may teleport to the wrong color if the level has too many of them.
  • If you reach the goal, you win, even if you happen to be dead.
  • You can trap enemies in any title that temporarily acts like an empty space.
  • You can jump in ladders.
  • Flying and phasing are not mutually exclusive.
  • Phasing downward will make you stop moving, even on ice covered tiles.
Joined: 5/19/2010
Posts: 259
Location: California
I remember playing this game a long time ago. Ironically, it was never on any computer my family members used, only at friends' places. I don't know if it was because their computers were STATE OF THE ART (at the time) and our computers were unable to process SUCH CUTTING EDGE GRAPHICS or vice versa. A quick refresher from wiki indicates that this game has 100 levels. And that a DS port is indefinitely on hold.
#3201
Joined: 11/22/2004
Posts: 1468
Location: Rotterdam, The Netherlands
I like this game more than its obvious counterpart, Lode Runner. It's also pretty hard :) Would love to see a TAS of it.
Joined: 4/2/2007
Posts: 68
Location: Latvia
This needs to be done.
This is a block of text that can be added to posts you make. There is a 255 character limit
Joined: 9/27/2011
Posts: 207
Location: Finland
I wonder if the random item spawns would turn out to be manipulable. I think probably they'd always be on a timer of some sort, but maybe where they spawn is.
Editor, Emulator Coder, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
IIRC, Jetpack has one of those "speed sliders" common on older games, and no consensus was reached as to how it should be set?
Emulator Coder, Skilled player (1141)
Joined: 5/1/2010
Posts: 1217
natt wrote:
IIRC, Jetpack has one of those "speed sliders" common on older games, and no consensus was reached as to how it should be set?
8. That's the highest locked speed (there's unlocked, but it is by far too fast[1]). And besides, there's an emulation error in JPC-RR: All the locked speeds are the same (whereas in DOSBox there's a difference). [1] It is so fast that it is almost impossible to control even tool-assisted (I guess subframe input would work, but would be nightmare to make run using one). Doesn't look fun to watch either.
Joined: 9/27/2011
Posts: 207
Location: Finland
The first level (I wanted to include a screenshot I'd taken myself but didn't understand how) seems to be something in the vein of the Travelling Salesman's Problem. I bet there's software out there created for solving the problem. If it was versatile enough, you could maybe "solve" the more open-ended levels using such software. You start at around where the "02" is in the bottom bar. There's a double fuel tank to your right. I think you could try different methods to simplify the equation, e.g. the two gems inside the room made of stone would be considered one node. You could also try to sever off connections that seem too distant and impose other restrictions and rules, again depending on the versatility of the software. I'm not skilled in maths or programming but I'd be interested in hearing whether this would be the general sort of strategy that anyone who's done TAS'ing would use.
creaothceann
He/Him
Editor
Joined: 4/7/2005
Posts: 1874
Location: Germany
Theoretically you just need to note the number of gems, and for each one the cost of travelling to every other one. Then brute-force it.
Joined: 9/27/2011
Posts: 207
Location: Finland
I understand such brute-force calculations can become very computationally costly. There's 15 gems in the first level, but really only 13-ish such that have to be considered separately. But if the level had 20+ gems, would it still be within computationally reasonable range? Or is it not as bad as I'm thinking?
Patashu
He/Him
Joined: 10/2/2005
Posts: 4016
Svimmer wrote:
I understand such brute-force calculations can become very computationally costly. There's 15 gems in the first level, but really only 13-ish such that have to be considered separately. But if the level had 20+ gems, would it still be within computationally reasonable range? Or is it not as bad as I'm thinking?
The total number of possible paths (on the order of 20!) is staggering, but the total number of likely to be good paths is much much smaller (since you never want to, for example, go from 1 to 3 then back to 2 that's about half way between them), and there are good heuristic approaches to the travelling salesman problem that aren't guaranteed to find the best, but find a great solution. (A trivial example is to create the path corresponding to always going to the nearest unused neighbour, then going around the path and trying every flip of nodes one by one to see if it improves it)
My Chiptune music, made in Famitracker: http://soundcloud.com/patashu My twitch. I stream mostly shmups & rhythm games http://twitch.tv/patashu My youtube, again shmups and rhythm games and misc stuff: http://youtube.com/user/patashu
Player (228)
Joined: 4/25/2012
Posts: 73
Another potential challenge is the existence of enemies; the cost of travelling from one point to another will vary depending on what position the enemies currently occupy, and as such you can't rely on reducing it to a travelling salesman problem.
Joined: 9/27/2011
Posts: 207
Location: Finland
Yeah enemies, block breaking and traps at least create complications, but the initial TSP solution(s) would serve as a starting point. In the first level it's unlikely to run into the two "joysticks" by accident, but elsewhere that stuff would certainly come into play. Hmm... I don't know what version the screenshot is from, cause my version has two "joysticks" and no spinners.
Emulator Coder
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
The game came in a 10 level demo version (if I'm not mistaken, they made more than one), a 35 full level version from Software Creations, a 100 level version from Impulse Software, and finally a 100 level version from Adept Software with a bunch of add-ons. The latter version is available for free and is the one which should be TAS'd. Of the levels that exist within all of them, the various versions made minor tweaks and changes to a bunch of them.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Editor
Joined: 3/10/2010
Posts: 899
Location: Sweden
That's two enemies called trackbot and spikes. Also, there seems to be at least three different versions of the game. I seem to have a copy of the rare early christmas demo. [URL=http://imageshack.us/photo/my-images/62/xmasjetpack.png/][/URL]
Emulator Coder
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
I think I enumerated all the versions that existed. As for that alternate demo, it's not that rare, it was part of many shareware collections back in the day. You can also get all 10 levels of it individually with the Adept Software release, among others. Edit: Apparently Adept Software also allows you to download early prerelease versions which are rather different. As for the name of the monsters, from the manual:
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Joined: 9/27/2011
Posts: 207
Location: Finland
I was trying to use JPC-RR in conjunction with Cheat Engine to find some memory locations and store them. However, it seems that the program assigns the game's data to a different place in memory each time so it's not enough to find the correct addresses once. Is it even possible to do what I'm trying to do? The game runs okay in the emulator, but I'm getting all sorts of crashes from CE and now the emulator froze as well... Yeah I had the German version for whatever reason.
Warepire
He/Him
Editor
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
Svimmer wrote:
I was trying to use JPC-RR in conjunction with Cheat Engine to find some memory locations and store them. However, it seems that the program assigns the game's data to a different place in memory each time so it's not enough to find the correct addresses once. Is it even possible to do what I'm trying to do?
If you mean that the memory block used by the game is in a different location every time (by this I mean that the memory has the same structure, but the addresses are never the same) this can be "solved". I don't remember exactly how but look at the Cheat Engine tutorial for Dolphin in the Dolphin Emulator section, it describes how to do it for Dolphin but the principal should be the same for any program that has the same behavior.
Emulator Coder, Skilled player (1141)
Joined: 5/1/2010
Posts: 1217
Svimmer wrote:
I was trying to use JPC-RR in conjunction with Cheat Engine to find some memory locations and store them. However, it seems that the program assigns the game's data to a different place in memory each time so it's not enough to find the correct addresses once.
JPC-RR doesn't have memory watch, but it has Lua (unfortunately it tends to freeze the emulator now and then, but one should be able to stop and restart the lua script). And Lua can be used to peek at various values. Unfortunately, depending on how the game is loaded, the memory addresses can vary (by multiples of 16), but once loaded (which only happens once) the addresses should stay stable (and differences between addresses should always stay stable). I once searched some of the memory addresses in absolute memory space: 25C83: X position (Word) 25C81: Y position (Word) 27020: Fuel left (Word) Depending on the loading, you might need to add or subtract some constant multiple of 16 from those addresses. Also as speed hint, set the CPUdiv as high as possible without game starting to lag (which should be pretty high with this game). The highest it will go is 256.
Joined: 9/27/2011
Posts: 207
Location: Finland
Warepire, I'll have a look at that Dolphin example. If that doesn't work, I'll have a look at the Lua option if it's not too complicated for me.
I once searched some of the memory addresses in absolute memory space: 25C83: X position (Word) 25C81: Y position (Word) 27020: Fuel left (Word)
By absolute memory space you mean the memory that the game data itself is loaded into as opposed to where JPC-RR keeps its own stuff? How did you know/did you just try different options to find out that it was indeed a word and not something else? Why does the game reserve a whole word for representing those things? It seems to me 2 bytes would be enough.
Depending on the loading, you might need to add or subtract some constant multiple of 16 from those addresses.
How big of a gap can it be? Is it always in the same "neighbourhood" so you could just browse the memory and be able to spot it if you knew whereabouts to look?
Emulator Coder, Skilled player (1141)
Joined: 5/1/2010
Posts: 1217
Svimmer wrote:
By absolute memory space you mean the memory that the game data itself is loaded into as opposed to where JPC-RR keeps its own stuff?
Yes. And also the bus address space of emulated PC. This is the address space memory read/write Lua functions use.
Swimmer wrote:
How did you know/did you just try different options to find out that it was indeed a word and not something else?
On earlier DOS games, memory addresses are usually words, unless game needs to store bigger values there or just boolean flag.
Swimmer wrote:
Why does the game reserve a whole word for representing those things? It seems to me 2 bytes would be enough.
The width of screen is 320 pixels... 1 byte would not be enough, and radix-320 representation would be complicated.
Swimmer wrote:
Depending on the loading, you might need to add or subtract some constant multiple of 16 from those addresses.
How big of a gap can it be? Is it always in the same "neighbourhood" so you could just browse the memory and be able to spot it if you knew whereabouts to look?
config.sys / autoexec.bat can make a big difference. One method is to memory search for the easiest one and then use constant differences to recover the rest.
Player (26)
Joined: 8/29/2011
Posts: 1206
Location: Amsterdam
Svimmer wrote:
Why does the game reserve a whole word for representing those things? It seems to me 2 bytes would be enough.
Because it was written for a 16-bit system, so working with 16-bit variables is fastest. This is more of a bottleneck than memory constraints.
Joined: 9/27/2011
Posts: 207
Location: Finland
Ilari wrote:
Svimmer wrote:
By absolute memory space you mean the memory that the game data itself is loaded into as opposed to where JPC-RR keeps its own stuff?
Yes. And also the bus address space of emulated PC. This is the address space memory read/write Lua functions use.
So wait... a simple Lua algorithm would find the necessary memory locations because it starts its search directly from the game data? Or is the BIOS data also searched? Meaning autoexec affects it? But how about if I always launch the BIOS the same way wouldn't the memory always be the same as well? Is there an example of how the algorithm should look? Preferrably as complete as possible :) i.e. one that actually also displays the values it finds in the designated memory locations.
Joined: 9/27/2011
Posts: 207
Location: Finland
Hmm... I'm really at a loss as to how to use the later examples given in Cheat Engine. I launched some of the scripts provided with JPC-RR. I discovered that the game runs at 70 fps. ... otherwise I haven't got a clue why this 5-line code I took (as a test) from the site's Lua Scripting section doesn't work. It gives "Kernel: Unprotected error in script: attempt to index a nil value" I'm guessing this is a message from the emulator itself. Somehow the code isn't compatible with JPC-RR? Yeah I'm pretty hopeless with this stuff. If there were tools (scripts I could easily modify to search and display the right addresses or to get to perform simple algebra) I would take a look into some of the basic mechanisms of the game, but as it stands I don't have the skills or the energy to acquire the skills that it requires. I'm sure that was always the hard part anyway. local str="test" while true do gui.text(0,0, str) emu.frameadvance() end
Reviewer, Expert player (2392)
Joined: 5/21/2013
Posts: 414
I'm interested in this game as a first TAS but there appears to be a problem with the emulation. In the first level in certain spots you just seem to vanish when moving from one block to another. An example: On the next frame, holding left: Gone! After that he pops out near the golden vases and just drifts down ignoring all collisions. Am I missing something or is it just not being emulated properly?
1 2
13 14