Many years ago (too many), I posted in this forum announcing a new single player project. That eventually turned into five episodes and wasn't even completed until this year.

I figured I'd post here again, since I'm now working on a new project. I can't give you an ETA, or screenshots, or anything like that: what I've done so far is in the very early stages, with only a little bit of JCS work and a lot of writing. But that's how everything begins with me. You probably shouldn't expect anything more than a demo/preview (which I plan on making for this) until the middle of next year.

It's adapted from a very rough outline I wrote about a year ago, and also takes a lot of elements from my original plans for episode three (it was going to be way different originally). But now the entire story is plotted out and probably won't change much.

This project isn't going to be some sprawling epic that takes five or more hours to beat, and five or more years for me to finish. It also isn't going to be a true sequel to the previous story. It will be set in the same "universe", but the plotline will only be distantly connected. So, it's not really an Episode Six, and by the time this is done, it will probably have a different name.

It's going to take place in the time between episodes 3 and 4, and it will focus on one of the warships that retreated from Carrotus (seen at the end of ep3, and inserted in there in case I ever wanted to do a story like this). The ship picks up a mysterious passenger on Exoticus, and travels off to a distant and unknown planet. On this planet is a large complex of ruins, an old rabbit living in it who really shouldn't be there (or then), and the one thing every good set of ancient ruins needs: a chaotic rift in the fabric of time and space.

What's more interesting is the gameplay. I told myself, and others, that I'd never make an SP episode again unless I was able to do a number of things which JCS (and frankly, the game itself) doesn't let you accomplish. Lately I discovered that these things are probably going to be possible way sooner than I expected (I was kind of expecting somewhere in the area of "never", to be truthful), and they also don't require nearly as much modifying of the game as I previously thought they would.

Basically, I'm tired of making big levels, and I'm tired of the same old JJ2 gameplay. So instead, I'll take away all of the special moves, and then throw in complete non-linearity with smaller levels that have 3 or more exits, and maybe even have a central store that uses coins. The entire thing (except for a prologue) would take place in the mysterious ruins. Oh, and you'll unlock the special moves (and spaz too) as you play. The buttstomp will probably be the last to be unlocked. Little to no use of triggers: progress will come from finding weapons and special moves. So basically, it's JJ2 meets Metroid.

Think of it as one episode where the whole thing is a giant level that uses multiple tilesets. Also, it's going to require JJ2+, 1.24 (probably), and something else. (that last one is the important one)

Anyway, I'm probably not going to say much more for now about the story, except that it has two main characters and I personally think it's more interesting than my previous attempt.


Me making this thread means two things.

The first is that you can offer suggestions or comments, or questions about this thing. Maybe you think it's a bad idea? Or have a way it could be improved?

The second thing this means is that I actually have to finish it now. I've gone and announced this project, so it's official. This is actually the main reason for the thread. I'm more motivated when people know I'm working on something and nag me about it.

I thought about doing something similar, but never figured a way to "unlock" things... But man, if you can accomplish this... Wow. I'm looking forward to this.

Sounds interesting. I'm gonna subscribe to this topic(!).

Theoretically it should be possible to create some new special moves too i.e. a really high jump or a really long sidekick.

It's always interesting to see a side-story from another persons's view from another awesome storyline. I was planning on doing something like this later as well.

I'm very interested in how you accomplish this. I'm planning something similar (as in Metroid meets JJ2) for Devil Dash, but in a much later episode, so by that time I'm surely not going to be all that innovative if you manage to make this as you imagine, but proved ground will be much easier for me to thread and I will be able to focus more on storyline and art direction. It's a bit of a selfish approach, but it's all for the good of JJ2.

Originally Posted by Penalty

Theoretically it should be possible to create some new special moves too i.e. a really high jump or a really long sidekick.

I tried to do this, it's not quite as simple (same goes with running speed).

Disabling stomping, uppercut, buttstomp, copter, sidekick and double jump are actually just a matter of changing a few variables from their normal values. Sometimes it requires exploiting a bug, other times it's just stuff like tricking the game into thinking you aren't jumping even when you are. Actually adding new moves is a lot harder (though not impossible). The only one that would be quite easy is something like an infinite double jump, or something like that.

Wall jumping!

I believe it could be done by freezing the jump/sidekick timer.
I've done it a few times in Cheat Engine.

Originally Posted by Penalty

I believe it could be done by freezing the jump/sidekick timer.
I've done it a few times in Cheat Engine.

That's true. The problem is more that the moves also need to account for things like whether you hit a wall/celing/spring/etc, what happens when you let go of the button (in the case of uppercut), how much longer it should be when running (in the case of kicking), and so on. As soon as these moves are "expanded" beyond what the game normally allows, it's possible to run into glitchy stuff unless it's all accounted for. That doesn't make any of this impossible though, just a bit harder!

I'm intrigued.

I know you've been wanting to build something like this and while I can only guess at how this'll all be accomplished it's be awesome if you pulled it off. I think we talked about this for a bit once but I'm a big fan of the Castlevania series and have played and enjoyed several of the 2D Metroid games so I'd absolutely love to see something like this done in Jazz2.

I say go for it.

Originally Posted by EvilMike

I tried to do this, it's not quite as simple (same goes with running speed).

Disabling stomping, uppercut, buttstomp, copter, sidekick and double jump are actually just a matter of changing a few variables from their normal values. Sometimes it requires exploiting a bug, other times it's just stuff like tricking the game into thinking you aren't jumping even when you are. Actually adding new moves is a lot harder (though not impossible). The only one that would be quite easy is something like an infinite double jump, or something like that.

I'll give you the source code of cheatz.exe if you like... though I made pretty much all functions by altering the ASM, not by altering the player-struct directly

I guess it's safe to announce that we're doing this by implementing a scripting language for jj2. Although coding a new application over something that's already been compiled to binary code is a hidious task, and it may not give you everything you'd expect, but it does open up a lot of new possibilities. It's currently unknown what the final implementation will look like since the whole project is still in very early developmental stage. There's even a chance it might get integrated into jj2+ once it matures.

Originally Posted by Grytolle

I'll give you the source code of cheatz.exe if you like... though I made pretty much all functions by altering the ASM, not by altering the player-struct directly

It would be interesting to see this, just to see how it works... but yeah, the way I'm going (scripting) means I'm a bit more limited. Doing stuff with ASM allows all sorts of neat things, but the problem is, it would require me to distribute the episode with it's own exe file, a patcher, or a dll (in other words, it would be a standalone mod). Scripting is a bit better, because it's a bit more "convenient" for the player, and scripts can be embedded in the levels (or something similarly easy), instead of needing its own dll file or whatever. Also, scripting makes it quite easy to have special moves toggled on and off depending on what's happening ingame, which is important.

Just with the player struct, I don't think it's possible to do things like change the maximum amount of ammo you can hold, or take away the ability to run, but it still allows quite a bit - a lot more than I thought. And, in the level struct, there is a gravity variable, which could also be interesting to play with... (I haven't been able to do much with the player jumpspeed variable).

Originally Posted by Penalty

I guess it's safe to announce that we're doing this by implementing a scripting language for jj2. Although coding a new application over something that's already been compiled to binary code is a hidious task, and it may not give you everything you'd expect, but it does open up a lot of new possibilities. It's currently unknown what the final implementation will look like since the whole project is still in very early developmental stage. There's even a chance it might get integrated into jj2+ once it matures.

Even in its early stages, it can already do a lot, and a couple small additions such as a ChangeLevel function will make it extremely useful for single player. With multiplayer it's pretty cool as well (could probably implement something like Assassination with it).

As for how it should be implemented eventually, I have a few thoughts. As someone who intends to use scripting for this, the way I'd like to use it is have scripts embedded in j2l files (or exist as seperate text files with the same filename) which auto-run when the level is loaded, and also allow the use of header files which exist in text format. For a large project like the one I'm planning, the header file(s) would contain the majority of the stuff. I think this is the most sensible route to take. Another option is to have just one script which runs for the whole episode, but I can see a lot more potential problems with this route.

The only problem with having each level use a unique script, is that it might make it harder to pass certain information between levels. For example, if you want the player to start with the same triggers (jj2 triggers, not script triggers) he had when ending the previous level. But I'm not too worried about that for now, since I already know of (bad) ways of doing this.

It would also be nice if certain script variables could be saved when the game is saved, but this obviously is a fairly advanced feature, and isn't something I'm really planning on relying on.

Anyway...

At the moment I'm mostly focusing on very preliminary level design, so getting everything to work isn't a big concern for me yet, and won't be for quite a while. It's hard enough just designing an overall map for this thing. It needs to convey that "metroid" sort of feel, with lots of exploration and revisiting. But also, there needs to be a sort of "path" through the whole thing, with maybe a couple of sequence breaks available, but otherwise linear. That means I need to know exactly where every single room is going to be.

I also haven't decided how I'm going to build the individual levels. The style of game I'm basing this on basically has levels act as rooms. They generally take 4 forms: small rooms (1 screen), large rooms (any size), horizontal corridors (1 screen high), and vertical shafts (1 screen wide). However, this might not be such a good idea for JJ2: the "end of level" sequence can be eliminated, but you'd still get things like music restarting and a lot of transitions due to how fast you can move. Because I want to have all of the levels laid out on a grid, I'll have to rely on a traditional "shafts and corridors" type of design to an extent... but I think the levels will probably have to be bigger, and maybe have it so one level contains multiple "rooms" which are disconnected from the others somehow (either visually, or just in terms of level design via walls and such). In any case, the way I'm doing this right now is having each level/room comprised of "units" of 25x25 tiles, with each unit representing one square on the main map grid (and on the visual map, each square being 25x25 pixels , BECAUSE I CAN).

If anyone has any ideas on how I should design this, feel free to suggest! I've never made something like this before, and it's easy to make changes while still in the planning stages (which last quite a while for me... lots and lots of text files). Some time I might post a couple of sketches of world maps too, if anyone is interested. Nothing too revealing or spoilery, just a sort of "this is what it will look like" thing.

How much do you know about how save files work? I know fairly little, but I do now wonder what sort of scriptish information JJ2 could potentially be tricked into saving into them.

Originally Posted by Unknown Rabbit

How much do you know about how save files work? I know fairly little, but I do now wonder what sort of scriptish information JJ2 could potentially be tricked into saving into them.

Save files are one of the lesser known JJ2 file formats, compared to ones like j2l or j2t. I don't think anyone has decoded it, though I think it uses zlib.

The trick would be finding some way to put extra information in the file without causing jj2 to see it as corrupt. I don't have the slightest clue on how to do this, but I've seen this sort of thing done with other (non-jj2) file formats, so who knows. I also don't know what a good way would be of telling the script to save/load stuff from there. Obviously an OnGameSave and OnGameLoad event would be a start.

There's also the problem of security, if the scripting language is allowed to write to the hard drive (which it would have to in order to save stuff). I never thought of this until Cpp mentioned it to me but it's actually a fairly big deal.

It's no big loss anyway. If I can't use expanded save files, I'll just use the variables that JJ2 does store in saves. Triggers would be an obvious choice, since I intend to set it up so they are persistent between levels (how to do this I'll figure out later). Each time you get an important "upgrade" (such as a special move or weapon), a trigger is set - and I'll probably only have 12 or 13 of those.

A somewhat more exotic option is just finding a way to save all that "scriptish information" without expanding the save file format. The trick would be to find some variable that does nothing, but is saved anyway. If there is one (and I'm not sure - have to experiment), all we have to do is throw whatever is needed into it. For example, let's say we have 25 arbitrary "upgrades" of some sort. When you collect one of them, it sets some flag to 1, let's say upgrade[13] = 1. Then, we just need to take our Magic Useless Variable That Is Saved and change one of its bits (let's say the 13th, since that would make sense) to 1. It's a little messy, and you'd probably run out of bits pretty quickly... but on the other hand, it's fun doing things in really obscenely hackish ways like this.

Now I'm interested. I think I might start looking for "candidates" soon. One I might look at first is the "fastfeet" player variable, which gets set to 210 when you collect a shoe (and does nothing else). Quite useless, in other words, and invisible too, so we don't have to reset it every time the game reloads (to prevent the player from seeing weird things). Another option would be to take something really out of the way, like the variable for the amount of purple gems you had when you last hit a checkpoint (set it to whatever when saving the game, then set it to 0 when loading). And if all else fails, there's always your score, though using this would mean getting 0 points every time you reload.

There's also crazier stuff like an array for lap times (meant for race mode), though I doubt that goes in the save file, and might be a bad idea to use in single player....

Originally Posted by EvilMike

(1 screen) ... (1 screen high) ... (1 screen wide)

No. Don't do this. Use at least two screens for width/height, using just one looks jarring.

That's why I'm going with 25x25 rather than something like 20x20. I don't like how in a 1 screen level the frame kind of "jumps" depending on what quadrant of the screen you are on. 25 tiles on the other hand isn't too jarring, I find. But besides that, I'm not sure how many levels will actually be that small - probably only a couple will, meant to serve a special purpose and kept like that for emphasis.

Here's a quick (and very simplified) illustration of how the rooms and levels might be structured:



Here you see one level, 200x125 tiles. That's 8x5 "units". Small enough to save the game in. However, it contains 6 rooms, and each of those rooms would be designed as if it were its own level (also remember that I'm having player health stay the same between levels). Of course, very few of them would actually be perfect rectangles like that, and they don't have to stay perfectly within those borders either... but the overall grid would be preserved. You get the idea.


This one level would be represented on the map, something like in the above image. This would only be one small part of the map, and on the "full" map, there would be no distinction that this section is its own level: the map would only show rooms, like this. The map is an abstract representation, so it would keep to a grid. The final thing would look something like this. There will be a room in the "home base" level where you can view it, hopefully with chunks of it being revealed as you progress.


So, the end result is preserving the aesthetic of the metroid/castlevania games, while adapting it to a format which works well with JJ2.

You're overcomplicating it, Mike. Remember that this is a scripting language meaning there should be much simpler solutions than trying to stick your variables in some unused jj2 memory. I am thinking about implementing two separate script contexts, the first one being game-wide and the second being system-wide. Each time a new level loads, the game context would load up an appropriate script that persists throughout the game until the level cycles while the system context is automatically created whenever the library starts up and persists throughout the entire game (level cycles, main menu, high score, credits, everything) until the game unloads. So if you were to put a custom object inside the system-wide context it would persist through level cycles. Then all you need to do is write down the desired variables to this object and have them retrieved again as soon as a new level loads - OnGameBegin().

NOTE: This is just a concept.

Originally Posted by Penalty

You're overcomplicating it, Mike. Remember that this is a scripting language meaning there should be much simpler solutions than trying to stick your variables in some unused jj2 memory. I am thinking about implementing two separate script contexts, the first one being game-wide and the second being system-wide. Each time a new level loads, the game context would load up an appropriate script that persists throughout the game until the level cycles while the system context is automatically created whenever the library starts up and persists throughout the entire game (level cycles, main menu, high score, credits, everything) until the game unloads. So if you were to put a custom object inside the system-wide context it would persist through level cycles. Then all you need to do is write down the desired variables to this object and have them retrieved again as soon as a new level loads - OnGameBegin().

But overcomplicating things is so fun

In all seriousness, that sounds good, but my problem isn't so much going from level to level (not too worried about that; while I COULD use some insane solution like I described, I won't... that's why I referred to it as a "bad" way of doing that). The problem, rather, is going from game to game.

Let's say I want the map to reveal itself a bit each time you visit a room. Ok, nothing complicated there: just have an array for that where a flag gets set each time you enter a new room. Then, when you visit the area with the main map, fiddle around with animations or the tile cache to get the map to show up as it's been explored. So far so good... but what happens when the player unloads jj2?

In other words, the game is saved, JJ2 is closed, JJ2 is run, and the save file is loaded. None of that "map" information will get saved, because it's not meant to be part of the save file. That's the real reason for looking around for unused bits of memory to mess with.

Of course even that is unnecessary, if the scripting language is able to save things on its own... but I'm not sure if that's a planned feature or even a good idea.

You can throw as much extra information into .j2l files as you like and JJ2 won't give a hoot, so long as all the data length longs are set correctly. Or that's how it works for data1, anyway, and presumably the other three.

I've been thinking of how I should handle ammo with this.

Weapons will play a big role, with each one opening new areas. I intend to use bouncers, toasters, RF missiles, seekers, and TNT, though TNT obviously won't be until near the end. However, I'm not so sure that scattering ammunition everywhere is such a good idea - it would make it too easy to get things in the wrong order.

An idea I've been toying with is to have it so the ammo pickups are rare and merely serve to expand the max ammo you can carry for that weapon. So, there'd only be around 5 bouncer ammo items in the whole episode (mostly hidden), and each one would let you carry an extra 20 shots (for example). Once you collect one, it's gone forever, so you can't go back and get it again. Think of how the missile expansions work in metroid games. This sort of design works well with open ended projects. It also gives lots of secrets for the player to find: in this case there would be 20 to 25 "expansions" to search for, 5 for each gun.

Also, an added advantage of this is that it would be easy to allow the player to carry more than 99 bullets. The variables can be set to whatever number you want, basically: the 99 limit in jj2 only applies to getting ammo from pickups. Could even balance it so you can carry 500 bouncers, but only 50 seekers.

So the matter of acquiring weapons (and ammo expansions) is all good. But what about the ammo itself? How should the player get more ammunition, when it runs out? Since I'm not using ammo pickups in the normal way, there needs to be another option. Right now I can think of three possibilities:

1. Have ammo "regenerate" slowly, at maybe 1 bullet (for all guns that you have) every 5 seconds, up to whatever the max amount is for that gun. This is an easy solution but I don't like the potential it has for encouraging players to sit idle to recharge. This should be avoided.

2. Have a central store or even multiple stores where ammunition can be purchased. 50 coins for a full refill, or something like that. Problem with this is when you run out, you'd have to backtrack a lot, and that would mean players ration their ammo a little too much. There will probably be a store anyway, but I don't like the idea of forcing it on the player.

3. Use gems. Something like, when you collect 100 your ammo is refilled (either fully or partially). This way I can use gems as a sort of "generic ammo", and also enemies drop them, which is nice. The disadvantage is that this method is a bit... weird. And it prevents me from using them for extra lives (though I may ditch lives alltogether due to gameover being irrelevant in small levels like the ones here).

I'm kind of leaning towards a combination of #2 and #3. I want to know what people think about this though, and especially gems thing: it's strange, but might be fun.

I like ideas 2 & 3. Either of those would be really cool.
If there are going to be Power-Ups in the levels how will you stop the player from side-kicking or buttstomping the PU? Because kicking it would gain 50 and stomping it would gain 25.

Originally Posted by SPAZ18

Because kicking it would gain 50 and stomping it would gain 25.

This could be easily disabled.

I like idea 3. Weirdness is fun.