Jump to content


map/level object design


7 replies to this topic

#1 chot

    New Member

  • Members
  • PipPip
  • 28 posts

Posted 03 November 2005 - 07:28 PM

hi, im considering two choices for loading and storing a map/level into my game;

1. have all containers "global" in the game, like if you (theoreticly then) would load two levels at the same time, all their objects would be put in the same storage and nothing would work

2. have a "map" object that stores all the information of the map, so that (again theoritcly, one would never actually do this) your able to load two maps at the same time

now, its a bit more work to implement the second approach, but its more general, but since two levels is never ever going to be loaded simultaniously its quite useless.
on the other hand, the second approach would most certanly make the programming more general and easy to understand

i would like to hear your point of view of this problem, and is there any third approach that ive forgotten?

thanx in advance
/chot

#2 sheijk

    New Member

  • Members
  • Pip
  • 4 posts

Posted 03 November 2005 - 08:49 PM

The second one might be nice if you want to preload levels. Apart from that I don't really see where putting your data in a class would be more complicated than making it global variables. You will need a pointer to the level to be able to add objects etc. but as the project grows bigger this might even turn into an advantage because you can't access the game objects freely from everywhere which might lead to a cleaner structure

#3 geon

    Senior Member

  • Members
  • PipPipPipPip
  • 893 posts

Posted 05 November 2005 - 08:30 PM

sheijk said:

(...) which might lead to a cleaner structure

Yep.

Globals are usually considered a bad coding practice. The "its so much simplier" argument is not really valid.

I made a small 1 player puzzle game once, where I stored the game field as a global. Naturally, I found out later I wanted to have a 2 player game instead. It would have been trivial if I just had a class for the entire field.

#4 Cybrid

    New Member

  • Members
  • PipPip
  • 19 posts

Posted 07 November 2005 - 05:01 PM

Yes, OOP gives a much cleaner and easy to maintain code that using globals that can be modifyed anywhere in the code and that can cause problems if it's modifyed when it shouldn't.
/*Books, days and ways, gives men wisdom*/
HUMAN KNOWLEDGE BELONGS TO THE WORLD

#5 pater

    Valued Member

  • Members
  • PipPipPip
  • 117 posts

Posted 08 November 2005 - 11:45 AM

You could, to make it simple in the beginning, implement the map class as a singleton. Then you could create a global (or even more OOP-like, static) function getCurrentMap() which returns the currently active map (stored in a static reference). This is almost as simple as having the whole map global, but is very easy to expand if you later decided you'd require more than one map at a time.

#6 SpreeTree

    Valued Member

  • Members
  • PipPipPip
  • 265 posts

Posted 08 November 2005 - 11:50 AM

geon said:

Yep.
Globals are usually considered a bad coding practice. The "its so much simplier" argument is not really valid.

Globals have their uses, as does every other "Don't ever use it" feature of a programming language. I personally like globals for a variety of reasons, but hey, just my opinon.

Spree

#7 geon

    Senior Member

  • Members
  • PipPipPipPip
  • 893 posts

Posted 08 November 2005 - 12:44 PM

Spree:

Yes, globals can be useful, but you should really know WHY you use them.

The laziest solution is mostly not simplier in the long run. To just think it is a simplier solution is naive. (Yes, I've been there, done that.)

#8 chot

    New Member

  • Members
  • PipPip
  • 28 posts

Posted 08 November 2005 - 06:13 PM

k thanx, think i got an idea on how to do now





1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users