Sounds simple enough :) thanks! I'll look into it later today and keep you guys updated.
I managed to get everything working in an... okayish way ^^ I created a topDownPlayerEntity which has all the changes necessary to get it working. Most of the issues I encountered had to do with improper frictions being applied.
On top of the changes you previously listed I had to:
1. Set the grounded state to true
2. Set the standing state to true
3. Override the EntityExtended's handleMovementTrace method
1: The grounded state of the entity defaults to false, which means Ungrounded friction will be applied. This is 0 by default and will keep the topDownPlayer moving up/down even when there is no user input.
2: This defaulted to 0 and seemed to keep the player moving as well, but I didn't manage to figure out why. Setting it to 1 fixed it.
3: This method set the Entity's standing state to false and whenever there was a vertical velocity it also set the grounded state to false. This resulted in (yet again) ungrounded friction being applied instead of grounded friction. I was quite puzzled by why it was constantly reset, but I'm sure there's some solid reasoning behind this ^^
So far so good! I'm not too happy with overriding the handleMovementTrace method though. Any idea if there's another way to achieve this or am I out of luck :D?
Thanks!
Glad you tested it. The standing property is actually from Impact itself, so I kept it for compatibility. I added the grounded state because I noticed the standing state was flipping between false and true constantly when an entity was grounded. I needed that particular property to be stable, but I didn't want to fundamentally change the way the standing property worked.
I wouldn't be happy overriding that particular method either... but keep in mind Impact++ is open source. I'd be stoked if you wanted to make a few changes to relevant files and make a pull request to the dev branch. One additional problem I can forsee is that currently entities are only able to flip animations horizontally. The entity's flip property gets applied to the entity's currentAnim's flip.x property, but it would also not be too tough to handle vertical flip also. I think currently at least one of the ability classes automatically flips the entity towards its target. I'd say we could add a boolean flag to ig.CONFIG that would switch how certain settings are handled within ig.Character, ig.Player, and maybe a few others. Then you could move between side-scroller and top-down with just a single property rather than 4+ steps.
As someone making a tower defense (top down) I'd really appreciate that!
Thanks for this library!
I'd be very happy to, but it'll probably have to wait 'til the weekend. I'm quite busy at work and all, programming all day and coming home to do some more programming is a bit overkill :D, but I'll definitely look into it and keep you updated ;)
Vertical flipping can indeed be necessary for certain sprites (projectiles?), but far from all. As far as I'm aware most entities in top-down games have separate animations for moving up and moving down because in this perspective you'll see the front or the back of a character, flipping it would make it go upside-down, or am I missing something here :o?
Don't rush, it is of course up to you. I don't like to be so forward and ask such things, but I'm working on pathfinding and AI, so I also have no time!
You're right on the animations, though that could depend on whether the game is top down with a tilt or not. So perhaps it would require more than one Boolean flag in the config.
Is there something I have to keep in mind if I use other plugins with impact++?
I used the
impact-astar-for-entities plugin and it worked perfectly. After adding impact++ path requests just resulted in "undefined" messages.
About the topdown element. I just used 'plusplus.abstractities.character' as the source for my player once and that worked without any tweaks.
@creadicted Each plugin is different, so I don't think there is anything specific I can offer. This huge variation in plugins is part of why I made Impact++... I got tired of hacking each one to fit my game. Not to mention, with Impact++ I can make them all play nice together and potentially improve performance. As for pathfinding, like I said, I'm working on it now. It is working great and is 100% garbage collector friendly, but I'm adding some extras before I push it. For example, avoiding other colliding entities and pathfinding maps so devs can draw out optimal pathing areas in the editor.
Managed to get it working with a config object called TOP_DOWN with ENABLED and FLIP_Y properties (feel free to ask me to refactor those to something else, I just chose something that seemed appropriate to me), but still need to do some extensive testing to make sure it doesn't break anything. The behavior should be entirely unchanged if the TOP_DOWN.ENABLED config isn't set to true in the user_config file, but you never know :D
While writing this, it occured to me that maybe it'd make more sense to use a TOP_DOWN bool config and a separate config for the X and Y flipping so users could enable/disable the flipping of any animations, or do you reckon refactoring this would be too big of a pain :)? I'm happy to do it as long as won't take me several hours :)
I read you request contributors to make and run some Jasmine tests. I've not previously worked with this but will look into it. I did my best to maintain your coding standards and added some JSDoc to the configs, so it shouldn't cause you too much trouble.
I must say, even though it's a rather large project, the structure of impact++ is very solid :) I'm impressed!
Edit: I just ran into some issues with animations for the abstract Character class ;) I'll have to add some checks for the TOP_DOWN and FLIP_Y configs there as well, as there's currently no proper way to set animations for moving up and down, only climbing/falling/jumping.
Another edit: I added the above functionality. Currently the animations used are named moveX for horizontal movement, moveY for vertical movement if _c.TOP_DOWN.FLIP_Y is set to true, or otherwise moveUp and moveDown.
However, when lookAt (ability entity) is called, the character will obviously only flip on the X-axis when FLIP_Y is not set to true. In order to "flip" the entity towards the projectile fired a different animation would have to be loaded, which seems a bit... inflexible, as animation names are hard-coded and there currently doesn't seem to be a way around this (except by adding even more configs :D)
@vassildador awesome work.
Are you working on the latest dev branch or the master branch? The dev branch is working towards r5 and has a huge number of changes (see the dev README r4 to r5 section), such as how ig.Character handles animation based on its state, grounded is now a boolean and not a number, the lookAt method moved from Ability to EntityExtended, etc.
(edit: I just now pushed those changes to the dev branch, sorry!)
As for the config, I'd say that a few boolean properties named "TOP_DOWN" and "FLIP_Y" in the main ig.CONFIG should be fine, rather than making a whole new namespace. Can we safely assume that flipping on the x axis is always okay? If not, then we'd probably need a "FLIP_X" config boolean too. Refactoring to add a check for FLIP_X would take some time, but I'll do that.
To be honest, the Jasmine unit testing is something I've wanted to do for some time, but have found it difficult for game behavior testing. Instead of unit testing, if you can just make a simple example showing the changes in action, that'd be great. You could even take the Jump N' Run demo and make it top down style, then I could add a toggle button on the demo to load one or the other. And if the changes breaks something, no big deal, we'll fix it =).
In ref to your second edit, I agree that hardcoding the animation names is not ideal, but I still don't have a good idea for how to tackle that one. I'm not sure I understand what you mean by loading a different animation to face the projectile... do you mean on a diagonal?
I did indeed start from the dev branch and created a new one from it, I'll merge your changes later (hopefully today) to pick that up (I can see a million merge conflicts coming D:!)
As for X-flipping, it's not really an issue for me but I'm sure someone at some point would like that :D no priority though, at all.
I'll refactor the configs to TOP_DOWN and FLIP_Y somewhere this week as well, and look into making an example ^^ so far it actually didn't look like it broke anything, I've done some testing yesterday and everything seemed okay :)
On the last point: I have no idea how to handle animation names either. I'll try to explain the lookAt animation stuff:
Say we have the following sprite (taken from Mozilla's BrowserQuest):
@vassildador sorry for the code churn! I agree on the x-flipping, I'll start working on it once I've finished the basic creature AI.
I see what you mean on the projectile, and the fix is actually simple (I think). I had a similar problem some time ago, and the way I fixed it was to add a simple animation override / release system to EntityExtended. For example, when the Melee ability is activated it "casts". The cast creates a POW particle effect on the target and overrides the current animation on the ability user to play the melee animation. When the melee animation finishes the override is automatically released.
So we'd need to change this to account for top-down, where the particular melee animation would be set by the direction of the target. Ex: if the target is horizontal, we'd play "melee" while flipping on the x, while if the target is above we'd play "meleeUp", and if the target is below we'd play "meleeDown". The same can be done for the shoot projectile ability, and I don't think we need a "meleeLeft" / "meleeRight", because it seems to be fine to flip horizontally whether it is side scrolling or top down, right?
The problem is, the cast checks for a single animation in the "animName" property of the cast settings object, and currently does not know what direction the ability target is in. The direction is easy to add, but should we change the settings to pass in up to 3 properties, "animName" for the horizontal, "animNameUp" for above, and "animNameDown" for below? Or is there a better way?
No worries mate :) it's all part of the process, was just jabbing a bit at you ;) Sorry for the delay, I'm quite busy at work (people having vacations and deadlines not moving :D) so I'm a bit slower than usual.
The overriding actually sounds incredibly logical, should've thought of that myself :). As for the lookAt flipping/animations, perhaps we can use the name of the ability (Melee, Shoot, ...) as the default animName with Up/Down appended depending on the current direction? It sacrifices some flexibility but I personally think it's not a bad way of naming them. Some issues will arise when we want to reuse certain animations, but these can easily be resolved by providing a way to override the defaults (either through an options object, some setters, ...).
What do you think :)?
@vassildador I agree. The more I think about it, the less I see a problem with hard coding a base animation name, such as "melee", and appending a direction, such as "Up", if the "TOP_DOWN" config value is true. Then if you wanted to have both a sword attack and an axe attack ability, each ability could set the base anim name to whatever it wanted, and again the direction can be appended automatically. So we would not need to change the cast settings, only the code specific to the cast to check for the top down flag and if true check direction and append it to the anim name.
1 decade ago
by mimik
how do I create and set a basic timer with ++?
vanilla
init: function() {
this.testTimer = new ig.Timer();
},
update: function() {
this.parent();
if (!this.paused) {
if (this.testTimer.delta() > 1) {
console.log('xx');
this.testTimer.reset();
}
}
},
impact++
??
and how would i pause the timer when game is paused?
@mimik you want to use ig.TimerExtended:
initProperties: function() {
this.testTimer = new ig.TimerExtended( 0, this );
}
You can replace the 0 with the timer time if you like, but the second parameter is a reference to the entity the timer should be paused with. Impact++ does pausing at the entity level, even though you can pause the game or pause a layer. This way, when an entity gets paused, any timers associated with it also get paused.
Just an update:
I'm currently working on a top-down demo, running into and fixing issues as I go along. I currently have the movement, lookAt, and animations (seemingly) properly working in both perspectives. I'll continue working on the demo a bit more to show some more things and fix whatever is still broken :)
@vassildador great, just saw your fork on github and seems solid so far. I'm in the midst of a pretty big overhaul to include WebGL rendering, and I don't think there are any conflicts, but I'll hold off on pushing any changes until we get this top-down feature knocked out. If you want more help from my end, feel free to make a pull request with your fork to the dev branch any time, and we can discuss any changes directly.
@collinhover: I added a simple demo with the default assets (added one public domain licensed sprite as I needed moveUp/moveDown animations) and pushed it to github. I'm certain quite some issues will still arise when this'll get actively used, but the basics are there. As I continue working on my game whenever I find the time I'll keep updating things as I go along, and will gladly help with some fixes/updates in general :)
Your knowledge of javascript and insights in programming in general are probably vastly better than mine though, so I'll have to ask for some guidance now and then I'm afraid :D I hope you won't mind.
Is there any convenient way we can communicate outside of this forum? I'll shoot you a pull request somewhere tomorrow (monday) :)
@vassildador looking forward to trying out the demo! We can chat through
https://twitter.com/collinhover, or you can find my email at
http://collinhover.com.
How can I make UI buttons for controlling player (for example a button which moves player to left as long as button is pressed)?
@collinhover I'll finally give in and make a twitter account :D
Don't expect too much though, I basically just took the jump n run demo, made a new top-down map with the existing assets, threw some "spike" enemies into it (even without changing the AI, they just keep running left & right :D) and left the default grenade launcher in as the weapon. As I said in my previous post, there's still a lot of work to be done from my end, but I'll get there eventually ;)
@tkorkalainen that should be possible by extending the abstract ig.UIElement to create a generic hold button that pretends to be a keyboard key. In the abstract ig.Player's updateChanges method, it does a series of checks to see if up, down, left, or right states and then moves the player according to whichever states are true.
Here is some pseudo-code to get you started:
1. Your button, lets call it ig.UIKey:
var ig.UIKey = ig.UIElement.extend({
key: ig.KEY.LEFT_ARROW,
activatedBy: null,
activate: function ( entity ) {
// lets not activate when we are already activated
if ( !this.activated ) {
ig.input.inputPressed( this.key );
// store reference to entity
// which in most cases will be the input point
this.activatedBy = entity;
this.parent( entity );
}
},
deactivate: function ( entity ) {
// lets only deactivate when we are already activated
if ( this.activated ) {
ig.input.inputReleased( SOME_KEY );
this.activatedBy = null;
this.parent( entity );
}
}
});
2. Override ig.GameExtended's respondInput method:
var myGame = ig.GameExtended.extend({
respondInput: function () {
// are we holding?
if (ig.input.released('hold')) {
// get input points that are holding
var inputPoints = ig.input.getInputPoints([ 'holding' ], [ true ]);
// iterate over each input point and check all targets
// any target that is an instanceof ig.UIKey should be activated
// check out the original respondInput code for an example
}
// now copy in the original code from the respondInput method
// and modify the tapping input check
// you'll need to use ig.game.getEntitiesByType
// to get all instancesof ig.UIKey
// and deactivate any that were activated by all tapping input points
// this is where the ig.UIKey's activatedBy property comes into play
}
This is a simple feature I'd like to get into the project, but I keep forgetting to add it. If you open an issue request on github I'll look into getting it added asap.
@collinhover I've sent you a pull request. I've included the basic changes to get top-down going, and added a simple example. As I've mentioned before there will still be issues with certain parts of the library though, which I feel quite unsure about :(
Kind of a newbie question, but what exactly are the steps to set this up after downloading and copying the "impactplusplus" folder into my /lib/ folder? What would a fresh, new main.js look like?
@collinhover Thank you very much, I'll give it a try :)
1 decade ago
by mpenner
@collinhover @vassildador I'm very interested in what you guys are doing with the top-down stuff. I'm (slowly) building a top-down RPG, so perhaps I could help, even just with testing. I've hopped onto Twitter to keep more up-to-date with the progress.
@tuttlegames I'd download the latest dev branch and check out the examples/jumpnrun. It'll show you the basics :-)
@mpenner would love the help! Try out the latest dev branch and let me know if you find any bugs. I'm fixing issues with top down pathfinding at the moment.
For anyone looking to use Impact++ for top down games as of August 2013: check out either r5 or the latest dev branch if r5 is not released yet. You'll want to specifically look at the examples/jumpnrun user config file.
ig.CONFIG_USER = {
TOP_DOWN: true,
// flip y is optional
// for when anims can flip vertical
// and is per entity (so not all need to flip)
ENTITY: {
CAN_FLIP_Y: true
}
};
These two config values can be set to true and they will handle all the specifics of top down functionality.
@collinhover: Is there currently a way to keep the impact++ camera "inside" the level? My goal is to make the camera follow the player until the player reaches the edge of the map, at which point it should stop.
Currently I'm trying to calculate the max X and max Y values with the size of the collision map and it's tilesize. The only issue is that when the Camera is initialized the level is not loaded yet. I'd like to do the calculation once at init of the camera (which I assume is reset on every level change) to prevent needlessly recalculating it.
Is adding a method in the Camera class to calculate the maxX / maxY values called on levelLoad an acceptable solution :)?
