Jump to content
  • Advertisement
Sign in to follow this  

A few general XNA questions

This topic is 2860 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

Hello everybody. So this is my second post, but I didn't really properly introduce myself in the first one. I'm Kris and I'm excited to be here, although as you might have guessed, I have very little experience with programming. I had an introductory course on Java at OU, and I've read up on C++ a little bit, but I haven't ever done anything very exciting with either language. As far as game development goes, I toyed around with RPG Maker XP pretty religiously a while back and had a great time with the scripting language that it uses. As you can see, I want to take it to the next level and start actually programming games. I decided to go with XNA, as it seems like it would provide me with a relatively painless transition between scripting and programming. Anyway, on to a few very general questions...

I've been reading tutorials and I actually bought a book on XNA, but all of these sources seem to discuss things on a level that really only accounts for a one screen game like pong, galaga, asteroids, etc... I'm more interested in a larger scale project, but of course, if I'm making a very large game, I probably don't want all of the logic to appear in that one update method in the game class. Right now, I'm working on a title screen. So, I decided I would make a separate class for the title. My first question is: for a bigger game, does ALL of the content need to be loaded in at the beginning in the load content method? Or do you load and unload the content as it is needed?

Also, should you ideally only deal with loading images in the game class? Or might you have multiple spritebatch objects, each contained in a class that carries out the logic for a particular phase of the game? (i.e. title screen, battle sequence, menu, overworld, etc...)

If it's inefficient or unnecessary for whatever reason to have more than just the one spritebatch object, then how about this: I figured (to use my titlescreen class as an example) I would keep names of the image files necessary for the title screen in a series of strings grouped together in an array. There would be a method that returns these names to the game class, where it then loads the images with that name, at coordinates dictated by the Title class. This way the raw image handling is still confined to the game class, but the more specific logic and image "arranging" is going on in the Title class. Is this a legitimate way to go about things?
EDIT--I just thought about this a bit more...specifically what I'm trying to avoid is having to create a Texture2D object for EVERY image in the game inside the game class alone, I'd like to be able to create the Texture2Ds in specific classes that they pertain to. I guess I could still do this with the previously mentioned way of going about it. The game class could receive the array from the title class, and create a texture2D object for each element in the array...?

I know this is a long post, and my questions might even be a little incoherent since I'm so new to this stuff. So you'll have to forgive me for that. Thanks a lot to anyone who shares their insights.

Share this post

Link to post
Share on other sites
While it's by no means the definitive solution for XNA games, I've seen a recurring pattern in larger projects that basically hands all the updating off to themed manager classes that keep track of all their own elements. An example might look something like this:

Update() //(in the main game class)
//and so on...

So yes, you'd technically be calling all your update logic in the main update method, but that's a fairly common game loop across game architectures that separate logic and rendering. The style I've mentioned above just keeps your main game class looking cleaner.

(Disclaimer: all example manager classes have been fabricated by me, a hobbyist, and do not reflect the ideal solution as they may have omitted some key element in favor of being a short and quick response)

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!