Forums » Help » Expanding Resident Raver example

Hi,

I just read through the "Introducing HTML5 Game Development" book and had a good time building the "Resident Raver" game they walk you through. I'm interested in expanding it to further learn the in's and outs of Impact.

One thing that sort of bugged me with the code was that he stored a lot of player centric stuff (like how many lives are remaining) in the main.js file. From a structural point, I would prefer to have the remaining lives within the player entity.

So I was able to get it working by making the following changes:

First, I added a 'lives' property to my player entity

Next, I modified the call back inside the player's kill() to include the amount of lives left.

        kill: function(){
            this.deathSFX.play();

            ig.game.respawnPosition = this.startPosition;
            
            var x = this.startPosition.x;
            var y = this.startPosition.y;
            
            ig.game.spawnEntity(EntityDeathExplosion, this.pos.x, this.pos.y, {
                    callBack: this.onDeath(this.lives)
                }
            );
            this.parent();
        },

And finally when respawning the player, I send over the amount of remaining lives when I spawn the new player entity.

        onDeath: function(lives){
            ig.game.stats.deaths++;
            console.log("++++");
            console.log(this.lives);
            lives--;
            if (lives <= 0){
                ig.game.gameOver();
            }
            else
            {
                ig.game.spawnEntity(EntityPlayer, ig.game.respawnPosition.x, ig.game.respawnPosition.y, {lives: lives});
            }
        },

Now this works fine, and I'm satisfied, but I'm worried about including more and more player options - such as ammunition & the deaths counter. It would seem that I would have to send a longer and longer list of settings properties when I spawn in the new entity.

Is there a better way of doing this?

Thanks,
John

Actually it seems like it wasn't "really" working as it should have anyway because

callBack: this.onDeath(this.lives)

was being called right away instead of waiting to be called back. (this.onDeath works properly)

So I'm at a loss because I think the this.parent() inside the kill function() is deleting the entity before the callBack is even reached.

What you are really wanting to do is use a static variable. Now when you make a new entity:

myEntity = ig.Entity.extend({
    entityyPropery: 10
});

And then later you call this 'static' property.

someVariable = myEntity.entityProperty;

Now because of the way that Impact is killing your entities you are running into problems. I am not sure if there is a better solution but I would handle this by creating a new entity.

EntityGameStatsManager = ig.Entity.extend({
    total_deaths: 0,
    lives_remaining: 10,
    ...
});

I would use this new Stats entity to decouple the code from main.js. I hope this helps, I'm not a JavaScript guru by any means and if someone has a better solution or more detail on JavaScripts crazy prototypal inheritance I would love to see \ hear it. But that is how I would start to solve your problem Robo.

Hmm.. thanks for the response, jswart. I'm not sure I like the idea of making a new entity to keep track of the variables.

I've been trying my best to get this to work over the last night, but I'm still having problems.

I'm thinking I'll give the player a dead property. I'll track whether or not the player is alive and instead of kill()ing him, I'll just move the character to the respawn point.

But...

                ig.game.spawnEntity(EntityDeathExplosion, this.pos.x, this.pos.y, {
                        callBack: this.onDeath
                    }
                );

when I'm inside onDeath, this refers to the EntityDeathExplosion and not the PlayerEntity.

so I can't do this:

        onDeath: function(){
            ig.game.stats.deaths++;
            this.lives--;
            console.log(this);
            if (this.lives <= 0){
                ig.game.gameOver();
            }
            else
            {
                this.init(ig.game.respawnPosition.x, ig.game.respawnPosition.y, {});
                //ig.game.spawnEntity(EntityPlayer, ig.game.respawnPosition.x, ig.game.respawnPosition.y);
            }
        },

Hmm.. this might be accepting defeat, but I think creating EntityGameStatsManager might be the best way to get around all these issues.

Do you have any suggestions for making the EntityGameStatsManager tied to a PlayerEntity?

Essentially, I'm already thinking towards being able to support multiple players, but If playerEntities are constantly being removed and added won't I lose track of which is which? My idea was to keep the players and managers linked by their index.

Suppose I have 2 PlayerEntities (A & B) and 2 ManagerEntities(a & b)

ig.game.getEntitiesByType(EntityPlayer)[0] = A
ig.game.getEntitiesByType(EntityPlayer)[1] = B

ig.game.getEntitiesByType(EntityManager)[0] = a
ig.game.getEntitiesByType(EntityManager)[1] = b

If my player A is killed and he is removed, then
ig.game.getEntitiesByType(EntityPlayer)[0] = B
player A respawns
ig.game.getEntitiesByType(EntityPlayer)[1] = A



but the EntityManager list is now 'out of order'. Is this line of thinking correct? Any ideas on how to fix it?

John, moving all the persistence (lives, ammo, etc) stuff to LocalStorage seems like an easier solution than what you've been doing thus far (LS is insanely easy to use).

Quote from Robodude
Do you have any suggestions for making the EntityGameStatsManager tied to a PlayerEntity?

Essentially, I'm already thinking towards being able to support multiple players, but If playerEntities are constantly being removed and added won't I lose track of which is which? My idea was to keep

...

but the EntityManager list is now 'out of order'. Is this line of thinking correct? Any ideas on how to fix it?

Well in keeping with the idea that we want the EntityGameStatsManager to be similar to a 'static' class property I would not create a new a EntityGameStatsManager. I would just have one.

In main.js create a single GameStatsManager.

When something happens that you want to track, add it to the GameStatsManager.

// ! psuedo code

player1 = new EntityPlayer;
player2 = new EntityPlayer;

if ( Player1.hasScored() ) {
    GameStatsManager.trackScore(Player1.name, 1); // add one point to Player1's score tracking
}

To me you were originally looking for 1 place to store all the stats. So I would make GameStatsManager a 'Singleton' so that you have one place to go to get everything.

I would love to be able to type out more code for you but I am still learning JavaScript myself. And the example I may write could likely be solved better. But I will dig around and see what I can come up with and possible provide you with some example code.

Hi guys, just catching up on the thread. If this was a real game I would use a state manager. Since I had limited space in the book to cover all my code examples I simply stored the variables on the only place I felt was "safe" which is the ig scope attached to main.js class. It's the only part of the framework that is not destroyed when an entity is removed or the game screen changes.

It's not ideal but part of what I am working on now is a better manager that is injected into the ig class. I would avoid keeping anything critical on the player since you can remove it at any time or if you add multi-player support. Ideally anything the player stores that needs to be saved should be transfered over to a scope that is outside of itself.

Hope that makes sense.

Quote from jessefreeman
Hi guys, just catching up on the thread. If this was a real game I would use a state manager. Since I had limited space in the book to cover all my code examples I simply stored the variables on the only place I felt was "safe" which is the ig scope attached to main.js class. It's the only part of the framework that is not destroyed when an entity is removed or the game screen changes.

It's not ideal but part of what I am working on now is a better manager that is injected into the ig class. I would avoid keeping anything critical on the player since you can remove it at any time or if you add multi-player support. Ideally anything the player stores that needs to be saved should be transfered over to a scope that is outside of itself.

Hope that makes sense.

Hey Jesse thanks for your reply. I enjoyed your book, and your Screencasts on Impact are what swayed me from CraftyJS over to Impact about a week ago.

In trying to learn more JavaScript and Impact I have forgone my previous thoughts of using another Entity, and instead extended ig.Class with a new StatsManager. Its good to know that my gut instinct is at least in the right direction of those with more experience.

I'll have something very basic to share with you RoboDude if you are still around and care to use \ see my solution.

Thanks for your replies guys!

Yeah, keep me posted, jswart - I'd love to see what you come up with :)