Wishlist

No, that's what I meant by having the debris-shaped enemies. Have them programmed to rush to the left and just spawn them at the right for both static obstacles and flying debris. The only problem I can see is if the background doesn't scroll, which I'm fairly sure it does, unless I'm remembering the fight wrong.

What you could do is just have a cutscene of the characters starting off, then insert the dodging scene, then another cutscene at the end for if they survive escaping.

 

@Timmy:
That might be possible, actually. The game's images can be resized, so adding faces would be possible. Some assembly hacking might be required to add picture coordinates though, or maybe they'd be added automatically, I dunno...

No assembly is needed as I do not believe any checks exist on the size of the file. The coordinates are dynamically calculated as:
[(face%6)*48, (face/6)*48, 48, 48]

I would draw these new faces myself but I'm terrible at pixel art and also do not find it very interesting.

 

No assembly is needed as I do not believe any checks exist on the size of the file. The coordinates are dynamically calculated as:
[(face%6)*48, (face/6)*48, 48, 48]

I would draw these new faces myself but I'm terrible at pixel art and also do not find it very interesting.

It works fine. I'll be taking advantage of this.

In other news, I've started working on the script, originally i thought it'd take around 9000 characters, but i've way over estimated. It'll still take a hefty amount, but apart from that, I don't think i'll have a problem (apart from the fact i've forgotten and remembered the theory already).

 

@Osmose:
I was thinking more along the lines of racing through a tight passage with jumps and exploding stuff, a-la 80s action movie.

Generating the enemies like you mentionned would work absolutely fine if a script ran a series of WAI commands to handle the timing and never calls KEY or such. Dunno if the game over scene would trigger while the script runs though... Being unable to run scripts in parallel sucks. :/ Did you give something like that a try? I'm curious what your results were, if you did.

 

I've never even touched Miza or Sue's beyond a cursory look. I've already got way too much crap to take care of without being obsessed by hacking CS and learning assembly to accomplish the things scripting can't.

EDIT: Is there any limit on the size of an enemy? If not, simply make a HUGE, room-sized enemy for the floor and ceiling, and have it just rush to the left for the entire sequence. That way, you could more easily handle crashes - hitting a wall or floor will do damage and cause a rebound.

 

That's a shame, I'd love to know how something like that would turn out.

I tried to get two scripts to run in parallel but it didn't work. I was hoping to spawn explosion-type entities all over the place in a room but no other script would run during that one's execution... That's why I'm a little curious how you'd keep spawning entities without affecting the gameplay. I'm sure there's a way, but personally, I don't know how at the moment. >"<

Edit: That wouldn't work, because enemy bounding boxes are rectangular. The moment you'd enter the "room" you'd register a hit... It's a bit frustrating to work with those, to be honest.

Enemy sizes don't SEEM to have a limit (though the coordinates of the display and hit boxes are 1 byte each.) There are some pretty big enemies, like most bosses (the core for instance.)

 

I think the way the game did it was have the boss spawn all of those little fishes, so you could define an enemy or boss entity that spawns the enemy debris things. and just follows right above the player at all times without ever hitting them.

As for the room, if you're REALLY devoted you could splite the room up and just spawn them in order. Other than that you'd work the chase by hand, which probably ends up with more control but is hardly an innovative way to use existing functions to your advantage.

 

I was thinking more along the lines of hooking up the entity to the player and making it constantly "fuel" the game engine's "velocity" variable with a value to keep the player moving. Vertical entities could be used to trigger explosions and changes in the bike's behavior if necessary.

As for damage, putting empty damage tiles in front of walls would result in damage when crashing.

Creating block-spawning entities doesn't give you much control over the "course" the player has to follow, and requires some assembly anyway, so it's a bit of a moot point.

 

Bah. My whole thing was that with the original idea of no course, just debris, you could have the game randomly generate coordinates so it's never the same ride twice. *shrug*

 

Don't get me wrong, it's a great idea. But I'm not sure how it'd work out because of the TSC scripting language's painful limitations...

 

I'd like to have half on the UNI0001 command, The anit-gavity thing, but have the screen scrolling normally. Is there any way to do this?

 

Sure thing. There's probably a bit of code that checks if the UNI variable is set when dealing with movement. Killing the check would solve the problem.

Come to think of it, it'd be REALLY easy to pull off.