Tales from the Dev Side: Making a Multiplayer XBLIG by James Petruzzi
May 10, 2012 83 Comments
The first time I had a chance to make a noticeable impact on the Xbox Live Indie Game scene, it was during the 2011 Indie Game Summer Uprising event. I just didn’t play the part I had in mind. Perhaps my expectations were a little too high, because what followed was one bad review after another. I believe the term Cute Things Dying Violently developer Alex Jordan used was “assassinations.” He then went ahead and had a panic attack when his game was up for review. Okay, so the event wasn’t all that good, but there were a few shinning gems in it. Cute Things Dying Violently was pretty good, and so was online shooter Take Arms by Discord Games.
I met James Petruzzi through Twitter, and our relationship got off to a rocky start in the form of a shouting match between us. He didn’t like how rough I was being on his fellow Uprising comrades, and I didn’t like how crappy the games were so I was in a foul mood. Needless to say, I don’t think he liked me very much. However, we patched things up like two reasonably mature adults, and I think mutual respect for our roles in the community has been established.
I want to say this for everyone to see: of all Xbox Live Indie Game developers, the person I learned the most about game development from was James. Long-time readers will remember that in the early days of Indie Gamer Chick, my policy when it came to multiplayer was “online or nothing.” It’s one of the few positions I’ve backed away from since starting my site. This came about after I had a conversation with James that lasted several hours, in which he educated myself and my boyfriend Brian on just what kind of bullshit a developer has to go through to get Live multiplayer on their XBLIG. To say it was enlightening was an understatement. So when I noticed a recent trend of players and critics commenting on the lack of Live support for the format, and I knew just the guy who had to tell everyone exactly what is up. This is not your typical Tales from the Dev Side. It’s highly technical. It’s very complex. It’s HUGELY educational. Fans of the Xbox Live Indie Game community owe it to themselves to read this, just so they know what a developer goes through.
Making a Multiplayer XBLIG
Or: How I Learned to Stop Worrying and Love XBLIG
by James Petruzzi
Hello, my name is James Petruzzi and I’m a co-founder of the independent game company Discord Games. Our first game Take Arms was released on XBLIG in August 2011 after two years of hard work, and was featured in the Indie Games Summer Uprising promotion. The game is a 2d multiplayer shooter or, as others have put it, a “2d Call of Duty”.
There were a lot of ups and downs during the development of Take Arms. It was our first released game, and we made a metric ton of stupid mistakes that you can read about in our post-mortem. Since the game was multiplayer-based, Kairi Vice approached me about writing a piece to clear up a lot of the misconceptions and confusion over multiplayer XBLIG development. This article is aimed at giving a general overview of that topic, as well as detailing the most common pitfalls developers will run into. There is a lot to cover, so I apologize ahead of time if I missed anything.
Network Architecture 101
All networking on Xbox Live Indie Games is Peer-to-Peer (P2P). If you are coming from the PC world where client-server is the norm, this will be totally foreign to you. In client-server, one person or server acts as the host and everyone else is a client and connects to them. Each client regularly sends their inputs (keyboard and mouse) to the server, the server processes that information and determines what happens, and then sends out an update to every client to keep them in sync. In this method, there is no argument of what happened since there is only one authority to decide. If I just shot my partner Tim in the face, that is what everyone will see.
In contrast, P2P relies on every player being their own server. Each Xbox takes the local player’s input, receives input from the other players, updates their version of the world, and then sends out an update to everyone else about the local player. As you can see, there are as many authorities as players with P2P. Maybe on my machine I shot my partner Tim in the face, but on his he saw me behind a wall shooting bricks in the face. In my perspective I would just be shooting him forever and he wouldn’t die, and in his perspective I’d just look like an idiot shooting a wall. Since his machine is the one that determines if he got hit, nothing happens. So which machine do you believe? Mine that is telling me Tim is impervious to bullets, or his that is saying I hate solid masonry?
As you can see, P2P is not the preferred method to networking by most of the modern gaming world. It is generally inaccurate, and is also very susceptible to manipulation. If I am the authority of my player, I am the only one able to decide if I die. If I pull my network plug, I am not sending packets to everyone telling them my health or registering their hits. In a client-server setup, all that logic is run in one place and is much more difficult to manipulate.
Membership Requirements
If you hear a developer moaning about developing a networked game for XBLIG, it is most likely going to be about the cost and overhead involved. It is surprisingly expensive and difficult for a platform designed for indie developers. When you are first getting started it is easy to test between you and a partner. You both probably already have an Xbox 360, Live Gold subscriptions, and App Hub memberships (Microsoft’s program that all developers must join for $99 a year).
Where you are going to run into trouble is when you want to test a full game session. In our case, we decided on a limit of eight players for Take Arms. The difficulties started to arise when we wanted to get some other members of the team and friends involved to reach the player limit. The first thing you will realize is that in order to deploy the game to an Xbox 360, you have to be an App Hub member. There is no way around this. You will even receive an exception message on the Windows build saying you are not an App Hub member if you try to search for games without one.
The second thing is that you are using Microsoft’s Live servers for matchmaking if you are playing over the internet. As you can imagine, Microsoft is not letting you use those for free. Every person that tests your game is going to need an Xbox Live Gold subscription in addition to the App Hub membership. This can be circumvented if you test locally over a LAN with System Link, but that gives you absolutely no idea of real-world performance.
So there is a yearly cost of $160 per tester, granted they have their own Xbox 360. If you’re ingenuitive you may be thinking, “Why not use Windows instead?” Unfortunately, you still need both memberships, and it is even more time-consuming to get them playing due to licensing issues.
Ingenuitive is a perfectly cromulent word.
So what about Windows?
Surprisingly, there is no XNA networking support in Windows. Yes, you can develop your networked game in Windows and test it, but that is about it. There are two install packages for XNA; XNA Game Studio and XNA Redistributable. You will need XNA Game Studio if you are a developer working in Visual Studio. It integrates with Visual Studio making it easy to deploy your code to Xbox, and it includes the XNA framework to code against. On the other hand, the XNA Redistributable is what an end-user must install before playing your game. It contains the same XNA framework that came with XNA Game Studio sans one important piece: the networking library.
If you want your friend to help test in Windows, you will need to install the full development environment and the needed subscriptions mentioned before. For clarity, if I was hooking up a friend who doesn’t own an Xbox to test Take Arms here is what she needs:
● A Windows PC with Shader Model 2.0+
● Visual Studio 2010 Express – Free download
● XNA Game Studio 4.0 – Free download
● Xbox Live Gold membership – $60/yr
● App Hub membership – $100/yr
What if you just want to make a multiplayer XNA game for Windows only? Well, you’re not going to be using the built-in networking. According to Microsoft’s license it is illegal for you to distribute the XNA Networking DLL with your game, and besides that, they would still need both memberships to play online. Your only options are either going with a 3rd party networking library like lidgren or writing your own.
A more general problem with P2P on PC is the overall terrible security. On Xbox, the game code resides on your encrypted hard drive and the network traffic is encrypted so it can’t be tampered with directly, but on PC it is like the wild west. People can modify their outgoing packets to always have full health, modify the IL to ignore damage altogether, or any other of a million possible hacks that would be difficult to detect. If you are doing a competitive game on PC, you should use client-server architecture.
Bandwidth
Be prepared to deal with bandwidth challenges if you are developing a multiplayer title. I do not have any experience with multiplayer outside Live, so I can’t really say if it is better in the PC world or not. I will just try to convey what our experience was and what steps we took to get Take Arms as smooth as it is now. Please keep in mind all traffic is routed through Live servers, so it does not travel directly from console to console. Voice communication is going to eat into your bandwidth as well, so expect some work ahead of you.
Going off the Net Rumble Starter Kit on App Hub, we used two different packets for players: a status update (state, health, ammo, etc.) and their controller inputs (which way the sticks are pointing, which buttons are pressed, etc.). With these two packets, you can somewhat reliably recreate the player’s actions on remote machines. Your first thought is going to be that you need to send these every single frame to make it smooth. While that will work well on your LAN, you will quickly find out it does not on Xbox Live.
In Shawn Hargreaves’ blog, he clearly lays out the fact that you need to stay under 16 kb/sec total bandwidth. This gives you 8kb going out, and 8kb coming in per second. There are two things you can do to improve bandwidth consumption: send less often and compress what you do send. We played around with the send rates for quite a while, and we ended up sending each player’s controller inputs every 15 frames (four times a second), and their status update every 30 frames (two times a second). This gave us something that was jerky, but stable. The other part of the equation is compression. We worked hard to pack as much info about the player into as little space as possible. For instance, a single byte stores how many grenades you have, how many clips you are carrying, and how much ammo is currently in your gun.
After reducing bandwidth, the next step is fixing the jerky motion. Your machine will update the remote player’s position when it gets their status packet, and apply their controller inputs to him as it receives them in the meantime. This may or may not be what is really happening on their end. When you receive their next status packet with their new position, your estimate via inputs will be off. This causes jerky corrections to happen that can be fixed with smoothing. Instead of instantly updating the remote player’s position to the new one, move them over time. If you keep track of how long it is taking to receive a packet from them, you can adjust how extreme the smoothing speed is. Check out the Prediction Sample on the App Hub for more details.
Pricing
During development we debated back and forth about the right price point. When we got close to release we had the option of 80 ($1), 240 ($3) or 400 Points ($5). We personally thought the game was worth 400 points, but knew it would sell more units if we lowered it. Making it 80 points did flash through our minds once or twice, but the 50MB limit, (we were at 49MB and did not want to raise the price if we added more content down the line) and the allure of roughly 3x the profit per sale pushed us towards 240 Points.
If you are making a multiplayer only game, your number one concern needs to be getting as many people online as possible. More people online means more value for your game. Your goal is to have friends recommending it to their friends to play with them online. While Take Arms sales started out decent enough in September during the promotion, they fell off a cliff in October. My first thought when seeing this was, “We need to drop the price immediately!”. I jumped onto App Hub to lower it, only to see the price was locked for 90 days from the date of release.
Sales skyrocketed after we finally lowered the price in late November. We sold more copies in December than we did for the previous three months combined. Make no mistake, there is only one price point on XBLIG. You will only find misery if you go with the higher ones. If you have a multiplayer game, don’t even consider anything else. You need to build your community first and foremost.
Patching
What is one thing that just about every multiplayer game has in common? They almost always have at least one major problem on release, and usually have a patch out within the first 48 hours. Networked games in general are very difficult to test due to their unpredictability, and I think in general most gamers understand that. Pushing out a patch on PC can be done as soon as the new code is tested. On XBLIG you wait. And wait. And wait!
A severe problem was uncovered on the day of release for Take Arms. Somewhere along development, a loop was commented out that iterated through all the packets in the buffer every frame. This in turn caused the game to only process one incoming packet per frame. With only a few people in the game, you couldn’t notice it at all. Once the game session was maxed out, however, the packets started quickly backing up. The game would slowly become unplayable, and it would eventually crash due to a buffer overflow. It took us about a day to figure out the issue and get some people together to test the fix. We put together the updated game package, uploaded it to App Hub for Peer Review, and then got a serious wake up call.
We were well aware of the seven-day lockout after failing a Peer Review. You don’t want your approval process to be clogged with untested games, so locking them out for a week helps to prevent abuse. That makes sense. However, what we did not know was the exact same lockout applies to approved games as well. So here we are, launch day with a fix for a broken game, but we can’t submit it to Peer Review for a week! On top of that is a 48 hour minimum Peer Review time. In total, a nine-day wait to push out a simple fix.
Seeing that the game was totally broken, I did the only thing I thought was right. I pulled the game from the Marketplace in the middle of the Indie Games Summer Uprising promotion. We might have lost a lot of sales because of this (people playing the bots-only trial would not have known it was broken and still purchased), but I felt like it was the only course of action for us. I would hate to ever buy a game only to find out it is completely broken.
Trials, Bundles, & Re-releases
Some people have asked why they cannot play online in the Take Arms trial. It is an integral part of the experience you are purchasing, so the question is definitely legit. The sad answer is that networking is not supported in any fashion while in Trial Mode on XBLIG. If your game is based solely around multiplayer then your only shot at giving them a taste of what it is like is to include bots. Also, keep in mind that after release there are very few people out there with copies of the game. This means that even with the purchased full version, they are probably going to be falling back on bots a lot of the time. In general, this is a huge issue with XBLIG as the market itself is small and self-contained, and the games do not tend to bring in outside people.
XBLIG Bundles are another thing we have been asked to participate in. Bundles are a point of difficulty on XBLIG for even single player games, but due to Xbox Live’s design they render multiplayer games near useless. The same goes for “re-releasing” your game as a new product with more maps or features. XBLIG uses Xbox Live for matchmaking, and as such each product has a unique identifier. This means when I go play a match of Take Arms, it is sending its unique ID to the Live servers to find matches. If you release your game in a bundle or re-release it as a separate game, you will not be able to connect to players that bought the original version due to different ids. Since your online community is already very small, you would only be hurting yourself by splintering it.
Leaderboards
Another commonly mentioned down-side to XBLIG is the lack of Leaderboards. I suppose Microsoft does not think the App Hub membership or XBLIG sales (Microsoft takes a 30% cut of each sale) cover the cost of storage and bandwidth, so it’s not made available to XBLIG developers at all. You are not allowed to talk to outside servers either, so how would you share high scores?
The #1 game on my Leaderboard, We Are Cubes, got there in part because of online leaderboards. However, they are very difficult to implement and not really all that effective.
The only possible method is to use P2P networking in the background of your game. The idea is that you start playing your game as normal, and in the background the game does a search against the matchmaking servers to see if anyone is hosting a session. If it finds an open session it will connect to it, otherwise a new session is created. Once you are in a session with other machines, it talks to all the other Xbox’s in the session and syncs up the scores.
While it sounds great in theory, there are several pitfalls to this method. The first is that other people must be on at the same exact time you are to swap scores. This alone severely limits what data you’re going to get. Kris Steele told me that he left his Xbox on for weeks to act as a server for one of his games and the results were still poor. The second pitfall is that it’s incredibly hard to test. Given how difficult it is to test a regular multiplayer game, testing a background process becomes even trickier. Milkstone Studios are very prolific XBLIG developers and they even ran into issues on a recent release.
I received some flack for not including Leaderboards in our recently released title 48 Chambers, but I did so for good reason. If I cannot be reasonably sure that you are going to have a smooth experience, I am not going to risk it. After going through all the Take Arms problems, knowing how flakey the networking can be and how poor the turnout is, I decided it was best to not even bother with it.
Framework Exceptions
This issue is not discussed as much, but there does seem to be some problems in Microsoft’s networking library. There is not much you as a developer can do about it since they originate in the framework itself. Unfortunately, that makes the exceptions impossible to trap and it will result in an ugly crash. We still get reports of Take Arms having a Code 4 every once in a great while. The simple fact is that we have wrapped every single networking method in a try/catch to trap errors, but it still occurs regardless.
Closing
In closing, I would just like to say that even with all these pitfalls and issues, it is still awesome having a multiplayer game on Xbox Live. I hope this article will help fellow developers avoid the mistakes we made, and help educate players of the difficulties developers have to deal with. I’d like to give a huge shout out to Microsoft developer Shawn Hargreaves for his awesome blog that saved our ass many times (and not just for networking!). Thanks to Kairi Vice as well for the push to finally write this thing. If you have any questions or criticisms please feel free to contact me on Twitter at @DiscordJames. Peace!
Check out Kairi’s Reviews of James’ games.
Indie Gamer Chick 
Ouch, I always knew that it was difficult to implement multiplayer features over LIVE, but I wasn’t aware of how limited XNA was when it came to that.
Very educational read, nonetheless.
I wonder how difficult it would be to make a friends only style multiplayer leader board? I’m planning to have that sort of approach for my next game although I’ll drop the idea if it causes too much work for too little return.
Do you mean you’d enter into a sharing session with a friend via the Main Menu? In that case it probably wouldn’t be bad at all. I’d only be concerned about it if you were trying to run it in the background with a high number of possible connections.
Sort of. I imagined that after every session it would send all your scores to your friends to compare and edit existing data accordingly. It could even only do it after every time you load up the online leader board and only keep each person’s top ten scores. Would the wait time be that long?
No, it’d be fast to transfer the actual information. Only problem is the friend needs to be in the game at the same time, so I don’t think you’d get automated scores from them that often. That’s why I was thinking manual session to do it that way.
The biggest feature request for Hidden in Plain Sight is online multiplayer. And I’ve consistently answered those questions with “Absolutely not”, and now I have a great article to point people to when they say “Why not?”. You really covered the bases here.
It was a question I struggled with a lot. Making a local-multiplayer ONLY game is crazy. But I just couldn’t justify the work that would be needed to do online play, combined with the notion that probably not that many people would actually play online. Your comments about building a user base is spot on. What’s the use of going through all the work to add online play if only 300 people in the world own the game? What are the chances that they’ll be online, in game at the same time?
I would like to add, though, that my second game “Battle for Venga Islands”, used multiplayer in a pretty clever way. I used SpynDoctors high score sharing component, but rather than sharing high scores, I shared actual game data. So as you moved around the map conquering regions, that data would get shared to create a sort of async massively multiplayer game. When the game first came out and people were playing it, it worked really well (as long as I left my Xbox on 24/7). But as soon as people moved on to new games and the playerbase shrank (and I wanted to use my Xbox), things dwindled. I no longer felt justified in selling the game. New players would be temped to buy the game to get this rich online experience and be met with a wasteland. It wasn’t fair, so I pulled it. But while it was up and running, it was beautiful.
So, just my comments on online mulitplay XBLIG, for what it’s worth. This is really a great peek into the development issues related to making an online game.
That’s awesome man, very creative idea! It’s really a shame the market isn’t bigger so we could experiment more like that.
If I put multiplayer in my next game, it’s only going to be optional co-op. If people want to play with a friend or something then go for it, but I don’t want multiplayer to define the experience. It’s just too risky for an indie game (especially an XBLIG) to lean on something that requires a large market to work well.
That’s just what it was… an experiment. And I learned a lot from it. You can google it or find posts on my blog for more details, if you’re interested.
I got an email from a fan of Bad Golf. She really wanted me to add multiplayer because her husband was away in Afghanistan and playing games online was something that made them feel closer together. It was almost enough to make me drop everything else I was doing and add it, just for those two people.
Kind of speaks to the transcendent nature of games and how they can bring people closer together…
I agree
Very informative article, thanks for writing it.
Great article! Another difficulty I had with networked XBLIG was with the peer review system. A lot of developers just don’t want to review a network game due to all the extra testing required. You mentioned that the “minimum” time to get an update out on XBLIG is 9 days, but I had Pajamorama updates that took almost a month to get through peer review.
Also, you actually CAN do client/server on XBLIG. The Prediction Sample even has a link right to the Network Architecture: Client/Server sample. Kudos on getting 8-player p2p running, but just wondering why you chose that route.
Also, instead of sending the whole controller state every time, I found it was better to parse input on the client side and only send velocity/state changes to the server. Like you said, the network is the bottleneck, so a design like this really improved performance.
Cheers!
Yea, you can do client/server with a p2p architecture. I didn’t mention it for a few reasons though. The biggest is that your server REALLY needs to be on a good connection in that case. Like I said earlier, if you go above that 16kb/sec you’re going to be hurting. In the case of someone acting as server, all the clients need to be constantly synced with them so they’re going to get swamped. Also, since that server is the authority on you, you will need to adjust your local player to where the server thinks you are and that introduces a whole bunch of other headaches. So while it sounds like a golden bullet, I don’t think it really is.
Let’s say that we even could cure all of the developer ills mentioned in this article. XBLA (and even retail) is littered with games that are multiplayer wastelands. It’s gotten to the point that you need a bunch of friends to buy and like the same games so you can play co-op into eternity.
For XBLIGs it seems co-op may turn out to be a much better driver than competitive community driven multiplayer. Sure it leaves out a lot of fun game scenarios, but at least if your fans like the game they can coordinate and play when they want.
That’s a really good point. Forget about “Call of Duty” type games, where the expectation is there are 50 servers full of players and you can always find a game, but focus more on something like “Rock Band”, where you can invite friends to play at the same time. I like that.
Agreed! I don’t think I’ll ever do another competitive game for XBLIG. Probably not even PC. It’s just a huge risk to stake the fun of your game on having a ton of people online.
That is a problem with gaming as a whole at this point. I actually think about this often.
In the mid/late 90s we had things like Heat.Net, Zone (Microsoft’s old matchmaking service), Kali.net, Gamespy, etc. which at the time, only had a handful of multiplayer games. That’s all we had at the time though, and there were rarely dedicated servers, so you were basically always P2P (that’s a story for another day).
But you only had a few games to choose from, so the matches were always packed! But now we have all of those games (many of which are still played) but now also EVERY game which has come out since! Granted, many more gamers have been added to the mix since then, but now every game is slowly getting diluted.
Look at something like Counter-Strike. You have the OG version, then 1.6, then Source, and now that recent one (forgot the name). So there are fewer players across ALL of those games now.
Indeed. One of the things that disheartens me about multiplayer games even in the mainstream/AAA realm, is how few can sustain any sort of community. There are some great games with interesting and distinctive ideas that never have more than a couple of people playing them, partly because lots of people seem to prefer playing something they know they’re already good at to learning something new, and partly because there are too many so loads of games have a handful of fans rather than one or two games having hundreds of fans.
Great article, James. While I’m on the reviewer/player side of things, it’s been interesting to chart my knowledge of game development, being largely ignorant of the process at first, to slowly reaching the point now, where I can at least better understand the limitations of XNA and the P2P concept and apply it to future reviews. Even knowing the difficulty of it beforehand, I was definitely one of those that gave you flak for the absence of leaderboards in the XBLIG version of 48 Chambers. Reading this now… apologies for that. 🙂
Haha, no worries man! I’m glad I could help 😀
By the way, James: I really enjoy Take Arms even against bots. I’ve tried to get friends to play it but they’re distrustful of anything that doesn’t cost £50 or more. Even so, the bots give me a run for my money.
I’ve even seen a bot camping in a corner, just aiming at the doorway until I walked through it. How did you programme them to behave exactly like real 12 year olds? 😛
Actually I wouldn’t mind knowing more about the AI in the game and what it’s like trying to both code for and test something like that.
The AI is actually pretty basic. Tim made an add-on for the level editor that let you place waypoints, and each edge you can specify if it requires jumping, whether its a defensive point, etc.
If it’s CTF they’ll go for the flag or guard the base. If its Deathmatch they just pick a direction and run. If they run into someone they’ll fire and sometimes try to find defense.
Hope that gives you an idea. I’d HIGHLY recommend reading Matt Buckland’s Programming Game AI by Example. We used a lot of his techniques.
They will go to marked defensive points if you’re playing CTF and they see no ones guarding the base. 😉
We’ve been toying with ideas for leaderboards and even sharing ghost files with friends. Knowing these challenges, we’ll either have to get creative or keep it single player for now. Thanks for the article, James (and Kairi).
Thanks, glad I could help!
Pingback: Making a Multiplayer XBLIG | Discord Games
Pingback: What I Learned From James Petruzzi « Indie Gamer Chick
I know from our experience online play has been hard to implement but the most difficult is online testing with live accounts. It would be really great if when you got your Apphub membership you also got a second membership that was only allowed to be used to deploy and run creators club games (something similer to the old DBP tokens or student membership). Then this would at least allow a lone developer to test how the game might behave across Xbox live instead of just as a serial link game.
Currently the only real why to test this is to purchase a second AppHub account (£80) or make friends wth someone that also has an AppHub membership and hope that your friend will be patient enough to help test your game.
I definitely agree with this. Would be way more reasonable if you got a membership pack or something, as well as not needing Xbox Live Gold if your account has an App Hub subscription attached.
http://msdn.microsoft.com/en-us/library/bb975826
Games are free to choose any network topology for their gameplay data:
Peer-to-peer
Client-server, where the host doubles as the server
Client-server, using one of the other session members as the server
Any other hybrid approach
So now that we’ve established that the claims about peer to peer approaches being enforced is bullshit, what portion of the article as a whole is patently false?
If I tell you five things, and one of them is false, are the other four false?
The editorial is describing how XNA devs on XBLIG can not host a dedicated game server the way a PC game might. As way of example. Terraria and Minecraft offer dedicated servers. On XBLIG you have to figure out how to make it all work from potentially any system.
Sure, it’s your choice how you decide to handle game state, and it’s likely for the work effort involved a dev would decide whomever started the game would be the “server” and handle sending out and receiving network traffic, updating game state, and getting that back to users. The problem is that you also have to maintain your framerate.
This is a problem games have dealt with for years, of course. When you started a game of Age of Empires, someone was basically the game’s server. But it is limiting. It’s also impossible to test without involving other App Hub members, because their only supported test path is over your local lan with a pc of your own and an xbox. That is the only supported debugging model.
Now, you CAN get a bunch of other app hubbers to come online with you, give them your .ccgame and playtest, but this isn’t going to be a typical debugging session. There’s likely no way you’re going to want to have a debugger hooked in during that session and certainly you’re not going to have the time to invest in monstrous code that lets you pause the game to debug something for everyone. Besides, these people who agreed to help you test have things to do.
It’s very much a write-it-and-pray model, and surely this is a hard problem to solve. Does the PS3 or Wii offer indie developers the ability to publish networked games and test them on the SAME conditions? (I don’t know).
(I have to define indie here as a developer who does this with no support from MSFT, not an “indie dev studio” who still has a publishing contract and some basic technical support).
Plenty of games throughout history have had one of the clients act as server. However, this isn’t a “dedicated server” and therefore is not really THAT much different from a peer-to-peer model. If you go with a client-server model in an XBLIG, all you’ve done is put the lion’s share of the load on one Xbox and it’s associated bandwidth. Are you going to pick the right Xbox or just take the host? What if the players pick the wrong host? How do they even know network conditions are the problem? Are they the problem? I don’t know because I couldn’t debug under those same conditions (I had to use a xbox and pc debugging model).
Even if MSFT provided a professional standard debugging model, non-trivial networked games are bigger undertakings than most new game devs realize. I think even with THAT, many would pass and offer split screen. This is potentially thousands of hours of time being put into a game that sells for $1.
(I tried to simplify how this works for non-developers. I would expect a developer to nitpick but I think this is basically a decent explanation… at least, an opening for dialogue about it.)
This is exactly right. I think the intention when you say client-server is that there is a dedicated server with proper bandwidth hosting. XBLIG’s client-server methodology is still just P2P as you said, but you’re pushing everything to one Xbox to solve. On top of bandwidth being an issue, since that Xbox is the authority on your player you’d have to sync your player to where it thinks you are as well. Just not an option at all for real-time games with a bunch of people in them on Live.
I maintain that you’re drawing a false dichotomy between fully decentralized P2P and dedicated server models…PC games have had one player’s game as the host (with dedicated hosts as an added bonus) for years, and it looks to me like the framework makes it fairly straightforward to migrate the server between xboxes. I’ll concede to your inevitable appeal to authority argument that follows (since you did actually release a game after all) since my personal information has been revealed publicly.
Your e-mail you provided when signing up here was Invalid.
It’s perfectly valid, and I ask that you remove it and the reference to the institution whose network I am utilizing.
Keyword is “hybrid”. You’re still connecting to everyone in the session P2P. Yes, you can have one peer to act as a server, but that doesn’t magically make it client-server. Someone already commented above that you can do this, but I told them that the bandwidth challenges don’t make it a good option for real-time gameplay since the server will get swamped.
“Games are free to choose any network topology for their gameplay data” … as long as they don’t use dedicated servers or any central service. I’m not saying everything stated is completely accurate, but networking with XNA for XBox has a LOT of important limitations, and if you’ve made a networked game yourself you’d know those limits.
Hmm, should I put more faith in the opinion of someone who’s read about XBLIG multiplayer on microsoft.com or several people who have actually done it themselves?
I claim shenanigans. I think Kairi posted this with the hopes of getting more traffic to her site…
*ducks and runs*
She does like trolling for views. 😛
Was that really necessary?
Son, I’m not sure what territory you’re getting into here…
Does one generally post comments on a blog with the expectation that the site’s owner will reveal their personal email and ISP?
On this point I have to agree with Sauced. It’s not really on to reveal that sort of information. In fact, we have a ‘confidential waste’ bin at work for exactly that sort of stuff. It definitely shouldn’t be waved around in public.
The E-mail Address he provided was INVALID.
Do you think a person of a race you’ve never seen before is not a person? It looks different from the emails you’ve seen, that doesn’t mean it’s invalid.
I tried sending one, it bounced. Send me an e-mail from that site. Just send one that says “verification.”
I’ve had plenty of personal attacks against other developers sent from that same IP, from that same college. Come on now, what are the odds that more than one asshole who uses a “fucking morons” or “fucking idiots” address that goes to that same college and fancies themselves an XNA expert?
Do you really think receiving an email from an address is proof of its validity? 😐
It probably bounced because many clients (not unlike yourself) abhor punycode domains.
To be quite honest I am behind the same NAT as three computer labs and this is literally the first day I’ve visited this site, not that I’ll be continuing to do so….though I am curious as to the nature of the other posts from my colleagues.
Assuming you are legit, I truly apologize. What kind of stuff have I been getting from your IP? Well, they typically make personal attacks against developers who comment here, calling people no-talents, saying they don’t know how to program shit, that their games suck, that they don’t know what they’re doing, and usually specifically target Tales from the Dev Side contributors. If you are legit, you have to admit my skepticism for yet another in a long string of uppity people going after XNA developers who use fake e-mails (or in your case, a very fake sounding e-mail). I actually thought I had already banned the IP address.
I…that is pretty funny actually. I am pretty sure I know who the culprit was and he just graduated, but in any case if you thought I was a troll why allow my comment to pass through the moderation queue and then post my info?
Also you may as well delete this whole thread because whatever wordpress plugin you’re using for comments is really dumb and made the whole thread into what appears to be top-level comments which will be confusing the hell out of your readers.
I…and you tried to raise a mob against me on twitter now?
Do you have any idea how to internet?
I told you you didn’t know what you were getting into…
I did NOT try to raise a mob against you on Twitter. You called out the writer of this piece and other XNA developers who commented on this article. I thought they might want to response. I mean, you did say, quote,
“So now that we’ve established that the claims about peer to peer approaches being enforced is bullshit, what portion of the article as a whole is patently false?”
So you called the writer of this article a liar. I only asked if he or anyone else cared to respond.
“Someone is calling @DiscordJames and all #xna developers who commented on his editorial liars,”
“some asshat”
These are pretty clearly torch & pitchfork words, particularly from someone with 500+ followers.
You did call @discordjames and other #XNA developers liars. I mean, you did.
Yes I suppose I did. And as to your yes-man, I am not painting myself the victim, just pointing out that there were a few more people informed of my asshattery than the author.
And I’m serious about the guy graduating. All you are doing right now is dumping more on the plate of our overworked sysadmin.
I’m not Kairi’s yes-man! I’m everyone’s yes-man! Freelance yessing at reasonable prices.
Just be warned that if you choose not to employ my yessing services, I might become a no-man. Look at what happened to poor old Rock Bottom.
Ooh what are your rates?
Cheese and/or pie to roughly 75% of the volume of my head twice weekly.
I think I can manage that. What’s your PiePal?
Okay, THAT was funny.
Ok, I still think that exposing your location in public wasn’t on, but stop playing the victim. You deliberately baited someone who you know has a lot of followers and has a reputation for not taking any shit. You’re not fooling anyone by manufacturing your own victimhood.
He just graduated between April 28 and today? Because that’s when I last got a rambling, personal-attacking thing against Adam Spragg for his Tales from the Dev Side from the same IP address.
I posted yours because it seemed like a valid question. Afterwards I saw the IP and was like “oh, this one looks familiar.”
Anyway, you have my apologies. I contacted your school’s general inquiry line to ask if things unlike posts you made, stuff from the previous Tales articles, are an appropriate use of the school’s faculties. They said no and asked that I forward all the stuff received from their IP address to them so they can take action on the student or students involved.
Receiving an email will prove it’s not fake, so yes.
Someone better become internet-famous out of all this.
Was the idea that your commentary would stand unchallenged and that would be enough to refute James’s editorial? I believe my answer was balanced. I pointed out that games have long since hosted “servers” within one of the clients (usually the one that clicks “Create Game”) and I posted the difficulties on making that work in general and the doubling of those difficulties on XBLIG.
It’s better to have the reasoned discussion than leave James’s editorial unchallenged but for some reason after that it just turned into name calling and non-sequitur. Oh well…
I hope this wasn’t directed at me, because the E-mail I got said this was directed straight at me. I’m guessing this is at Sauced. Oh well, Fucking word press.
I like the whole apologizing to me here and continuing the circlejerk on twitter thing. I can see why you were trolled previously…maybe I should start filling the shoes you’ve set out for me here.
Nah, I’ll save you the time. Chris Gomez, James, etc, they tried to explain stuff to you. You continued to play the victim card. I’ve gotten at least 10 things from your IP, all with e-mails that start with stuff like “FuckingIdiots” “MikeRotch” “StupidFuckers” etc. I’m just going to wash my hands of it and remove that IP’s posting. I wouldn’t want to cause any extra problems for your school’s system’s administrator.
The problem with being so vindictive is that eventually you run into another vindictive person.
Sounds like a threat to me. I’ll be forwarding that one to your overworked system administrator.
Just like “what portion of the article as a whole is patently false” sounds like me calling someone a liar? Give me a little credit here, I was calling him full of shit! Come back to reality. You’ll even see that my domain is real.
Here’s a question for you: instead of going the “bullshit” in the comments route, why didn’t you contact me and offer to do a counter-point Tales from the Dev Side? Someone pointed out to me that you posted your point much more elegantly in the NeoGaf forum. Tales from the Dev Side is completely open to everyone. Instead of being an ass about it, you could have done your own Tales and opened up a legitimate debate, and maybe people would have had a chance to learn from each other on it?
I admit, I was a bit of a bitch, and you’ll forgive me for that considering I’ve had exactly 10 shitty trolling comments from your exact IP address since I started Tales from the Dev Side months back, all directed at other developers, none directed at me. What are the fucking odds of that? Assuming you are legit, and I have my doubts (and can you honestly blame me?), why go the route you did?
Why do you think the neogaf person is me? I’d never visited that forum until I saw the tweet. Different developers can see the same tripe and react the same way…all it takes is some formal networking training to see the gaps in the article’s rhetoric.
And I would never *ever* contribute to this blog. This discussion is exemplary of why.
I don’t blame you for making the assumption that I am the same recurring troll but I’d advise against making it again; it is far from unheard of for people with similar viewpoints to end up in the same computer lab, taking the same educational program….plus if I come back to harass your dumb blog it sure as hell won’t be from this IP again. I do blame you for how you handled it. The internet is a wild place and you act like this is your first time being exposed to someone with a dissenting opinion. And unless someone is expressly attacking your infrastructure, releasing their personal information to the public is absolutely uncalled for.
Now if you’ll excuse me, I have a colleague to pat on the shoulder.
Fill your boots. As I said, my first visit to this site was today. My domain will verify my email for you.
It is not the first visit from your IP. It is the 5th visit this year, from the same IP address, all with e-mails such as “StupidFuckers” “FuckingIdiots” FuckingRetards” etc. Your first post here today was to call James Petruzzi a liar. Enough.
Pingback: The World Really Isn’t Flat: Xbox Live Indie Games & Pricing « Indie Gamer Chick
Whats code 3? I cant play.
Pingback: Tales from the Dev Side: What Xbox Live Indie Games Have Meant to Me « Indie Gamer Chick
Pingback: Arcade Of Neon Post Mortem « Ivatrix
Pingback: Developer Interview: James Petruzzi – Developer of Chasm « Indie Gamer Chick
Pingback: Sportsfriends | Indie Gamer Chick