Blizzard plans to announce all game systems before the beta goes live. We already know quite a bit, but Bashiok makes it sound like there's still a decent amount of information regarding in-game systems that has not been revealed. Earlier today, Bashiok commented on how the breakpoint "system" is going to work in D3.
Official Blizzard Quote:
Just for those who aren't aware, Diablo II animations were rendered at 25 frames per second. This is important because it meant that events could only occur on those 25 points in every second. When you start getting into the nitty gritty of faster attack and cast rates, 25 ticks per second to shave off time for actions to occur isn't nearly granular enough to account for a direct comparison between point increases and an actual result of removing a full frame. These are called break points. Essentially your attack rate increase points don't mean anything until you get enough to hit the next break point and remove an animation frame, which would actually result in a real effect on your actions.
I'll make two statements on break points:
Break points were an effect of the Diablo II engine, not a gameplay mechanic specifically designed into the game.
Even modern games run at specific tick rates, and Diablo III is no different. I'll only say it's more than 25.
With that information in mind, I asked how this will differ from Diablo II. A different rate for D3 could potentially mean either more ticks to hit the next breakpoint, or less ticks if there are more breakpoints spread throughout. The answer I received was...
Official Blizzard Quote:
It's all dependent on the curve.
Which makes complete sense, though still leaves this mechanic a little bit of a mystery, because we do not know how much weight each item's stat will give, nor do we know what exactly the curve may be. This mechanic will require a bit more math to figure out than D2's system did, but until we get more information on this, the formula will remain unknown.
Aside from some breakpoint information, Bashiok has recently reiterated how runestones (or runes) work. Essentially, each skill can be considered as the "vanilla" or "classic" version of the skill, which also includes at least one (usually two) rune(s) that does/do not change the core mechanic of the skill. However, all other runes will make some pretty big changes to the dynamics of skills. Some may be wondering, how viable could every potential skill/rune combination be?
Official Blizzard Quote:
Every skill has at least one rune that doesn't change the core mechanic of the skill. Usually two. We definitely think the base skills are viable and will be used, but it's going to be a base skill with a cost reduction rune or basic damage increase rune.
It's tough to really argue some of the concerns being made because it comes down to balance and making sure that a skill isn't worthless in its base form with a cost reduction rune, as compared to the same skill with a rune that changes the mechanic entirely. Ideally they'd be balanced in such a way that both could be options for different builds and play styles and one wouldn't become the 'only' way to rune a skill.
Those are the sometimes eternally elusive goals of game balance. Assuming highest rank runes that's ~550 skills, so I don't think anyone is fooling themselves by thinking the game will ever truly hit a perfect balance in every situation (and in some cases it's maybe better it doesn't), but it's something we're going to strive for.
For those who are wondering what that 550 number means on a per class basis, it boils down to: 550 / 5 runes / 5 classes = 22. This means that there is an average of ~22 skills per class. Now, keep in mind that this is just an approximation. I should also note that this does not include the passive skills, as they were moved to the trait system some time ago.
While we're on the subject of game systems and mechanics, Bashiok also discussed how gems will be dropping in the game. For those curious, gems a few levels over level five will be droppable. Anything above this level will need to be crafted, which eventually becomes a hefty number. However, something that I really want to point out is that he mentions a more robust trading system, which may make these high numbers easier to achieve:
Official Blizzard Quote:
But more importantly we expect a more robust trading system will make it much more feasible to sell off a ton of gems, earn that wealth, and then buy back into gems later when you want - and on the buyer side of that, if you have some gems and just need one more to upgrade, it will be quick and easy to go get one for a reasonable price.
A more robust trading system could mean quite a few things, one of which is a possible auction house. The auction house in WoW works great: I can throw stuff up on the AH, go to sleep, and make myself some money while being logged out. As we heard, gold will be the currency in Diablo III, making an auction house even more viable in-game. However, if this were to happen, I am curious to see how it would be implemented. Keep in mind, we are no longer in an MMO, so this is not just a giant world. Each game has it's own instance. Therefore, an auction house would need to be implemented in the Battle.net interface. However, I have no doubts that there will also be a personal trading system (as there was in Diablo II). So those of you that feel intimidated by the auction house concept have little or no cause for concern.
There is no way D3 would not have 60 ticks per seconds at least. I mean, its not like even 10 years ago, games could handle 100 tics a second. I still work with the Unreal Engine 1 (1998) and the engine handles ticks as 1/100th of a second.
If D3 would have any sort of issue because its running at 25 ticks per seconds, something is wrong.
There is no way D3 would not have 60 ticks per seconds at least. I mean, its not like even 10 years ago, games could handle 100 tics a second. I still work with the Unreal Engine 1 (1998) and the engine handles ticks as 1/100th of a second.
If D3 would have any sort of issue because its running at 25 ticks per seconds, something is wrong.
I don't think they were insinuating any issue with more ticks but instead confirming that it runs on a higher tick/second ratio.
To me it sounds like they're trying to say that they have thought about how things like faster attack and cast rates will affect animations and effects - and that's great. Where they weren't a "feature" of the D2 engine, they are now? Really, with a higher tick count we can probably expect to see more fluid transitions from various attack and caster speeds.
Or i'm insane and I read that the completely wrong way. *shrug*
The battle.net UI for StarCraft II chat, that's going to be quite similar to the one we'll use for Diablo III will probably have an anti-spam feature, as well as the easy to use report spam feature from WoW, Broc.
I'm sure we won't have too many issues with those. At least not as many as we had in Diablo 2 and LoD.
What i don't want to see, although in this kind of game it's pretty hard to do it as i see it, is the gold sellers that exist in almost any(not say all) online game that is P2P, but i guess DIII since it's not a usuall online game(not an MMO) those kind of guys won't be anywhere to be seen. Baaaah guess i think too much :geek: .
As unfortunate as it is I think it's a bit naive to think that Diablo 3 won't have gold sellers. They'll most definitely exist. Even though it's not an MMO as such, the gold & item market still is very similar.
It will exist. All we can hope for is that Blizzard will take heavy action to try to stop all the gold selling they can.
Edit: Oh and, yes on the spambot side I don't think that'll be such a big issue indeed. But there are other ways they can market their business, while you might not see it directly through spam/bots etc gold selling would make a big impact on the economy of the game.
Try "at least 1000 ticks/second" and the resulting "breakpoints hardly matter." We're likely to have a very smooth curve instead.
Does anyone have an idea of how many cycles per second modern game engines run at (not to be confused with frames per second)? I can't find any information on this whatsoever.
An auction house over battle.net would be nice. since its over battle.net, would you be able to access the auction house somehow through your profile while on another game, like SC2?
From what little I can find, 1000 is a laughable number, and probably grossly inefficient for anything logically required by any games.
While I'm not a game developer and I have never helped build or worked with a development engine I did take an Open GL class a few years ago while trying to get my degree. We never used the term 'ticks' so I'm not quite sure what that represents, but really, when we created animations, frames per second was the metric we used to coordinate and manage our animations.
Now things may obviously different but my understanding back then was that every game was basically rendered in a "loop".
Every time a frame was rendered *tons* of calculations were done by the system to determine everything from object positions from one frame to the next to color transitions, the addition or subtraction of objects, etc. As a part of that process game logic would be included too.
So a simple pong game might go through a process like:
Create and define court dimensions.
Create and define paddles.
Create and define ball.
Check for user input from paddle 1.
Calculate paddle 1's location based on user input.
Check for user input from paddle 2
Calculate paddle 2's position from user input;
calculate ball's location.
Determine if the ball has collided with another object.
If the ball has collided with a paddle: Calculate a new position based on previous position.
Determine if the ball has exceeded the boundary of the court.
If so: award a point based on ball's exit location and reset game.
Then, using all of the calculations above render the various elements at their calculated positions. Rinse, and repeat.
The crazy thing is that objects were rarely elements of their own. To make a person, example, you had several objects working together (Head, neck, upper arms, forearms, hand, fingers, abdomen, thighs, calves, feet) and the calculations were done based on their relative position to the other objects.
Now things may be drastically different these days but one thing is still clear: as a user we don't see any change on our screen until a frame is rendered. So it doesn't matter how much the objects are processed or change in the background until they are rendered to the screen. So 1000 "ticks" seems drastically high to me. Granted the higher "fps" the better animations and the more opportunity for those objects to change based on their environments and user interaction, but there's a point where the human eye can't even keep up with it.
Well, I don't think the concept of "ticks" is very different from frames per seconds.
I know that, using Unreal Engine 1 as an example because its the only one I know a bit, during a tick the program can do an incredible amount of things, like you said. It can runs thousands of things in parallel and update each of them in a single tick.
I'd guess that the "ticks" is like the time going forward on a clock. So when animations, or pretty much anything needs to change, the engine needs to call that change multiple time through a passage of time: each tick changing something.
Thats just how I always pictured it, anyway. Each tick the engine checks, updates and maintains all of its elements, maybe. That would be logical.
I'd really love to find an article on that or have someone knowledgeable to comment on the technicalities. The term "ticks" is probably not widely used, or something.
Well, I don't think the concept of "ticks" is very different from frames per seconds.
I know that, using Unreal Engine 1 as an example because its the only one I know a bit, during a tick the program can do an incredible amount of things, like you said. It can runs thousands of things in parallel and update each of them in a single tick.
I'd guess that the "ticks" is like the time going forward on a clock. So when animations, or pretty much anything needs to change, the engine needs to call that change multiple time through a passage of time: each tick changing something.
Thats just how I always pictured it, anyway. Each tick the engine checks, updates and maintains all of its elements, maybe. That would be logical.
I'd really love to find an article on that or have someone knowledgeable to comment on the technicalities. The term "ticks" is probably not widely used, or something.
Yeah, that's pretty much how we did it in that class. Granted games today are exponentially more complex then Pong, LOL. But i'm pretty sure, at their simplest form, they still run in the same way.
This actually makes me want to go back and take some classes like that again...
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
Official Blizzard Quote:
Just for those who aren't aware, Diablo II animations were rendered at 25 frames per second. This is important because it meant that events could only occur on those 25 points in every second. When you start getting into the nitty gritty of faster attack and cast rates, 25 ticks per second to shave off time for actions to occur isn't nearly granular enough to account for a direct comparison between point increases and an actual result of removing a full frame. These are called break points. Essentially your attack rate increase points don't mean anything until you get enough to hit the next break point and remove an animation frame, which would actually result in a real effect on your actions.
I'll make two statements on break points:
With that information in mind, I asked how this will differ from Diablo II. A different rate for D3 could potentially mean either more ticks to hit the next breakpoint, or less ticks if there are more breakpoints spread throughout. The answer I received was...
Official Blizzard Quote:
It's all dependent on the curve.
Which makes complete sense, though still leaves this mechanic a little bit of a mystery, because we do not know how much weight each item's stat will give, nor do we know what exactly the curve may be. This mechanic will require a bit more math to figure out than D2's system did, but until we get more information on this, the formula will remain unknown.
Aside from some breakpoint information, Bashiok has recently reiterated how runestones (or runes) work. Essentially, each skill can be considered as the "vanilla" or "classic" version of the skill, which also includes at least one (usually two) rune(s) that does/do not change the core mechanic of the skill. However, all other runes will make some pretty big changes to the dynamics of skills. Some may be wondering, how viable could every potential skill/rune combination be?
Official Blizzard Quote:
Every skill has at least one rune that doesn't change the core mechanic of the skill. Usually two. We definitely think the base skills are viable and will be used, but it's going to be a base skill with a cost reduction rune or basic damage increase rune.
It's tough to really argue some of the concerns being made because it comes down to balance and making sure that a skill isn't worthless in its base form with a cost reduction rune, as compared to the same skill with a rune that changes the mechanic entirely. Ideally they'd be balanced in such a way that both could be options for different builds and play styles and one wouldn't become the 'only' way to rune a skill.
Those are the sometimes eternally elusive goals of game balance. Assuming highest rank runes that's ~550 skills, so I don't think anyone is fooling themselves by thinking the game will ever truly hit a perfect balance in every situation (and in some cases it's maybe better it doesn't), but it's something we're going to strive for.
For those who are wondering what that 550 number means on a per class basis, it boils down to: 550 / 5 runes / 5 classes = 22. This means that there is an average of ~22 skills per class. Now, keep in mind that this is just an approximation. I should also note that this does not include the passive skills, as they were moved to the trait system some time ago.
While we're on the subject of game systems and mechanics, Bashiok also discussed how gems will be dropping in the game. For those curious, gems a few levels over level five will be droppable. Anything above this level will need to be crafted, which eventually becomes a hefty number. However, something that I really want to point out is that he mentions a more robust trading system, which may make these high numbers easier to achieve:
Official Blizzard Quote:
But more importantly we expect a more robust trading system will make it much more feasible to sell off a ton of gems, earn that wealth, and then buy back into gems later when you want - and on the buyer side of that, if you have some gems and just need one more to upgrade, it will be quick and easy to go get one for a reasonable price.
A more robust trading system could mean quite a few things, one of which is a possible auction house. The auction house in WoW works great: I can throw stuff up on the AH, go to sleep, and make myself some money while being logged out. As we heard, gold will be the currency in Diablo III, making an auction house even more viable in-game. However, if this were to happen, I am curious to see how it would be implemented. Keep in mind, we are no longer in an MMO, so this is not just a giant world. Each game has it's own instance. Therefore, an auction house would need to be implemented in the Battle.net interface. However, I have no doubts that there will also be a personal trading system (as there was in Diablo II). So those of you that feel intimidated by the auction house concept have little or no cause for concern.
Diablo III Analyst
SC2Mapster
If D3 would have any sort of issue because its running at 25 ticks per seconds, something is wrong.
I don't think they were insinuating any issue with more ticks but instead confirming that it runs on a higher tick/second ratio.
To me it sounds like they're trying to say that they have thought about how things like faster attack and cast rates will affect animations and effects - and that's great. Where they weren't a "feature" of the D2 engine, they are now? Really, with a higher tick count we can probably expect to see more fluid transitions from various attack and caster speeds.
Or i'm insane and I read that the completely wrong way. *shrug*
I'm sure we won't have too many issues with those. At least not as many as we had in Diablo 2 and LoD.
As unfortunate as it is I think it's a bit naive to think that Diablo 3 won't have gold sellers. They'll most definitely exist. Even though it's not an MMO as such, the gold & item market still is very similar.
It will exist. All we can hope for is that Blizzard will take heavy action to try to stop all the gold selling they can.
Edit: Oh and, yes on the spambot side I don't think that'll be such a big issue indeed. But there are other ways they can market their business, while you might not see it directly through spam/bots etc gold selling would make a big impact on the economy of the game.
Does anyone have an idea of how many cycles per second modern game engines run at (not to be confused with frames per second)? I can't find any information on this whatsoever.
P.S. Fellow lurker here - the Langolier
While I'm not a game developer and I have never helped build or worked with a development engine I did take an Open GL class a few years ago while trying to get my degree. We never used the term 'ticks' so I'm not quite sure what that represents, but really, when we created animations, frames per second was the metric we used to coordinate and manage our animations.
Now things may obviously different but my understanding back then was that every game was basically rendered in a "loop".
Every time a frame was rendered *tons* of calculations were done by the system to determine everything from object positions from one frame to the next to color transitions, the addition or subtraction of objects, etc. As a part of that process game logic would be included too.
So a simple pong game might go through a process like:
Create and define court dimensions.
Create and define paddles.
Create and define ball.
Check for user input from paddle 1.
Calculate paddle 1's location based on user input.
Check for user input from paddle 2
Calculate paddle 2's position from user input;
calculate ball's location.
Determine if the ball has collided with another object.
If the ball has collided with a paddle: Calculate a new position based on previous position.
Determine if the ball has exceeded the boundary of the court.
If so: award a point based on ball's exit location and reset game.
Then, using all of the calculations above render the various elements at their calculated positions. Rinse, and repeat.
The crazy thing is that objects were rarely elements of their own. To make a person, example, you had several objects working together (Head, neck, upper arms, forearms, hand, fingers, abdomen, thighs, calves, feet) and the calculations were done based on their relative position to the other objects.
Now things may be drastically different these days but one thing is still clear: as a user we don't see any change on our screen until a frame is rendered. So it doesn't matter how much the objects are processed or change in the background until they are rendered to the screen. So 1000 "ticks" seems drastically high to me. Granted the higher "fps" the better animations and the more opportunity for those objects to change based on their environments and user interaction, but there's a point where the human eye can't even keep up with it.
I know that, using Unreal Engine 1 as an example because its the only one I know a bit, during a tick the program can do an incredible amount of things, like you said. It can runs thousands of things in parallel and update each of them in a single tick.
I'd guess that the "ticks" is like the time going forward on a clock. So when animations, or pretty much anything needs to change, the engine needs to call that change multiple time through a passage of time: each tick changing something.
Thats just how I always pictured it, anyway. Each tick the engine checks, updates and maintains all of its elements, maybe. That would be logical.
I'd really love to find an article on that or have someone knowledgeable to comment on the technicalities. The term "ticks" is probably not widely used, or something.
Yeah, that's pretty much how we did it in that class. Granted games today are exponentially more complex then Pong, LOL. But i'm pretty sure, at their simplest form, they still run in the same way.
This actually makes me want to go back and take some classes like that again...