Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (475)
Games in Android Showcase (106)
games submitted by our members
Games in WIP (530)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Populating sprites in a platformer  (Read 1828 times)
0 Members and 1 Guest are viewing this topic.
Offline zparticle

Senior Member




Thick As A Brick


« Posted 2002-12-22 19:42:10 »

It is starting to look like the game I'm working on will have massive level maps with a boat load of enemy and pick-up and power-up sprites. My question is this:

I'll place the sprites initially based on clues from the level map data. I could prepopulate the entire level or only populate those areas that have been uncovered by the player. Which would you do?

My concern is that with an enormous number of sprites to update positions on each frame it could slow down the game. On the other hand I could just prepopulate everything and only update the visible ones.

Offline Harley Rana

Junior Member




Java games rock!


« Reply #1 - Posted 2002-12-23 04:36:45 »

Id guess that updating the visible sprites is the best way to go.
checking if the sprite is visible should be pretty easy.
mabye if the sprites are sorted by in the array, then you could have the min and max visible indexes.
Harley.
Offline princec

JGO Kernel


Medals: 339
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #2 - Posted 2002-12-23 11:06:21 »

I'd suggest having a zone around the visible area in which sprites are activated and kept animated, as you could walk off a moment and walk back and the gidrahs would mysteriously disappear...

Cas Smiley

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Contrast

Junior Newbie




where's the beef?


« Reply #3 - Posted 2002-12-23 18:16:44 »

i think it's a question of what you want the game to behave like. in order from least to most processor work:

1, like princec suggested, you can have cues inside your level to create an enemy when the screen's border touches this or that location. the result is like mega man: the enemies will vanish and die when they leave the screen, or they can mysteriously reappear when you run back toward where you killed them before.

2, like harley suggested, you can create all the enemies and only update them when they're onscreen. the result is that if you outrun an enemy that's chasing you, he won't keep chasing you once he's outside the screen, yet if you step back he'll be right there as though nothing had happened.

to make the cons of the above two methods less problematic, you can use a shape focused around your character that is larger than the screen. basically this allows the enemies to drift off the screen a little ways and then come back on. i think double dragon did this.
you could also try keeping enemies awake for a limited time after they had left the screen, and then ceasing updates if the time elapsed before they returned. in a game like sonic the hedgehog, where the character can travel many screens in a second, this method is faulty.

3, you can keep a list of all the enemies that have been on the screen, and update those. as such, once an enemy is 'awake', he's awake for good, but he won't wake up until your character gets close.

4, you can work your AI as a state machine, and have all or most of your enemies start out in their 'idle' state. idle in this case would mean doing squat, such that updating them would execute practically no code. then, when the player saw them, the enemy would wake up (change to an aggressive state). you might want the idle state to even do a quick line-of-sight scan for the player, such that enemies a few screens off might see him, wake up, and come running.

the above two methods become worse and worse ideas as you increase the number of enemies in your level, but i've used this method and had a few hundred objects being updated with simple physics (maybe 20 lines of java executed for each) plus several with in-depth physics, and seen no slowdown at all.
Offline zparticle

Senior Member




Thick As A Brick


« Reply #4 - Posted 2002-12-23 23:52:56 »

Thanks everyone for your input, I think I'll do a combination of the solutions presented here.

1> Prepopulate everything.

2> Take the power-ups and pick-ups and only update them while they are on screen, since they stay stationary but have animations.

3> Take the enemies that travel various paths inside of the levels and always update their positions but only update their animations while they are on screen.

Now I just have to come up with an efficient method to determine what to update based on the rules above.

Offline Harley Rana

Junior Member




Java games rock!


« Reply #5 - Posted 2002-12-24 21:32:20 »

Hey id like to also suggest using 2 different lists, 1 for the activated sprites, and 1 not activated.

I don't know how you have you levels, but assuming each is like a big rectangle.   You could easily sort the enemys in the non activated list by there X position.
You would still need to check if the enemy was visible, but not have as many checks.

When the enemy is visible put it into the activated list until it dies.  Then you update every sprite in the active list, with each sprites AI finding the right action.  If the enemys can get the players postion, you could make the enemy sleep if the distance is large enough.  Mabye then kill the enemy is the distance is huge.


Hope that helps Smiley
Harley
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

ctomni231 (32 views)
2014-07-18 06:55:21

Zero Volt (28 views)
2014-07-17 23:47:54

danieldean (24 views)
2014-07-17 23:41:23

MustardPeter (25 views)
2014-07-16 23:30:00

Cero (40 views)
2014-07-16 00:42:17

Riven (42 views)
2014-07-14 18:02:53

OpenGLShaders (29 views)
2014-07-14 16:23:47

Riven (29 views)
2014-07-14 11:51:35

quew8 (26 views)
2014-07-13 13:57:52

SHC (63 views)
2014-07-12 17:50:04
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!