[gameprogrammer] Re: 2d side scroller
- From: Ken Johnson <johnsk16@xxxxxxxxx>
- To: gameprogrammer@xxxxxxxxxxxxx
- Date: Mon, 7 Nov 2005 10:48:30 -0700
One thing that I noticed is that I would render the screen as the last
operation. You render enemies/player before you test if an enemy may have
been killed by a players bullet and you also render the player before you
test if he needs to be moved from a moving platform.
On 11/7/05, Alan Wolfe <alan.wolfe@xxxxxxxxx> wrote:
>
> Hey everybody!
>
> I'm working on a 2d side scroller in SDL/OpenGL and this is the first
> actual one i have ever made. Because of that, I have found some things I did
> which were not the most efficient way to do things and have changed them,
> but I have found other things which i know must not be the best way, but am
> unsure of what the best way would be.
>
> Here is my order of operations in my game loop:
>
> 1) Check which keys are down and move the player accordingly or spawn
> bullets etc. (movement checks that there are no blocks in the way, as well
> as checks if they touch spikes etc). This section also figures out which
> frame of animation to draw for the main character whether he looks like he
> is jumping running shooting etc.
>
> 2) Handle gravity and other physics for player, moving as necesary
>
> 3) Handle the scrolling of the camera to keep player on screen (the game
> uses mouse look so the screen really scrolls based on mouse coordinates.
>
> 4) Draw paralax layers that are behind the map
>
> 5) Draw the map
>
> 6) Draw the main character
>
> 7) Draw and handle enemies - draws enemies as well as handles enemy
> physics and logic (AI)
>
> 8) Draw projectiles - both enemy and player projectiles. Draws them and
> does physics and logic, also checks to see if friendly bullets have hit
> enemies (if so take away life from the enemy it hit) and checks to see if
> enemy bullets have hit the player (if so take away life from the player).
>
> 9) Draw game objects such as powerups etc. Does physics and logic as well
> for each.
>
> 10) Draw moving platforms (along with path logic as well - such as if it
> moves in a circle, it will move it the next step). This part also checks to
> see if each moving platform is going to hit the player when it moves. If so,
> it pushes the player out of the way (checking to make sure it doesnt push
> the player through a wall or anything like that).
>
> 11) Draw paralax layers that are in front of the map
>
> 12) Draw game GUI such as lives left etc
>
> 13) see if the player has touched any bad guys. If so, take away life and
> mark the player as being in the "injured" animation state.
>
> 14) see if the player has touched any power ups. If so, give them energy,
> extra life, or whatever.
>
> Does anyone see anything sticking out which might be optomized or done in
> a better way?
>
>
>
> A secondary question is how is the best way to program moving platforms? I
> am in the middle of implementing them and right now my tactic is this...
>
> -----
> Loop through each moving platform...
>
> If the player is on the current platform, move them the same amount as the
> platform is moving (this makes sure if they are standing on a platform that
> it carries the player with it) - (taking into account other walls etc so you
> don't push them into space etc)
>
> Move the platform.
>
> If the player wasnt on a platform but is now, move the player the same
> amount as the platform is moving (taking into account other walls etc so you
> don't push them into space etc)
> -----
>
> I know this isnt the best way because this makes the player "float"
> slightly above the platform at times and rarely, the player will get stuck
> inside the platform.
>
> Is there a better way to do this?
>
> Thanks!
> Alan
>
Other related posts:
