Java Side-scroller...?

A 2D camera is just an offset. When drawing your sprites, you'd draw them at their world position minus the camera offset. It's easy to implement this yourself, really. :)

Games usually tend to be structured around two things: the game state and the game loop. Exactly how those are used vary with the game and implementor, but are usually quite similar conceptually.

The game state is the collection of data that is necessary to fully describe how the game looks like at the current moment in time. A side scroller's game state will typically need to include how the current level looks like, the position and state of the player[s] (health, inventory, jumping, running, shooting...) as well as the position and state of each of the enemies and all other entities in the game.

The game loop is something that will repeatedly:
- Retrieve input from the player.
- Update game state with regard to time passed since last update and what input was retrieved from the player.
- Render the current state of the game to the screen (and any other output, e.g. sound etc.)


Retrieving the input from the player is usually relatively straight forward. Read the keyboard (or whatever other controller you support) and make sure that the game behaves accordingly in the update step. E.g. if the right arrow is being held, the player should have some velocity to the right.


There are a number of things that are usually included in updating the game state:
1) Basic physics
I.e. things that have a |velocity| != 0 should move an appropriate distance based on how long since it was last moved. Things that are in the air should accelerate downwards due to gravity etc.
2) Collision detection
You need to determine if there are any entities in the game overlapping each other, and what to do if there are. What will happen when the player collides with an enemy? a friendly shot and an enemy? an enemy shot and an ememy? the player and a powerup? etc. Results range from changing the direction of the collidees movement to removing them from the game and any- and everything in between.
3) AI
How does the enemies behave? The most basic AI could consist of something the keeps moving in a straight line towards the player. More complex AI could take more factors into consideration such as the direction and speed of the player, it could utilize path finding algorithms to navigate around obstacles in the level etc.


When rendering, you need to determine what is visible at the moment, which is usually the entities and the part of the level that is within some distance of the player, and translate those to screen-coordinates and render them.

So, if you are for example building a tile based scroller using sprites and measuring all distances in pixels: If the player is at x position 3864, your window width is 800 pixels wide and each tile being 32 pixels square, you need to find all tiles in the level from column floor((3864-(800/2))/32) = 108 to column ceil((3864+(800/2))/32)=134, all enemies; powerups and other entities that have an x-position between 3864-(800/2))=3464 and 3864+(800/2))=4264.

Each of those needs to be translated to screen coordinates. Your player is at position 3864, that means that the left edge of the screen is at 3864-(800/2)=3464, so anything that are going to be drawn should be drawn at their current x position minus 3464 in order to be correctly placed on screen.

Finally, you need to retrieve the correct graphic associated with each object, which could be based on their current state (jumping, running...) and the type of object (player, powerup, kind of enemy...), and pass that together with their screen-location to the renderer.

Seeing how you're doing it as a java applet, your renderer could be a subclass of a JPanel (or Panel) with a method void render(Renderable r) that simply adds each Renderable to a List. Renderable in turn should be an interface with the methods Point getPosition() and Sprite getSprite(). Sprite would just enclose a reference to an Image instance with the sprite sheet and a Rect holding the specific tile in the sprite sheet. The renderer would then override the paintComponent(Graphics g) method to call drawImage(...) with the Image and coordinates from each Renderable in it's list of things to draw.


That's the basic rundown of a game, hope it is enough to set you off in the right direction.

Hi.
I've uploaded a little SuperMario clone I made for a school project a year ago. It was made in a hurry in a couple of days so the code isn't exactly the most tidy and well coded, but maybe you can get some ideas out of it. It also include code for controlling the game with a WII controller (using WiiRemoteJ lib), which was the reason I made the game (to show innovative ways to control the computer...anyway :)).

By the way, this is an application (web start) not an applet.

Hope it can be to some help :)

Download from mediafire:
http://www.mediafire.com/?sharekey=c6283f0d267cdb4161d4646c62b381cbe04e75f6e8ebb871
(run the jnlp-file)

[Edited by - kae on August 30, 2009 11:44:49 AM]

Okay, first of all: wow thank you everyone for the helpful responses! Usually I get no responses whatsoever on other forums, haha

@Luctus: Thank you very much! That did clear some things up for me, thank you

At this point I'm now wondering how to make a tile based game

I've Googled it for some time now and found a couple of sort-of helpful resources, but I was wondering if anyone here can point me to some solid tutorials or syntax-examples?

Thank you all very much again!