Author Archive

Creating a Space Shooter Weapon System

So a question came up the other day from Dave Voyles about how to design a weapon system for a space shooter. He needed to figure out how to track what weapons a player had collected and how to switch between them. I got to thinking about it and decided to see what I could come up with. Here’s the basic requirements that I figured would be good to have:

  • A ship could start out with no weapons or 1 or more weapons, with or without ammo
  • A weapon can have infinite ammo or require ammo pickups
  • The player shouldn’t be able to switch to a weapon that hasn’t been equipped on the ship or if it doesn’t have ammo
  • An ammo type could be shared between weapons (think universal energy cells for energy powered weapons)
  • Ammo pickups could have different amounts of ammo for an ammo type
  • Switching between weapons could wrap around both forward or backward. For example, using an Xbox controller, the left and right bumpers could be used to switch to the previous or next weapon – if the first weapon is selected and the left bumper is pressed, the last weapon that’s equipped would be selected.
  • An icon on the game’s HUD would show the currently selected weapon and the ammo available for that weapon would be displayed.

Starting from an empty Unity project, we’ll only need one scene and some GUI elements in that scene. I’m using buttons for all of the player input in this sample, but you would want to handle whatever method of input you’re targeting for your game, touch included. Here’s what my example looks like:

The 5 images on the right are used to display the currently selected weapon, which is the blank image between the Next and Previous buttons. Notice that the button to fire the weapon is initially set to disabled. Whether or not to enable this will be handled by the script we’ll attach to the scene. The small images above the currently selected weapon image will show the weapons that have been equipped on the ship. The buttons to pickup weapons and ammo would be replaced in a real game with sprites or some other element that the player’s ship would interact with.

The next thing we’ll need is a script to control everything and a script to define weapons and ammo. We’ll look at the latter first:

using UnityEngine.UI;

public enum AmmoType
{
    Regular,
    Shotgun,
    Sniper,
    Energy
}

public enum WeaponType
{
    Vulcan,
    SoloGun,
    Sniper,
    ShotGun,
    Seeker
}

public class Weapon
{
    public WeaponType Type;
    public Image HUDIcon;
    public AmmoType Ammo;
    public int AmmoCount;
}

 

For our basic example this is all we’ll need. More than likely your weapon class would have more members and functionality and you might even have an ammo class.

Notice that we only have 4 ammo types. The SoloGun and the Seeker I decided were energy weapons and will share whatever energy ammo is available.

The script to control the interaction with the weapons is only a bit more complex in my opinion:

using UnityEngine;
using System.Collections;
using System.Collections.Generic;
using UnityEngine.UI;
using System;
using UnityEngine.EventSystems;

public class WeaponInventory : MonoBehaviour
{
    private int[] weaponAmmoRate = new int[] { 10, 1, 1, 1, 5 };

    Dictionary<WeaponType, Weapon> weapons;
    WeaponType curWeaponIndex = WeaponType.Vulcan;

    public Image CurWeaponIcon;

    public Image VulcanImage;
    public Image SoloGunImage;
    public Image SniperImage;
    public Image ShotgunImage;
    public Image SeekerImage;


    public Image MiniVulcanIcon;
    public Image MiniSoloGunIcon;
    public Image MiniSniperIcon;
    public Image MiniShotgunIcon;
    public Image MiniSeekerIcon;


    public Button FireButton;

    public Text AmmoDisplay;

    public bool WrapWeapons = true;

    private Dictionary<AmmoType, int> Ammo; //-1 for infinite


	// Use this for initialization
	void Start () {

        weapons = new Dictionary<WeaponType, Weapon>();

        weapons.Add(WeaponType.Vulcan, new Weapon() { Type = WeaponType.Vulcan, HUDIcon = VulcanImage, Ammo= AmmoType.Regular });

        MiniVulcanIcon.color = new Color(1.0f, 1.0f, 1.0f, 1.0f);

        Ammo = new Dictionary<AmmoType, int>();

        Ammo.Add(AmmoType.Regular, 100);
        Ammo.Add(AmmoType.Energy, 0);
        Ammo.Add(AmmoType.Shotgun, 0);
        Ammo.Add(AmmoType.Sniper, 0);

        FireButton.interactable = true;

        GetCurWeaponImage();
	}

    public void NextWeapon()
    {
        if (!WrapWeapons && (int)curWeaponIndex == Enum.GetValues(typeof(WeaponType)).GetUpperBound(0))
            return;
        else
        {
            WeaponType originalIndex = curWeaponIndex;

            curWeaponIndex++;
            while (!weapons.ContainsKey(curWeaponIndex))
            {
                if ((int)curWeaponIndex > Enum.GetValues(typeof(WeaponType)).GetUpperBound(0))
                    curWeaponIndex = 0;
                else
                { 
                    curWeaponIndex++;
                    if (curWeaponIndex == originalIndex)
                        break;
                }
            }

            GetCurWeaponImage();
            CheckWeapon();
        }
    }

    public void PreviousWeapon()
    {
        if (!WrapWeapons && (int)curWeaponIndex == 0)
            return;
        else
        {
            WeaponType originalIndex = curWeaponIndex;

            curWeaponIndex--;
            while (!weapons.ContainsKey(curWeaponIndex))
            {
                if ((int)curWeaponIndex < 0)
                    curWeaponIndex = (WeaponType)Enum.GetValues(typeof(WeaponType)).GetUpperBound(0);
                else
                {
                    curWeaponIndex--;
                    if (curWeaponIndex == originalIndex)
                        break;
                }
            }

            GetCurWeaponImage();
            CheckWeapon();
        }
    }

    private void CheckWeapon()
    {
        bool enable = Ammo[weapons[curWeaponIndex].Ammo] > 0;

        FireButton.interactable = enable;
    }

    private void GetCurWeaponImage()
    {
        CurWeaponIcon.sprite = weapons[curWeaponIndex].HUDIcon.sprite;

        UpdateAmmoDisplay();
    }

    public void PickupVulcanWeaponButtonClick()
    {
        if (!weapons.ContainsKey(WeaponType.Vulcan))
        { 
            weapons.Add(WeaponType.Vulcan, new Weapon() { Type = WeaponType.Vulcan, HUDIcon = VulcanImage, Ammo = AmmoType.Regular });
            MiniVulcanIcon.color = new Color(1.0f, 1.0f, 1.0f, 1.0f);
        }
    }

    public void PickupSoloGunWeaponButtonClick()
    {
        if (!weapons.ContainsKey(WeaponType.SoloGun))
        {
            weapons.Add(WeaponType.SoloGun, new Weapon() { Type = WeaponType.SoloGun, HUDIcon = SoloGunImage, Ammo = AmmoType.Energy });
            MiniSoloGunIcon.color = new Color(1.0f, 1.0f, 1.0f, 1.0f);
        }
    }

    public void PickupSniperWeaponButtonClick()
    {
        if (!weapons.ContainsKey(WeaponType.Sniper))
        { 
            weapons.Add(WeaponType.Sniper, new Weapon() { Type = WeaponType.Sniper, HUDIcon = SniperImage, Ammo = AmmoType.Sniper });
            MiniSniperIcon.color = new Color(1.0f, 1.0f, 1.0f, 1.0f);
        }
    }

    public void PickupShotgunWeaponButtonClick()
    {
        if (!weapons.ContainsKey(WeaponType.ShotGun))
        { 
            weapons.Add(WeaponType.ShotGun, new Weapon() { Type = WeaponType.ShotGun, HUDIcon = ShotgunImage, Ammo = AmmoType.Shotgun });
            MiniShotgunIcon.color = new Color(1.0f, 1.0f, 1.0f, 1.0f);
        }
    }

    public void PickupSeekerWeaponButtonClick()
    {
        if (!weapons.ContainsKey(WeaponType.Seeker))
        { 
            weapons.Add(WeaponType.Seeker, new Weapon() { Type = WeaponType.Seeker, HUDIcon = SeekerImage, Ammo = AmmoType.Energy });
            MiniSeekerIcon.color = new Color(1.0f, 1.0f, 1.0f, 1.0f);
        }
    }


    public void FireWeaponButtonClick()
    {
        Ammo[weapons[curWeaponIndex].Ammo] -= weaponAmmoRate[Convert.ToInt32(weapons[curWeaponIndex].Ammo)];

        if (Ammo[weapons[curWeaponIndex].Ammo] == 0)
            FireButton.interactable = false;

        UpdateAmmoDisplay();
    }

    private void UpdateAmmoDisplay()
    {
        AmmoDisplay.text = Ammo[weapons[curWeaponIndex].Ammo].ToString();
    }

    public void PickupRegularAmmoButtonClick()
    {
        Ammo[AmmoType.Regular] += Convert.ToInt32(EventSystem.current.currentSelectedGameObject.tag);
        CheckWeapon();
        UpdateAmmoDisplay();
    }

    public void PickupEnergyAmmoButtonClick()
    {
        Ammo[AmmoType.Energy] += Convert.ToInt32(EventSystem.current.currentSelectedGameObject.tag);
        CheckWeapon();
        UpdateAmmoDisplay();
    }

    public void PickupShotgunAmmoButtonClick()
    {
        Ammo[AmmoType.Shotgun] += Convert.ToInt32(EventSystem.current.currentSelectedGameObject.tag);
        CheckWeapon();
        UpdateAmmoDisplay();
    }

    public void PickupSniperAmmoButtonClick()
    {
        Ammo[AmmoType.Sniper] += Convert.ToInt32(EventSystem.current.currentSelectedGameObject.tag);
        CheckWeapon();
        UpdateAmmoDisplay();
    }

}

I had originally planned on using an enum for weaponAmmoRate, but the duplicate values made that impractical. Obviously the values need to match the order of the WeaponType enum.

The weapons variable holds all the possible weapons a ship can carry, even if they’re not equipped. If you add new weapons to the WeaponType enum, there will automatically be room for them in the possible weapons the ship can equip, no change necessary.

The curWeaponIndex is straightforward, it points to the item in the weapons array that’s currently selected.

CurWeaponIcon is the image in the scene that shows the player the weapon that’s currently selected. We need the member here to allow us to change it when the player uses an input device to switch between weapons. We could grab the Image every time the weapon is switched, but that’s cumbersome, more code than we need to use and wastes time. You’ll see this a lot in Unity, having a member in a script that is hooked to a UI object. This is one of the features of Unity that I really like. The Unity IDE recognizes the public members of a script and allows you to set them by dragging something from the Hierarchy onto it in the Inspector.

The next two chunks of Images are used to set the CurWeaponIcon and display which weapons the ship has equipped respectively.

We have a reference to the button that fires the selected weapon as we need to enable or disable it when the selected weapon is changed or if the selected weapon runs out of ammo.

As the player fires the selected weapon, we use the AmmoDisplay member to update the amount of ammo that’s available for the weapon.

Some games allow the selection of the weapon to wrap from last to first or vice versa when navigating through the equipped weapons. The WrapWeapons member allows us to decide whether or not we enable this feature. The code for handling the navigation between weapons uses this member to correctly set the selected weapon as we’ll see shortly.

The Ammo member holds the amount of ammo for every type of weapon. In the case of the some weapons you might want this is be infinite. This is usually the case with the default or first weapon that’s equipped in the ship. Setting the value to –1 for a weapon allows for infinite ammo for a weapon.

At the start of the scene we create our weapons array, add a Vulcan to it, set all the UI elements to indicate we have a weapon set, and add some ammo for it.

In the NextWeapon and PreviousWeapon methods we first check to see if the current weapon is the last or first respectively and if weapon wrap is not turned on we just return as there’s nothing to do. We then go through the weapons list checking to see if a weapon has been equipped on the ship to select. If we go through the entire list and don’t find one we just re-select the original weapon. We set the select weapon icon and check to see if the weapon has ammo, disabling the fire button if not. We also update the display of the available ammo for the selected weapon.

For each of the method for picking up a weapon we first see if the weapon is already equipped. If not, we create an instance in the weapons list and set the icon to indicate that weapon is available.

When the fire button is pressed we subtract from the ammo for that weapon based on the weapon rate for the weapon and disable the weapon is the ammo has run out. There’s a potential bug in this code. See if you can find it. 😉

When ammo is picked up, we grab the Tag property of the GameObject to see how much ammo it contains and add that to the proper element in the Ammo array. One thing that you could change for a real game is add a property to the ammo GameObject to indicate what type of ammo it is and have one method for handling all ammo pickups. Try replacing the buttons with a GameObject that does this.

That’s it. Pretty simple I think, but it should be enough to at least start you out with a space shooter type game. As also, feedback and questions are welcome. :)

More GameSparks and Unity Goodness

So if you’ve read the previous post and have a GameSparks project set up with leaderboards and achievements and a Unity project that handles adding achievements and scores you’re all set to complete the basics by adding functionality to display the high scores and the achievements a player has earned.

Add a new scene and set it up like the following:

leaderboards

All that’s needed is a few lines of code to display the scores in the leaderboard. Open the Leaderboards class and add the following:

using UnityEngine;
using System.Collections;
using UnityEngine.UI;
using GameSparks.Api;
using GameSparks.Api.Messages;
using GameSparks.Api.Requests;
using GameSparks.Api.Responses;
using GameSparks.Core;

public class Leaderboards : MonoBehaviour {

	// Use this for initialization
	void Start () {

        LeaderboardDataResponse response = new LeaderboardDataRequest().SetLeaderboardShortCode("HighScoreLeaderboard").SetEntryCount(10).Send();

        if(!response.HasErrors)
        {
            foreach (var entry in response.Data)
            {
                Text player = GameObject.Find("Player" + entry.Rank.ToString()).GetComponent<Text>();
                player.text = entry.UserName;
                Text score = GameObject.Find("Score" + entry.Rank.ToString()).GetComponent<Text>();
                score.text = entry.GetNumberValue("Score").ToString();
            }
        }
        else
        {
            Text player = GameObject.Find("Player1").GetComponent<Text>();
            player.text = "No Scores";
        }
	}

    public void OKButtonClick()
    {
        Application.LoadLevel("MainMenuScene");
    }
}

If you don’t have any scores other than the one from the previous post you should add some players through the GameSparks Test Harness and log some scores. To do so use the RegistrationRequest and AuthenticationRequest calls:

new player2

 

authentication

then add scores using the PostHighScoreEarned call under LogEvent:

posthighscore

Make sure you make all three calls in this order or your scores won’t be posted correctly.

On to achievements. I created a couple of additional achievements from the one created in the previous post:

achievements

Of course, we’ll need a scene to display them in:

achievementsscene

The graphic for each achievement is a UI Image object. We set the tag for the graphic to the achievement’s shortcode so we can find it when the scene loads.

Create a script and attach it to the scene’s Canvas as usual. Add the following to it:

using UnityEngine;
using System.Collections;
using UnityEngine.UI;
using GameSparks.Api;
using GameSparks.Api.Messages;
using GameSparks.Api.Requests;
using GameSparks.Api.Responses;
using GameSparks.Core;


public class Achievements : MonoBehaviour {

	// Use this for initialization
	void Start ()
    {
        new ListAchievementsRequest().Send((response) =>
        {
            if (!response.HasErrors)
            {
                foreach (ListAchievementsResponse._Achievement achievement in response.Achievements)
                {
                    //if achievement hasn't been earned grey out icon
                    if (achievement.Earned.HasValue && !achievement.Earned.Value)
                    {
                        Image graphic = GameObject.FindGameObjectWithTag(achievement.ShortCode).GetComponent<Image>();
                        graphic.color = new Color(1f, 1f, 1f, .1f);
                    }
                }
            }
        });
	}

    public void OKButtonClick()
    {
        Application.LoadLevel("MainMenuScene");
    }

}

The ListAchievementsRequest call gets all the achievements set up in the system with a member for each achievement that tells if the player has earned it. If he hasn’t we change the alpha component of the color for the achievement’s graphic to indicate that the player hasn’t earned it.

That’s all it takes to get basic achievements and leaderboards working in your game. The project for this post is located here.

There is a lot more functionality in GameSparks that I’d like to cover. I’m thinking I might dig into some of the social functionality like friends and messages next. If you’ve looked into GameSparks and there’s something that you’d like to see covered let me know.

Integrating GameSparks into a Unity game

A big selling point of video games is having things like leaderboards and awards/achievements. Unfortunately, implementing these things is a lot of work. Tools like Azure Mobile Services and 3rd party offerings make this a little easier, but it’s still a lot of work. I originally started looking at Azure Mobile Services, via bitrave, but recently stumbled across something that looked like it might be a bit easier, being built specifically for what I was looking to implement – GameSparks. I’m going to go over using the SDK in a couple of posts, each one being relatively short and sweet.

Obviously, the first thing that needs to be done is to download and install the SDK. Rather than rewrite something, just follow the instructions here and come back when you’re done. Go ahead, I’ll wait. :)

OK, so you should be all set up and able to authenticate against the service. The first thing we’ll need is some way to log in to the game. We have to have an ID for the player in order to track things like leaderboards and achievements. We’ll need a scene to allow the user to enter the data for a user ID and password:

login screen

Create a new scene and place some UI controls similarly to the layout in the picture. Notice that I’ve put a GameObject in the scene for the GameSparks functionality as the instructions above stated. Once you have the scene create a Login class and add the following to it:

using UnityEngine;
using System.Collections;
using UnityEngine.UI;
using GameSparks.Api;
using GameSparks.Api.Messages;
using GameSparks.Api.Requests;
using GameSparks.Api.Responses;
using GameSparks.Core;

public class Login : MonoBehaviour {

    public InputField LoginIDText;
    public InputField EmailText;
    public InputField PasswordText;
    public Text LoginErrorText;

    public void CreateAccountButtonClick()
    {
        //ensure all items were entered
        if (LoginIDText.text.Length > 0 && EmailText.text.Length > 0 && PasswordText.text.Length > 0)
        {
            RegistrationResponse response = new RegistrationRequest().SetUserName(LoginIDText.text).SetDisplayName(LoginIDText.text).SetPassword(PasswordText.text).Send();

            if (!response.HasErrors)
            {
                Global.UserID = response.UserId;
                Application.LoadLevel("MainMenuScene");
            }
            else
                LoginErrorText.text = "All information must be entered";
        }
    }

    public void OKButtonClick()
    {
        //verify credentials
        if (LoginIDText.text.Length > 0 && PasswordText.text.Length > 0)
        {
            AuthenticationResponse response = new AuthenticationRequest().SetUserName(LoginIDText.text).SetPassword(PasswordText.text).Send();
            if (!response.HasErrors)
            {
                Global.UserID = response.UserId;
                Application.LoadLevel("MainMenuScene");
            }
            else
                LoginErrorText.text = "Incorrect credentials";
        }
    }

    public void ExitButtonClick()
    {
        Application.Quit();
    }
}

Note the references to the GameSparks namespaces added at the top. We’ll need these to send requests to the service. We have the members that we’ll link to our controls so we can retrieve the text in them and 3 methods for handling clicking on each button.

If the player is creating an account, we send the info to the GameSparks service using the RegistrationRequest object and assuming we get a valid response set a global (yes, I use globals. Don’t hate! :D) with the ID so we can use it later, then load the menu scene. If the player already has an account we use the AuthenticationRequest object and, if the credentials are correct, load the menu scene. Fairly straightforward stuff. Once you have the code entered, save and go back to Unity. Drag the class from the Project tab onto the Canvas in the Hierarchy and hook up all the events and drag the input fields onto the Login class members in the Inspector. If you’re not sure how to do this, head over to the Unity Tutorials site and learn the basics of working in the Unity IDE. If you’re really stuck let me know and I’ll try to walk you through the process. :) The interesting stuff happens next.

Before we can use the Achievements and Leaderboards scenes we need to set up some achievements and leaderboards in GameSpark. In the GameSparks Configurator, click on Achievements, then the Add New “+” graphic:

gamesparksachievements

Add some info for the achievement:

achievementinfo

Click the Save button and you’re done with that part. You can add as many other achievements as you’d like of course.

Next we’ll need an event that’ll be called when an achievement is earned. Click on the Events item in the Configurator and create a new Event:

achievementevent

The ShortCode is the same as the Name here since the text area isn’t wide enough to show it. :( We’ll send the Player’s ID and the shortcode for the achievement to a chunk of Cloud Code that’ll save the achievement. After you save the event, go ahead and click on the Cloud Code item. Under the Bindings | Events item, click on the PostPlayerAchievementEarned item and add the following code:

achievmentcloudcode

Save that and that’s it for the GameSparks side of things.

How do we tell GameSparks the player has earned an achievement? Good question, let’s implement that now. Create a new scene that we’ll use to fake earning an achievement (and adding to a leaderboard soon):

testscene

Add a script file call GameSparksTest and add the following to it:

using UnityEngine;
using System.Collections;
using UnityEngine.UI;
using GameSparks.Api;
using GameSparks.Api.Messages;
using GameSparks.Api.Requests;
using GameSparks.Api.Responses;
using GameSparks.Core;



public class GameSparksTest : MonoBehaviour {
    public Text ResponseText;
    public void TestAchievementButtonClick()
    {
        LogEventRequest request = new LogEventRequest(); ;
        request.SetEventKey("PostPlayerAchievementEarned");
        request.SetEventAttribute("PlayerID", Global.UserID);
        request.SetEventAttribute("AchievementID", "PlayedGame");

        ResponseText.text = "";

        request.Send((response) =>
        {
            if (!response.HasErrors)
                ResponseText.text = "Achievement Added";
            else
                ResponseText.text = response.Errors.JSON;
        });

        if (ResponseText.text == "")
            ResponseText.text = "Response not received";

    }

}

Fairly straightforward. Create the LogRequest object, set the name of the event to be called, set the parameters, and send it off.

Leaderboards work in a similar fashion. Head back to the GameSparks Configurator and set up an event:

leaderboardevent

Then set up a leaderboard:

leaderboard

That’s it for the GameSparks side of things. Go back to the GameSparksTest class in your Unity project and add a handler for the TestLeaderboardButton (making sure to hook it up to the button):

public void TestLeaderboardsButtonClick()
{
    LogEventRequest request = new LogEventRequest();
    request.SetEventKey("PostHighScoreEarned");
    request.SetEventAttribute("Score", 10);

    request.Send((response) =>
    {
        if (!response.HasErrors)
            ResponseText.text = "High Score Posted";
        else
            ResponseText.text = response.Errors.JSON;
    });

    if (ResponseText.text == "")
        ResponseText.text = "Response not received";
}

It doesn’t get much simpler than that I think. You can use the Test Harness section of the GameSparks site to pull the data for the achievements and leaderboards for the player to verify that the data was saved. Using the Test Harness is pretty straightforward. You’ll have to make an authentication call, then use the List AchievementRequest under the Player section and the ListLeaderboardsRequest under the Leaderboards section, filling in the necessary information in the JSON.

I’ve put the Unity project for this post here. You’ll have to fill in your own GameSparks credentials of course. Feel free to ask any questions about what we’ve gone over.

Next post I’ll add functionality to pull and display the achievements for a player and display the leaderboard information. Take a stab at figuring it out beforehand if you’d like.

World Screen Screenshot

Well, it’s getting there:

WorldScreen

New Dungeon Editor Screenshot

Some progress:

  • Added 2nd layer for regular and secret doors
  • Triggers (X in screenshot) and traps (square in screenshot) now rendering
  • Load and save working, using sharpSerializer since normalize XmlSerializer doesn’t like arrays, among other things.

 

DungeonEditorScreenshot2

Dungeon Editor, 1st Iteration

Behold my awesome graphical skills! :) It’s got a long way to go, but it’ll do for now:

 

DungeonEditor

Thoughts on Stat Types and Skills

So I’m thinking of going with just a few types of stats for the dungeon crawler I’m prototyping:

Strength – how much a character can carry and modifies the damage done with melee weapons
Dexterity – helps determine if a character hits during combat and how well he performs skills like lockpicking
Agility – how well a character moves and dodges during combat and performs skills like climbing
Constitution – helps determine a character ability to soak up damage, whether in combat or due to things like poison. Fairly standard.
Intelligence – overall stat for character’s mental abilities, includes will power in resisting magical spells like illusions, ability to learn spells, etc. I can’t think of a better term for this.

I don’t want to overdo this, but I want some flexibility and “realism” (quoted because I mean realistic in the game world, not necessarily in this one :D). Some RPG systems lump agility and dexterity together into one stat, which I think doesn’t fit. A character could be a great lockpicker but horrible at dodging blows in combat or a great swordsman but doesn’t climb very well, so one stat for both is kind of silly.

For skills, the usual dungeon crawler types of actions will need to be done by a character, besides combat. Lockpicking, the ability to find things that don’t want to be easily found (traps, secret door, etc.), climbing (maybe, for getting out of pits if I implement them), sneaking up on other entities. I’m not sure how deep I want to go here. Implementing skills means dealing with allowing a character to become better at them, and I’ve never really liked many skill progression systems. “Realistically”, a character would get better at things the more they do them, as in games like Dungeon Siege. That’s a good bit of work to handle. Less realistic is allowing a character to “train” at skills by spending skill points. Easier to implement, but just feels wrong.

New game idea LFF (Looking For Feedback)

So I’m a glutton for punishment. I’ve got a couple of games already started and decided to think about starting a new one. :\

Being an RPG/dungeon crawler fan, I wondered what a game that is completely about dungeon crawling could look like. I also thought about how cool it would be if the game could dynamically be expanded through user contributions.

The basic idea is a world map that shows, from the start, all the dungeons that are known to exist in the world. It shows dungeons you’ve completed and not completed differently. It could also show new dungeons that have been “discovered” (uploaded by community) since you last played. The “goal” of the game would be to complete every dungeon in the world.

Leaderboards would show stats such as most loot collected, most monsters killed, most experienced characters as well as non-in-game stats such as highest-rated dungeon (did I fail to mention that the community could vote of contributed dungeons? :D), most crawled through dungeon, highest rated designer, etc.

One idea I’m kicking around is that a player can only have one character at a time. If a character dies, you start over. Stats will carry over, loot and such, but stats would also be displayed as an average – total loot/exp/etc. / number of characters.

Ideally, contributions uploaded by the community would be scanned and ranked based on content – total treasure, total monster exp, etc. in order to allow only characters in a certain range to go through them. Designers could just load down a dungeon will all treasure and no monsters. The loot-to-monster ratio would have to be within a certain percentage.

I need to figure out the specific RPG elements – character stats, classes, equipment, etc. as well as monster and dungeon designing tools, but that’s just a matter of time to ensure the tools are robust enough to enable designers to create good, fun content.. Figuring out if this would even work and be fun is something that I need to get some opinions on. I know it would be fun for me as both a player and a designer. I imagine the achievement/leaderboard junkies would play to get to the top of the boards.

I could see this expanding into areas like allowing players to trade and buy and sell loot, grouping and guilds (this would be single-player only at first), etc. Things like this would be wayyyyy down the road. :)

I’m hoping I get some good feedback and see where this thing goes.

Once more into the breach!

So I got that email I was hoping I’d get this morning. I’m once more an XNA MVP. Seven years now. Now I have to figure out what to do this year to keep it. With XNA being the proverbial red-headed stepchild right now to MS, that’s going to be more difficult.

I’ve been planning on looking into other technologies for doing games on Windows 8 so that they would be able to be featured in the Windows Store. That’s probably going to take away some time from doing anything XNA related to maintain my MVP status.

I’m still planning on, and currently taking a break from coding to write this, releasing at least one game on XBLIG. That won’t really help with with maintaining my MVP status, but it could be a step towards becoming a full-time indie game developer.

Note to self: I need to work on some other New Years resolutions besides getting a game on XBLIG.

In any case, I think it’s going to be an interesting year now that we’ve survived the non-existent Mayan apocalypse. :)

Picking up Microsoft’s slack

Seems like Quality Control is something MS (at least the Windows Phone/XNA/XBLIG/whoever is left these days) isn’t interested in. They broke a huge amount of content in the split between Windows Phone and XBLIG in the old App Hub site. One of the pieces of content was a Best Practices page for doing XNA games. While it’s still findable using the Way Back Machine, all the links in it are broken, so I figured I’d recreate it here and also use it as an excuse to update this blog which I’ve slacked on.

 

Best Practices for Indie Games 3.1

 

If you are interested in creating an Xbox LIVE Indie Game, use this guide to understand the expectations of the millions of gamers who will be downloading and playing your game, and the actions you can take to make your game look, feel, and play its very best.

This Guide references features in XNA Game Studio 3.1. A guide for XNA Game Studio 4.0 is being developed, but is not yet available.

A few things to remember:

  • The sections in this guide are ordered by priority, but everything in it is important! Please be sure to read it all and verify that your game take these issues into account.
  • While these best practices are suggestions and not requirements, in many cases your game will be unplayable if you do not follow them. While they are not necessary to pass peer review, and reviewers should not use these guidelines to pass or reject games, they may reject games that are unplayable!
  • Use the playtest support available in the submission process on the App Hub website to have other developers help validate and catch issues with your games, before millions of gamers do.


Gamers Expect Games to “Just Work” on Any TV


Background: Xbox 360 consoles can be plugged into TV sets of all types, with many different resolutions, aspect ratios, and more. Overscan (edges of the TV screen which don’t draw the entire viewport), stretching of your game’s visuals, and even crashes can occur if resolutions are not handled properly.


Actions:

  • Set your game’s resolution to 1280 x 720 (720p native resolution) to work on all TVs. This gives you a single resolution target for all of your art content.
  • Draw the entire scene to your Viewport size, but draw your critical gameplay features (HUD, main character, and so on) to the region inside
  • Viewport.TitleSafeArea.
  • If using text, use a 14-point or higher font to insure the font can be read on standard-definition TVs. Draw the SpriteFonts at full size.

For Reference, See:


Gamers Expect a Good Trial Mode


Background: Many gamers want to try before they buy, and the Xbox LIVE Indie Games system allows players to try a timed trial of your game before they buy. Currently, the trial mode time is set at eight minutes. When the time runs out, the player is shown a screen where he or she can either purchase the full game, or exit. The only additional restriction in Trial Mode is that Xbox LIVE matchmaking is disabled. During the trial, you have the opportunity to show off the very best your game has to offer.


Actions:

  • Check whether the game is in Trial Mode by checking if the Guide.IsTrialMode property is true. This will always start out as true, and can change shortly after game startup, or as part of a new player signing in, or in response to an in-game purchase. Be sure to check this once every frame, as opposed to just once at startup.
  • Consider ways to give the player the best experience in the limited amount of time available. This may mean you want avoid title screens or exposition on the story and get right to the gameplay as soon as possible. The time limit for trial mode time is currently set to eight minutes, although this may be changed in the future.
  • When the purchase screen opens, Xbox LIVE Indie Games will set Game.IsActive to false. If the player chooses to buy the game and a successful purchase is made, the game will resume and Guide.IsTrialMode will be set to false. You can manually activate the purchase screen before the time limit expires if you wish, by calling Guide.ShowMarketplace. Your game must be able to handle the IsTrialMode changing without re-starting. This may mean that you need to reload or re-initialize the menus, gameplay or other aspects of the game “on-the-fly” when the flag changes.
  • Consider displaying a scene as the gamer exits the game that gives the gamer the option of being taken to Marketplace to purchase the game using the Guide.ShowMarketplace API, if Guide.IsTrialMode property is true.
  • If your game has Xbox LIVE multiplayer support, disable it at the menu if the game is in Trial Mode – if the player selects the option, you can call Guide.ShowMarketplace. Remember to re-enable it if the Guide.IsTrialMode flag changes to false during the game!
  • Test out trial mode by setting Guide.SimulateTrialMode to true, or by using the “Play Trial Game” option to launch your game from the Xbox Dashboard. This forces the Guide.IsTrialMode flag to true. You can also test that the game handles the transition from Trial mode to being purchased by changing the Guide.SimulateTrialMode to false during game play using a button on the controller that game doesn’t ordinarily use. This way, you know that the game will work properly when they purchase the game without re-starting.

For Reference, See:


Gamers Expect a Friendly Menu and Control System


Background: Games are essentially a cycle – from the Main Menu (and alternate menus such as Options and Help), gamers expect to enter a game session, play, and return to the main menu when they are done. Any deviation from this should be intuitive and easy to remember.

For menu navigation, gamers expect to use both the stick and the D-Pad, with A being the “accept” or “go forward” button, and B and Back being the “cancel” or “go back” buttons.

Both successful and unsuccessful menu operations should be reported in some way to the user, in both graphical and audio form. If there are errors, they should be provided to the user in simple, prescriptive language that tells the player what to do.


Actions:

  • Use a Menu system, such as in the Game State Management Sample.
  • Use the stick and D-pad to move the menu selector, and use A and B/Back to choose menu items or cancel, respectively. When using the stick for menu movement, poll with a delay to keep the menu selector from moving too fast.
  • The active menu item should stand out clearly from other menu options – use patterns, animations, or other graphical items to account for color blind players.
  • Make sure confirmations and errors are clearly shown to the player, with guidance about what the player should do next.
  • Consider changing the Back button on the controller which by default exits the game with no warning. Provide either a confirmation dialog to insure that the player really wanted to leave the game, or provide an exit menu option from the main menu and remove the Back button exit functionality entirely.
  • The game should bring up a pause menu if the active controller becomes disconnected, or if the player presses the Start button.
  • In networked games, gameplay should continue behind the pause menu even though the local player is no longer engaged in the action.
  • Make sure the game respects Game.IsActive and pauses as appropriate when this is set to false, such as when the guide is being displayed over the game.
  • Games should not stop or pause without game-representative, on-screen graphics. When the pause time is greater than five seconds, the game must indicate the reason and provide on-screen feedback/explanation (aka Loading Screen)

For Reference, See:


Gamers Use One Xbox 360 Controller


Background: This may seem obvious, but it is important. Not only do gamers expect to use an Xbox 360 Controller (not a plugged-in keyboard or Chatpad), but in a single-player game, they are going to expect whichever controller they pick up to be the one the game recognizes throughout their gaming session.


Actions:

  • Be aware that the player may not be using the controller that is assigned to PlayerIndex.One. To detect which controller the player is using, create a splash screen or initial menu which prompts to the player to press A or Start. Detect which PlayerIndex pressed the button to start the game and use that as the active controller. Here is an example of code to do this:

PlayerIndex controllingPlayer = PlayerIndex.One;
for (PlayerIndex index = PlayerIndex.One; index <= PlayerIndex.Four; index++)
{
if (GamePad.GetState(index).Buttons.Start == ButtonState.Pressed)
{
controllingPlayer = index;
break;
}
}

  • If your game requires a signed in player profile, you can then look up the profile details for the selected PlayerIndex, or if no profile is currently signed in at that index, call Guide.ShowSignIn to let the player select their profile:

SignedInGamer gamer = Gamer.SignedInGamers[controllingPlayer];
if (gamer != null)
{
playerName = gamer.Gamertag;
}
else
{
Guide.ShowSignIn(1, false);
}

  • Do not require the Keyboard for input.
  • Games should launch successfully and get to their menu and/or attract mode even if a controller is not active (For example: game is launched with an IR remote).
  • Use Guide.ShowSignIn to support the signing-in of multiple players to a local multiplayer game.

For Reference, See:


Be Kind With Audio


Background: Audio, at first glance, looks like a very easy technology to get right. Drop in sounds, and play them when asked. However, audio systems are as diverse as TVs. Volume, position, and frequency ranges may be different across the different systems.

Be sure you’re not playing sounds with wildly different volumes that force players to turn their TV’s volume up or down.

In addition, some gamers don’t like music in their games and will want to turn it off – or replace it with their own through the Xbox 360 Guide.


Actions:

  • Be sure to test your game audio on as many audio configurations as possible (stereo, mono, 5.1, and headphones).
  • Identify and eliminate major volume changes between sounds that would force the player to change audio volume while playing your game. Do this by leveling your sounds to a standard sound. The Xbox 360 startup sound is a good reference. Adjust your speaker volume so that the Xbox 360 startup sound is loud, but not overly so, and adjust your game sounds to match that level.
  • If you have music in your game, you should tag it as such. If you are using XACT, drag the music sounds into the Music category in the tree. If you use the Sound Effects API, then be sure to load your background music files as Song objects, and play them with MediaPlayer.Play. These methods ensure that the player can replace the music through the Xbox 360 Guide.
  • Here’s a tip to lower your game binary size if you are using XACT: enable XMA compression on your wave banks. Add compression in your XACT project in the “Compression Presets” node, and choose the XMA format. Edit the properties of your wavebanks, setting their “Compression Preset” box to the new preset.
  • Be aware that MediaPlayer.Play on the Xbox 360 is asynchronous which means that the song doesn’t immediately start playing. Indeed, you can check the next frame and the song almost certainly won’t have started playing by then and theMediaPlayer.State will probably still be MediaState.Stopped! If you want to start a new song when the old finishes and you check every frame for the current song to be done, each frame you will change songs if you aren’t careful. Instead, add an eventhandler to the MediaPlayer.ActiveSongChanged event and when this event fires, you can begin checking for the current song to be done using MediaPlayer.State == MediaState.Stopped.
  • The content processor for the XNA Framework sound effect API defaults to high compression. Consider how compression affects the overall size and load times of your game, versus the quality of the audio.


Gamer Profiles Matter


Background: Gamers spend a lot of time and effort on their Xbox 360 Profiles. Even if they are not connected to Xbox LIVE, profiles are used in-game to identify which player is which, to store saved games, to identify a gamer in a high score list, and, in some cases, store game defaults such as controller sensitivity. Use these profiles to identify with your gamer, and do things that personalize the experience.


Actions:

  • The key to profiles is the GamerServicesComponent. Add it to your Game component list. Then you can track profiles in your game.
  • When you start your game, check Gamer.SignedInGamers to check your active controller for a profile. You can choose to ask the gamer to sign in if a profile is not returned, or you can allow the gamer to play anonymously. Unfortunately, anonymous play prevents you opening a storage container for saving game progress, or looking up the player name (eg. for a high score chart) without them having to enter their name manually.
  • Use the gamer’s name. Check SignedInGamer.Gamertag and use it in your game, such as in a status bar or in high score charts.
  • The SignedInGamer class holds a variety of information about your player, including a GameDefaults property that may be useful in automatically tuning your game’s control scheme or difficulty. The GameDefaults.InvertYAxis property is of special interest to 3D games.
  • There’s even more data inside SignedInGamer.GetProfile, such as their gamer picture. You can use this at your discretion.
  • Respond to SignedInGamer.SignedOut on the active controller PlayerIndex. If the player signs out, you can decide what to do. Most games return to the main menu.

For Reference, See:


Represent Your Game


Background: After doing all the hard work to create your game, make sure you take the steps to represent your game in Xbox LIVE Marketplace. Also, you will want to know when people are playing it! Thumbnails, Box Art, Screenshots, Videos, and Rich Presence are key components to making sure your game shows well on Xbox 360.


Actions:

  • Have a thumbnail. When you submit your game, you will be able to submit a 64×64 jpg file that is your game icon.
  • When submitting your game to the Peer Review process, there are more ways to represent your game – be sure to give your very best! Four screenshots, a short video trailer, and box art. Take the time to create these assets. Your game’s assets are the means by which the Xbox LIVE Marketplace displays your game!
  • Rich Presence is a way for your game to display on Xbox LIVE while it’s being played. For each SignedInGamer playing your game, set Presence.PresenceMode and, if needed, PresenceValue, based on what a gamer is doing in your game at any particular moment. Xbox LIVE Indie Games adds your game title automatically, so everyone knows people are having fun in your game.


Make Loading and Saving Seamless


Background: From the time the game starts to the time the gamer quits the game, there should be good interaction between players and the game – or at the very least, there should be something for gamers to look at.

Most games do a great deal of loading at start-up, so be sure to show something interesting during that time. When saving games, do not pause or freeze the gameplay – keep the action moving and the disk operations in the background.

Players might use Memory Units (MUs) and expect to save their game there. You must use the Storage APIs asynchronously to avoid locking up in the case that your users are using a Memory Unit. Be sure to test your game both with and without an MU connected.


Actions:

  • Never start your game with a device selector screen. First, this is tacky and makes a poor first impression; second by requiring a player to hit start first you will know the active controller and can handle follow-up message boxes properly.
  • Use an animated loading screen when loading content in your game. This keeps the player from thinking the game has crashed or locked up.
  • Test that your game works when more than one memory device is present, such as having a hard drive AND a memory unit, or two memory units.
  • The first time a player’s game data must be saved or loaded, use Guide.BeginShowStorageDeviceSelector asynchronously to prevent locking up.
  • Do not ask for a storage device again after the first time – this may annoy the player.
  • If you are going to auto-save, notify the player of the auto-save, and tell them not to turn off their Xbox 360 Console while it is saving.
  • Make sure you associate saved games to a profile, but do not associate high scores to a profile. That way, everyone can see the high scores.
  • Saving and loading data in text formats can be problematic depending on the region the Xbox 360 is set to. If you convert a floating point number to a string during a save when the Xbox 360 is set to Germany, for example, you will get 1,234 when you might expect 1.234! To insure that that numeric conversions to and from strings generate the same values in all regions, be sure to store the numbers in a culturally invariant manner, or use a binary file format instead of text.

For Reference, See:


Xbox LIVE Multiplayer: Make it Full Featured


Background: Multiplayer is a valuable feature to have in your game. It increases replay value and connects gamers all over the world. However, it can be frustrating for customers if the experience is not optimized and made user-friendly. If you are building multiplayer into your game, be sure to go the extra mile and provide the features that make Xbox LIVE gameplay great.


Actions:

  • Take full advantage of the Xbox LIVE Party system to get likeminded players together in your game. Use the SignedInGamer.PartySize to determine if you should inform the player that with a simple button press they can open up the Party UI and quickly send out game invites! A size of zero means you aren’t in a party, one means you are all alone, and anything greater means you are ready to invite some friends. A simple call to Guide.ShowParty() will open the guide directly to the Party screen to streamline the invites to your fellow party members.
  • Support invites, it improves game visibility and ease of joining others for gameplay. To do so, respond to the NetworkSession.InviteAccepted event, quitting any session that the player is in, and joining the new session by callingNetworkSession.JoinInvited. Players can then send each other invites – the invited player will be given the option to purchase the game if necessary – and can join each other’s games in progress.
  • Have a Quick Match feature – don’t make your player hunt for games. Run the matching process in the background and join up with the best session available. Make quick match the default, to improve the odds of gamers finding other players via the Xbox LIVE service.
  • Have a Custom Match feature with a few parameters such as level and rule sets. Limit the number of sessions returned to make it easy for the player to pick.
  • If you have a pre-game lobby, ensure that you are displaying the match settings so that players entering the lobby know what they are getting into.
  • Optimize, optimize, optimize! The XNA Framework can simulate latency and packet loss – you should make sure to turn on both when testing. You should target 8Kb of bandwidth for your network game has this will cover 90% of Xbox 360s. You should also make sure your game can continue playing well with 500 ms of latency. For more details, see the link to Shawn’s talk below!
  • Hosting and/or joining a Multiplayer Game through Xbox LIVE is not available on Xbox LIVE Silver and some Xbox LIVE child accounts, even when the game is purchased. You can determine if a particular Gamer is allowed to participate in an Xbox LIVE session by checking that the SignedInGamer class’s Privileges.AllowOnlineSessions flag is set to true. For example:

if (Gamer.SignedInGamers[activeController].Privileges.AllowOnlineSessions) …

  • Be sure to use the rich presence to let other gamers know that your game is being played. You can also specify where a particular player is in the game using the rich presence strings. Rich presence will also require the SignedInGamer’s PlayerIndex which is another reason why you need to poll for it at startup and save it during game play. For example:

Gamer.SignedInGamers[activeController].Presence.PresenceMode = GamerPresenceMode.AtMenu;


For Reference, See:


Gamers May Have Special Controllers


Background: Many different types of controllers are supported by the XNA Framework. These controllers, which range from flight sticks to dance pads, all return values inside the GamePadState class. Gamers who have these controllers expect them to work in the types of games for which they are traditionally used.

Regardless of the special types used in your game, you should always support the default Xbox 360 Gamepad, and never require special controllers to be able to play.


Actions:

  • Determine what kind of controllers your game would best be suited for: racing games should support the wheel, flying games should support flight sticks, and so on.
  • When the player starts the game and you know which controller they are using, call GamePad.GetCapabilities and check the GamePadCapabilities.GamePadType returned value to understand what type of controller the player is using.
  • Respond to a special controller type by changing your control scheme to best fit that type. The trigger on an Xbox 360 Controller may not be best suited to a flight stick, for instance. Use the Input Reporter (linked below) to test special controller types to understand their inputs.

For Reference, See:


Avatars


Background:Starting with XNA Game Studio 3.1, developers have the opportunity to use Avatars when making their Xbox LIVE Indie Game.


Actions:

  • Users may not have an Avatar so your game should handle this situation. After retrieving the AvatarDescription via the Avatar property on the SignedInGamer the developer should check the IsValid property. If the description is not valid then the player doesn’t have a valid avatar. The developer can replace the users avatar with a random avatar using the AvatarDesctipion.CreateRandom method or load a pre created AvatarDescription.
  • If avatars are used in your networked game users should be able to see the real avatars of the other player. When creating a networked game that uses avatars the developer should send each players AvatarDescription across the network so that each player can display all of the other players avatars. A player should see a players real avatar and not a random avatar.
  • Games should be tested with different size avatars. A players avatar can be a number of different heights and sizes. A game should consider this when developing the game. Collisions may look incorrect with some size avatars.
  • Games should not expect a player to have an avatar with a specific gender. If the game contains gender specific text such as “she”, he”, “her”, or “him” the game should determine if the players gender if female or male using the AvatarDescription.BodyTypeproperty.
  • Keep in mind the rules regarding Avatar Use at all times.

For Reference, See: