|
If I could solicit some advice: I'm not the greatest pixel artist, and I find this a significant roadblock in working on my own personal game development. I find that my three biggest failings are:
With that in mind, what is the best thing to look at/best techniques to use to help myself improve with regards to these aspects?
|
#
¿
Sep 19, 2012 22:16
|
|
|
|
| # ¿ Apr 28, 2024 15:46 |
|
|
Just wanted to say: Thanks for all the advice up above. Here's to trying to improve my abysmal artistic skills. 
|
|
#
¿
Sep 20, 2012 05:21
|
|
|
Mug posted:To add more to this post, does anyone actually look at my game so far and really think "Ugh, pixel art indie game"?. Not really. I've never really gotten tired of pixel art, especially assuming there's stylistic differences used. Something like Demon's Crest is quite stylistically different from, say, Link to the Past, though they both involve pixel art as their fundamentals. I'm ultimately more quick to judge games based on their gameplay than their art styles; I consider the art to simply be a medium to make the gameplay more comprehensible.
|
|
#
¿
Oct 1, 2012 02:41
|
|
|
I'll go ahead and rep Multimedia Fusion 2. As long as you're not trying to do anything really crazy, it's got all of the bells and whistles you really need. The visual programming interface is also excellent for you to learn the basics of programming in, since it makes various functions (like loops/if statements/etc.) more comprehensible to someone who's just starting out.
|
|
#
¿
Oct 4, 2012 05:22
|
|
|
The Kins posted:Kind of interesting to see people arguing for MMF2. It seems to... not have that good a rep anymore in comparison to Game Maker. I mean, *I* like it, but I'm always surprised when someone else does. It's likely just familiarity talking. v  v I've been using MMF and its predecessors for something like ten or eleven years, now, so the event editor and etc. are all second nature to me.I've always been curious as to what the advantages are in GameMaker, however. It does seem to be getting a lot more press nowadays.
|
|
#
¿
Oct 5, 2012 05:59
|
|
|
HelixFox posted:I don't really have a spritesheet - just a messy PSD I use to work on animations, etc. Here are Johnny's updated animation frames (jumping and pushing against a wall weren't in the contest version). The color separation technique you're using is absolutely brilliant. I never would've thought of doing that to make doing animations a little more comprehensible.
|
|
#
¿
Oct 8, 2012 12:42
|
|
|
Mug posted:Haha, creating a window and button based interface is some of the ugliest code in EVERY project I've worked on. It's really horseshit even when working in something like MMF. I always used to think there was some kind of magical method I was missing for it, but, nope, it's literally just moving a whole bunch of poo poo around. 
|
|
#
¿
Oct 11, 2012 04:38
|
|
|
Could anyone recommend some good, comprehensive C# tutorials for Unity? I decided to pick it up on a lark, and I like how there's a lot of things baked in (lighting, physics, etc.), but I'm still completely rear end at programming. I'm mostly looking to learn the major functions and variables I can use and go from there.
|
|
#
¿
Dec 6, 2012 19:05
|
|
|
blowingupcasinos posted:I've been doing codeacademy to get me to stop doing only Multimedia Fusion 2 game making and move into something more professional like Unity. That's a good move, right? You should try just hopping into Unity. I was intimidated as hell moving to that from MMF2, but it's very user-friendly and has a lot of the otherwise hard-to-code stuff (like physics) already baked in.
|
|
#
¿
Dec 11, 2012 23:16
|
|
|
SystemLogoff posted:Well, that's not quite true. RPG Maker XP, VX, and ACE all have access to ruby for more advanced scripting, and coding your own systems. You can recode quite a bit of the base system, except things that call the RPG.dll stuff. (Image decoding, etc) I was honestly surprised at how modular the thing is. It's a good program if your goal is really just Make An RPG, especially since it has a large, active base of users with plenty of scripts you can either use or pick apart to figure out how the systems work.
|
|
#
¿
Dec 17, 2012 18:06
|
|
|
psychopomp posted:I'm looking for suggestions regarding what language/engine/framework to go with here. Unity is probably what you're looking for. It can do basically anything you want with it, and the asset store means that you don't need to be a professional artist to get some good looking graphics for your game.
|
|
#
¿
Jan 10, 2013 05:43
|
|
|
Bit of a weird question, but what would people recommend in terms of 2D graphics: pixel art or vector-based graphics (e.g. Paper Mario, Braid)? I've been working on traditional art as a hobby for nearly a year, now, and would eventually like to transition into making a video game some day. I like the visual appeal of vector-based stuff, but it seems as though it would be a lot harder to animate than pixel art (since you have less fine control over positioning), and I have a small background in pixel art already. On the other hand, there seems be a lot of market saturation of pixel art-based games already.
|
|
#
¿
Feb 11, 2014 20:48
|
|
|
netcat posted:Is Braid really vector based? I always thought the graphics looked hand-painted. Usually when I hear vector based graphics I always picture that horrible flash-game aesthetic. Yeah, I suppose Braid is different - although I'm still not really sure what to call it. Painterly? Traditional? v v
|
|
#
¿
Feb 11, 2014 22:32
|
|
|
Since we're on the subject of Unity and 2D games: what sort of things should I be aware of/reading with regards to getting started in Unity on 2D stuff? I've heard 2D Toolkit and Playmaker mentioned, which both look good, but I'm not sure what I should be aware of with regards to things like tile systems, loading, etc. I'm completely new to making things in Unity.
|
|
#
¿
Mar 10, 2014 16:55
|
|
|
HelixFox posted:2D Toolkit and similar plugins (Futile, etc) predate the built-in 2D support that Unity now has. I don't think Unity has a fresh start tutorial for their 2D stuff yet so it might be an idea to go through one of the simple 3D game tutorials and then look into how 2D games are different. Thanks! Is there anything I should be aware of with regards to "best practices" in terms of the actual coding stuff (e.g., some of the stuff being mentioned here, like image loading)? I've only really had experience with Multimedia Fusion and some Neverwinter Nights modding back in the day, so I'm very much a novice when it comes to working with this sort of stuff.
|
|
#
¿
Mar 10, 2014 18:31
|
|
|
Medieval Medic posted:This is more about the theoretical side of game design than the technical side, but does anyone have tips on keeping focused on one aspect before moving on to another or overreaching? You need to think about the overall design of the game, first. That is: what are the gameplay systems, and how do they fit together? A very basic example of this is a platforming game in the Mario vein. You first need to isolate what actually matters, and then work sequentially based on that design, going from most important to least important. So, you might have a list that looks something like:
Once you've got the basic plan for what your game actually looks like, and have programmed those elements in, you can then begin to add in additional variables if you think it will continue to reinforce the core conceits of the gameplay.
|
|
#
¿
Mar 25, 2014 18:11
|
|
|
Sorry for the weird question, but is there a way to use 3D objects when setting Unity to 2D mode? I was thinking mainly of something ala the old Mode7 effects for a background water/fog or a similar effect. I didn't know if I needed to stick in 3D mode for this, however.
|
|
#
¿
Apr 24, 2014 01:56
|
|
|
Can anyone recommend some good animation software for spriting? I'm using Inkscape to do my actual sprite components, which will then be stitched together and animated, but Inkscape is a little cumbersome to actually do animating in. Is there something similar to Flash that could be used to do the actual animation/spritesheet part?
|
|
#
¿
May 14, 2014 02:56
|
|
|
Shalinor posted:This - and all of Adobe Cloud is currently $10/mo, and there are a few different tools in there you might like. Definitely worth at least trying 'me, see if they fit with your work style. Thanks! I think my school's even got some discounts running for it, so I'll take a gander. Illustrator would be great, too - the bristle brush tool looks fantastic.
|
|
#
¿
May 14, 2014 03:07
|
|
|
Shalinor posted:Not at all. You can't examine the code at all. It is only useful for visual scripting. This isn't like Stencyl. You can easily read and edit the scripts for Playmaker Actions. Just right click on the 'Setting' cog icon on the action, and you can find or edit the script. Making custom action scripts is also quite straightforward.
|
|
#
¿
May 18, 2014 23:48
|
|
|
$95k is a fairly large amount for an indie Metroidvania, honestly. Even highly anticipated games like Hyper Light Drifter started off with much smaller Kickstarter goals. If you've got something that blows every other competitor out of the water, perhaps, but you're throwing your hat into an already common genre. You'd need something significant to stand out for that kind of money.
|
|
#
¿
Jul 23, 2014 03:46
|
|
|
JossiRossi posted:Depends on how much you are undervaluing your team member's time at I guess. I think people should absolutely be compensated well for their time. My point is merely that you're going to need a really bang-up presentation to get $95k for a first-time project in the Metroidvania genre.
|
|
#
¿
Jul 23, 2014 03:51
|
|
|
Zaphod42 posted:Yeah we're getting to where the hard truths just have to come out, he isn't hearing us. Let's try to make this more concrete, PxlWrm: take a look at Sumoboy. This is a well-done Kickstarter. It has a colorful graphical presentation, plenty of information about the game (including shots of a well-polished alpha), praise from various media sources, a notarized summary of expenses, and a team of experienced industry veterans. It was asking for $100,000 and had less than $10,000 pledged before it ended. One of the things that you'll notice when looking through a lot of the wildly successful Kickstarters within your expected funding range is that very few of them actually ask for $100,000 to start with. My suspicion is that people are more skeptical about sending money towards a project with a large funding goal (unless the aforementioned big personalities or unique concepts are there), simply because it seems unlikely that it will actually be reached. The most well-funded projects are ones with smaller initial goals who, through word of mouth and the buildup of hype, are able to shoot past them. Check out Timespinners, which is basically a direct competitor to the game you're looking to make. It was successful based largely on what I can only assume was pre-Kickstarter hype (it was already halfway funded by the time its first day finished) and the strength of its presentation, and gradually grew from there. It has a small, lean team (one guy doing all of programming and art with some sound people working alongside him, which is a fairly common scenario in a lot of smaller indie games) and a functional, polished alpha on display. You're asking for $45k more than what they did. I just don't think it's realistic. The advice that people are giving you here is sound advice that you should heed: you cannot go into a Kickstarter half-cocked hoping to succeed off of the strength of your dreams. Dreams are cheap. You need to do serious research into the kind of pledges you can hope to get at the stage where your new studio is at, and the attributes that make a successful Kickstarter.
|
|
#
¿
Jul 25, 2014 17:20
|
|
|
PxlWrm posted:So you guys don't think that pointing out right at the start of the video that the video below it is all gameplay is enough? One of the first tips of good writing I was taught was that your first two sentences will determine if someone is going to read the rest of your story or not. You have to grab people by their shirt collars, point to your gameplay, and say, "You like this? Watch the rest of the video." Few people are going to scroll much past your opening bit unless you manage to interest them enough to do so. This is especially critical if you don't have any of the big name personalities that other Kickstarters have. I donated to Project Eternity, for example, because I knew Obsidian's reputation was solid and I sincerely respect J.E. Sawyer as a designer of good games. If it were twelve random people with a long video telling me about their gameplay and story vision, without any actual gameplay, I would've turned the thing off within about 10 seconds and flipped to a different page. I'd reckon you have about that much, if not less, to catch people's attention and keep them watching.
|
|
#
¿
Aug 12, 2014 06:04
|
|
|
supermikhail posted:So, you know, any advice? (Not very aggressive, please - I realize all this sounds kind of dumb.) Possibly those ideas could even end in tech demos, so as not to require thousands of man-hours in asset making - I'd be fine with that, too. If you're willing to spend the cash, Construct 2 sounds perfectly workable for what you're interested in doing, assuming you just want to do 2D stuff. I'm currently working with Construct 2 for my little game, and it's going along well. I'm cognizant that Unity allows more freedom and requires less workarounds for certain things, but Construct 2 is so much simpler for me to visually comprehend and work with. Partly this is because I've been working with Klik products since I was 12, but it's also just how the IDE is laid out in such a way that the logic is readable to someone who isn't highly proficient in coding (re: me) and reasonably easy to organize. It's got a few odd quirks (such as being able to draw a value directly from an array in an expression, but not being able to modify that value in any way further in that same expression), but nothing that's prevented me from carrying out what I want to do. Give the free version a shot and see if you like the general layout and IDE. It's got a 100 event limit, but it should give you a decent idea of how it functions and see if it meshes well with what you're looking to do.
|
|
#
¿
Sep 28, 2014 00:34
|
|
|
ToxicSlurpee posted:RPG maker is, in fact, a thing that exists but it has a bad reputation because there are hordes of people assuming they're going to make the next Final Fantasy but totally lack the skills to do so using it. I have very little experience with it myself. I looked at it once long, long ago and found it too restrictive. It's fine for somebody that wants to do a generic thing as a hobby but its restrictions become very apparent very quickly. Even so, if you know any programming at all it's best to avoid kits like that, I think. You could possibly look at Game Maker but I've heard it has its own issues and I didn't like it much. It's not that RPGMaker is bad - it's perfectly serviceable for the type of games it was made to produce - but its restrictions eventually drove me away from it. Even the newest version has an insanely small, hardcoded maximum resolution and a relatively arcane series of scripts for its core systems that I struggled a great deal to figure out. Construct 2 or Game Maker are probably the better options for someone without a great deal of scripting knowledge. You can also get Playmaker for Unity, which uses a similar idea to Construct 2 in how it lays out scripts (with the whole conditions -> actions thing). For me, it ultimately came down to comfort. The fact that Construct 2 is essentially a better Multimedia Fusion means that I can work a shitload faster than if I were trying to scramble around in Unity figuring things out. I recommend trying out a few different programs to see what ends up clicking.
|
|
#
¿
Sep 28, 2014 00:37
|
|
|
cat doter posted:So anyway, I assume plenty people that post in this thread use Unity and plenty of you were once in my position. How do I start? I'm not looking to make the next big MMO and design the logo, I just wanna learn. Well, I guess the big question is: do you know the basics of how programming works, especially in terms of data structures (functions, etc.)? That might be the best place to get started, regardless of what sort of language you're using. Programming can seem like a daunting task until you understand the essential building blocks of how code works. Once I figured out the general logic of coding (and I'm a total idiot when it comes to formal logic and mathematical functions), it became a thousand time easier, with the major difficulty then becoming finding creative solutions for problems and learning the actual language (its inbuilt functions, mostly). Vermain fucked around with this message at 19:11 on Dec 6, 2014 |
|
#
¿
Dec 6, 2014 17:03
|
|
|
That being said, having code that's easy to change and relatively dynamic (such that you don't have repeats of basic functions like menus) will make your life significantly easier when trying to bugsquash or when adding in new features. "Optimization" is a bit of a red herring, but having easy-to-read code that you don't have struggle with to try and edit is never a bad thing.
|
|
#
¿
Dec 7, 2014 16:53
|
|
|
Big Scary Owl posted:Could someone explain me how a button mashing minigame/QTE is made? I mean, it's really just about detecting an input when your game is in a particular state. Let's say that I've got a platforming game, and there's a section where I run across a button-mashing minigame. The Platforming state (which has all of the platforming controls, enemy AI, etc.) in it is turned off, and I switch instead to the Minigame state. Instead of button inputs triggering movement like in the Platforming state, specific button inputs instead add to a variable constantly. A timer is started that decreases by delta-time until it hits 0. If the variable has reached a certain arbitrary number when the timer hits 0, the minigame is completed, and it switches back from the Minigame state to the Platforming state. If the variable fails to get to that arbitrary number (because the player didn't input enough button presses in a period of time), then the Minigame state resets and the player repeats it. The only really tricky thing here is establishing exactly how many button inputs is "enough." Do some experiments with a simple application to see how many times you can mash a button in X seconds, and then adjust the arbitrary number accordingly (along with feedback from other players, since not everyone's reflexes are the same).
|
|
#
¿
Dec 27, 2014 02:25
|
|
|
Dewgy posted:I would guess you basically make a tug-of-war kind of deal in your variables, where every button press adds some amount and every frame passed removes some amount, so the faster the player is in button smashing the higher the variable is after a number of frames (speed, strength buildup, etc), meaning they do better. Yep. Just make the code automatically subtract a certain amount every frame. Keep in mind that this is equivalent to the player having to press Y times more over a particular period, so you can first come up with your initial target number (say, 50 button presses over 10 seconds), figure out how much the variable will fall per frame (say, 2 * dt, for a total of 20), and then set the new target number to the initial number minus the total fall in the variable (50 - 20 = 30 button presses over 10 seconds). This will require the same amount of effort on the player's part as if they didn't have the constantly falling variable. It's mostly just an aesthetic thing that gives the feeling of having to "pull against" something.
|
|
#
¿
Dec 27, 2014 05:30
|
|
|
Yodzilla posted:What in the gently caress is your game. A Zombie Nation remake, clearly.
|
|
#
¿
Dec 29, 2014 06:10
|
|
|
Omi no Kami posted:The meat of the game is the depth of the living world and the fact that it's built to be 90% procedural, and there's already a real wealth of data to inform investigations, but just switching between sneaking through someone's house stuffing things in a sack, then taking things out of that sack and showing them to people while screaming at them doesn't feel like a full game. I want you to watch this video (sound is a bit loud at the start), because the idea that a game isn't "complete" unless it has some kind of advanced combat system is fallacious. This video specifically addresses L.A. Noire, a game in the same sort of genre as yours, so the criticisms in it will, I think, help to inform your own design.
|
|
#
¿
Jan 16, 2015 03:23
|
|
|
Dirty posted:I guess one other thing I should mention - try to keep in mind that every step is necessary in finishing your project. Even the boring bits like console tweaks. It's progress. Yeah, this is important. I'm going through UI work right now and it is hella boring and doesn't seem like it's very important progress on its face, but the game will not run without it.
|
|
#
¿
Feb 12, 2015 18:10
|
|
|
JossiRossi posted:I feel the role of music should be to help set the tone of a game. Some people essentially try to fake a tone with the music, by adding a lot of grandiose orchestral work to make a game seem really "big". This works when the rest of the themes match, but if the game play or art or story don't also add to this, it simply doesn't work. Another good point is that the music ought to fit the environment. You don't have to be cliche about it, but there's compositional elements that are so widespread that, even if you've never played the game (or seen the film, whichever), you can tell where it's supposed to be taking place in. Here's an example from Donkey Kong Country. I can bet you that, if you showed it to someone who had never played the game before, they would still be able to guess the kind of environment (aquatic) that this music plays in. The Arctic Waters theme sounds too generic to really express the same thing. It's got that sort of standardized heroic composition to it (Pirates of the Caribbean, etc.), but it tells me nothing about where I am, and I thus feel less connected to what's onscreen. To highlight this: One of the most effective uses of music in recent memory is Dark Souls 1, which uses almost no music (except for boss battles). Nevertheless, it is incredibly atmospheric, since it emphasizes the lonely nature of the game world (sometimes the only sound you can hear is ambient wind and your own breathing) and lets other sounds (dragons roaring, and so on) serve as the rest of the composition to accentuate key moments. Vermain fucked around with this message at 20:06 on Feb 26, 2015 |
|
#
¿
Feb 26, 2015 20:01
|
|
|
SweetBro posted:So in my great search to outsource some art, I've found that despite expectations the most reasonable offers in terms of price for professional quality come from people in countries with high cost of living. It's not too counterintuitive. In a competitive market, competition will gradually drive your price down (especially if you're competing with areas that have low cost of living), meaning that you just work more to pick up the slack of not being paid as much.
|
|
#
¿
Feb 27, 2015 20:51
|
|
|
simosimo posted:Do you think it will help to get my concepts on paper first, then when a basic idea is formed [hopefully I will see what I want from game design, rather than learning how to make mario when I want minesweeper, (for example)]. My creative mind is going a mile a minute, but I gotta look at cubes for a while Yes. You should always, always do a bit of planning beforehand, because it's hella easy to slide off into Ultimate Game Fantasy Land and completely lose sight of actually producing and releasing a completed game. For a first time project, I would recommend nailing one specific gameplay system that you want to focus the game around. In Super Mario World, this focus was on jumping. In Thief, it was on stealth gameplay. In Chrono Trigger, it was on RPG combat. Having this kind of focus makes it easier to plan the rest of the game around it, rather than having a bunch of ideas that you try to stitch together into a workable game. I know this gets repeated ad infinitum, but start small. The reason for this, especially when you're doing programming for the first time, is more than just it being easier to manage. The biggest reason is because your code's going to be an absolute mess, because you're working piecemeal to try and get basic systems up and running, and some of those pieces of code are going to conflict and interact with eachother in weird ways. If you've got a small game that does some really basic stuff, it's not a huge problem. Even if the game doesn't work beautifully, it gives you valuable experience with regards to what to do/not do the next time around, so that when you do make some really big dream project, you have the ability to organize your code in a way that's easy to understand and easy to bugfix. If you need any basic explanations about code, etc., don't be afraid to ask in here, or send me a PM. I come from a similarly inept background when it comes to programming, so I don't mind explaining the basics in the simplest way possible.
|
|
#
¿
Mar 4, 2015 07:40
|
|
|
It's basically a matter of determining stat weights (that is, how important each stat is to the specific goal) and the degree of randomness you want your game to have. D&D, for example, uses a 1d20 roll (that is, a roll of a single, 20-sided die) for the majority of its random elements. This creates wild swings in the combat, where your chance of getting a 1 and a 20 are both equal, and you thus have some combat encounters where you obliterate the enemy and others where you're missing every second attack. Using something like, say, 2d20 (two rolls of a 20-sided die) creates more of a Bell curve distribution, meaning that a 1 or a 20 are comparatively much rarer than the "average" roll. This reduces the randomness of the rolls so that you're much less likely to get strings of fantastic/poo poo rolls. It's important to note that neither of these methods are "better." It's entirely about the kind of game you want to make. D&D's 1d20 can be swingy as hell, but it also produces moments of great tension or triumph when the numbers line up the right way. A game that uses 2d20 has less of these moments, but is also less random to deal with and produces fewer moments of frustration where everything keeps missing. For the kind of system you're trying to make, you'll probably want to establish a basic "outcome range" that will determine what happens when the algorithmic result lands in a specific part of that range. In D&D, attack rolls (that is, a 1d20 + any attack roll bonuses a character has) are made against an enemy's defense defense (basically, the difficulty of actually hitting an opponent). If your attack roll fails to meet the defense number, or the die lands on a 1, it's a miss and no damage is dealt; if it equals or exceeds the defense number, it's a hit and damage is dealt; and if the die lands on a 20, it's a critical hit that deals additional damage. You can make this more or less granular depending on the degree of complexity you want. You might have it so that, on a 100-point range, a 1-19 is a dropped ball, a 20-39 is a catch but with a speed penalty (or a minor stun or something; you caught the ball, but at an awkward angle), 40-59 is a regular catch, etc. You might have a Catching skill, but also a Footwork skill, with the Catching skill being weighted more for attempting to catch a ball (so that 100% of the value of the Catching skill is added) compared to the Footwork skill (so that only 50% of the value of the Footwork skill is added). These skill values are added to a random roll (again, determine how much randomness you want the player to have to fight against for this part), and an outcome is determined based on where this combined value lands on the established outcome range. Vermain fucked around with this message at 00:31 on Mar 13, 2015 |
|
#
¿
Mar 13, 2015 00:28
|
|
|
the wildest turkey posted:Legitimately curious: what, in your opinion, is the alternative? I just feel like if you're playing a game where your chance to succeed is based on a die roll, then you can't complain when the die doesn't roll your way. Having methods to mitigate bad rolls (preferably tied to a resource) is one of the better options, especially if you've got very all-or-nothing outcomes for certain rolls. 4E D&D, for example, has numerous once-per-fight (and sometimes once-per-day) powers that give you rerolls or provide boosts to a specific roll if you happen to fail it, which makes the relatively binary nature of combat and skill checks less aggravating (since you have ways, limited though they are, to overcome bad rolls at critical times).
|
|
#
¿
Mar 14, 2015 04:00
|
|
|
Onion Knight posted:To tie it back in to the RPG discussion, read the TG GM Advice thread sometime, because there's a lot of good stuff about game feel and making players feel satisfied by a "fair" and exciting environment. One thing that is agreed on almost universally (with the exception of only the must tedious grognards) is to lie about failing dice rolls that would frustrate your players. I disagree strongly with this assertion as someone who's both DMed and played in tabletop games before. If a game system is designed as such that it needs to regularly lie to its players about the outcomes of dice rolls (because the alternative is a feeling of "unfairness"), then you should either have outcomes that are less "all-or-nothing" (which is where the feeling tends to stem from), or you should have methods of mitigating bad rolls built into the system. Transparency in system design is critical, as it allows players to make informed decisions about how they play the game, rather than having weird under-the-hood mechanics that attempt to remove "unfairness" without player input.
|
|
#
¿
Mar 14, 2015 04:55
|
|
|
|
| # ¿ Apr 28, 2024 15:46 |
|
|
al-azad posted:I don't think anyone is arguing it's right to regularly lie. But the DM's job is to make the game fun and sometimes that means gauging the players' disposition on the fly. If the DM looks in their toolbox and says "this is a legal action but will kill the mood if I open with it" they're doing their job. I've left a game with a TKO feeling satisfied because it was hard fought. If the DM opened with a circle of death and we all died it would've sucked. Again: this is a consequence of a poorly designed system. If we are designing a system from scratch (which is the assumption here), the objective should be to design it in such a way that a feeling of "unfairness" as a consequence of random elements never develops in the first place. This is easy to do, with one or more of the several different methods that have been given: 1) Ensure that the range of outcomes is more granular and less "all-or-nothing." 2) Ensure that the randomization fits a Bell curve to reduce the frequency of very high/very low results. 3) Ensure that players have some way of mitigating the effects of bad rolls, such as through a resource that allows them to reroll. If you've designed a system where you have to switch out a bad dice roll behind the scenes to make the game feel fair, then you've designed a bad system.
|
|
#
¿
Mar 14, 2015 06:04
|
|