#xna tutorial

Making a sound manager is easy as 1, 2, 3 so why don’t you learn with me :)

An issue that came up when messing with my current engine was dealing with sounds. I knew off the bat that just using the standard methods of calling sound.Play() using the SoundEffect class wouldn't cut it. What if we want no music to play? What if we want to mute all sounds? Then we are put in quite the pickle, I'm mean if you're a hardy fellow you can put an if infront of each sound call. What I also knew I wanted to be able to do was just call the sound to play and not have to deal with it past that. In example: SoundManager.Instance.Play("soundName", 100 ) and then bam the sound plays. We can also apply any other effects we want with a modified constructor. I also knew I wanted to have effects that could change all the noises active.

So with these facts laid out I immediately thought of my best friend Mr.Singleton Pattern. Using him we can have our calls at a global level and not have to deal with a disgusting tentacle class ( what I sometimes call important classes that need to be passed through the constructors of nearly any class, for example how we pass spritebatch through to anything with a draw method and that then tends to be passed even deeper ). Then the other thing that sounds nice would be to keep all the background work contained to one class, this would store all the sounds in the games content folder and hold all the playing sounds and remove them as needed. Some may concider this gross and I don't blame them, but I like it. Feel free to just keep it all in one class.

Now let's start off with a class called something like "SoundManager". In this class let's put the good ole fashion singleton pattern:

       public static SoundManager Instance        {            get            {                if (instance == null) // if the instance doesn't exist then create it                {                    instance = new SoundManager();                }

               return instance; // returns itself            }        }

For those of you who don't know what this is, it is a pattern that essentially states "Hey, there's only ever going to be one of me so like why bother instantiating me all around your code and just instantiate me once in myself." What I mean by that is the singleton pattern creates a global point of access to the class, and it ensures only one instance of the class is ever created.

This is the fundemental part of making this approach work.

Now we're going to go ahead and move to the other class for a second. We're going to now create a class called SoundDictionary where we'll store all the work that will actually be done with the sounds for the most part. In here we need to create a dictionary for our sounds to be loaded in, an arraylist to hold the active sounds and an arraylist to hold the sounds that need to be removed.

       Dictionary<string, SoundEffect> sounds = new Dictionary<string, SoundEffect>();        ArrayList activeSounds;        ArrayList soundsToRemove;

Now we need a way of adding sounds to the dictionary from the outside. Create a function called AddSound that takes in a soundeffect and a string.

       public void AddSound(SoundEffect sound, string name)        {            if (!sounds.ContainsKey(name))            {                sounds.Add(name, sound);            }        }

It's pretty self-explanatory there, just makes sure the name isn't already loaded in and if it isn't it adds it in.

Now we can get down to the Update function. Stick a standard Update in there with GameTime in the constructor if you want.

Now we need a foreach loop to make sure all the sounds are still running, and if not we'll take them out.

           foreach (SoundEffectInstance s in activeSounds)            {                if (s.State == SoundState.Stopped)                    soundsToRemove.Add(s);            }

After that we gotta actually remove those useless guys:

           if (soundsToRemove.Count > 0)                foreach (SoundEffectInstance s in soundsToRemove)                {                    s.Dispose();                    activeSounds.Remove(s);                }

Now we need a function that will actually play the sound:

       public void PlaySound(string name)        {            if (sounds.ContainsKey(name) && !disableSounds)            {                if ((!(disableSongs && name.Length > 4 && name.Substring(0, 5) == "Song")))                {                    SoundEffect soundEff = (SoundEffect)sounds[name];                    SoundEffectInstance sin = soundEff.CreateInstance();                    sin.Play();                    activeSounds.Add(sin);                }            }        }

We just make sure the sound of the given name exists and that sounds aren't disabled ( Just create two booleans: disableSounds and disableSongs ). At the heart all this does is make sure the sound is okay to play and if so creates an instance of the sound and plays it, then adds it to a list of active sounds. We can make all sorts of variants of this function now changing different properties of the SoundEffectInstance class.

Now what about those times when we want sound to just stop:

       public void StopAllSounds()        {            foreach (SoundEffectInstance s in activeSounds)            {                s.Stop();                s.Dispose();            }            activeSounds.Clear();        }

Whe can make modifications to this to do some fun stuff. I had my sounds dim out and wobble ear to ear. I'll include that in the link to my code at the bottom.

Now let's add one last function, a little guy meant to see if a dictionary key is already taken or not:

       public bool ContainsSound(string name)        {            return sounds.ContainsKey(name);        }

Okay, back to the Sound Manager. Almost there.

Let's create a private SoundDictionary for us to use. First let's add a LoadContent in there and pass through Content to it:

       public void LoadContent(ContentManager Content)        {            DirectoryInfo DI = new DirectoryInfo(Content.RootDirectory + "\\Sounds");            FileInfo[] files = DI.GetFiles();            foreach (FileInfo f in files)            {                soundDirectory.AddSound(Content.Load<SoundEffect>("Sounds/" + Path.GetFileNameWithoutExtension(f.Name)), Path.GetFileNameWithoutExtension(f.Name));            }        }

All this code does is automatically read in each sound in the Sound directory.

Now create an Update function and plug your SoundDictionary's update into it.

And lastly add a PlaySound function with name as a parameter:

       public void PlaySound(string name) // Plays Given Sound        {            soundDirectory.PlaySound(name);        }

Now that's that, you're done with your basic Sound Manager. Ez-pz. Maybe next time I'll do something a bit higher level. Like how to get an entity-part system off the ground in XNA. This is a very basic approach, I suggest taking what you now know and expand out from here. I like the idea of sounds having a custom class so then they can just act on themselves and make it semi-modular so you can just stick on sound effects for it to then use. You can also streamline a decent amount of the code in this.

If you have suggestions for how I should do my tutorials from now on lemme know. I’m pretty sure I’m mostly just making these for myself.

I'll put a link for the final code which includes a few extra things: Here

In the next few days I’ll be putting out a tutorial for how to make a simple sound manager in XNA. I’m excited to share my approach to the issue and hope some people find it useful or at least interesting. I have it half written out, but I don’t think it’s very user friendly so gotta fix that. I should be able to get it done very soon though. I’m writing it in notepad++ since tumblr is currently lagging out on my computer for some reason, so that will be my excuse.

     This is a short tutorial on how to set up a basic Screen Manager in C#/XNA ( or really any language ). When I started out my biggest peeve was how overly complicated the tutorials got I felt like I wasn't learning anything, just how to copy code and spend the next few hours either deciphering the diction of the tutorial or mess with the code to the point of breaking to learn the bounds. Essentially walking around a dark room feeling everything with my hands to find out where I am, otherwise they were very inefficient for a beginner.

     With this I'm far from intending to teach you how to make a strong working system for a game you plan to go deep into. I just intend to walk through the basics so you can move to those bigger scarier tutorials and feel not so lost in how things work ( even though it could damn well just be my ineptitude leading to that happening, or just not finding the right tutorial ).

So to do this let's ditch the idea of sticking everything in the "Game1.cs" and essentially make new instances of it. To do that we're going to start by making a class called "ScreenManager.cs" in this class we're going to have two variables: - int screenChoice;- Screen[] screens; And in the constructor of the class we need to bring in (Game1 g) by doing so we're essentially opening a gap to use the power of the main in any screen we want. Then we need to do this with the Update function and finally have the SpriteBatch brought in with the Draw function. All of this is shown in the image bellow.

From here we need to create a parent class which is going to be inherited by all screens in the game ( main menu, the game screen, etc. ). Create a class called Screen with a constructor and two functions. "public virtual void Update(Game1 g)" and the same for the draw. Nothing more, nothing less.

Finally I'll give you an example of a screen:

As you can see this is not as hard as it seems. That screen ( main menu in this case ) will act essentially the same as your Game1 class. Just change the screenChoice to a new value to change screens. There are many optimizations you can make from here and many paths to choose. I only really use this method if I have a game with only a few screens. For use as a level manager, point and click, etc. don't rely on this alone. Hopefully I didn't miss anything, and remember there is never just one way to approach a problem!

Ever dreamed about developing your own Tower Defense Game, but always thought that it was to hard, or to complex to learn?

Well if it is the case, and not because you are too lazy, here is the opportunity to learn about it in a very simple way.

  http://xnatd.blogspot.com/

  Through, more or less, 15 articles, the author will guide the reader through the process of building a Tower Defense game. The technology used is XNA with Nick Gravelyn’s Tile Engine Series, but it can be easily adapter to any technology you wish as the ideas exposed are very simple and straight forward.

  Some of the points being explained by the author:

  - Building the level

- Sprites or painting the assets

- Implementing the enenmies classes

- Waypoints

- Towers and towers management

- Weapons and Firepowers

- Waves

- The user interface

- Tower Types

-  Drag and Drop

- Game polishing