Now sadly, the vanilla engine ran at ~550 fps; the pixel-based edit drops it to ~100 fps (with 1 player). Is it worth it? I think so. I'll probably cap it around 30... so as long as it doesn't go farther, the more control the user has is definitely worth it.
A small list:
•Knockback
•More "action" in the combat. No more 1 second attack timers defining battles. Attack and Defence alone won't determine battles.
•The general sense that players will have more control
•Jumping, Gravity, Physics, the works.
Of course, next I want to add pixel-by-pixel collision detection (or something CLOSE). Theoretically, I have to methods of how to do this. In my head, I feel like they will work out well, but nothings for sure until I try!
I'll illustrate what I mean with this tree! (Taken from Earthbound, graphic is copyright its respective owners.)
Method 1: Series of Squares
Okay, so what we are trying to do is to have VB6 draw a bunch of squares. (Obviously, they won't be visible to the player. But when a player's coordinates hit the coordinates of one of the squares, it will block them. So obviously it's not super precise... but it won't take a ton computations as it runs... so FPS will be better.
Pros
•Better for lower-end computers
Cons
•Not very precise
•Someone would have to figure out all the square coordinates (I say someone cause I'm really lazy :) )
I'm going to try to implement method 2 first. As I think it will work much better.
Method 2: Series of Squares
Hey Mr. Tree Number 2. Okay, so the idea here simply color detection. Every object will have a mask layer (which the user won't be able to see). The black is walkable, the white is not. When a sprite collides with a white pixel, it will be blocked from moving into it.
Pros
•Very precise
•Easy to make masks
Cons
•Will drop FPS
So that's whats coming up next! Hopefully I'll be able to get at least of these implemented sometime in the next couple days!
I like the ideas!
ReplyDelete