Diablo 3 Thoughts
by Brian Wilson · in General Discussion · 06/28/2008 (2:15 pm) · 10 replies
So D3 is official news. For those of you who haven't seen it yet, head over to www.diablo3.com and at least grab the gameplay trailer. The Cinematic and Artwork trailers are well worth a look as well.
So, what does this new developement mean for the Indie scene? Granted the cutting edge technologies and massive amounts of content that high-budget studios crank out have been generally avoided by the indie scene. But the indies have been able to go after many of those high-budget projects by finding surogates to fill the financial gaps. The best example I can think of is Fate.
Here we were, just a couple of years past the release of Diablo 2, which, graphically speaking, was technically behind the curve by producing a 2D title in a 3D market. But in what D2 lacked in graphics technology excelled in shear content. The Fate crew certainly new that they couldn't match the cinematic and content heavy efforts that Diablo 2 required, but they made up for it by using many of the elements that made Diablo 1 and its generation of clones so successful. Fate heavily borrowed on the "bottomless dungeon" model, random dungeon generation, and random item creation. And don't forget, that this indie title brought us something that Blizzard did not, a 3D engine.
Now, I know that the fate of the indie scene is not to create clones of blockbuster titles. That is not where I'm going here. What I'm curries about is the innovations, or realizations of proven tech that exists in what is known about D3 that could possible be produced effectively by the indie world, and more importantly, using TGE/TGEA engines.
Most of my time toying with the GG products over the past couple of years has been primarily in TGB. So I'm still technically a TGE/A newbie. Moreso with TGEA than TGE.
So, what, using D3 as an influence and inspiration for tech, can we do with TGE/A?
Destructable Environments
There are countless threads where this topic has been brought up over the years. And yes, many of implementated it. But with limited functionallty. Be it a the classic breakable barrel, or a simple destructable building. But as seen in the D3 trailer, about 20% of any given space contains destructable environment, be it furniture, shelves, banisters, walls. It seems to permiate throughout the environments, making them more part of the game vs. a pretty, yet very static backdrop.
Challenge: Is the level of destructability in D3 going to be possible with TGE/A? Is tracking that many objects, handling the collision and physics even remotely efficient with the engine?
AI
There's no doubt that D3 is taking AI and scripted events to the next level (in the context of the franchise). I don't think there's deep AI, but there is definitely dynamic AI.
Challenge: How effective are the AI implementations currently out there using the TGE/A engines? Wouldn't an reasonable amount of AI, especially when it involves 50+ monsters on screen, need to be coded in C++ and compiled to provide proper performance?
Scripted Events
I'm seeing quite a bit of scripted events that like they could be very cleaverly encapsulated into an object. Allowing for haphazard placement of very dynamic events without crazy amounts of triggering. It really does look like these scripted events are drag-and-drop.
Hordes
Hack-n-slash looks to be alive and well D3, and that's delivered via throngs of mobs to beat on.
Challenge: I know when I fire up TGE, and start spawning buggies to tumble down the side of a mountain, I start seeing bugs and performance hits at around 20 or so buggies. Certainly TGE is stronger than this. Granted that 20 vehicles = 100 physics objects. But that's without evironment content. Where is the bottleneck here? The physics? Otherwise how is a large scale RTS or Hack-n-Slash become feasible with TGE/A?
...to be continued...
So, what does this new developement mean for the Indie scene? Granted the cutting edge technologies and massive amounts of content that high-budget studios crank out have been generally avoided by the indie scene. But the indies have been able to go after many of those high-budget projects by finding surogates to fill the financial gaps. The best example I can think of is Fate.
Here we were, just a couple of years past the release of Diablo 2, which, graphically speaking, was technically behind the curve by producing a 2D title in a 3D market. But in what D2 lacked in graphics technology excelled in shear content. The Fate crew certainly new that they couldn't match the cinematic and content heavy efforts that Diablo 2 required, but they made up for it by using many of the elements that made Diablo 1 and its generation of clones so successful. Fate heavily borrowed on the "bottomless dungeon" model, random dungeon generation, and random item creation. And don't forget, that this indie title brought us something that Blizzard did not, a 3D engine.
Now, I know that the fate of the indie scene is not to create clones of blockbuster titles. That is not where I'm going here. What I'm curries about is the innovations, or realizations of proven tech that exists in what is known about D3 that could possible be produced effectively by the indie world, and more importantly, using TGE/TGEA engines.
Most of my time toying with the GG products over the past couple of years has been primarily in TGB. So I'm still technically a TGE/A newbie. Moreso with TGEA than TGE.
So, what, using D3 as an influence and inspiration for tech, can we do with TGE/A?
Destructable Environments
There are countless threads where this topic has been brought up over the years. And yes, many of implementated it. But with limited functionallty. Be it a the classic breakable barrel, or a simple destructable building. But as seen in the D3 trailer, about 20% of any given space contains destructable environment, be it furniture, shelves, banisters, walls. It seems to permiate throughout the environments, making them more part of the game vs. a pretty, yet very static backdrop.
Challenge: Is the level of destructability in D3 going to be possible with TGE/A? Is tracking that many objects, handling the collision and physics even remotely efficient with the engine?
AI
There's no doubt that D3 is taking AI and scripted events to the next level (in the context of the franchise). I don't think there's deep AI, but there is definitely dynamic AI.
Challenge: How effective are the AI implementations currently out there using the TGE/A engines? Wouldn't an reasonable amount of AI, especially when it involves 50+ monsters on screen, need to be coded in C++ and compiled to provide proper performance?
Scripted Events
I'm seeing quite a bit of scripted events that like they could be very cleaverly encapsulated into an object. Allowing for haphazard placement of very dynamic events without crazy amounts of triggering. It really does look like these scripted events are drag-and-drop.
Hordes
Hack-n-slash looks to be alive and well D3, and that's delivered via throngs of mobs to beat on.
Challenge: I know when I fire up TGE, and start spawning buggies to tumble down the side of a mountain, I start seeing bugs and performance hits at around 20 or so buggies. Certainly TGE is stronger than this. Granted that 20 vehicles = 100 physics objects. But that's without evironment content. Where is the bottleneck here? The physics? Otherwise how is a large scale RTS or Hack-n-Slash become feasible with TGE/A?
...to be continued...
#2
06/28/2008 (2:24 pm)
Well besides the fact that I will most definitely be buying this game, I have to say I was really impressed by the video on it. I am curious just how TGEA stacks up against their engine. 
#3
Diablo III is going to be delivered in a brand new, "real-physics" 3D engine developed by Blizzard.
That was taken from RPS, those guys are LIVE covering the Blizzard World Wide Invitational in Paris (where the D3 has been announced actually.)
I dont know exactly what that means. Blizzard is using Havok for Starcraft 2, what could make us think about the same physics engine in D3, using the licencing methods that Havok impulses for middleware integration. Also the game apparently has been under development for about 4 years now, what leaves doubts about why they would duplicate work working on different engines...
Maybe the simple fact is that they can. (AND that they got very good results till now...)
06/28/2008 (3:47 pm)
A little more about Physics. Diablo III is going to be delivered in a brand new, "real-physics" 3D engine developed by Blizzard.
That was taken from RPS, those guys are LIVE covering the Blizzard World Wide Invitational in Paris (where the D3 has been announced actually.)
I dont know exactly what that means. Blizzard is using Havok for Starcraft 2, what could make us think about the same physics engine in D3, using the licencing methods that Havok impulses for middleware integration. Also the game apparently has been under development for about 4 years now, what leaves doubts about why they would duplicate work working on different engines...
Maybe the simple fact is that they can. (AND that they got very good results till now...)
#4
On the video, which actually didn't seem to be much on the tech side that was extremely new or innovative (and Diablo, or most things our of Blizzard, has never really craved to be innovative, but they seem to have, once again, nailed the coolness factor of the gameplay). The destructible environments seemed limited in the amount of destruction and the limits of the destruction. While it was cool to see it happen in realtime, I do not know if it had to be or if it had to be that way. Being dark and at a distance helps with the illusion if they are not really full-destructible environments (see Red Faction or some of the interesting Alone in the Dark fire trailers for some of the extremes in this area) but gameplay-enhancing areas of environmental destruction. While it can be fun to show off a couple of bookshelves and walls crashing down (and crashing them down yourself the first time you play), solidly placing them where they enhance gameplay and balance the odds is an even better idea (IMO). It is difficult to tell whether some walls are more sturdy than others (static, non-destructible vs. dynamic or pseudo-dynamic). That'll probably be a question that has to wait until more gameplay videos are released.
The pieces of debris and enemies fade once destroyed. Also, once the enemy dies and is effectively taken out of the gameplay context, it seems that the client could take care of any physics without transmitting it to the network. In fact each client could have the bones fall differently and end up in a different position and it wouldn't really matter. They are not a threat and will fade away soon enough. I do not think that true ragdolls are needed. Animated ragdolls like Chris Calef's pack would suffice since the object has nothing to do with "oh cool, they falled down" and knockbacks and such are common animations used in these games. When they die and fade, most likely the player will be on to new frontiers before they notice that there are ten death animations. Also, on the idea of blowback, if the blowback is deterministic, then the actual animation can be resolved clientside. Enemy moves back x number of units if hit from this spell at this distance. Let the client resolve the animations. In a horde, the collisions can be pretty huge, but nothing compared to having to network them.
The levels themselves are examples of EXCELLENT art direction. You could create the main levels demoed with triggered wall destruction as needed in TGE/A with scripting alone. Creating the water surfaces, and assuming they react to footsteps, would be a bit more difficult, though with a shader, I'm not sure how much more difficult. Otherwise, excellent texturing and animation work should rule the day there. You would probably need to rework the lighting system somewhat in the C++ code to get some of the lighting effects. while you could heavily use and abuse particle effects, I think that it would require some C++ changes to get the weapon effects and magic effects right; just like AFX has some excellent C++ code enhancements.
I believe that the number of animations necessary would need to be upped like was done with Chris Calef's ragdoll pack. It upped the base number of animations per model, and required C++ changes.
I would say that to create an environment in an engine built from the ground-up around the design, you will definitely need to do some C++ heavy lifting, but you can quite easily do some major prototyping to see where that heavy lifting needs to occur. If you are concentrating on artwork, I would recommend starting there. Create a very basic "level" of interior and exterior artwork. It doesn't have to be randomly generated, etc. Just work with a high-art concept and run with it. See which parts need work, which parts need help. Off the top of my head, I'm thinking that 1) lighting and 2) shader programming will be the largest part of the art project. I'm sure there will be a ton more as you prototype, but those are the two the jump at me from an art perspective.
I would not initially spend too much time on combat physics for this side of it. Instead, make the richest environment your team can make. Some of the interesting things you will encounter are:
- creating modifiable collision meshes. Notice that while the enemies in the opening can climb up walls and over the bridge, etc and the bones can fall "off" it, the player is restricted to the bridge. This is good gameplay at work. When dealing with fighting on precipices, avoid cheap death due to control issues at all costs. But you have to calculate what can cross a mesh (and how meshes change if a section of bridge collapses), etc. In TGE/A, I would recommend looking at how doors change their collision meshes in the resources. If you are using Polysoup collision, then you may be able to create collision polies with alpha'd textures (haven't tried, so I don't know). It may lead to lighting issues, however. I know it would with DIF's and NULL textures or collision blocks as the lightmap is generated via the collision mask.
I can't wait to play it. Looks like a rip-roarin' good time!
06/28/2008 (3:58 pm)
Well, the engine was most likely built from the ground-up or near it to directly take advantage of the design. A lot of houses do that, especially when there is a massive advance in tech from one engine to the next or the gameplay mechanics (say Warcraft 3/WoW/StarCraft 2) do not match the technical needs of an action-rpg.On the video, which actually didn't seem to be much on the tech side that was extremely new or innovative (and Diablo, or most things our of Blizzard, has never really craved to be innovative, but they seem to have, once again, nailed the coolness factor of the gameplay). The destructible environments seemed limited in the amount of destruction and the limits of the destruction. While it was cool to see it happen in realtime, I do not know if it had to be or if it had to be that way. Being dark and at a distance helps with the illusion if they are not really full-destructible environments (see Red Faction or some of the interesting Alone in the Dark fire trailers for some of the extremes in this area) but gameplay-enhancing areas of environmental destruction. While it can be fun to show off a couple of bookshelves and walls crashing down (and crashing them down yourself the first time you play), solidly placing them where they enhance gameplay and balance the odds is an even better idea (IMO). It is difficult to tell whether some walls are more sturdy than others (static, non-destructible vs. dynamic or pseudo-dynamic). That'll probably be a question that has to wait until more gameplay videos are released.
The pieces of debris and enemies fade once destroyed. Also, once the enemy dies and is effectively taken out of the gameplay context, it seems that the client could take care of any physics without transmitting it to the network. In fact each client could have the bones fall differently and end up in a different position and it wouldn't really matter. They are not a threat and will fade away soon enough. I do not think that true ragdolls are needed. Animated ragdolls like Chris Calef's pack would suffice since the object has nothing to do with "oh cool, they falled down" and knockbacks and such are common animations used in these games. When they die and fade, most likely the player will be on to new frontiers before they notice that there are ten death animations. Also, on the idea of blowback, if the blowback is deterministic, then the actual animation can be resolved clientside. Enemy moves back x number of units if hit from this spell at this distance. Let the client resolve the animations. In a horde, the collisions can be pretty huge, but nothing compared to having to network them.
The levels themselves are examples of EXCELLENT art direction. You could create the main levels demoed with triggered wall destruction as needed in TGE/A with scripting alone. Creating the water surfaces, and assuming they react to footsteps, would be a bit more difficult, though with a shader, I'm not sure how much more difficult. Otherwise, excellent texturing and animation work should rule the day there. You would probably need to rework the lighting system somewhat in the C++ code to get some of the lighting effects. while you could heavily use and abuse particle effects, I think that it would require some C++ changes to get the weapon effects and magic effects right; just like AFX has some excellent C++ code enhancements.
I believe that the number of animations necessary would need to be upped like was done with Chris Calef's ragdoll pack. It upped the base number of animations per model, and required C++ changes.
I would say that to create an environment in an engine built from the ground-up around the design, you will definitely need to do some C++ heavy lifting, but you can quite easily do some major prototyping to see where that heavy lifting needs to occur. If you are concentrating on artwork, I would recommend starting there. Create a very basic "level" of interior and exterior artwork. It doesn't have to be randomly generated, etc. Just work with a high-art concept and run with it. See which parts need work, which parts need help. Off the top of my head, I'm thinking that 1) lighting and 2) shader programming will be the largest part of the art project. I'm sure there will be a ton more as you prototype, but those are the two the jump at me from an art perspective.
I would not initially spend too much time on combat physics for this side of it. Instead, make the richest environment your team can make. Some of the interesting things you will encounter are:
- creating modifiable collision meshes. Notice that while the enemies in the opening can climb up walls and over the bridge, etc and the bones can fall "off" it, the player is restricted to the bridge. This is good gameplay at work. When dealing with fighting on precipices, avoid cheap death due to control issues at all costs. But you have to calculate what can cross a mesh (and how meshes change if a section of bridge collapses), etc. In TGE/A, I would recommend looking at how doors change their collision meshes in the resources. If you are using Polysoup collision, then you may be able to create collision polies with alpha'd textures (haven't tried, so I don't know). It may lead to lighting issues, however. I know it would with DIF's and NULL textures or collision blocks as the lightmap is generated via the collision mask.
I can't wait to play it. Looks like a rip-roarin' good time!
#5
It notes on the website that it is "all powered by the Havoc physics system."
EDIT: Most likely, though, they have a full-source license and have majorly refactored it around the gameplay just like Valve did for HL2.
Very cool. To implement the cloth dynamics and such, you would need to do some C++ heavy lifting as well.
06/28/2008 (4:17 pm)
I'm not well-versed with audio, but hopefully the new audio subsystem in TGEA will be better than the OpenAL layer, which was often an issue. I'm not sure exactly why it would need to be tied to the physics system, however, but it could make for some nice fx if you bowl over a hundred skeletons.It notes on the website that it is "all powered by the Havoc physics system."
EDIT: Most likely, though, they have a full-source license and have majorly refactored it around the gameplay just like Valve did for HL2.
Very cool. To implement the cloth dynamics and such, you would need to do some C++ heavy lifting as well.
#6
I have been here for the last 5 months reading nearly every post and seeing where the Devs now stand with the current engine technology.
What I see is Holes in the developement of Indie Games such as:
Cash Flow, We are Indie developers because we don't have unlimited cash.
Experience, We didn't write the Engine code so we need to wade through Documentation to fill knowledge gaps.
Teams, We are usually a Team of One with a game concept that first we need to "sell" the pitch to community members to recruit, often unpaid, help to complete a project.
Also when seeking Self Help through the Search of TDN we are often met with an error page.
Now maybe this post seems a little synical but really is meant for perspective.
I have huge amounts of faith and trust in the entire community from the beginner that started yesterday .. all the way to the Dev thats been with GG since Birth ( or since dirt was invented, which ever came first ).
I know this community of people could pull together to make such a game as Q3 with all the bells and whistles...Will that ever happen? probably not... But the Talent is here, at GarageGames.
SO, while I really enjoy this sort of Post about Next Generation Games, We need to stay focused on our current projects so that we don't fall into the same rut.. Play a Game we love.. find something we wish we could change.. and then Remember we have the engine on the hard drive and if we didn't waste the last 3 years in some other game, we might have finished our own.
Anyway.. Thank you for this Post about Q3 =)
06/28/2008 (6:29 pm)
Though I enjoyed reading this Post thus far, I can't help but to read each paragraph and relate that to Torque usage. I have been here for the last 5 months reading nearly every post and seeing where the Devs now stand with the current engine technology.
What I see is Holes in the developement of Indie Games such as:
Cash Flow, We are Indie developers because we don't have unlimited cash.
Experience, We didn't write the Engine code so we need to wade through Documentation to fill knowledge gaps.
Teams, We are usually a Team of One with a game concept that first we need to "sell" the pitch to community members to recruit, often unpaid, help to complete a project.
Also when seeking Self Help through the Search of TDN we are often met with an error page.
Now maybe this post seems a little synical but really is meant for perspective.
I have huge amounts of faith and trust in the entire community from the beginner that started yesterday .. all the way to the Dev thats been with GG since Birth ( or since dirt was invented, which ever came first ).
I know this community of people could pull together to make such a game as Q3 with all the bells and whistles...Will that ever happen? probably not... But the Talent is here, at GarageGames.
SO, while I really enjoy this sort of Post about Next Generation Games, We need to stay focused on our current projects so that we don't fall into the same rut.. Play a Game we love.. find something we wish we could change.. and then Remember we have the engine on the hard drive and if we didn't waste the last 3 years in some other game, we might have finished our own.
Anyway.. Thank you for this Post about Q3 =)
#7
My thoughts as it relates to torque:
The graphics we have in tgea. Someone expert enough with shaders could make that same water.
An expert modeler could construct the buildings, and an expert in environmental effects and terrain could make the world itself. (I say expert becouse those models are awesome) The physics are nice, but not totally necessary for the game play. As David stated, preCanned animations could take care of the majority of it.
TGEa combined with AFX could handle all of it. (I'd be willing to bet)
I am impressed with how that game has come along. It's looking quite cool.
06/28/2008 (6:38 pm)
Wow. That game has come a very long way since D1. (the only one in the series I've played, and have yet to win/complete)My thoughts as it relates to torque:
The graphics we have in tgea. Someone expert enough with shaders could make that same water.
An expert modeler could construct the buildings, and an expert in environmental effects and terrain could make the world itself. (I say expert becouse those models are awesome) The physics are nice, but not totally necessary for the game play. As David stated, preCanned animations could take care of the majority of it.
TGEa combined with AFX could handle all of it. (I'd be willing to bet)
I am impressed with how that game has come along. It's looking quite cool.
#8
They are actually using FMOD for most of their games produced today, and FMOD has their virtual sound system which lets you play as many (within hardware constraints, of course) channels as you wish, but only the most important ones play. If a non-important sound suddenly becomes important, it will swap itself with the least important sound, and will once again be hearable.
06/29/2008 (3:35 am)
Quote:
Sound
When you have that many objects banging around and that many monsters taking damage, it would seem that the sound engine can have quite a large number of sounds running through it at any given time.
They are actually using FMOD for most of their games produced today, and FMOD has their virtual sound system which lets you play as many (within hardware constraints, of course) channels as you wish, but only the most important ones play. If a non-important sound suddenly becomes important, it will swap itself with the least important sound, and will once again be hearable.
#9
As related to TorqueX, I am not sure on how to get some of those things in the video to something passing just yet. We dont have a 3d Builder (yet!), and documentation is fairly nonexistent for TorqueX 3d , other than the demos. As an Indie, it looks rough, but D3 to me is something to strive for.
07/17/2008 (7:03 am)
Interesting thread. . D2 is by far my greatest gaming influence, and the approach (isometric action-rpg) is the direction I am taking with my game. Brian has an excellent summary, and while I was watching the videos on the site, I too couldnt help but wonder if TorqueX could be stretched that far. I know we dont have a havoc engine, and I have no illusions that whatever I end up making grapahically will pale to D3. Nonetheless, it is a good goal to have, and the journey is what is important to me. As related to TorqueX, I am not sure on how to get some of those things in the video to something passing just yet. We dont have a 3d Builder (yet!), and documentation is fairly nonexistent for TorqueX 3d , other than the demos. As an Indie, it looks rough, but D3 to me is something to strive for.
#10
07/17/2008 (7:46 am)
The AI portion is the most troublesome to me in terms of limiting factors. My own limited experience with AI also shows performance bottlenecking pretty low down the chain vs where I wanted to be. It probably needs to be approached via a new paradigm as opposed to plain out tickable objects in the same processing space as everything else, maybe multithreaded, in a library, or using an event/messaging system. 
Torque Owner Brian Wilson
The most obvious physics visible in D3 demo are the ragdoll physics and destructable environment physics.
Challenge: Again, is this a component best served in compiled C++ or an external physics engine strictly for performance reasons? Certainly a devistating blow that knocks backs and kills 30 zombis becomes computationally expensive when apply ragdoll to them. And demolishing 3 tables and a run of banisters into 50+ objects is just as complicated.
Environment Graphics
D3 has a lot of dynamic environment graphics ranging from scurrying rodents, to destructables, to light sources, to swinging chains, to mists and fog, to water pools.
Challenge: Is it realistic to try and put this much dynamic content into a TGE/A title with script alone? Or again, are we looking at engine modifications to better perform such functionality. Or is scripting really enough?
Sound
When you have that many objects banging around and that many monsters taking damage, it would seem that the sound engine can have quite a large number of sounds running through it at any given time.
Challenge: Is TGE/A limted by number of active sounds? Or can it handle as many as you can throw at it. Are the performance bottlenecks system specific, or are there rough spots that people have experenced? I've seen over the past few years where 3rd party engine designers have talked about audio and physics engines being tied closely together. It would seem that this type of functionality would be were such an implementation would come in handy.
If anyone has any other observations from the Demos, please feel free to add them in. Or for those of you who have already considered these challenges, please share your experences.