I think that's a fair question. I'll try to use some words to answer it. (Mouse usage is partially separate from AS, though--you can interact with the mouse in it, but if you're thinking of being able to aim bullets with the mouse instead of by looking left/right/up, that's a separate JJ2+ feature, just like chat commands or green/yellow teams or new MP gamemodes.)

Technically AS is a scripting language, analogous to C or C++, but what we mean when we say "angelscript" is really a) the way JJ2+ runs it (primarily the hook functions) and b) the things it can do (the API). In reality the two categories are actually kind of isomorphic, but that fact isn't always as clear as it could be, because we didn't do the greatest job of designing the thing.

I'd tentatively say AS usage falls into three patterns, each with its own (largely independent) sets of hook functions and API details:

1. Reacting to something that happens in the game. Think about events like Trigger Zone or Warp or Set Light: when you touch this tile, something happens! This is the probably the simplest kind of AS at a conceptual level, and it was (coincidentally?) the first kind to be implemented. If a Warp event says "Warp this player to Warp Target 0," you can use AS to say instead "Warp this player to Warp Target 0 if they're Jazz, or Warp Target 1 if they're Spaz." Or instead of caring which rabbit, maybe the level cares which CTF team they're on. Or maybe entering a new area should change the current music file in addition to changing the ambient lighting. Such examples take very little code to implement but can have a huge impact on how (well) a level works.


2. Altering a basic fact about the game. There are a lot of things that, if we'd had complete power, should probably have been implemented as level options in some JCS window or other. That wasn't possible. But you can do that stuff in AS instead, and even alter it again later in the level if need be. You can decide that you want players to be able to carry only 15 Seeker bullets instead of 50. Or: RFs should fire only a single missile at a time. Or: Jazz should use a double jump instead of copter ears. Or: Water should be drawn in front of layer 2 but behind layer 1, so that some foreground tiles don't get distorted.


3. Adding new content entirely. This comes in various forms--new weapons, new enemies, new sprites, new behaviors for old enemies with old graphics, whatever. This tends to take a whole lot of code (or artwork, depending) because there's so much to define, it's not just a question of setting some specific integer property and calling it a day.

Is that what you're asking, or am I totally off-base? (Probably the latter; I just got off from having entirely the wrong conversation and my head is likely still a bit muddled.)

As for "cool levels" that use AS "hardcore," I'm wary of that kind of recommendation because there's a certain art to this... the more AS you add to something, the more you run the risk of losing the core JJ2 gameplay, and at that point it becomes less clear why you're using JJ2 to begin with. Apart from as a personal challenge. But you could take a look at my latest—it gets kind of complicated later in the level (and ended up requiring more lines of code than I'd hoped), but the basic gameplay concept is very easy to understand. You can almost pretend it's all about trigger scenery. EDIT: Borgia agrees apparently.

Anyway, from what I've seen in "the other thread," I think the biggest problem people have when learning AngelScript is figuring out what they want to do... or at the least, how to express what they want to do, because we're not mindreaders. :# Let's say someone wants this: "Winning my new SP level should require the player to defeat every enemy before the time limit runs out." They come to the other thread, and may get questions like these:

• Are there regenerating enemies like the bats in Castle? If so, how should those be treated?


• If the player dies, how does that affect the count of which enemies have or haven't been defeated? Are there checkpoints? How do they interact with this system?


• How is the time limit shown to the player?


• How is the defeated enemy count shown to the player?


• What happens if the time limit runs out and not all the enemies have been defeated?

Once all those questions have been answered, it becomes possible to provide code (or hints for how the person can write the code themselves) to make all those things happen. But writing code requires that you know what you want code to do. And if you can think of all those questions I listed yourself, you've won; you may not know how to do everything in detail, which takes research and practice, but you've got the mindset figured out.