|
Post by Gravedust on Jan 17, 2012 15:48:06 GMT -8
I have prepared an example!! Let's say you're on a mission from god to get 2 20 damage lasers on a pod. As in my other example, let's say when all is said and done, you're at 710 points. Here's a list of everything on your pod: Armor Mobi Shields Reactor Capacitor Laser1 Laser2 Let's say your pod is balanced how you like it: Your reactor pumps out enough power for you to shoot all your lasers and have a 10 point energy surplus to put into shields if you're taking fire. Your capacitor have the.. uh.. Capacity to handle all that energy throughput. Your shields are of a size that allows you to (if you don't fire your weapons) refill them entirely in one round off the proceeds of your reactor. (Recharge shields, step behind cover so you don't get shot again, your regen tick fills capacitor to full again and you're good to go next round.) In all a tight, focused little pod without a lot of slop. These are the lasers you're using: =============================================================== [Energy] [Ares RE20 Ext.][Damage:20][Focus:15][Energy:5][Signature:5] - [SIZE: 20][COST: 120] - Description: A common variant of the original RE20 designed for extended range. - [Damage:20 (1-30)][Signature Reduction:2(0-10)][Energy Reduction:5(0-10)] [Focus Extension: 3 (1-3)][Miniaturization: 0 (0-10) ===============================================================These are the other ones that are available at 20 damage: (actually these are from the stock lists I'm working on today) =============================================================== [Energy] [Ares RE20][Damage:20][Focus:10][Energy:5][Signature:5] - [SIZE: 19][COST: 100] - Description: A widely used and commonly produced laser system. - [Damage:20 (1-30)][Signature Reduction:2(0-10)][Energy Reduction:5(0-10)] [Focus Extension: 2 (1-3)][Miniaturization: 0 (0-10) ===============================================================
=============================================================== [Energy] [Wisperlite L20][Damage:20][Focus:10][Energy:5][Signature:0] - [SIZE: 24][COST: 125] - Description: Utilizes a unique system to eliminate all emissions from the firing process. …Except the actual laser. - [Damage:20 (1-30)][Signature Reduction:7(0-10)][Energy Reduction:5(0-10)] [Focus Extension: 2 (1-3)][Miniaturization: 00 (0-10) ===============================================================
=============================================================== [Energy] [Greentree H1][Damage:20][Focus:10][Energy:1][Signature:5] - [SIZE: 24][COST: 130] - Description: Experimental power-recirculating weapon for the environmentally conscious. - [Damage:20 (1-30)][Signature Reduction:2(0-10)][Energy Reduction:9(0-10)] [Focus Extension: 2 (1-3)][Miniaturization: 0 (0-10) ===============================================================I'm not done with the list, so I can't offer more alternatives just yet, but you can see the base model, the model with a longer range, A lo-sig model and a lo-energy version. Covering the niches as discussed. If we downgrade to the regular 10 range lasers we'll be under our cost but we don't have the range we really want. And also there's 40 points going to waste. In a different scenario we can say that we're using the Greentree (low energy) in which case we can we can side-grade them to Wisperlites (Low sig) and get exactly to 700… But then you'll also have to change your reactor to keep your optimal setup since your lasers are now consuming more energy than you planned. Well bummer.. So okay, if we can't touch the weapons to get what we want then let's see what else we can change: Armor: A pretty good choice, assuming you aren't already flirting with low armor. And a 20 point drop is potentially significant if your armor isn't great to begin with. Mobi: We could sacrifice a point of movement speed, but then we'll have a big block of unused points, and one less movement. Shields: We could get a component with 5 points less shield strength. This isn't a terrible choice but is does mean 5 points less shields, and the extra reactor power you took so you could do your emergency-recharge to full shields is now a bit going to waste. Reactor: We could drop some reactor power, but then we lose some of that energy surplus we wanted so we can recharge our shields while still shooting. Capacitor: We've already got enough capacity for 100% throughput from reactor to capacitor, if we make it smaller we again have more reactor power than we can use. By contrast, you could look at the laser formula, decide that you can live with generating 1 more sig per shot, change Sig Red from 2 to 1, and get: =============================================================== [Energy] [Ares RE20 Ext. - CHAMPIONSHIP EDITION!][Damage:20][Focus:15][Energy:5][Signature:6] - [SIZE: 19][COST: 115] - Description: A common variant of the original RE20 designed for extended range, slightly modified to fit on a specific pod. - [Damage:20 (1-30)][Signature Reduction:1(0-10)][Energy Reduction:5(0-10)] [Focus Extension: 3 (1-3)][Miniaturization: 0 (0-10) ===============================================================Which fits perfectly without you having to make any other changes except to recalculate your mobility to account for 2 less size. Now I understand that this is a very limited example and things like this won't happen with every single build, there would be more options to choose from, etc. But hopefully it showcases the problems I'm foreseeing. Specifically that builders would have a hard time coping with even small overruns (or underruns if they're OCD and/or really want to squeeze every last point out of their pod) and tweaking the formulas is a very effective way to do that. But again to reiterate: What I'm advocating is the use of the stock lists AND the formulas in tandem. That's actually the way I've always handled pod design. Use existing components to get as close to my goal as I can, (Because why do the work again when I already have the result?) and then massage one or two parts via the formulas to smooth out any overruns or fill in any gaps while maintaining my overall design.
|
|
|
Post by captainfoo on Jan 17, 2012 15:53:02 GMT -8
Next time I am going to test the shit out of everything with rigor and verve, and I'll ask others to help if they want. As I've mentioned before my previous attempts at balancing were ridiculously lax. Looks like we agree. Uh, my point was that no matter how much you think you can effectively playtest alone - you can't. It wasn't that you just didn't do it very well. It's that you can't. Nobody can.
|
|
|
Post by Gravedust on Jan 17, 2012 15:54:33 GMT -8
Looks like we agree. Uh, my point was that no matter how much you think you can effectively playtest alone - you can't. It wasn't that you just didn't do it very well. It's that you can't. Nobody can. And my counterpoint was that I don't plan to do it again. Edit: By which I mean to say that I don't plan to develop the next version of the ruleset without outside input and independent testing, providing I can find people who are willing to help.
|
|
|
Post by captainfoo on Jan 17, 2012 16:08:28 GMT -8
Uh, my point was that no matter how much you think you can effectively playtest alone - you can't. It wasn't that you just didn't do it very well. It's that you can't. Nobody can. And my counterpoint was that I don't plan to do it again. Edit: By which I mean to say that I don't plan to develop the next version of the ruleset without outside input and independent testing, providing I can find people who are willing to help. You've got 'em. But you have to be willing to listen. So far you've dodged basically every criticism and this is a nice strawman you've provided at the top of the page.
|
|
|
Post by Gravedust on Jan 17, 2012 16:33:24 GMT -8
I thought it was pretty good. It's the closest thing to a realistic mockup I've seen so far for the system that's being proposed, and it illustrated why I have concerns with it.
Look, I'm not disagreeing with the idea simply because it's not an idea I came up with. It's within my abilities to just cross my arms an so "no we're doing my my way, so blah." but I'm not. I am listening to your arguments and pointing out the flaws as I see them. I do see flaws, as I attempted to illustrate above. I AM still listening, and if the system proves itself then chances are I'll use it. But if you're going to propose something that will very likely require hours and hours and hours of work, you should also be prepared to back up your suggestion with examples that show it works and in general have a better argument than "It'll totally work. Trust me." SHOW me it works.
I have taken critisism in the past, Distra pointed out some things that were very very wrong with the hacking system and those were amended. I really like Shalc's ideas about increasing sig gain/decay and I'll probably incorporate it as soon as I can. I'm still evaluating his proposed new direct fire rolls.
I do take advice, and consider it carefully, and if it works and is to the benefit of the game I'll incorporate it. But I will not swallow it blindly. I've raised my legitimate concerns about the proposed system. You can at least offer a logical answer as to why they are incorrect before accusing me of putting forth a straw argument.
|
|
|
Post by captainfoo on Jan 17, 2012 17:04:32 GMT -8
It's not my job to tell you how to design your game. If I've got a fix, I'll tell you. But it's ultimately your responsibility as a designer to make something fun. You've also gotta remember that as designer, you are not the arbiter of fun, the players are. If your players are giving you feedback that things aren't fun, take it to heart.
The pod design system as written is not fun, and actively works against all but the spergiest dedicated players from having fun as long as you keep player pod design an active part of the game.
---
Either you don't give them the option (rigid modules) or it makes no real sense to have stock modules other than a form of shorthand because everything will be customized on a per-pod basis.
|
|
captainbravo
Full Member
Vhiki readies Flame Breath!
Posts: 140
|
Post by captainbravo on Jan 17, 2012 17:07:42 GMT -8
Foo, maybe cut a little slack until the stock sheets go back up. Although since I'm one of those spergiest maybe my opinion is invalid.
|
|
|
Post by captainfoo on Jan 17, 2012 17:10:00 GMT -8
I ran a system of equations to build a pod...
|
|
|
Post by atomikkrab on Jan 17, 2012 17:39:31 GMT -8
I find that while flawed the game is quite fun.
Yes it needs fixing, but people are getting overly antagonistic about it.
Also yes people are going to design stupid pods under the system, people design stupid shit when given the chance to make customized things under ANY SYSTEM and the people who will min-max would min-max anyway.
So in conclusion these arguments are silly, you are all silly, it does need to get fixed but that is the entire purpose of this campaign on the SA forums, to test things out and fix/improve the system. Also a lot of you are getting a bit emotionally invested in this stuff which is even sillier.
|
|
|
Post by captainfoo on Jan 17, 2012 17:41:35 GMT -8
I find that while flawed the game is quite fun. Yes it needs fixing, but people are getting overly antagonistic about it. Also yes people are going to design stupid pods under the system, people design stupid shit when given the chance to make customized things under ANY SYSTEM and the people who will min-max would min-max anyway. So in conclusion these arguments are silly, you are all silly, it does need to get fixed but that is the entire purpose of this campaign on the SA forums, to test things out and fix/improve the system. Also a lot of you are getting a bit emotionally invested in this stuff which is even sillier. The only one emotionally attached to this is Gravedust, and in order to make real changes to an admittedly flawed system is to try to take a step back from emotional attachment and make objective judgments. It's hard!
|
|
|
Post by atomikkrab on Jan 17, 2012 17:42:56 GMT -8
I find that while flawed the game is quite fun. Yes it needs fixing, but people are getting overly antagonistic about it. Also yes people are going to design stupid pods under the system, people design stupid shit when given the chance to make customized things under ANY SYSTEM and the people who will min-max would min-max anyway. So in conclusion these arguments are silly, you are all silly, it does need to get fixed but that is the entire purpose of this campaign on the SA forums, to test things out and fix/improve the system. Also a lot of you are getting a bit emotionally invested in this stuff which is even sillier. The only one emotionally attached to this is Gravedust, and in order to make real changes to an admittedly flawed system is to try to take a step back from emotional attachment and make objective judgments. It's hard! I was speaking of the silly arguments rather than the game.
|
|
|
Post by Gravedust on Jan 17, 2012 17:47:18 GMT -8
======================================================= If your players are giving you feedback that things aren't fun, take it to heart. ====================================================== I am, hence the length of this thread and my responses.
====================================== It's not my job to tell you how to design your game. ===================================== Of course not. But if you do make a suggestion that I reject initially because I have misgivings about it, don't accuse me of ignoring input or refusing changes due to emotional attachment when it hasn't been proven that the new system won't be just as bad as the old. So far I'm the only person apparently who has gone so far as to actually test it, in even an extremely basic capacity. I WILL give it a full evaluation when the stock lists are completed, as I've said. And other people will be able to do the same and we'll all be able to see the results, one way or another.
|
|
|
Post by captainfoo on Jan 17, 2012 18:07:06 GMT -8
The only playtest going on (that I am aware of) is the one on SA, which is currently using full formula build rules.
|
|
|
Post by shalcar on Jan 17, 2012 22:21:07 GMT -8
First off, this is likely to be long as there are a few points I wish to address.
This is something that several people are trying to explain to you, namely, this is a crystal clear example about how you are holding an existing system to be a sacred cow.
Suggestions for even large changes should *never* be rejected due to misgivings, as misgivings are a purely arbitrary set of feelings about something and are emotional responses. What a designer needs to be interested in is “How well does this system reach my design goals”, not “Does this feel right?”.
A clear example of the fact that you are not approaching the suggestions in an objective manner is the frankly ludicrous strawman that was constructed at the top of the page as some sort of proof against a suggested form of modular system.
To recap, you suggested that a pod at 710 points and with everything unable to be changed because it was “perfect” couldn’t be brought into cost spec without breaking it, whereas under your system you could change the weapon slightly and it would fit.
Let’s work on the underlying assumptions that are not in any way backed up.
Immutability of weapons damage and range Immutability of Shields Immutability of Reactor Immutability of Jets Immutability of mobility Immutability of armour Role appropriateness of pod Flawed Design approach
In your example, we are given a “Magic pod”, that is, a pod in which any change to the provided values will render it unable to be used for its intended purpose. At no point is this assumption based on any reason other than “Gut feel” or the acceptance of the assumption that mathematics has somehow determined this to be the only way forward. It is stated that neither weapon range nor damage can be sacrificed. Speed can not be sacrificed, nor can the reactor or shields. It is stated that the loss of armour would render to pod significantly less functional.
Unsurprisingly, when all the fine tuning levers in a system are locked, fine tuning can not take place. Conveniently, the fine tuning levers not shared by the separate systems are left unlocked and as such fine tuning can take place. This provides evidence that the current system can make this pod under the previous assumptions, where the modular system, theoretically, can not.
This is problematic, as this is then taken to be given as evidence of the unworkability of a modular system that the “perfect pod” can’t be created like in the current system. However, this conclusion has several large flaws.
The existing system recognizes that there are limitations on the capabilities of any given pod (So no amount of wrangling will net me a pod with 3 damage 100 missile weapons regardless of the fine tuning) and so the fact that a similar limitation is applied to the modular system is not a detraction from its comparative functionality. In addition, pods created under one system are not in direct contrast with pods created under the other system. There is no “race” to see which system creates the best pods as all players operate under identical constraints.
Pods exist to be used inside the battlefield and as such their capabilities are not defined by the raw numbers on a spreadsheet but on the combat role that the pod is visualized to occupy. How well a certain pod performs at its design role is it’s “fitness” metric. The example provided does not approach it in this manner and instead tries to assemble a pod by forcing components into it with no thought for how these interact except to state that the loss of any one component would be catastrophic (presumably compared to another pod which had spent all their points) at the fitness of the pod. This is not a rational assumption, as there are many possible combinations that would perform almost functionally identical at an expected role without trying to force an overpriced set of components into a pod, which is also a boundary case.
Without having seen any modules or example modules (short of the half dozen cannons I generated as an illustrative example) you have somehow decided that the level of granularity is not sufficient. This can be proven patently false by simply making an item for each possible permutation of your existing system (So around 5000 different railguns) and suddenly the module system has sufficient granularity! While this many modules is unworkable and would be inferior to the current system, it’s ridiculous in the extreme to claim that there is obviously no combination of jets, shields, capacitors, armour and mobility that could resolve the 10 point difference in your boundary case. It may even end up with a pod more fit for purpose.
The final assumption is that fitness of a pod is decided by how close to the 700 point limit it is able to spend. This is simply not true in any sense except the most basic. Using the Arclite as an example, this is a pod that costs 698 points and yet is completely terrible at its prescribed role. It’s possible (I believe Foo did this earlier) to build a pod that’s better at the combat role for 500 points. Given that good design is clearly significantly more important to a pod than the proximity to the points ceiling and the fact that even the most wasteful extreme pods would be not spending around 1% of their points at the outside it is simply not an important factor in a system.
As an aside, it’s important to note that Elitist Jerk style players are willing to put in enormous amounts of effort for increases in effectiveness of as little as 1%. Considering that use of the pod on the battlefield is of significantly more importance than the minute power fluctuations of designed pods, it’s likely they would be focusing their mathscraft towards that.
With the deconstruction of the strawman concluded, I would like to pose a question:
“What are the stated design goals of the pod building system?” “What are the stated design goals of the combat system?” “What are the stated design goals of the strategic update system?”
As this is a game, allow me to provide you with a primary design goal:
“A stated design goal of these systems is for the players to have fun that is enhanced by this system”
If this *isn’t* one of your primary design goals, then I might suggest writing novels as you have an exceptional talent for worldbuilding that would be a shame to waste.
Try to come up with 5 goals for each section. You don’t have to succeed, but it will make an enormous difference in the quality of feedback you receive from testers as well as helping clear the muddle of what is and isn’t important.
As we move towards constructing a design document and head towards detail design, you will find management and running of this to be a lot simpler. These are living documents and things are never set in stone, but it will help you hold perspective (not saying you have ever lost perspective) so that when a player says “Item X isn’t fun” it’s not that he is being problematic or picking faults, but that the Design Goals are not meshing nicely and the issue can be more accurately targeted.
I’m hoping you will engage with me and meet me halfway with my request.
|
|
|
Post by Gravedust on Jan 18, 2012 1:13:33 GMT -8
Suggestions for even large changes should *never* be rejected due to misgivings, as misgivings are a purely arbitrary set of feelings about something and are emotional responses. What a designer needs to be interested in is “How well does this system reach my design goals”, not “Does this feel right?”. =================================================== Perhaps I chose the wording poorly but the "misgiving" I was referring to was my previously explained notion of how limiting the build system to stock-only parts would encourage cookie cutter designs. It was not a matter of me feeling uncomfortable with the idea, it was a matter of me analyzing the idea and identifying what I believe to be faults in it. Nobody has yet demonstrated to me that the potential faults I've identified do not exist, and I'm not willing to trade the system I have for a new one until it has been proven that it won't wind up being just as flawed but in a different way.
Understand that I still haven't decided one way or another. I haven't closed my mind to the idea at all, but neither am I going to blindly accept it.
My post at the top of this page was NOT a be-all, end-all attempt to prove the inadequacies of a fixed system, it was an attempt to explain the problems that I can forsee with such a system using a hard example. I acknowledge the fact that it is not a wholly accurate representation in the post itself, but the only way to fully test the system would be to have the system already fully constructed. Again, I was not attempting to prove anything, and I have not made a decision based on my admittedly biased example. I was trying to provide an illustration that showed the potential problems I forsee clearly.
======================================================= Without having seen any modules or example modules (short of the half dozen cannons I generated as an illustrative example) you have somehow decided that the level of granularity is not sufficient. This can be proven patently false by simply making an item for each possible permutation of your existing system (So around 5000 different railguns)and suddenly the module system has sufficient granularity! While this many modules is unworkable and would be inferior to the current system, it’s ridiculous in the extreme to claim that there is obviously no combination of jets, shields, capacitors, armour and mobility that could resolve the 10 point difference in your boundary case. It may even end up with a pod more fit for purpose. ======================================================= Let's actually discuss granularity, since it'll be an important factor in the proposed system one way or another and It's something I've thought about previously. In my example I assumed a granularity of 5 points per shield unit (seems reasonable to me) Which would result in 20 shield units on the list, which baloons to 240 if you include options for miniatirusation (at a 2-point detent)
At a 2-point shield granulatity (shield strength 2,4,6,8 etc.) 50 components on the list, which becomes 600 with 2-point miniturization. This is a rough figure that includes extreme cases that probably nobody will use and also configs that are barred by the rules, (zero size, etc) but even after cutting those out you are likely to be left with a very large number.
Shields (along with capacitors and reactors) are the simplest components there are. Generating lists of weapons with sufficient granularity to cover both the type of weapon desired and a multiple cost levels would be a herculean task (the kind you would write a program for, perhaps) and result in a huge number of weapons. I don't have the time or capacity at the moment to give an accurate figure. Less than the 5000 you mention, obviously, but my fear is the result will be very unweildly, and the process of generating all these components very time consuming.
Anyway.
It's important to realize (and this is a blanket statement for everyone in this thread) that my not accepting ideas is not the same as me rejecting them. By raising opposition I intend to bring out any possible flaws in the proposal, If you can counter my arguments reliably and provide solutions to the problems I pose- (For instance: How do we solve the issue of sufficient granularity vs. list bloat and huge production times? And is it even actually an issue at all?) -then you will advance the cause of the proposal. I'm hesitant to throw my lot in immediately with a proposal that does not seem to have any hard math accompanying it that proves it's feasibility. It will be a monumental waste of my time and effort to put it into effect if it does not turn out to be a clear improvement over the system that is already in place. Additionally, saddling myself with an alternate system that proves unworkable will crash the project.
If you can prove that it is feasible and if you can demonstrate that it is a clear improvement over the current system, I'll adopt it. I'm already intending to test the proposal myself once the materials are in order. If any of you wishes to expend any effort you can hasten this process along by generating parts yourself and testing, or donating lists of compiled parts. My time is extremely finite and I'm already spending more than I can afford in this thread.
Shal I hope you realize that I'm working with you as best I can. But I will not swallow a change as big as this one without it being proven first.
I'll see what I can do about goals but I am too exhausted to really think right now.
|
|
|
Post by xelada on Jan 18, 2012 5:53:41 GMT -8
You guys aware you don't need perfectly optimized pods to play, or even play well, it is the GM's job to balance the campaign so that un-optimized pods are of use. If this where a one on one PvP game I'd understand the heated debating, however it is more a team based PvE or PvBG (player versus badguys), the balance doesn't have to be perfect. Yes making it better is... better but people keep saying only dedicated players can play or get anything out of it total garbage, a newbie can potentially get in with a semi decent pod try, gain experience and make better decisions later; the fact it is team based means that the new and the type 1s can still survive with the help of “friends”; the fact there is no perma-death means even if they end up getting blown to smithereens they can still play and learn from mistakes.
|
|
|
Post by captainfoo on Jan 18, 2012 8:21:38 GMT -8
You guys aware you don't need perfectly optimized pods to play, or even play well, it is the GM's job to balance the campaign so that un-optimized pods are of use. If this where a one on one PvP game I'd understand the heated debating, however it is more a team based PvE or PvBG (player versus badguys), the balance doesn't have to be perfect. Yes making it better is... better but people keep saying only dedicated players can play or get anything out of it total garbage, a newbie can potentially get in with a semi decent pod try, gain experience and make better decisions later; the fact it is team based means that the new and the type 1s can still survive with the help of “friends”; the fact there is no perma-death means even if they end up getting blown to smithereens they can still play and learn from mistakes. BattlePod seems to me to be a tabletop wargame in the vein of Warhammer or Battletech, and we are playtesting within a scenario. As a finished game, I would suspect that the dominant mode of play would be PvP with each player controlling a squad of Pods - likely without Gravedust's involvement! I guess that's been my unstated assumption. And of course you don't need perfectly optimized pods to play - but if the option is there for someone to bring one against you...they will. And if you're not in equally optimally designed pods, this goes back to my "entrenched advantage" concept. --- There's no problem here, in my eyes. 5 or 6 similar variants of say, a 2-rail pod are great! They each allow a different style of play. Perhaps some of these combinations are better than others. That's fine, really. Not every combination is going to work out as well as others. Again, the exemplar of this is the Arclite. The slow, small artillery pod with a backup missile sucks. But what you will find out is which designs are good. And besides, perhaps 2 medium rails with melee is a good pod, and 2 large rails with melee is a bad pod. Or vice versa. Playtesting will tell. And again, if you don't have to break every pod every time you want to test the effect of a component change, the easier it is to test. Effectively, you want an unstable equilibrium as to what "the best type" of pod is. Ideally, the metagame will evolve over time.
|
|
|
Post by Gravedust on Jan 18, 2012 12:02:04 GMT -8
============================================================================================ BattlePod seems to me to be a tabletop wargame in the vein of Warhammer or Battletech, and we are playtesting within a scenario. As a finished game, I would suspect that the dominant mode of play would be PvP with each player controlling a squad of Pods - likely without Gravedust's involvement! I guess that's been my unstated assumption. ============================================================================================ Yep, that's pretty much the case. The finished version (which this is far from) needs to be able to stand on it's own to be considered a success in my eyes. So ensuring balance without GM moderation is important.
============================================================================================================= And of course you don't need perfectly optimized pods to play - but if the option is there for someone to bring one against you...they will. And if you're not in equally optimally designed pods, this goes back to my "entrenched advantage" concept. ============================================================================================================= On this hand you seem to be saying that the advantage that 'optimized' formula-built pods (which are able to be balanced more precisely than stock-built pods) have over pods made with the stock parts. (That may not balance out exactly so well due to more limited options) is important.
================================================================================================================= Perhaps some of these combinations are better than others. That's fine, really. Not every combination is going to work out as well as others. ================================================================================================================= On this hand you seem to be saying that the advantage of an 'optimized' stock-built (where the numbers just happen to fall into place and everything fit perfectly according to the designer's wish) and an 'unoptimal' stock-built pod (that contains some cruft because the given components couldn't provide an exact fit**) is not important.
When the differences in terms of design compromise are roughly the same. I may have clouded the issue by including point totals as part of my example. The real issue is how close the ultimate designs were to their creator's conception of their ideal design.
I see that what you're advocating is to balance the playing field by simplifying the build system so it won't frustrate people who don't like to mess around with the formulas, thereby negating the minor advantage that people using the fomulas are likely to achieve through increased synergy. (For the record I hardly think this disparity is particularly significant. A good design will still beat a bad design, regardless of the method used to create it.) But in the process a stock-only system would invalidate pod designs that would otherwise be workable**, and promote designs that just happen to synergize well with the parts available.
From conception I envisioned the pod design system as a way for pod designers to match wits and come up with innovative designs. The narrower the options presented to pod designers the shallower the potential depth becomes. I'm well aware that the complexity and time required is off-putting for some, (Just as I'm aware that some people are likely to find it more appealing than a simpler system, since such systems are commonly available for other games) which is why I'm giving the stock system my serious consideration. But if the simplicity engendered by the new system proves too limiting to a designer's overall options then I will likely not adopt it. If it provides results that are very similar to what can be achieved with the current system but for less effort, then I most likely will because there would be no reason not to and it would be to the overall benefit of the game.
The main purpose of the proposed change is to increase the 'fun' aspect of the pod system (and hence, the game as a whole) But I can see players being frustrated just as much by the inability to find (or the length of time it takes to find) the part or combination of parts that perfectly completes your design** as they would with having to shuffle numbers around with the formulas. One system is frustrating one way, but the other system is frustrating as well in another.
I still believe the best answer is a combination of the two systems, use of stock parts to rough out a design, then use of formula manipulation on a small number of parts as a final touch to either fill out available points if desired, or to correct an overcost pod without resorting to potentially larger than necessary changes.
In the spirit of compromise, there is always the possibility of simply agreeing that "Official" matches between pods be limited to pods constructed from the 'official' parts list. But also have 'freebuild' matches using pods built with all the tricks of the formulas available, as two separate categories. And ne'er the twain shall meet unless agreed upon by both parties. Similar to how Battletech apparently works, where custom mechs are outlawed in some games and accepted in others.
Under those circumstances I don't see why the two systems have to be mutually exclusive.
In terms of the ongoing game on SA we could even switch between "freebuild" missions and "stockbuild" missions in order to test both systems once the stock lists are compiled.
____________________________________________________________________________________________ **This of course is subject to variable granularities as Shal and I were discussing on the previous page. Too much 'room' between component types increases the number of designs that become unworkable or unoptimal because just the right combination of parts doesn't exist. Too little results in a very large number of parts that need to be combed through to find the right one, and could potentially take a very long time to produce. (I'm very much not enamored with the concept of producing 200 capacitors) It also makes it more difficult to enact the clean changes you envision making to components for balancing. Modifying a certain flavor of laser to generate 1 less sig becomes less trivial if you have to change it along 50-100 iterations that make up a certain weapon archetype. One of the hinging points in my mind on the suitability of the system is if a solid compromise can be found that allows a good choice without component bloat. Though again this is something that we won't be able to gauge until the lists are actually compiled. If this can be achieved successfully then it would be a major point in the proposed system's favor. __________________________________________________________________________________________________
|
|
|
Post by Gravedust on Jan 19, 2012 11:42:48 GMT -8
Okay, I've had some time to think about it, and here's what I've come up with: (Ordered in terms of importance by category)
• Primary design goal: (1) -For the players to have fun that is enhanced by this system
• Secondary goal (if you'll allow, but my desire to keep devoting my time to the project does hinge on it.) (1) -To provide a stimulating mental and artistic exercise for the designer (This goal will cease being relevant once the game has reached a 'finished' state)
• What are the stated design goals of the pod building system? (1) -To ensure that no pod design is unfairly superior to all (or most) others. (2) -To allow a greater level of unit customization that is present in most other games. (3) -To allow the creation of Pods that most closely match a creator's intent. (As the 'truest' expression of the Pod designer's creativity) (4) -To present a system that is easy to grasp initially, but with enough depth to avoid an immediate plateau in the learning curve.
• What are the stated design goals of the combat system? (1) -To present an environment where success is dictated more by strategy than luck.** (2) -To contain enough sensitivity to make most pod design choices (and pilot skill choices) relevant. (3) -To present an environment wherein pods cannot succeed on their individual merit. (Teamplay/cooperation increases the chance of success.) (4) -To present a system that is easy to grasp initially, but with enough depth to avoid an immediate plateau in the learning curve. (5) -To present a system where as few rules as possible need to be 'looked up' (The information is either readily available or easily remembered.)
• What are the stated design goals of the strategic update system? (1) -To tie the missions together in a comprehensible manner and add weight and meaning to the individual missions. (2) -To allow for gradual advancement in terms of the players' capabilities. (Pod design options, Assembler upgrades, Alliance bonuses) (3) -To allow the telling of an overall narrative. (4) -To offer a variety of possible choices for the next mission.
__________________________________________________________________________________________________________________________________________________ **Meaning that while the game is inherently random, the player's overall success or failure should not be determined by one (or two) lucky or unlucky dice rolls. Likewise the player should not be destroyed by events or forces that are outside his control.
|
|
|
Post by captainfoo on Jan 19, 2012 15:36:25 GMT -8
Okay, I've had some time to think about it, and here's what I've come up with: (Ordered in terms of importance by category)
• Primary design goal: (1) -For the players to have fun that is enhanced by this system As given, and ultimately must be the point of any system that you expect people to play...
• Secondary goal (if you'll allow, but my desire to keep devoting my time to the project does hinge on it.) (1) -To provide a stimulating mental and artistic exercise for the designer (This goal will cease being relevant once the game has reached a 'finished' state) ...because it would be possible to have a project that is solely a design toy, but you've stated that you want people to play it. And yes, we must grant you the interest to remain working on the project or why bother making any suggestions at all!
• What are the stated design goals of the pod building system? (1) -To ensure that no pod design is unfairly superior to all (or most) others. Right, you don't want one pod to dominate, and there should be several quality choices for pod selection. (2) -To allow a greater level of unit customization that is present in most other games. This is a clearly stated goal but the requirements are actually rather murky. Greater than X-COM? Greater than BattleTech? Greater than Carnage Heart? Less than Dungeons and Dragons? Also consider why this is goal is more important than (3) below. (3) -To allow the creation of Pods that most closely match a creator's intent. (As the 'truest' expression of the Pod designer's creativity) This is good; obviously, a pod creations system must allow people to build what they have ideas for. But remember, you're going to have pathological designers. Some designs are going to be out of bounds for your system. It is good that this goal is subordinate to (1). (4) -To present a system that is easy to grasp initially, but with enough depth to avoid an immediate plateau in the learning curve. I think this goal is where the pod creation system as currently written fails miserably. It is very very difficult to grasp.
I would actually consider reording the goal preference to be 1-3-4-2. Ultimately, the order of 3 and 4 are going to be based on how easy you want the system to be to work with. I would disagree that an extremely high level of customization (2) is necessary as long as goals 3 and 4 are being achieved. I suspect that it is tied in with your stated secondary goal, however. I believe that complexity for complexity's sake is something that will have to be examined very closely.
• What are the stated design goals of the combat system? (1) -To present an environment where success is dictated more by strategy than luck.** Yes! A game where luck outweighs skill will almost definitely fail the primary design goal. (2) -To contain enough sensitivity to make most pod design choices (and pilot skill choices) relevant. Again, yes. Do note that it is likely that subtle pod design changes will only have subtle effects. Also note that in order to achieve this goal, large parts of the construction and/or skill system will (likely) have to be changed. (3) -To present an environment wherein pods cannot succeed on their individual merit. (Teamplay/cooperation increases the chance of success.) I think I see what you're going for here, but I'm not sure it's as expressed as clearly as it should be. Yes, in a squad-based game the squad with the better teamwork SHOULD win, but at what point does teamwork become outweighed by either relative pod quality or player skill? How "well" should a team of 500 point pods have to play to beat an equal amount of 700 point pods (assuming well designed pods i.e. ones that are near the top of the power curve for the point total). Don't want to get too far off the rails, but consider the clarity of this goal. (4) -To present a system that is easy to grasp initially, but with enough depth to avoid an immediate plateau in the learning curve. This is an excellent goal, and something to keep in mind as the game continues to undergo revisions. This is possibly the #2 goal, actually. (5) -To present a system where as few rules as possible need to be 'looked up' (The information is either readily available or easily remembered.) Looking up a simple rule takes the same amount of time as a complicated one (more or less). The important distinction is that you have to stop playing to look something up. The game as written succeeds admirably in some places (3 action rule) and fails badly in others: weapon to-hit formulas. Also, pod construction formulas although it is much less crucial there.
• What are the stated design goals of the strategic update system? I'm not going to address this much because we haven't really seen much that there is a system - which is fine. I think the tactical game and pod design are fairly separate from the strategic game (at least so far as it has been presented). (1) -To tie the missions together in a comprehensible manner and add weight and meaning to the individual missions. (2) -To allow for gradual advancement in terms of the players' capabilities. (Pod design options, Assembler upgrades, Alliance bonuses) (3) -To allow the telling of an overall narrative. (4) -To offer a variety of possible choices for the next mission.
__________________________________________________________________________________________________________________________________________________ **Meaning that while the game is inherently random, the player's overall success or failure should not be determined by one (or two) lucky or unlucky dice rolls. Likewise the player should not be destroyed by events or forces that are outside his control.
|
|
|
Post by Gravedust on Jan 20, 2012 15:15:29 GMT -8
…Man I forgot how nice it is to be able to color-mark things..
I want to give Shal a chance to weigh in with his views before we go too much further, but I'll touch on some of the points you've raised.
(2) -To allow a greater level of unit customization that is present in most other games.
I guess that does need more clarification. It's a little difficult since there are so many games to compare it to. Battletech seems to be the most apt comparison, and in certain areas it is actually -more- customizable than Bpod (specifically in terms of mech structural construction) I've already messed around with games that put importance on structural construction (Steam Armada) and I discovered that tracking structural damage across a large number of units quickly becomes overwhelming for online play, ((which is a goal I forgot to state, suitability for online/tabletop play, I will add that.)) so I abstracted that aspect for Bpod. The main area where Bpod has it's customization options is in it's weapons, (As they are the main effectors of combat performance, and the game is essentially about combat) Anyway. My overall goal was to give pod designers direct control over each of the stats that are used in the game. ((which I guess cuts to the heart of it, so that'll be added to my goal statement))
For overall pod stats:
• Movement speed • Movement type (Walking Vs. Jumping) • Pod size • Armor • Shield levels (where applicable) • Power generation (where applicable) • Power reserves (where applicable) • Signature decay (Was removed, may possibly be added in again with change to sig generation rate.)
And weapon/equipment stats:
• Type • Damage (Or magnitude of effect, whatever that effect is) • Range • Ammunition level (Where applicable) • Energy consumption (Where applicable) • Signature Generation
So I suppose the difference that I want to have between 'most' games is that most games usually say: "Here are the tools you are allowed, arrange them how you want"
Bpod would say: "Here is the range your tools are allowed, configure them how you want and arrange them how you want."
The reason this approach interests me is: • It's unique (Or at least less common than the norm, I haven't personally found another game that handles things in quite this way) and I'm attracted to novelty. ..Actually this is important enough that I'm gong to add it in as a secondary objective. (Yes, there is a whole other discussion to be had on whether uniqueness is necessary for a game to be fun but in this case uniqueness correlates to (1) in that category.)
• It (theoretically) allows for a more clear expression of pod designer creativity. Tactics in most games are centered around what weapons are allowed and what the stats of those weapons are, which is in turn centered around the philosophy of the game designer. (I.e. what pieces the designer makes available shapes the overall tactics of the game and build philosophy, whether intentionally or not.) By keeping the stats as malleable as possible, this centers the design theory more on the podbuilder's philosophy rather than the game designer's, allowing the players greater freedom to drive the metagame based on creating designs that counter other designs, or explore newly-developed design philosophies. (Though obviously the designer's hand must come in somewhere in order to maintain balance.)
How many variables and options in pod construction are really required to achieve this will likely come into debate later…
====================================== (4) -To present a system that is easy to grasp initially, but with enough depth to avoid an immediate plateau in the learning curve. I think this goal is where the pod creation system as currently written fails miserably. It is very very difficult to grasp. ======================================
If you will do me a favor, can you explain the process you use for pod production? (with a little hyperbole as possible) I want to understand things from your perspective, and see how other people are approaching the system. (Since I don't have much of a problem operating the formulas obviously I'm not seeing this issue as the same side as others) If anyone else is reading this thread I'd like for them to also weigh in with their processes as well, I'd like to see what people are doing and how they're doing it.
Please explain what your process is, the parts that are the most confusing or frustrating, and what you think takes up the most time.
I'm not certain what about the process can be changed without making large alterations to the system, but this should at least help me understand better where the problems are.
======================================================================================
(3) -To present an environment wherein pods cannot succeed on their individual merit. (Teamplay/cooperation increases the chance of success.) I think I see what you're going for here, but I'm not sure it's as expressed as clearly as it should be. Yes, in a squad-based game the squad with the better teamwork SHOULD win, but at what point does teamwork become outweighed by either relative pod quality or player skill? How "well" should a team of 500 point pods have to play to beat an equal amount of 700 point pods (assuming well designed pods i.e. ones that are near the top of the power curve for the point total). Don't want to get too far off the rails, but consider the clarity of this goal.
Yeah, I think I tunneled in too much with that statement. I've changed it to be a bit more general: (3) -To present an environment that encourages teamplay. (the rest of that was basically saying that no pod should be able to cover every aspect of a pod's range of abilities well, there should always be a shortfall of some nature in every design (even if the shortfall is that it's -mediocre- at everything but not -great- at anything)
===========================================================================================
(4) -To present a system that is easy to grasp initially, but with enough depth to avoid an immediate plateau in the learning curve. This is an excellent goal, and something to keep in mind as the game continues to undergo revisions. This is possibly the #2 goal, actually.
This is an objective call, or course, but I personally place the importance of a game having lasting appeal over making it easy to pick up. (So long as it isn't blindingly difficult at the beginning.) I think most people with a light background in strategy games will have a fairly easy time understanding what the basic tenets are.
===========================================================================================
(5) -To present a system where as few rules as possible need to be 'looked up' (The information is either readily available or easily remembered.) Looking up a simple rule takes the same amount of time as a complicated one (more or less). The important distinction is that you have to stop playing to look something up. The game as written succeeds admirably in some places (3 action rule) and fails badly in others: weapon to-hit formulas. Also, pod construction formulas although it is much less crucial there.
Yep, the main reason being that having to stop to check the rules interrupts the flow of play, exactly.
I agree with your assessment here. I haven't quite finished evaluating Shal's proposal on a reworked direct fire roll but I have been thinking of ways to abstract the variables of the existing one a little more than they are now without losing too much fidelity; at least enough to allow the creation of a table where you can look up range/size bonuses. I think if we can eliminate the need to divide then most players will be able to do the calculations in their head with reasonable accuracy.
The other area I feel the game fails is with the hacking, as hacking effects are myriad and most have different difficulty levels that are not easily remembered. I have a cheat-sheet printed out that I refer to, usually. I've been trying to find ways to simplify it, but I figure that as long as players have ready access to a sheet that lists the effects and difficulty it's not an overwhelming problem. I may produce a printable .pdf for convenience.
=================================================================================================
Anyway. Updated design goals:
• Primary design goal: (1) -For the players to have fun that is enhanced by this system
• Secondary goal (1) -To provide a stimulating mental and artistic exercise for the designer (This goal will cease being relevant once the game has reached a 'finished' state) (2) - To create a unique game. (See Building System Goals (3))
• What are the stated design goals of the pod building system? (1) -To ensure that no pod design is unfairly superior to all (or most) others. (2) -To allow the creation of Pods that most closely match a creator's intent. (As the 'truest' expression of the Pod designer's creativity) (3) -To allow a greater level of unit customization that is present in most other games. (Give designers direct control over every stat used in the game) (4) -To present a system that is easy to grasp initially, but with enough depth to avoid an immediate plateau in the learning curve.
• What are the stated design goals of the combat system? (1) -To present an environment where success is dictated more by strategy than luck. (2) -To contain enough sensitivity to make most pod design choices (and pilot skill choices) relevant. (3) -To present an environment that encourages teamplay. (4) -To be suitable for Online or Tabletop play. (Concessions for tabletop play should be considered, but need not be enacted yet.) (5) -To present a system that is easy to grasp initially, but with enough depth to avoid an immediate plateau in the learning curve. (6) -To present a system where as few rules as possible need to be 'looked up' (The information is either readily available or easily remembered.)
• What are the stated design goals of the strategic update system? (1) -To tie the missions together in a comprehensible manner and add weight and meaning to the individual missions. (2) -To allow for gradual advancement in terms of the players' capabilities. (Pod design options, Assembler upgrades, Alliance bonuses) (3) -To allow the telling of an overall narrative. (4) -To offer a variety of possible choices for the next mission.
================================================================================================= If there's anything you wanted me to address that I skipped, feel free to bring it up.
|
|
captainbravo
Full Member
Vhiki readies Flame Breath!
Posts: 140
|
Post by captainbravo on Jan 20, 2012 21:22:06 GMT -8
If you will do me a favor, can you explain the process you use for pod production? (with a little hyperbole as possible) I want to understand things from your perspective, and see how other people are approaching the system. (Since I don't have much of a problem operating the formulas obviously I'm not seeing this issue as the same side as others) If anyone else is reading this thread I'd like for them to also weigh in with their processes as well, I'd like to see what people are doing and how they're doing it. Well, I start by asking myself one of three questions. 1.) How can I make a pod that more effectively does X than the current pods? 2.) How can I take something pod X does well, and do it better? or 3.) How can I take feature X to it's highest concievable limit? Pretty much every pod I design follows one of those rules. I'll either try and make a pod for a role not covered by current pods, improve on an idea for a pod, or pick something and try to design a pod from the ground up completely based around that one thing. For me, the biggest problem and what takes the most time is plugging everything into the sheet. I keep a notepad open, and jot down numbers for all the various components, with a running tally on the side for size/weight. Once I've got everything figured out, though, it takes forever for me to plug each of those numbers in to the build sheet, and I always generate about 3 or 4 errors in the process that I have a hard time catching. The same for if I'm using the excel pod builder. It's just a lot faster and easier for me to work with the numbers using notepad and a calculator, but once I've got the finished numbers plugging them all in is a chore. I know that that's probably not very helpful to the discussion at hand, but that's just my experiences with it!
|
|
|
Post by Gravedust on Jan 20, 2012 21:38:08 GMT -8
Any and all information is useful! Thanks for your input.
|
|
|
Post by captainfoo on Jan 21, 2012 16:53:32 GMT -8
I don't have time to give a full overview of my pod-building process, but I'll give you two quick anecdotes - my first attempt at building a pod led me to stick 500 armor on the thing because I didn't really know what I was doing. That may have been my fault for not looking at the stock pods that closely, but I was trying to not take too much influence from the existing material and to see what I came up with - this point only makes sense once you examine the rest of the system to see that a 500-armor pod is not gonna be good at much else other than being a block.
Second: In order to have any cost/size baseline to work around, I set up a table (which I posted in the SA thread) of "maximum size per movement value" and associated mobility scores. I found that without pre-calculating this information and building up to a size limit for a given speed, I was not able to effectively build a pod that did not waste the resources available (size and/or cost). I hope that's clear...
|
|
|
Post by shalcar on Jan 22, 2012 1:22:37 GMT -8
I've been sick these past few days and so have not had the time or energy to give this the attention or clear thought that it deserves. Hopefully I'll be feeling better tomorrow and able to give Grave some useful information.
Just letting you know I've not forgotten nor ignored you!
|
|
|
Post by Gravedust on Jan 22, 2012 11:21:12 GMT -8
I've been sick these past few days and so have not had the time or energy to give this the attention or clear thought that it deserves. Hopefully I'll be feeling better tomorrow and able to give Grave some useful information. Just letting you know I've not forgotten nor ignored you! Yikes! Hope you feel better, and don't sweat it, get back whenever you have the time/inclination.
|
|
|
Post by captainfoo on Jan 23, 2012 17:10:16 GMT -8
I see the discussion on SA moving in this manner, so i'd figured I'd comment - I think one problem with the pod design as of now is that build points don't really correspond to "effectiveness." Again I am going to make an argumentum ad Arclitio as the best example of this. A pod's point value should tell you a bit about relative power, but it doesn't. I don't know if this is because the Arclite happens to be a pathologically bad design or not, but the fact that a pod as bad as the Arclite can be worth the same amount as say, the Peregrine (referenced as "breaking the game") or a Virus indicates that there are definitely flaws with the cost/effectiveness formulas.
|
|
|
Post by Gravedust on Jan 23, 2012 20:03:01 GMT -8
Yes the Arclite is a terrible design, but terrible designs should be possible under the system, which is built to support choice, even dumb ones.
Where are the points?
Well you run an artillery rig yourself so you ought to be able to appreciate this:
Sledge 1 launcher, 10 Shots, 60 damage Damage output per turn: 60 Total damage output: 600
Arclite Mk2. 2 launchers, 34 shots, 30 damage Damage output per turn: 60 Total damage output: 1020
That's just the artillery part, you've got a hack deck, Arcy has a missile, but I figure I'd compare the parts that match up.
The points are all there, you just have to look, as it's not always obvious. The Arclite does 58% more total damage than your equally-costed pod, not counting another 400 in missiles.
The points are just poorly configured. I.e. too much firepower and not enough mobility to really use that firepower, and the pod has essentially no defense.
So no, the points don't translate into effectiveness, so much as Potential Effectiveness, and it's up to the designer to use that potential to its greatest extent. That's the -entire point- of the build system, and that's what separates a good design from a bad one.
You can of course make the argument that the point weights aren't even across all the formulas.
In fact when you are arguing that one weapon is unbalanced because it's cheaper/lighter than others, that's essentially what you're saying. I'm already totally aware of that, and I'm working on fixing it.
|
|
|
Post by xelada on Jan 24, 2012 0:03:17 GMT -8
I'm pretty sure any bad pod like the Arclite or my Apocalypse have the potential to be useful, the problem being that the times they would be useful are few and far between. Heck my Apocolypse is only any use on flat ground against slow enemies with little protection, while the Arclite would really only be useful against bunched up pods that get sig heavy very quickly.
|
|
|
Post by Gravedust on Jan 24, 2012 8:24:57 GMT -8
Yeah, the Arclite could be situationally good as basically a semi-mobile turret. Stick it behind a couple of walls or somewhere where it's hard to get to /shoot at and pound away with it all day. The lack of speed makes it very susceptible to counterbattery, though.
In all it's still not something I'd probably take if I had a choice though. =P But yeah, there are some designs that can get pretty far into 'works well or very well in some situations but not great in others' territory. Khamsin's another example. It's built as a city fighter and seems pretty well suited to that role, but at range it's pretty worthless.
|
|