1 decade ago
by drhayes
Prototype:
http://www.davidrhayes.com/games/prototypes/platform1/
Blog post:
http://blog.davidrhayes.com/post/34523414782/platformer-game-prototype
I'm trying some different stuff for the somewhat largish RPG platformer I want to make. I'd love some feedback on movement and "feel". ( =
I like it so far! However, I am assuming the pauses when entering a portal will be for some animation, sound effect, or something? Otherwise it was a bit confusing, and I did not know I was going in until I had waited for a split second and then tried to move on, only to realize I can't. Then the portal completed and I went to the new area.
Also, I like the blog outlining the development decisions and sharing some code :)
I like the simple graphics for the prototype. Braid was created this way, and at the end of the process, once all bugs and movement were figured out, the author worked on the beautiful graphics.
The blog is also a great idea. If not for others, for your own archives in game dev.
1 decade ago
by drhayes
Thanks for the feedback! The blog is the real artifact at this point; the prototype doesn't do much. ( ;
Jackolantern: You got it. Eventually there will be a "fading as you enter the portal" animation for the player. For future prototypes I might add that in anyway, just to emphasize what's going on.
stahlmanDesign: That's the idea. I'm actually looking to finish this one and focus on what's important first.
I can't decide if the next blog post will be about the player physics or the little behavior framework I added. Basically, when the player picks things up I wanted the player to gain and lose abilities... but didn't want a bunch of if/then/else cluttering my update and check methods. Hence, behaviors.
For different behaviours, I'm not sure if it's a good approach but it worked well for me to have different player Entities. Instead of a bunch of if/then/else statements, I have a EntityPlayerSwimming, flying, jumpNrun, and one that takes control of its host. Whenever I jump out of the water, the EntityPlayerSwimming is killed and an EntityJumpNRun is spawned in its place, having passed off the movement data. The player's inventory and health etc. is controlled in main.js so it doesn't matter if one of the player "roles" is killed. This helped me keep the code pretty simple and clean.
1 decade ago
by drhayes
Yup, that's what I'm doing.
I ended up doing that for different player states: when the player is entering a door, that's an EntityPlayerEnteringPortal. When the player's vertical velocity exceeds some threshold I swap the EntityPlayer for a EntityPlayerFalling.
I have an EntityFollowCamera (the entity responsible for setting screen.pos) that always looks for the entity named 'player'. Only the EntityPlayer is named 'player'. So when I swap the EntityPlayer out for the EntityPlayerFalling, the camera stops following and the new EntityPlayerFalling falls off the bottom of the screen.
They all derive from EntityPlayerBase. That's the class that sets size, gravity, friction, etc. It also has the swapEntity method:
swapEntity: function(entityName, settings) {
var defaultSettings = {
vel: {
x: this.vel.x,
y: this.vel.y
}
};
ig.game.spawnEntity(entityName, this.pos.x,
this.pos.y, _.defaults(defaultSettings, settings));
this.kill();
}
(I'm using underscore.js... that's where _.defaults comes from).
I wish I were smarter when I first started messing around with Impact, would've made my first prototypes a lot better. ( =
Very nice, I will read the developer blog next. The physics seem very nice, very realistic and smooth. Using simple, abstract shapes and really getting the physics and feel is spot on and I would like to use that approach for my first game.
Page 1 of 1
« first
« previous
next ›
last »