Hello all, I am making a 2D game that I can't say its style. Let me explain. It is that kind of game where you can move around the entire screen, without the background changing at all. And as you reach one of the edges of the screen, the entire background changes and you can travel again through the entire new background till you reach an edge again. I can just remember one name of a game of this kind. It is Black Thorne from SNES. Ok, my game is fine and I have three diferent screens where I can travel around. But I have made some obstacles in the backgrounds. One of them is a closed door, where the player will just be able to get through after he finds the key. And one of the obstacles is a gap that the player must jump over. Ok, I can handle the collisions. They are not a problem for me, but what I want to know is how the collisions in this kind of game are handled. I can create some variables to keep the player away from the door if he has not the key yet. But what will I do when my game has 100 different screens? Will I have to create 100 different variables to keep track of every obstacle? I don't think so. actually, this is a way that i thought about to solve this. The other way that I thought about was saving the informations about the obstacles in a text file and load them at runtime. But I dont quite know what to put in this textfile. How could I organize the information about the obstacles. And in some screens there are more than one... Well, I just want to know if you guys know how is it really done in this kind of game. Thank you for your time.

Each screen should be it's own class (or struct if you're using C). Each screen contains it's own variables about what's in that screen. You must design the screens such that the collision data is symmetric on each adjacent screen:

   Screen 1         Screen 2--------------  --------------|            |  |            ||            |  |            ||           D1  D1           ||            |  |            ||            |  |            |--------------  --------------

Note that the right hand wall of Screen1 matches the left hand wall of Screen 2. Also there is a seperate pointer to D1 (Door 1) in both screens; both screens have a pointer to the same door.

If you have various doors that require various keys, you will have to have an array of doors somewhere that maintains their state (i.e. whether or not it is locked). When a player updates the door you update the state of that door.

So essentially, each door will have up to 3 pointers to it:

- in the list of doors
- in the screen on one side
- in the screen on the other

You could actually just skip the global list of doors all together and just have each room point to it. The memory cleanup is just easier with that global list because only the list is responsible for free'ing the memory associated with the door.

-me

Hmm... nice way of doing it.
I am using a similar way but without pointers.
I am making something like this:


It is something like this.
But I didn't quite understand what you told me to do.
Do you say that i have to do this?



So that each creen has its own variables of what is in the screen? I don't think I quite understood you.
And I liked your ascii drawing by the way

[Edited by - Rafael_Treiber on May 4, 2007 10:12:03 AM]

Could someone tell me a site related to this topic please?
Thank you very much

That's the style I refer to as "original Zelda style" scrolling.

If both your keys, and doors are structures (or classes), you could have an ID number assigned to the key, and the door it goes to. Before you handle the character moving from one screen to the other, make sure they have the right key (assuming it's locked).

If you load all your screens from text files, which include exits, doors and their key id's, there would be no hard-coding for checking the keys.

I'm assuming you're using an Object Oriented language like Java, C++ or C#.

Well, in a 2D adventure scrolling kind of game you're probably going to end up with something like:

class Screen{    //a unique ID so you can look up a screen later    int ID;    //a struct/class of whatever data is on a screen    //probably contains: a monster list, a door list, an objects list, etc    ScreenData data;    //pointers to the adjacent screens    Screen *north;    Screen *south;    Screen *east;    Screen *west;    };//the global list of screensstd::vector<Screen*> allScreens;class Player{    Screen *currentScreen;};//if you're doing save/load then the player will save out the screen's ID//number to the save file.  At runtime you can look it up in the allScreens//list by doing a find by ID in the vector.

Each screen is kind of like it's own encapsulated level. It will contain everything necessary to: draw a screen, let the game know what objects are where, etc.

But look. Your design is going to depend a lot on how much you already know about the language you are learning. If what i've said is way over your head then try to create an architecture that makes sense to you using the techniques that you understand. Since this is a learning project, if it works then it's correct.

The process of trying to get it to work and learning new techniques to make the code more simple is really what the project is about. =)

However, I will point out that the type of game you are making is not going to be possible without you at least reading and fully understanding the chapters on pointers and memory allocation in whatever text you are using. You should also be familliar with basic data structures like: linked lists, tree structures (binary trees), etc.

-me

Yes, I forgot to say that I am using Microsoft Visual C++ and SDL.

Quote:
But look. Your design is going to depend a lot on how much you already know about the language you are learning. If what i've said is way over your head then try to create an architecture that makes sense to you using the techniques that you understand. Since this is a learning project, if it works then it's correct.

The process of trying to get it to work and learning new techniques to make the code more simple is really what the project is about. =)

You are completely right. I just code for fun and I am doing this kind of game just to learn a little more and because I like this kind of game. :)

When I wrote this topic I already had some ideas on how I was going to do this, but I just wanted a little more opinions. And I have already got some more ideas. Thank you very much and thanks for your code. It gave me some more ideas too.