Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

AppGameKit Classic Chat / Constant Side Scroller

Author
Message
Greg_C
14
Years of Service
User Offline
Joined: 22nd May 2010
Location:
Posted: 20th Jan 2012 01:04
My question isn't about how to make a sidescroller but more on what would be the preferred method in terms of how you side scroll. On one hand you can have the entire level scroll on the -X axis or you could have the character constantly moving on the +X axis while the ViewOffSet is also moving constantly on the +X with the character. I will be using physics objects for all the collisions and possibly some other stuff. Is this really just a preference, or are there some problems that I will have down the road where I will be wishing I had did it the other way?
baxslash
Valued Member
Bronze Codemaster
17
Years of Service
User Offline
Joined: 26th Dec 2006
Location: Duffield
Posted: 20th Jan 2012 09:56
I would move the player sprite and build everything in "world" space. That way you only have to offset the view rather than moving every scenery object every loop!

Take a look at the first AppGameKit Bitesize tutorial in the January Newsletter (linked at the top of the page currently), it explains the world / screen system and gives an example of setting up a parallax scrolling system.

BatVink
Moderator
21
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Gods own County, UK
Posted: 20th Jan 2012 10:35
I agree with Baxslash, lay the World out statically and move the view.

I have made a game using this method. I have a zone in the centre of the screen (about 25%) that the player moves in. When the player reaches the right hand side of this zone, the screen scrolls right, and the same at the left. It means the player is not entirely static, but is always fairly central.

Greg_C
14
Years of Service
User Offline
Joined: 22nd May 2010
Location:
Posted: 20th Jan 2012 18:07
Ah great! Thanks for the responses.
Digital Awakening
AGK Developer
22
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Sweden
Posted: 21st Jan 2012 10:19
Batvink's solution is easier on the eyes and sometimes more practical in a sidescroller. Many platformers are made this way. But if the player has to move too close to the edges of the screen to move it, it becomes frustrating instead.

DVader
20
Years of Service
User Offline
Joined: 28th Jan 2004
Location:
Posted: 23rd Jan 2012 17:51
Building the level and moving through it is easiest, and works ok for small levels. But if you wanted large levels, you would quickly start using lot's of memory. The most efficient way (memory wise) is to build your screen out of blocks and update them as you scroll through. You could do that for an entire level I suppose, but that would be a lot of sprites in memory at the same time, compared to just having the on screen ones.
I did a small test for an isometric type game awhile back which used this method. It got wiped with a hard disk fail unfortunately, and only a video of a bug I was having with scaling in and out remains. But it worked pretty well and allowed for massive levels. It allowed scrolling in all directions as you would expect from an isometric game.

baxslash
Valued Member
Bronze Codemaster
17
Years of Service
User Offline
Joined: 26th Dec 2006
Location: Duffield
Posted: 23rd Jan 2012 17:59
I disagree, you can use the same theory in a "World" based level just loading the necessary sprites for the area around the current view offset as you go in exactly the same way you are describing without the need to set the position of every level sprite every loop.

That's why when they make a movie they put cameras on wheels rather than moving and rotating the set around the camera

bitJericho
22
Years of Service
User Offline
Joined: 9th Oct 2002
Location: United States
Posted: 24th Jan 2012 15:25
Quote: "I did a small test for an isometric type game awhile back which used this method. It got wiped with a hard disk fail unfortunately, and only a video of a bug I was having with scaling in and out remains. But it worked pretty well and allowed for massive levels. It allowed scrolling in all directions as you would expect from an isometric game."


Hey I saw that screeny, it looked great. Did you store the entire level in memory? Did the engine ever chug when you were moving around sprites?


Greg_C
14
Years of Service
User Offline
Joined: 22nd May 2010
Location:
Posted: 24th Jan 2012 19:19
So because this game that I am making has the capability of going on forever (As long as the player doesn't die) I am thinking that I am going to have to create the level procedurally. Has anyone tried this yet with agk? Is there any information that you guys know of that you could direct me to?
Digital Awakening
AGK Developer
22
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Sweden
Posted: 24th Jan 2012 19:35
Because AppGameKit is single threaded (at least Tier 1) any loading will freeze the game. But since you can reuse images over and over you can create something that goes on and on without loading times.

You don't need to create all sprites at once. Actually you don't need to create much more than to cover the screen and then simply move them around and altering the image shown. If you make a tile based game this wouldn't be very hard to achieve. You could also write some quite simple algorithm to generate your endless level.

Are you perhaps planning to do one of those run and jump type sidescrollers?

Greg_C
14
Years of Service
User Offline
Joined: 22nd May 2010
Location:
Posted: 24th Jan 2012 19:49
Yeah exactly. The character will be closer to the left edge of the screen and will constantly be moving through the level until he is killed by an obstacle or the thing that is chasing him.

Oh and I will be using tier 2 for this. Just working on a content manager right now and then will move onto the actual scrolling and how I am going to generate the level. I am now thinking that I will create a basic tileable base meaning the ground that he would run on and then generate all my obstacles and enemies procedurally based on difficulty.
bjadams
AGK Backer
16
Years of Service
User Offline
Joined: 29th Mar 2008
Location:
Posted: 24th Jan 2012 20:13
I have experimented with various options to do this kind of game on T2, but all involve some complex programming. If anyone has some more neat tricks that can maybe share....
DVader
20
Years of Service
User Offline
Joined: 28th Jan 2004
Location:
Posted: 24th Jan 2012 22:28
@baxslax, yes that would work, as you say. I thought you meant build the entire world up and scroll through it. I am just used to doing these sort of things from the Amiga days.
@Jeric2day, yes it was all in memory it just changed the tiles on screen, as it worked through the map array. Theres was no speed problems that I noticed, as it was pretty much dealing with the same amount of sprites wherever in the world you were. Obviously the map arrays could get large and take up too much memory, but that would have to be a very big level.

Login to post a reply

Server time is: 2024-11-23 02:15:52
Your offset time is: 2024-11-23 02:15:52