Jump to content
  • Advertisement
Sign in to follow this  

concept/organizational questions

This topic is 4516 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

well, i sat down last night and organized my thoughts on how i wanted to setup the game i'm working on. and here are the ideas i came up with, i would really appreciate any suggestions/comments you have on them (especially if any are distinctly bad ideas):
  • since this is one of the biggest projects i have ever worked on, i knew i would eventually have to setup a data file structure that would tell the game what was where, what it was doing, and such nonsense. at least i think so. my idea for how to do this was a text file that would be parsed by the game and this file would determine what objects to load (models and textures) and what properties to set for them. an example of this file would be something like this:
          ...different locations for the different objects...
          ...model and texture...
        ...info here...
    an improvement might be that some tags don't need end tags (like location) since they are single values of their own. is this a method that is commonly used (not necessarily the formatting), or is there a better one?
  • in the couple of books, tutorials, and papers i have read i never seemed to find where they discussed how to deal with event triggers in a game. by event trigger i'm not talking about key presses, but rather end game scenarios or when it is appropriate to load a new level. this is the one area that has always made me stop and think "do i really know what i'm doing?" the reason i ask myself this is because i wondered if developers just created source that had one to one correlation with each level. by that i mean, for each level there is new source code created. and if so, how is that dealt with? but, i was wondering, is it possible, or even feasable (spelling?) to use the data file i discussed above to indicate the trigger locations and take from that a string that would then be parsed and used to execute some generic functions? example:
    the file --
      <prompt>Press action button</prompt> -- text prompt overlay
      <icon>/icons/hand.bmp</icon> -- just a symbol that appears
      <action>move: box1, 10, 10, 10</action>
    and then the program would have a vector/list of event triggers for each level/area and it would do collision detection for the defined area, give the prompt and icon (if necessary), and then parse the "action" section. in this case the action would be to call a function that moves (not necessarily the name of the function, but this keyword would tell the program which function to call) an object, named "box1", from its current position to the new position listed. again, is this something that is done, or am i making this harder on myself and should just suck it up and hard code everything for each level?
  • this is kinda opengl specific, but i didn't want to create another topic there, but i would guess it also carries over to other apis also. i was thinking to save space, and also go with the very first example, i would load each used model and associated textures only once into memory then use pointers for each instance to point to this model. these pointers would probably be inside a class or struct that also includes values for mass, velocity, position, and orientation that would be (possibly) different for each instance. then when going to draw the scene i cycle through the list of pointers and use pushmatrix and popmatrix to draw the individual instances. does pushing/popping count as a state change, and if it is, how expensive is it? again, is this a good idea or a bad one?
  • lastly, if i were to get one of the game programming gems books, (i'm looking into #3 because it is the cheapest on amazon), should i look into getting another, or do they all cover the same concepts but with different articles and authors? also, which would version would you suggest? i saw #6 (and recognized some names ;)), but i can't afford $60 right now because college is starting soon and real textbooks (oh, i can't wait to purchase my copy of the steel handbook ... joy) will be needed soon. again, thank you for taking the time to read this and offer advice, i really apprecaite it! edit: is coldet a good open collision detection library that is supported anymore, or are there better ones? i'm pretty sure writing my own collision stuff is going to be more time consuming now than i have. thanks! [Edited by - supercat1 on July 5, 2006 11:35:13 PM]

    Share this post

    Link to post
    Share on other sites
    I can't offer anything specific here really, as I have never worked on a truly large-scale project and don't have much experience of my own, but having recently tackled C++ file I/O, which took about 2 months of here and there study to firmly get a grip on...

    Why not use binary files and dump the information necessary for things like savegames completely into the source file? This way you just need to os.read() all the data directly into the relevant objects in game when loading and you're good to go, no need to write messy text-parsing garbage.

    I might be wrong, but then again... I might be right, interested to here ideas or suggestions on this one.


    Share this post

    Link to post
    Share on other sites
    in all honesty, i only know text parsing. i was gonna make some lame excuse like "well i'm teaching myself opengl and all this other crap, so i don't have time to figure that out", but that is an excuse and i'll definitely look into it. thanks!

    edit: now i remembered something, the idea is that it is a group project and so i would like to make it as easy as possible for others to fix/change the level (others meaning other team mates) quickly. i'm thinking using binary would require some form of conversion to do that. also, if i use this format, it is kinda like scripting ... kinda, and so would be useable for other projects (if i like what i end up with :) ).

    Share this post

    Link to post
    Share on other sites
    about level changing(or event-triggers as you called them), its simple.
    2 alternatives:
    1. have a variable keep track of it, like so:

    int level = 1;
    /*or you could do bool like:
    bool level1;
    bool level2; etc....
    //so in your loop, just have all your functions ready:
    if(level == 1)
    if(level == 2)

    2.the other way, is to make a bunch of reset functions, for example, once you have completed the level, then reset everything to how the next level should be arranged, like so:

    int displayList[2]; //[0] = Level1 [1] = Level2
    //inside initialization
    ....displayList[0] = Load3ds("level1Scene.3ds");
    displayList[1] = Load3ds("level2Scene.3ds");
    //in loop or render
    int displayChange = displayList[0];
    displayChange = displayList[1];
    //reset could involve changing bounding volumes for collision, and as you can see, what model should be displayed.

    so basically, you can either reset everything, or just have a your loop call each level depending on what the "level" variable equals.

    sorry if thats not too clear, or as far as i know, it might not even be the most effecient. someone please correct me if im wrong

    hope that helps

    Share this post

    Link to post
    Share on other sites
    Some games use level-specific source code to handle level-specific stuff. That's pretty old-school, and I highly recommend against it.

    In a recent large-scale commercial project, we had collision volumes with Python code attached. Much of it was simple Python (that potentially triggered quite a lot of C++ activity), like PlayMovie("foo"), but some of it was more complicated on the Python side. There are waaay too many uses for this sort of thing to list here, but trust me, it's a useful way to approach the problem. Even if you don't attach a scripting language, keep the "collision volume" notion around.

    Stick with text & xml based formats for now. If you were dealing with a commercial game with lots of assets, you would need to concern yourself with the performance difference between text and binary assets.

    Yes, you definitely want to share common resources. There are plenty of suggestions out there, but they all boil down to "share what's the same, and put what's different into the classes that point at what's the same."

    If I were a student without much money, I'd probably stick to the Internet for source material for right now. There's enough out there to keep you busy for decades. When it comes time to actually have a job, you can partially determine what the quality of your potential employer when you ask them about their policy on building up a personal library is.

    Share this post

    Link to post
    Share on other sites
    The above text you posted (with the tags and such) looks almost identical to XML, check out http://www.grinninglizard.com/tinyxml/, its a library that handels I/O of XML files and will save you alot of time writing your own custom parser. I used XML files extensivly in an RPG project that I was working on and it seems to work well. There isnt alot of overhead for opening and reading the files either.
    PM me if you decide to use it and have questions, there is also plenty in docs and examples floating around.

    Share this post

    Link to post
    Share on other sites
    Sign in to follow this  

    • Advertisement

    Important Information

    By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

    We are the game development community.

    Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

    Sign me up!