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).


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.