Timeline for How to develop RPG Damage Formulas?
Current License: CC BY-SA 3.0
18 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 23, 2024 at 20:25 | comment | added | Questor | @NicolBolas But optimizing the math so that is simple enough for OP to understand what each of the knobs OP is turning makes it easier to balance the game for fun. | |
| Jul 2, 2011 at 7:53 | comment | added | Randolf Richardson | @Nicol Bolas: Then you've only seen one aspect of optimization, and I hope that you do get exposure to other types of optimizations at some point because there really is a lot to be gained. For one very simple example in ASM, one can shift all the bits to the right to multiply by 2 or 4 with less time. Another example would be to use multiplication before a loop starts instead of adding repeatedly within a loop (effectively reducing X number of calculations down to just one calculation) where the result isn't needed until afterward. There are countless ways that optimization is sensible. | |
| Jul 1, 2011 at 17:34 | comment | added | Nicol Bolas | @Randolf: I have seen very few useful optimizations that make code simpler. Most optimizations introduce complexity and obfuscation by forcing the code away from proper abstractions. And consequently, optimized code is often harder to debug. Worrying about things that could become a problem takes away precious time from worrying about things that actually are a problem. | |
| Jul 1, 2011 at 17:25 | comment | added | Randolf Richardson | @Nicol Bolas: +1 because your point is certainly a good one (and important in the context of time management), but I don't entirely agree -- optimizing something that has the potential to become a bottleneck at some point in the future is not a waste of time. (There are other benefits to optimization as well, such as code simplification, the elimination of bugs, etc., which can be [at least partially] incorporated into other processes such as code review so that it doesn't require a lot of extra time. I think that code optimization techniques are not very well understood by many people.) | |
| Jul 1, 2011 at 17:17 | comment | added | Nicol Bolas | @Randolf: I'm implying nothing; I'm saying that optimizing something that isn't a bottleneck is a waste of time. | |
| Jul 1, 2011 at 16:52 | comment | added | Randolf Richardson | @Nicol Bolas: Are you implying that optimization isn't useful? | |
| Jul 1, 2011 at 8:19 | comment | added | Nicol Bolas | @Randolf: If you have the time to optimize a simple math formula, then you have the time to be doing something far more useful than that. | |
| Jul 1, 2011 at 1:17 | comment | added | Randolf Richardson | @eBusiness: Optimization is important everywhere. It's simply the degree of importance that matters -- optimization is certainly possible without negatively impacting game play. If you've got the time or option to optimize anything, then why not do so? I suspect that we generally agree on these matters, but for some reason things went off course. | |
| Jun 30, 2011 at 22:21 | comment | added | aaaaaaaaaaaa | @Randolf Richardson: I just think you might be missing the target a bit in this case. For an MMO a good fast no-fat protocol is paramount, and heavy tasks like physics need to be designed with performance in mind. But damage calculation is core gameplay, it should be designed with gameplay in mind, if you bring performance concerns into such a question you risk compromising the gameplay part. Talk about performance when it matters, you risk giving the impression that this is an important area to optimise, thus stealing the attention from the real performance sinners. | |
| Jun 30, 2011 at 20:20 | comment | added | Randolf Richardson | @eBusiness: Optimization of the protocol (and not wrapping everything up in XML like all the cool kids like to do these days) certainly helps, but having a proper amount of bandwidth does too. This all underlines my original point about the value of optimization though, which unfortunately seems to be a unpopular idea these days despite its importance. | |
| Jun 30, 2011 at 20:10 | comment | added | aaaaaaaaaaaa | @Randolf Richardson Big as in the maximum you'd expect to happen in a common RPG. For the sake of the argument, it shouldn't be a significant load in a common MMO either, but if you optimise and cull to the point where it becomes a significant part of the calculations, networking will be the bottleneck determining how many players a server can service. | |
| Jun 30, 2011 at 19:12 | comment | added | Randolf Richardson | @eBusiness: A big battle yielding only 10 damage calculations per second? I think our ideas of "big" must be wildly different. When you have thousands of players on simultaneously (for which I've purposely excluded computer-controlled characters), these become major factors because "10 damage calculations per second" will simply be insufficient. As for a small game with a minor battle scenario between a handful of players, you're right in that it won't be noticeable (and such a game may not need to scale into something massive). | |
| Jun 30, 2011 at 9:36 | comment | added | aaaaaaaaaaaa | @Randolf A big battle in an RPG might mean something like 10 damage calculations per second, a modern CPU can do several billion operations per second. You can safely assume that the performance impact of any such "visible" maths is negligible. Simple in this case is for the sake of those who design and those who play the game, not for our computers. | |
| Jun 30, 2011 at 7:34 | comment | added | Randolf Richardson | @Tetrad: "Here and there" certainly won't be noticeable, but for code that is run repeatedly and often, this can make a difference, especially as more features are added later that require more calculations and whatnot -- it will compound, so if it's possible to start out with the more optimal solutions, this can really pay off in the long-run. | |
| Jun 30, 2011 at 6:34 | comment | added | Tetrad | @Randolf unless you're running on an Apple 2 or something, it's highly doubtful that removing a multiply or a divide here and there is going to affect performance in any measurable way. | |
| Jun 30, 2011 at 4:33 | comment | added | Randolf Richardson | "Simple" can also require less calculations, which means fewer CPU cycles are needed (and those spare CPU cycles can then be used for other aspects of game play, graphics, etc.). | |
| Jun 29, 2011 at 22:27 | comment | added | aaaaaaaaaaaa | +1 for simple. Anyone can make rigorously complicated stuff, that doesn't make a good game though. | |
| Jun 29, 2011 at 21:15 | history | answered | Mitch Lindgren | CC BY-SA 3.0 |