Forums » Help » spawn entities "just outside" of player's view

am trying to figure out how to code this, the reason being to save the computer resources (it's also good for mobile)

I assume that game.js needs to be hacked, since that's where the spawnEntity function resides. Perhaps to call spawnEntity ONLY when the coordinates of where it's put (in Weltmeister) are less or equal then a set distance?

Anyone has any clue how it's done? Some example code would be awesome.

I also noticed that in the loadLevel method of game.js, the code reaches into data.entities and spawns them all.

just came up with a quick & dirty method, not sure if it even works

in our player's update() method: (assuming the player is already spawned)

EntityPlayer = ig.Entity.extend({
     buffer:100,

     update:function(){
		for( var i = 0; i < data.entities.length; i++ ) {
			var ent = data.entities[i];
                        
                        var xdist = Math.abs(this.pos.x - ent.x);

                        // spawns entity just outside of game box
                        if(xdist<=(ig.system.width+this.buffer){
			    this.spawnEntity( ent.type, ent.x, ent.y, ent.settings );
                        }
		}

     }

the thing is, constantly calling data.entities might be a little 'heavy' for the computer/mobile device running it.

what do you guys think?

another strategy would be to create two versions of the same entity

eg:

EntityEnemy1Static
EntityEnemy1Spawned

the static entity is created primarily for Weltmeister, has a very basic update() method:

EntityEnemy1Static=ig.Entity.extend({
        update:function(){
             //checks distance to player
             var xdist = Math.abs(ig.game.player.pos.x-this.pos.x);
             var ydist = Math.abs(ig.game.player.pos.y-this.pos.y);

             if(xdist<=ig.system.width+buffer){
                 // spawns the wanted (aka animated) version 
                 ig.game.spawnEntity(EntityEnemy1Spawned,this.pos.x,this.pos.y);
				
		//kills the static entity
		this.kill();
	     }
        }
});

the thing that sucks is, we got to always make two versions of the same entity

I did it with two entities like described above, I had my usual 'enemy' entity with its animation, death sequence, how it attacks inside its update(), etc which ended up being fairly complicated. Then I have a really simple entity with no animations or anything that simply spawns the other when the player is close and then kills itself. (Give it a box coloring so you can see it well in Welmeister) For me, I based it on distance from the player (grabbing ig.game.player from the main() loop where the main game loop looks for the player using getEntitybyType only once so that each spawner entity doesn't have to go looping through all entities to find the player, using more resources).

I place my spawner entity wherever I want that enemy in Weltmeister. Using a spawner entity doesn't cut down on the number of entities in the map since a spawner still exists until the entity is created, but the fact that its a much simpler entity with no animation or much in the update() until the player is just within view seems to help a lot.

I happened to use ig.system.width*.6 as the distance from my player that sets off the enemy spawns. This is provided that the player is always in the center of the field-of-view and that your width is larger then your height. For fun I made it smaller to see the entities pop in to watch it work.

As a side note, for entities that I need to exist the whole time such as platform movers and things I felt always need their position updated, they exist from level load and get updated each frame, but I only draw them based on the same distance from player. I did this by overriding their draw() function to only draw based on the same distance from player. For example if you have two platforms that move back and forth for the player to make it from one to the other and need to be in sync, you don't want to spawn one based on distance, then the other or they will be out of sync with each other. I think this helps since they aren't drawn to canvas unless they can be seen. but their position always remained correct. I could be wrong but I think the actual drawing of animations and rendering them to the canvas seems to be much slower on a mobile device.

I modified my game's loadLevel method to allow loading of multiple levels without wiping out the entities and maps that are already loaded. Now I can just load a section of a map, then trigger loading of other subsets of entities and maps based on player position. A slightly modified EntityTrigger class kicks off the sub-level loading when the player ventures into certain areas of the level.

@xdissent - would you be willing to share pieces of that code. That sounds identical to what I need to do for my next project. If you recall older games like Zelda Link to the Past, the way the map sections scrolled when you got to the edges etc.... I'm trying to get that same effect.

@xdissent - yes would be great if you can share your code, seems pretty awesome

@BFresh - cool ideas! cutting down the spawner entity to its bare minimum (to just a box coloring) is clever!

@fugufish - I did the work on that for my company and I haven&039;t cleared it for release yet so I can't show you, but I can tell you how to implement what you need without divulging anything we'd ever consider proprietary info. All you need to do is copy the implementation of #loadLevel from Impact&039;s sources into your main game class definition and rename it something like #loadSubLevel. Then simply comment out the parts that reset the entities and maps upon loading a new level. You might have to make further modifications other than comments, but they should be obvious when reading the code. Then you could take Dom&039;s #EntityTrigger class from the Biolab entity pack (available in your Impact download area) and tweak the check method to call ig.game.loadSubLevel(this.sublevel) (rather than triggeredBy) to load the a sublevel from a property on the entity named sublevel. You can set that property programmatically, or through Weltmeister when editing an instance of your trigger entity (preferred). Either way, it should contain the class name of the level you want to load. That point in the code would also be a good place to take care of tweening the screen to show the new level or whatever it is you want to do. Make sense?

@xdissent, thanks for the pointers, That's a definitely better roadmap then what I had in my head at the time. I'll post any progress here.

@xdissent - I like the strategy employed. I'm trying to figure out its application for a 2d platformer.

take, a super mario style game.

if I use your technique, I can , say spawn 1/10ths of the level on loading (with the entities that fall within its region). As the player moves further into the level, the other 9 parts (or sub levels as you call it) are loaded in serial fashion. This is done based on active tracking of the player's position within the entire level.

sounds neat!



* current state **

I'm trying to visualize doing sub levels that actually 'couple' well with one another... with Weltmeister it's kind of difficult, because the user can only view ONE level at a time. It's a little tricky to paint the tiles for sublevel 1, then close the view, and then try to paint for sublevel 2 (not having both sublevels side by side).


* potential modification *

loading the entire level first ( just the tiles ), leaving the entities to load as the player moves forward. I think loading tiles take time (especially if there's lots of them).

i'm currently using the method that BFresh mentioned, it works pretty well so far.

Due to my limited CS skills, I can't quantify the performance of BFresh's method versus the traditional method of loading all entities at loadLevel.

To me, Google Chrome (where I test the game on) still runs at 70% no matter what.

@fugufish - I mostly use a large map on my base level and just put entities in the sublevels. Sometimes it makes the most sense to spawn your player entity in your main level, but not much more than that. Not having all of those entities loaded at all times will cut down on time spent in your game&039;s #update method dramatically, since it won't loop through every single entity in your game. Drawing a subsection of a huge map doesn't seem to be as computationally intensive (or Dom did a good job optimizing the tiling stuff) so it's best to focus on not calculating and/or drawing entities where possible.