• Create Account

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

4 replies to this topic

#1Akashi  Members   -  Reputation: 293

Like
0Likes
Like

Posted 19 June 2013 - 10:05 PM

Before presenting the question proper, I'll provide the train of thought I went through, if only to try and figure out different reasoning on the way there.

I made a virtual base class for game objects, Entity, and I have two basic objects that derive from it: Player, and Block. Each owns several variables, amongst them an LPDIRECT3DTEXTURE9 member that stores their sprite's information. So I started thinking about how I was going to store surfaces; for instance, the background, or maybe a foreground layer. For a foreground in specific, it would require both a transparency value and a position. So I thought to make a Surface class to store that information. So then I started to work on my SceneManager's class for iterating through my list of game objects and having them drawn to the screen, and I started thinking about how to load the background image for the level. I realized that it would be clunky to make a subclass for every use of a background, because they aren't distinct enough to warrant making a subclass for them per level and I felt there was a [much] better way. So I thought, why not make a Level class? This is where I started to run into further difficulties.

So in case one, I thought I would make a virtual base class for Levels that other levels would derive from, since I've been really into this whole inheritance thing, but then thought about it for a little bit and figured that might be a bad move; if I was going to have practically identical levels that accomplish the exact same things-- providing a background tileset and providing positions for certain objects to go, with no behavioral differences other than aesthetic, then why would I make classes for each one I need? What if there are a hundred levels? I wouldn't want to make Level1, Level2, Level3... Level(n) subclasses.

So I figured that my other option was to have a single Level class that stored generic information about a level. But then I thought about implementing this; if I start up SceneManager.Init() and I feed it a value of say, 5, for Level 5, how would my generic Level class know exactly what to load? Surely I wouldn't hard code this information in like, a switch statement? I'd probably load in a text file for the tiled backgrounds, but how would I know where to load objects depending on the level? Would I need an array of data for information regarding position and object type?

#2__SKYe  Members   -  Reputation: 1419

Like
3Likes
Like

Posted 20 June 2013 - 05:34 AM

The best thing to do, in my opinion, is to separate the level data from the code (never hard-code things).

You should create a file for each level, that contains the data for that level.

If at level load you need to know what is the tileset for the background, then put it into the file, and when you load a level, open this file and read the appropriate data.

About the objects, it's also simple.

Imagine you can have multiple objects in your level that requires 2 things: a position and a sprite (this is just an example, you can have much more properties).

But you don't want to have a fixed number of objects for all levels (by doing this, you either waste space, if the level doesn't require all the objects, or you are limiting the number of objects you can have.

To solve this you could have this in your level file (again, just an example):

Level1.txt

//Background stuff here

//As an example, using 2D position (x, y)
///he sprite here is the name of a texture/image, but you could put instead the coordinates for a specific tile from a tileset

NUM_OBJECTS = 2

OBJ_POSITION = 0 0
OBJ_SPRITE = image

OBJ_POSITION = 10 2
OBJ_SPRITE = image2


In your Level class, along with the background stuff, you would have a pointer to an array of objects (imagine your object struct/class is called object_s).

At the level load, you read the NUM_OBJECTS value from the level file, and allocate the required number of objects, and then loop through the number of objects to load their properties.

It could be something like this:

void LoadLevel(...)
{
//Open file, read any other stuff you need first (could be level name, background tileset, etc...

//This Read function doesn't exist, it's just an example

//Allocate space for the objects
//You should probably check if the number is valid (either 0, negative or just too large)
object_s *objs = new object_s[numObjects];

for(int A = 0; A < numObjects; A++)
{

}
}


Note that this code is just an example, and obviously wouldn't work, but it demonstrates the process of reading an arbitrary number of objects from a file.

This way you don't have to limit the number of objects for all your levels.

The "read any other stuff you need first" part, just means that if your level file has other things that have to be read before the objects (it could be the level name, the background properties, what BGM should be played in that level, etc) you should read them first until you reach the objects part.

As an example, this is a possible level file:

File: Level.txt

LEVEL_NAME = MyLevel

BACKGROUND = BgTileset.png

BG_MUSIC = MyLevelMusic.wav

NUM_OBJECTS = 2

OBJ_POSITION = 0 0
OBJ_SPRITE = image
OBJ_POSITION = 10 2
OBJ_SPRITE = image2


Also, note that the level format is entirely up to you, as is the type of file (you could use a binary file instead of a text file).

I hope that this is understandable, if you don't understand something, i'll try to explain better.

#3Akashi  Members   -  Reputation: 293

Like
0Likes
Like

Posted 20 June 2013 - 10:20 AM

No, this makes sense; I just wasn't sure if I was required to read information from a file or if there was some dreadfully clever way to do it without having to jump through too many hoops. Thank you! This has definitely made my path a bit clearer. I'll research into making binary files.

#4__SKYe  Members   -  Reputation: 1419

Like
1Likes
Like

Posted 20 June 2013 - 01:10 PM

That's great you understood it.

Also if you need help with binary files, i can help too, they aren't that much harder than text files.

I have one final piece of advice, although it wasn't solicited.

Although binary files have the advantages of being more efficient in terms of speed and space, keep in mind that text files are much easier to edit by hand (which you'll probably do unless you make some level/map editor).

So perhaps during development, unless you build a custom level/map editor that creates the binary files automatically, you may want to use text file, for the easiness of use.

Good luck!

Edited by __SKYe, 20 June 2013 - 01:10 PM.

#5Khatharr  Crossbones+   -  Reputation: 6998

Like
1Likes
Like

Posted 20 June 2013 - 05:55 PM

Although binary files have the advantages of being more efficient in terms of speed and space, keep in mind that text files are much easier to edit by hand (which you'll probably do unless you make some level/map editor).

So perhaps during development, unless you build a custom level/map editor that creates the binary files automatically, you may want to use text file, for the easiness of use.

Well stated. I typically leave things in ASCII format until I've either got everything working or else I've decided to make a level editor. Abstracting your load/save routine can help a lot there, since you can just swap it out when-and-if you decide to move to a serialized format.

Edited by Khatharr, 20 June 2013 - 05:55 PM.

void hurrrrrrrr() {__asm sub [ebp+4],5;}

There are ten kinds of people in this world: those who understand binary and those who don't.

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

PARTNERS