Shall I move the world or the character?

[tonberry1]

I have been thinking for a while now, that how are the games made which have like a little window and like invisible scroll bars when the user goes near the edge of the screen.

So, is it done by moving the world and letting the player stay where he is at the center of the screen (won't work in multiplayer games) or are those usually made for example with JScrollPane's with invisible scroll bars? Or am I missing something here?

[MickeyB]

You really can do and/or.  Some games, like isometrics scrollers, the world moves in an opposite response to a centered characters movement.  If the workd is stationary, the player moves around.  SOme use a combination thereof...the character moves around a stationary world until he nears an edge in which the players movement is met by the world scrolling to expand more map.   Sony's infantry is a good example of centered player, isometric and both the map and character can move based on where you are in the scene.

[tonberry1]

Thanks.

I have to try both ways or atleast consider both then if there is not any unofficial standard for that.

Games published by our own members! Check 'em out!

[Malohkan]

I like to think of it like I'm using a camera.  All of my objects rendered have real coordinates, but when I draw, I shift backwards by my camera coordinates.  That, in my opinion, makes things easiest to keep track of.

[JuddMan]

yes, the character is easier to move than the whole world including all the other sprites and objects in it... and a 'camera' is much easier in the long run, you can do what you like with the view then, like for a house you can keep the camera fixed, or prevent the camera from moving any further when the player is near the edge of the map...

but i would strongly advise against using a ScrollPane (yes, i did it myself once in my first ever game... it was a mario bros clone and it was dodgy as hell... 1.5 made it a lot better but still it is jumpy and not good...)

this is very general, but get yourself a BufferStrategy on a JPanel (or a Canvas) and draw the tiles for the background yourself... make a class that holds them all with a render(Graphics g) method to draw them...

there is a Framework for full screen or windowed JPanel with bufferStrategy in the Shared Code section...
http://www.java-gaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=share;action=display;num=1036791657;start=11#11

it's big, but its one class... this is probably the best way to do graphics using plain old java 2D.

or you could use the GrexEngine i think it provides the same thing...

[K.I.L.E.R]

I keep my character in the center of the screen at all times while changing his world coordinates.

The world however stays the same.

[Mark_J]

Also it depends on how you build your worlds, as if you never reach the exact edges of the map, then just moving the 'camera' is best definately.
Im currently writing a side scrolling platform game and with been able to goto the very edges, I had to write it so the lil guy dosnt move when hes not by the edge etc, but when the map limits are reached, change to move the actual character and not the bg. Took me a good few days tweeking it to get it all working nicely as I had it working lovely, then I added a slide to the characters movement and that kinda threw things off a bit!   but its now working lovely.
I could have just padded out the map so we never got right to the edge, but then you'd end up with a load of wall tiles etc half filling the screen etc.

[CaffeineOverdose]

A "camera" would be the best way to go and it offers the most flexibility.

I have never coded this type of thing in Java, but I did make an RPG in Flash MX using action script. I think the same basic principles apply.

In most cases you will want the location of the camera to equal the location of your character (making your character look like he is in the middle of the screen all the time). Thinking back to the old RPGs I played years ago here are the exceptions:

-When you character is in a small room the character does not stay in the center of the screen, he moves around and the building stays in place. (For this you will want want the camera to stop or just turn off, have the character move around. These controls are pretty simple and you probably know how to do them. Also, make these types of rooms a class, because they all share the control. Make different types of rooms (if you will be repeating them often with or without slight variations in color and texture) subclasses. An example where subclasses like this would be appropriate is if you were in a maze or a very box like castle where the only thing that changed from room to room was placement of furniture/artwork and where the doors are. Otherwise you just need this type of room as a class and have you different rooms stored as data. In the olden days designers had to limit the size of their games (it's still a good idea) so lots of rooms (as well as other things in the game) looked similar with other variation. If you write you game like this it will be far less tedious than having to design hundreds of rooms and more educational as well.

-Characters sometimes look ahead during cinematic sequenes or they have an ability to look ahead. A camera is very usefull here. The camera location does not equal the character location here. Either have controls move the camera (if you have the ability to look ahead) or have it done automatically if it is a cinematic sequence.

Other than that I cannot think of instances that I have seen where the character is not in the center of the screen (in RPGs where the chracter is usually in the center of the screen).

For regular situations you will want the cameras location to equal the characters location. When you press a key it changes the character's location and because the camera's location is equal to the characters location it "follows".

You can also have the camera lag behind in situations where the character is moving extremly fast (i.e. sprinting away from something, or riding a mine car) but now that I think of it, that sounds nausiating to have to watch.

Basically you want you camera to be responsible for drawing everything. What the camera draws is dependent on the camera's location.

Having a camera (if it is written correctly) will allow you to zoom in and out. When your character is in a dungeon or something the camera should be zoomed in so you can see within a reasonable distance. You wouldn't want to be able to see the entire dungeon on the screen upon entering it, would you? For different areas you might want a slightly different zoom. If you are using 8-bit looking sprites it probably would be best to have only 2 zooms, one for the world map, and one for places like towns, dungeons, caves, ect...

You might also want to do fancy things like rotation. The only way I can think of doing this is having the program recalculate the point of everything on the loaded map using basic trig x degrees. However this sounds like it would slow down the system a lot. I don't think the result would be pretty considering answers will not be exact and rounding could result in pixil overlap, having some locations where one pixil is assigned several different colors and other locations where a pixil is not being assigned a color..... confused..... better stick to 90 degree rotations unless someone here can explain to you how this would be done.

Anyway, using a camera and allows it to display things differently in your 2D game (zoom, rotation, to keep character in center of screen, to let character move around screen) will develop camera skills and an understanding of the role of a camera in a game. This would probably make the learning transitions from 2D graphics to 3D graphics easier for you.