Skip to content

Instantly share code, notes, and snippets.

@ajweeks
Last active January 31, 2016 15:54
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save ajweeks/faf0f31f8186ed7a7c68 to your computer and use it in GitHub Desktop.
Save ajweeks/faf0f31f8186ed7a7c68 to your computer and use it in GitHub Desktop.
Twenty-Second of Devember

Devember Day 22

tl;dr: TM495 is looking good.

Surprise surprise, more work on TM495 today. First thing I did was greatly improve the collision detection algorithm. Within the player's update method, if they have attempted to walk into a solid object, I nudge them to the correct direction. I still need to add a check to see if they're near the edge of the object. Even still, walking around the level feels much smoother now. Although I still need to tweak some values, as it can feel kind of weird getting shot to the side when walking into a tree. The algorithm could also probably use a bit of an efficiency improvement, but I will think about that later. For now, the game is silky smooth, and you know what they say - I don't want to be doing the root of all evil.

I realize that these posts are a little boring since I'm not adding any screenshots. The actual look of the game hasn't really changed over the last few days. But to keep things somewhat interesting, I'll try to add some code snippets here and there. (Hopefully you're the kind of person who would agree that code snippets are interesting.)

Here's the current method of collision detection between the player and the trees (or stumps) which gets called inside the player update function:

// save the previous position

var px = this.pivot.position.x;
var py = this.pivot.position.y;

if (Keyboard.contains(Keyboard.KEYS.W) || Keyboard.contains(Keyboard.KEYS.UP)) {
    this.pivot.position.y += this.maxVel * deltaTime;
} else if (Keyboard.contains(Keyboard.KEYS.S) || Keyboard.contains(Keyboard.KEYS.DOWN)) {
    this.pivot.position.y -= this.maxVel * deltaTime;
}
if (Keyboard.contains(Keyboard.KEYS.A) || Keyboard.contains(Keyboard.KEYS.LEFT)) {
    this.pivot.position.x -= this.maxVel * deltaTime;
} else if (Keyboard.contains(Keyboard.KEYS.D) || Keyboard.contains(Keyboard.KEYS.RIGHT)) {
    this.pivot.position.x += this.maxVel * deltaTime;
}

if (px == this.pivot.position.x && py == this.pivot.position.y) {
    this.animator.switchAnimation(0); // play the idle animation
}

var nudgeMultiplyer = this.maxVel * 2; // somewhat arbitrary
var tree = this.level.collides(this.pivot.position.x, this.pivot.position.y, this.width, this.height);
if (tree !== null) { // Collision!
    if (this.level.collides(this.pivot.position.x, py, this.width, this.height) === null) { // the new y value is the problem
        if (this.pivot.position.x < tree.pivot.position.x) { // check what half of the object we're on
            this.pivot.position.x -= this.maxVel * deltaTime;
        } else {
            this.pivot.position.x += this.maxVel * deltaTime;
        }

        this.pivot.position.y = py;
    } else if (this.level.collides(px, this.pivot.position.y, this.width, this.height) === null) { // the new x value is the problem
        if (this.pivot.position.y < tree.pivot.position.y) {
            if (this.level.collides(this.pivot.position.x, this.pivot.position.y - deltaTime * nudgeMultiplyer, this.width, this.height) === null) {
                this.pivot.position.y -= this.maxVel * deltaTime;
            }
        } else {
            if (this.pivot.position.y > tree.pivot.position.y) {
                this.pivot.position.y += this.maxVel * deltaTime;
            }
        }

        this.pivot.position.x = px;
    }
}

The most annoying bug now is when the player is very close to a tree and they render incorrectly - either behind it or in front of it. Although, with the improved collision detection, it is much less noticeable.

After that, I improved the camera movement slightly. All I've done so far is make the camera's x position constant (since you can see the whole width of the level) and make the y position only change when the player is closer to either the top or bottom of the screen. This means there is now a "dead space" in the center where you can move around without affecting the camera's position. I'm not sure if most people would even call this an improvement, but I kind of like it. I'd like to also make the movement of the camera a little bit smoother, so that it doesn't just directly follow the player, but rather has a small acceleration time to slide up to show the player. I think that will improve the "game feel" - something vlambeer has taught me to mind. (If you haven't already seen it - even if you have - definitely check out the talk he gave about game feel (here). Even if you don't make games, it will change the way you look at them.)

The animations really need to be improved since right now it's just a twirling dude who twirls faster when you sprint. I think I will spend some time working on assets tomorrow. As tempted as I am to try to model everything in 3ds Max, animating things would likely be a huge hurtle which I would inevitably fail to complete, so for now I'm sticking with pixel art. If in the future I learn that it's easier than I had imagined to animate 3D objects, then I will certainly consider making a TM495 3D.

In previous Devember entries I've talked about camera offset algorithms, and so I think I should share what I'm using now - with three.js.

updateCamera(): void {
    var deltaY = playerY - Main.renderer.camera.position.y;
    if (deltaY > 8) {
        Main.renderer.camera.position.y = playerY - 8;
    } else if (deltaY < 3) {
        Main.renderer.camera.position.y = playerY - 3;
    }
}

I'd like to figure out a more concrete way of finding the minimum and maximum values for deltaY, but for now this works. That's all for now, hopefully you are having a great holiday break. See you tomorrow!

Previous Entry | All Entries | Next Entry

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment