Chris Butcher from Bungie gave this presentation. This was talking about how matchmaking works in H2/H3 and differences (goods and bads) of both.
This was a pretty technical talk about the internals of the matchmaking process. Chris started by talking about why this is needed. The idea of user being matched in games that will be fun (not too easy or hard) with some way to hold the user and keep them playing.
The problem with H2 matchmaking was that is was based heavily on skill. The cheaters who had figured out ways to break the system created bad experiences for typical users.
With H3, the team worked with Microsoft (Research) to use the TrueSkill and integrate this into their matchmaking to make this process seamless and transparent to users. This is a pretty complex system based on a bayasien algorithm to compute the players real skill. This combined with some somewhat complex networking code pulls off the matchmaking we are now using with H3. Chris presented results with > 80% of all Halo users playing over 100 multiplayer games. This is a pretty substantial improvement over H2.
Problems with the new system are the complexity can confuse users (as they don't get to see the under the cover working going on, nor would most understand it).
I will post the slides when available (Feb 25th).
Thursday, February 21, 2008
The profile of a Great Software Tester
This was hosted by Anibal Sousa, a Microsoft XNA manager (and Lead). He is responsible for testing XBox Live and components contained therein. I am trying to get an electronic copy of the presentation he showed.
Anibal has a very good type of analysis used to determine if a person fits as a good software tester. The attachment I will post will show this better. I will post an update when I get this.
Anibal has a very good type of analysis used to determine if a person fits as a good software tester. The attachment I will post will show this better. I will post an update when I get this.
Technical Issues in Tools Development (Roundtable Discussion)
John Walker hosted this session.
Topics:
Topics:
- Using reflection to help build GUI for tools
- 3rd Party tools / components used to build tools
- C# and managed code for tool building
Reflection with C++ and C is a bit harder to pull off (use header files) than something like C# or Java. This limits this approach for dynamic generation of gui based tools and plugins for IDEs.
Some of the studios still using C++ or C for tools development were commenting that technical artists hate (yes I said hate) most of the grids and property setters exposed by tools. Most of the time this is because artists (creative type) are looking for color pickers and such (nice gui's) and developers are more analytical (just numeric values will do). The tools typically created by tools developers fit better with developers.
Possible ways to fix this were discussed. One would be to adopt something like MVC pattern and expose different views based on user.
With regards to 3rd party tools, artists again are looking for more WYSIWYG interfaces, instead of the lower level interfaces they are given. The idea of creating debug versions of data structures as well as executables came up. The problem here is when problems only show in the release build (data structures) and are ok in debug build.
Bug databases are crucial and automation to fill these without intervention (or light intervention) from artists are an absolute requirement. Artists typically will just quit using or find workarounds if given broken tools.
If using managed code, Sony Online mentioned they were using Cruise Control .Net but does not have it fully working yet (automate builds done but not functional tests).
Many studios are adapting Agile software development tactics (like daily calls about projects / issues).
Automated logging came up, with log4net pushed as a very good tool.
Maybe 60% of the studios in attendance (including Sony Online, Bioware, Pandemic, Microsoft Games Studios, 2K, EA) are currently using C# and managed code to build tool sets (at some level).
The ones still using C or C++ were doing so for richer data when crashes happened. Also, these studios were happy with what C# could do, but typically they have to use what is in place, with not alot of time to rewrite everything with a new language.
The idea of standardizing on languages (scripting, tools, engine) was discussed. John pointed out that its almost obsurd to try this. Developers use what they are familar with to get the job done. Whether is Ruby, Java, .Net, C, C++, Lua, Perl or whatever else. The one key point was not to be writing your own scripting engines, which is where some studios went. This becomes more of a computer science project than a functional piece of software. Standardization on a variety of languages (common used, non-proprietary) is required. Key point, make all tools dump data in common format (XML)! Embrace the chaos, don't try to eliminate!
Technical Consulting Engineer, Intel C++ Compilers (Sponsored by Intel)
The speaker was a no show, so nothing here. :(
Wednesday, February 20, 2008
Running Halo3 without a Hard Drive:Presentation by Matt Noguchi
- Current Next Gen Games are IO bound.
- DVD drive supports about 12MB/s transfer rate
The key item impressed by Matt was to minimize seeks. When using hdd, the problem is much less pronounced, but with systems that might not have hdd, the system must work with at least just DVD drive.
Break the levels down to required and optional resources.
- Required resources -> blocking to load/synchronous
- Optional resources -> non-blocking to load / asynchronous
Sound assets are huge issue (level 5 in H3 has 566MB of sound assets alone)
- Cannot stream sound from DVD (only HDD)
- Solution is to cut out AI dialogue when on DVD only (limited experience)
- With HDD, stream everything (speed much less issue)
Break up levels into zone sets with transitional volumes created by designers. Trigger volumes will (pre-cache) assets required as need (and evict non-required ones). Bungie had to limit objects used in each zone set (to keep under mem limit of ~334.8MB).
Next problems, thread contention (game thread/render thread). Solution was to provide a further abstraction from resources as the streaming IO is loading/evicting resources (use another cache).
Last optimization was layout of items on disk. Global or shared items (used in most levels) should be written to DVD at same location to allow sequential IO (much faster). All games assets in H3 totalled 15GB, but after optimization and culling were under 7GB.
Monday, February 18, 2008
Tuesday, February 12, 2008
GDC 2008 Agenda
Subscribe to:
Posts (Atom)