So, today was the first day of GCDC '08. In this post I am going to try and put some of the sessions I've gone through today.
First session: Agile Project Management in Game Development.
This session really did not go into anything I did not already know. All about Scrum, and how that works in practice. Some troubles that can occur while implementing it, but I think nothing really new for the way we work.
The second session was about multiplayer development best practices.
In particular about shooters. While mostly focusing on first person shooters and on both the design and management side of it, there were definitely some interesting and valid points made.
First of all: Better no multiplayer than poor multiplayer. Something I can wholeheartadly agree on. Especially in shooters. They passed out results of a study showing that good multiplayer sells 4 times better than bad multiplayer, and twice as good as no multiplayer, when taking into account highly rated titles.
Second: When doing multiplayer in a shooter, include both a clasic game type and a custom game type at the very least. This allows players to get used to the game in the clasic game type, and after that, shift the fun to your custom game type. The custom game type really draws people, and keeps them playing the game.
Third: Keep the teams in sync. If you are doing both multiplayer and singleplayer in seperate teams, ensure that the teams communicate often. Try to remove dependancies as much as possible, and for those that are still there, make an owner for those dependancies. This way you can prevent things from influencing the other game type in a bad way.
Then there were some design principles / best practices that I don't all remember. Here are the ones that I do: Ensure the player can reach the "hot spots" or "action zones" in a comfortable amount of time. Not so that you are instantly in the line of fire when you respawn, but also not that you have to walk an hour to get to the action. Give meaningful choices to players, such as multiple ways to the objective, place cover that they can use, etc.
Even losing can be fun in multiplayer. However, this requires good map design. If you start feeling that you are losing because of the terrain, or that you could not get the weapon you wanted, the game just gets more frustrating.
The third session I went to was about threading tools (by intel, so for windows/linux/macos mainly)
In this (slightly boring) session, some guys from intel showed off some tools that they've been developing. The first is an open-source library for to make threading easier. In this threading library it is relatively easy to make concurrent tasks out of even something as simple as a for loop. The library will then select the number of hardware threads to generate to finish the job as quickly as possible on the current processor. It also contains various useful classes for use with concurrency. For instance a task scheduler, a memory manager and wrappers for STL containers, to make these thread safe.
The second set of tools where threading and profiling analysers. These seemed very interresting, as they where able to show very detailed, and useful, data about the program.
The final tool they showed was their compiler, which they made specifically for creating very optimized code, and is for use next to the regular compilers (MS VC Compiler, gcc, etc.). With this compiler you can give both a minimum and a target platform (processor), so that the code can be as optimized for your target as possible. The compiler can create object files for most common compilers / linkers, and as thus can even be used to optimize only part of the entire code. Finally, the compiler has three passes of optimization: Normal optimization during the compling, post-compile optimization, and profile-based optimization. The latter seems a bit risky to my, but apparently allows the compiler to even inline virtual functions based on branch prediction.
I have evaluation versions of all of these, if you want to give them a spin.
The fourth session was about bringing the Lego brand into the digital space.
Truth to be told I went here because the other sessions at this time all sounded boring to me, but I was glad I went. While mostly a business related keynote, seeing how Lego went from a poor online presence, to what they have now, really is impressing. The key note about this keynote: If you have a brand, stay true to it's values, even when going into new forrays. And: Don't do something purely for marketing, but do it because it fits the brand that you have. They showed off a bit on what they did with Lego Universe, and I have to say it is looking pretty good. They took part of their customer group, and let them help build the digital world, partly using normal lego bricks.
The fith session I went to, today, was about shooter bots, and AI
This sessions was fun, and interresting. Though I guess mainly to show off an AI library, they did show off some neat AI stuff.
First of all, they showed the difference between node-based paths and mesh-based paths. The mesh-based paths allow for a much more freedom for the bots. Namely they are using parts of a defined space to walk around, rather than just a normal waypoint system. This allows bots to move past dynamic objects a lot more natural. He refered to a thesis called "Fixing Pathfinding Once and For All" by Paul Tozour where this is described in much more detail.
Next he went on about how to make the bot track the player more naturally. For this he used a technique which name I have forgotten, but the basis is this: give the player some "heat", which you let spread. Not in the sense that you take a look at what place is "the hottest" directly, but look at it more like this: If the player would give out heat, that heat would spread. So you take the last location where the bot saw the player, and reason with that.
With that out of the way, we need to move the bot to the correct location in a bit of a natural way. Basically you do this by giving preferences to locations. This is best displayed on a waypoint based system, but it is also possible in the mesh-based environment. Basically you give the bot a behavious by labeling points around him. You give each point a certain score, based off of several different conditions. For instance: The bot could be lazy, and wants to not move too far, then closer points have a higher score. However the bot also wants to move to a place where it can fire on the player, so anything outside of the line of sight to the player (or the "hot area" above) gets a null value. Then, the weapon the bot is currently wielding may have a certain range, based on that, the points in that range may get a higher value, and the points outside a lower one. There are many factors you can take into account, and this is just a small selection of them, but with this system, the way a bot moves can appear to be more intelligent.
After this, he explained about a simple AI learning sheme. Mainly on where to stand. I forgot the formula he had for it, but the idea is pretty simple. For a starter, take the system above, but we add a modifier of a danger level. Now we don't want the bots to never got back to a certain positions, so we have a degrading function. We remember it, but the danger level becomes lower over time. The higher the modifier for a certain area is, the lower the chance should be that the bot goes over this area. So, if the bot has been shot / killed in an area a number of times, it will try to take a different path, because the danger modifier will lower the chance the bot will take the path. This can also be used when the bots are working as a team, and share this data (when they are close enough), to modify the danger level.
Finally he showed off their AI control suite, that brings it all together. Which basically creates finite state machines for the bots, and adds a framework for AI knowledge, and the sharing thereof.
Then another keynote came up: The making of Gears of War 2
Michael Capps of Epic Games talked about Gears of War 2, and what it took to make a sequel. All in all some very nice points were raised during this keynote about how to approach a sequel to a game. He raised the problem about that sequels get higher expectations than first games do. The game will in the end always be compared to the original, and is always expected to exceed it, making development harder. The reduced development time for a sequel usually adds to the issues there.
The way they approached these issues was to look at the game they currently had, and take a look at what was there. They took a good number of areas of the game, and looked: What can be added here to add to the experience (but keep it in the right style), what can we do better here, and what do we need more of. In the areas where the game was weaker, these are usually easy to find, however the challange rises in finding these in the areas where the game was excelling in. Doing well in the areas where the game was good in, will (probably) end up being the most important. Whether he was right, we'll see in November, however I must say, the level he played looked absolutely awesome! (Yes, there was a live demo ;))
The last two sessions were not of much interest. At least not to me.
As such this is what I will leave you with for now. More tomorrow :)
- Sjoerd