I enjoyed GameFest this year, but there seemed to be a lot more excitement last year. It may have just been that there were so many announcements last year and the entire DBP finalist and winners.
The big news announced was the fact that Microsoft is 'allowing' game creators to sell their games on Xbox LIVE Marketplace. I used quotes because if you want your game on Marketplace - it has to be sold. You will not be able to give your game away.
So at this point you can sell your game for either 200 points (about $2.50), 400 points (about $5.00) or 800 points (about $10.00). Microsoft takes at least 30% of the sales. Making 70% on a product in this type of distribution model is excellent. Additional fees (yet to be determined) will be deducted for transactions and similar things. If Microsoft puts your game on the 'Featured' page in the Marketplace then they will take an additional 10-30%. There is no details at this point regarding how games will be picked for this list. It will be based on some heuristics, but they are still flushing that out.
It is up to the developer as to which tier they want to sell their game in. There is one exception to this. If the game is over 50MB (compressed) then it cannot be sold for the lowest tier (200 points). It must be sold in the middle or high tiers. It is no problem for a game that is under 50MB to sell for more than 200 points. The maximum size a game can be (compressed) is 150MB.
Microsoft announced a new dashboard look and feel a couple of weeks ago during E3. This new look is to try and help with the enormous amount of content in the marketplace. Because of this new dashboard, when a game is created a new requirement is to also create 'Box Art', which is basically what it says. If your game was shipping in a box, what would the front cover of the box look like? There may be a requirement (will definitely be an option) to provide more information like 'Slideshows' which also fall in line with the dash's new look and feel.
I listened to a talk from Frank Savage, who has a new title of Architect. Frank's talk discussed a few things, but he mentioned 'Frank's 3rd Law' which states:
Optimize because you must not because you can!
So this falls right in line with the whole premise of performance that I go by. You have to measure. By measuring you can determine if your game (or application) is performing well enough to meet the goals of the project. So measure, measure, measure. Make notes on some code that may be a problem area if frame rates start to suffer, but don't just dive in and really optimize that code until there is actually a problem. Spend that time writing better game play, or AI or Physics or anything else that is needed for your game.
Shawn Hargreaves had two talks. One was regarding the Content Pipeline (Eli Tayrien also had a talk on the Content Pipeline) and the other was on Networking. As expected, both of Shawn's were very good. In the Content Pipeline talk, I learned about Opaque data which is data you can set in the modeling program that your Content Pipeline can read in and do something with it. For example, let's say you build out an entire 3D level in Maya or 3D Studio Max. You can put place holders in the level for Triggers for example. Those meshes can be assigned Opaque Data that the Content Pipeline can look for. When it finds a mesh that has that Opaque Data custom processing can be done. For the trigger, the code may remove the actual dummy mesh that was used and create a custom trigger that your game can understand. I used this method about 10 years ago when I worked on a train simulator. I didn't have a nice content pipeline to strip it out and had to do it at run time.
His networking talk was phenomenal. Between this talk and a few from the XBOX LIVE track that I attended I learned that the goal for a game is to not send any more than 8kb of data per second. It is extremely bad to send network data at the same rate as your frame rate. Sending 60 packets a second is not a good thing. In another talk they mentioned 15-20 packets per second was good. Something that may not be immediately obvious is the fact that 8kb is not just game data. It also includes the Xbox LIVE header information for the VDP packets (UDP with some encryption specific to Xbox LIVE). It also includes all the voice data. So if you have 16 players in a game and they all talk at the same time the 8kb is used up. While this is acceptable in the Lobby, it isn't during the game play as no game play data will be sent. So it is a good idea to limit who all hears each other. Some ways to limit this is by proximity in the game world. Only the players 'physically' close to each other can hear each other chat. For some games, perhaps a way to accomplish this is by only allowing teammates to chat. It was also mentioned that latency (the amount of time it takes for the player to actually receive the packet) is about 500 milliseconds (.5 seconds). This is pretty significant. So network prediction is really required. This involves passing enough information to take an educated guess of where the object will be by the next time the next packet arrives. A good example of this is on the creators club site in the Network Prediction sample.
Mitch Walker had a couple of talks as well. I ended up writing the most with his talks as he had a lot of bullets in his power points. He had a talk discussing what is new in 3.0. The second talk was about creating great community games. Both were very good. I enjoyed going to all of the XNA Game Studio sessions. The sessions were repeated the second day so I was able to hit a couple of other tracks. Well, I went to one other track beside the Xbox LIVE track. I attended two Casual Game sessions. Both discussed Silverlight. I enjoy working with Silverlight and was excited to see it being talked about.
Overall it was a very enjoyable conference. I had a good time and learned some new things. I met a couple of new people as well, so that is always good.
Good things are coming with XNA GS 3.0...
Happy Coding!
-Chad
bab391a1-3df0-4c8e-a885-228bc7582d2b|0|.0|96d5b379-7e1d-4dac-a6ba-1e50db561b04