next »

[BlueSweatshirt]

So, I'm getting ready to start doing some hard coding of my next game project.

A problem has presented itself: how I'm going to manage 'levels'.(rooms/places/areas in a vidya gaem.)

I'm sure many of you have had this problem before. Do any of you have any suggestions for how to tackle separating each individual level in a game? There's some data I'd like to keep global(like player stats and such) but most data is level-specific.

I know classes are a good idea, but does anyone have any specific structural ideas on how to incorporate a kind of level system?

[Sos]

I can help you with that:

Code:

typedef struct SPRITE {
  BITMAP *img,*bmp[32];
  int x,y,w,h,img_w,img_h,frames,current_frame,frame_delay,collision,hp,atk,on,fullhp;
  char name[32],text[256],file[64];
} SPRITE;

typedef struct LEVEL {
  BITMAP *tileset,*bg,*prerender;
  int w,h,tilesize,startx,starty;
  unsigned char map[SIZEY][SIZEX];
  char name[64],script[256],tilefile[64],bgname[64];
  SPRITE **sprite;
} LEVEL;

LEVEL *level;

SPRITE *load_sprite(const char *filename)
{
  // look belowand do it the same way
}

LEVEL *load_level(const char *filename)
{
  LEVEL *lvl;
  lvl=malloc(sizeof(LEVEL));
  //read data from file
  for (several times) lvl->sprite[x]=load_sprites();
  return lvl;
}

int update_level(LEVEL *lvl)
{
  // do stuff with level here
}

Pointers are your friends. You should drop player data out of the structs (as shown above). You may use the loading function to prerender the level, but it may fail it these are too big.
Pointers are your friends here. Also, after you're done with your level, be sure to free it. You can load all the levels at once, which is much safer, but they should not be too big.

[Mikademus]

Pointers are your friends. You should drop player data out of the structs (as shown above). You may use the loading function to prerender the level, but it may fail it these are too big.
Pointers are your friends here. Also, after you're done with your level, be sure to free it. You can load all the levels at once, which is much safer, but they should not be too big.

Jakman4242, before you hurt yourself, let's point out that naked pointers, as is used in the example above, is your ENEMY because they will cause memory leaks and kill your potted plants. What you want to use are instead /smart pointers/.

So instead of a "Sprite *pSprite" you will have a "shared_ptr<Sprite> pSprite". Is is used the same way, but it will deallocate its contents when it isn't references anymore.

Code:

smart_ptr<Sprite> MakeSprite( char *filename )
{
   // do some magic
}

int main()
{
  smart_ptr<Sprite> pSprite = MakeSprite( "MyCat.png" );
  pSprite->setTransparentColour( 0xFF000000 );
  pSprite->render();
  return 0;
}

[shrimp]

I think Jakman is asking for a language independent, object-oriented solution. What language are you using? AS3? With Flixel? (I'm guessing based on your website)

[Zaphos]

Yes, before the holy war we should ask what language are you using, Jakman?  Sos appears to be using straight C, Mika is using C++.

Anyway, I'm not quite sure what you're looking for Jakman.  There isn't much to say in general besides "write the data structures your game needs to define a level" ... what those are would depend on the game.

[Mikademus]

Yes, before the holy war we should ask what language are you using, Jakman?  Sos appears to be using straight C, Mika is using C++.

Heh, yeah, I didn't even think of that, I was so caught up in my heroic attempt to save a newbie from memory leak insanity. And having to replace his potted plants. 

[Skofo]

A level object for each level, with the global data kept outside of them?

[Ben_Hurr]

Are the game's levels tilebased? object based?
Are the levels persistent if the player leaves one?

We need the details man 

[BlueSweatshirt]

 

I was in quite a rush, sorry.

I'm using C++ for this particular project, but I'm looking for it to be portable to other languages.(C#, Obj-C, and possibly AS3)

The levels are object based, for flexibility. The levels are designed to not be persistent, except for the chests you open.(which I don't need particular help with executing)

@Skofo
Obviously, but I'm asking if anyone knows an efficient way to approach this, rather than me jumping in without any overhead knowledge and making a structural error.

I'm looking for an efficient way to handle level data in a class, and how to handle the level itself.

I'm also running into the issue of making levels themselves. I don't think I have the experience to make a level editor for myself, and I don't think a level editor like Mappy can give me what I want.

[salade]

Have you checked out XML? It's a pretty popular choice, and there are tons of quality parsers.  If you don't wan't to make a level editor, xml is also easy to edit by hand.

The trick with levels is to have them completely non-hardcoded, while at the same time having a flexible enough system to ensure that they don't take up too much memory, hence the mentioning of referenced pointers.

On reference pointers: they are a real b*** to use and write. I'd recommend writing a resource manager, which would also give you a bit more control over what you can do with your memory.

So, bottom line? Level class should contain data + either memory managers or memory managing methods itself. I personally like to have my managers as separate classes since it is more object oriented, but it depends on your overall engine i guess.

[Sos]

Pointers are your friends. You should drop player data out of the structs (as shown above). You may use the loading function to prerender the level, but it may fail it these are too big.
Pointers are your friends here. Also, after you're done with your level, be sure to free it. You can load all the levels at once, which is much safer, but they should not be too big.

Jakman4242, before you hurt yourself, let's point out that naked pointers, as is used in the example above, is your ENEMY because they will cause memory leaks and kill your potted plants. What you want to use are instead /smart pointers/.

Sure, but that is like stating, that "C is your enemy and causes leaks". smart pointers doesn't exist there, and the code I posted works, and doesn't leak.
Also you should have read this:

I know classes are a good idea, but does anyone have any specific structural ideas on how to incorporate a kind of level system?

[Mikademus]

Pointers are your friends. You should drop player data out of the structs (as shown above). You may use the loading function to prerender the level, but it may fail it these are too big.
Pointers are your friends here. Also, after you're done with your level, be sure to free it. You can load all the levels at once, which is much safer, but they should not be too big.

Jakman4242, before you hurt yourself, let's point out that naked pointers, as is used in the example above, is your ENEMY because they will cause memory leaks and kill your potted plants. What you want to use are instead /smart pointers/.

Sure, but that is like stating, that "C is your enemy and causes leaks". smart pointers doesn't exist there, and the code I posted works, and doesn't leak.
Also you should have read this:

I know classes are a good idea, but does anyone have any specific structural ideas on how to incorporate a kind of level system?

Yay! I got an invite to a geek fight!

[Fallsburg]

Pointers are your friends. You should drop player data out of the structs (as shown above). You may use the loading function to prerender the level, but it may fail it these are too big.
Pointers are your friends here. Also, after you're done with your level, be sure to free it. You can load all the levels at once, which is much safer, but they should not be too big.

Jakman4242, before you hurt yourself, let's point out that naked pointers, as is used in the example above, is your ENEMY because they will cause memory leaks and kill your potted plants. What you want to use are instead /smart pointers/.

Sure, but that is like stating, that "C is your enemy and causes leaks". smart pointers doesn't exist there, and the code I posted works, and doesn't leak.
Also you should have read this:

I know classes are a good idea, but does anyone have any specific structural ideas on how to incorporate a kind of level system?

Now, now, let's not get ahead of ourselves.  Your code certainly does have the opportunity to leak, so let's not pretend that it doesn't.  A C/C++ neophyte could easily never free the LEVEL allocated in load_level.  I'm not saying your implementation of the code leaks, but with what you posted someone could easily make code that leaks.

Anyway, I agree with Mikademus that someone who is new to C/C++ should be using smart pointers, as they are going to be learning a whole lot and proper usage of pointers is likely to get lost in the shuffle. 

[BorisTheBrave]

While it would be wrong to accuse that code of leaking when is is clearly a sample of a larger thing, it seems a damn bold claim to assert that it doesn't leak when none of that code is written. Any C noob reading that would immediately go on to write leaky code.

Unfortunately, smart pointers are nearly as much a deathtrap as naked pointers. My advise is to actually spend some time learning about memory management, C/C++ just isn't a "dive into" language.

Anyway, level structure. There are only really two choices, imho: 1) a list of objects, with positions, 2) a tile map. You can have both, too. Plus a header for level global details (the sound track, gravity, max score, whatever).

Personally, I don't really have levels as a distinct concept from "current game state". Loading a level consists of populating the game objects into a blank game from a file - afterwards, that information source is forgotten, except as metadata for niceties. Level are more like "scripts", in a DSL designed for convenience. Not so good an approach if you want to save lots of information (unless you save the entire thing as a new level), but it sounds like you don't have that.

[BrianSlipBit]

Unfortunately, smart pointers are nearly as much a deathtrap as naked pointers. My advise is to actually spend some time learning about memory management, C/C++ just isn't a "dive into" language.

I have to agree with this.

In fact, I'll argue that smart pointers, especially in the case of someone who is just learning the language, could complicate things and make matters worse.  They often times obfuscate and hinder one's ability to see what's going on, rather than help clarify it.

As BorisTheBrave said, I think I'd start with understanding why, when I want to allocate some memory I need to make a call to "malloc" or "new", and why, when I want to free said memory I need to make a corresponding call to "free" or "delete".