All RPGs and Storygames by Tod Foley are now available at DrivethruRPG and RPGnow. Bring these games to your table!
For those following along from the sidelines, Drupal 8 core has 3 modules that make up the migrate sub-system. For the past few years, the community has been working very hard to get these to a stable state an out of their "experimental" designation. Drum role please... as very soon the first of these modules is going to do just that. Go stable. The migrate module (also known as the API module) should have its last critical release blocker committed in the next few days. At which point, this module can be called stable.Admin User Fri, 12/15/2017 - 08:06
If You’re Not Familiar…
My schedule lately has been… less than stable, so my gaming has been coming in small chunks. I’ve got games I play in and run that go off once a month or once every two months, I’ve got one-shots that occur on sporadic weekends, and when I feel the need to get some time as a player and just jump into a game, I find a local adventurers league game and throw something together to play.
If you’re not familiar with Adventurer’s league games, D&D’s current organized play model, they are fairly formulaic, super light on story, and focus more on combat options. They are great fun for jumping in without prep, buying into the railroad, and getting some play in. In adventurer’s league games, everything is logged and there are strict rules to how your characters level. I’ve worked on products for adventurer’s leauge games and I’ve played in more than a few. While they are sometimes light on deep story, focusing more on the play aspects of the game, they distill D&D down to its core game and…They Are Really Effective At Doing Combats, Especially First Level Combats
Playing characters in AL games mean there is a lot of playing through level one adventures, and combats made specifically to be the first combat your low level character ever sees. One thing I learned from playing in the various games offered around Columbus (there are many) is that there is an IDEAL style of combat for low level characters, especially if it is the first combat.
If the first combat doesn’t fit into the ideal, things can go very wrong for the game down the line. Even if a formulaic game, like some AL games can be, the first combat is an essential part of the plot, story, and action. It has certain purposes it needs to fulfill. This holds true for games that are not D&D, but really for any game that has combat as a general them. Combat is always a challenge, something for the players to overcome, using their characters abilities. If it is too hard, it stalls the action or kills morale up front. If it is too easy, it sets a tone for how the rest of the challenge of the adventure will be. If it feels like it has no connection to the overarching plot, it just feels like a time filler. So, what do I see as the ideal first level combat?A Formula For The Ideal First Level Combat For Any Game
Elements of this will change based on the game you are playing and the goal you are trying to achieve with the first combat, but here are my guidelines for an ideal first level combat.
- The enemies should be somewhat squishy – The players want to feel that their combat abilities matter, so the enemies used in the first combat shouldn’t be tanks or impossible to hit for their level. The enemies don’t need to all be one-shot kills, but the players should be able to get in a good blow and take out at least one enemy with ease. It could be a group of small squishy enemies and one or two harder to take down enemies, but the first combat shoudl validate characters ability to affect the world.
- The enemies damage should be a threat, cumulatively – You want the damage of an enemy to feel threatening, but not one shot most of the party. Taking the squishy enemy example from above, each time one of your enemies makes a hit on a character, it should be a small amount. Not enough to kill them at once, but enough that 3 or 4 hits takes a person down. If you are using one or two more threatening enemies alongside your squishy enemies, then their damage levels can be much more threatening, marking them as the true danger in the combat.
- The Right Number of Enemies – So far, in our example, we’ve got squishy enemies with minimal damage, and one or two more threatening enemies with more impressive damage, but how many of them? That will depend on the number of player combatants (PCs and NPCs on the players side). You’ll want enough squishy enemies that each player can take out one or two on their own, or if they have an area of effect ability, or clever use of terrain or scenery, they can take out multiple. The many squishy enemies are a threat in numbers, meant to distract and harass so that they characters can’t focus on the bigger threats. A fairly standard option would be 2 per PC that is very combat oriented, or 3 per PC if there are some good area attack options.
- The Big Enemies – The smaller squishy enemies are primarily there to give the players something to push through to get to the real challenge, which is the big enemies who are harder to take down and who do a bit more damage. Because there are less of them, perhaps one or two per combat, they can provide a large threat, but not a constant threat in the way the many squishy enemies do. One shot from these enemies will put a character close to dead, but that means they shouldn’t get too many attacks like that, perhaps that these bigger attacks don’t happen until the 3rd of 4th round once the smaller squishy enemies are already engaged.
- The Rewards Should Be Commensurate With The Threat – As far as the threat goes, a combat like this should feel fairly threatening, and the rewards should match up for the level of threat. Included in the rewards should be something to restore any fallen characters to full health, or near full health, and something that provides a small boost in wealth, if that is the vibe of the game. A bigger reward should also be in something that progresses the plot forward, something that helps validate the combat that just occurred. If you are using a game system where leveling up occurs based on what you have defeated, there should be a small boost to the next level based on this combat. It’s not necessarily enough to level the characters up, but for the players to get a taste for the next level and feel the reward as a tangible thing.
- And It Leads To… – Maybe this first combat is just the introduction, a way to shake out the bugs on the characters and provide a small bonus (in wealth and xp) in exchange for a moderate threat that they can mostly recover from. It validates their choices to buy healing potions or bring a cleric with them or upgrade their armor. Once they are done with this one and slightly recovered, the next threat might be right around the corner. The next combat can be whatever is needed, but it is now in line with the first combat and follows through with the challenges set up by the first one.
Unsurprisingly, it has more to do with the story and the experience than it does with the actual combat. Every part of the formula: 2SLDper+2BT+CR+PP (2 Squishy Low Damage per PC + 2 Bigger Threats + Commensurate Rewards + Plot Progression) is meant to provide a valid threat with a valid reward that gives the characters a bit of a workout while progressing the story. The end goal is how it feels to the players at the end. It feels like the squishy enemies were a threat because there were many of them, it feels like they got some early wins by easily taking out many of the squishy enemies, it feels like a bigger threat because the bigger enemies really hurt them with just one hit, it feels like the fight was worth the rewards in loot, and it feels like the combat mattered because they got to push forward with the story.
Unsurprisingly, it has more to do with the story and the experience than it does with the actual combat. It all comes down to how the players feel at the end of the combat. They feel validated, threatened, shaken out, recovered, a little proud, and like they matter to the story. While the 2SLDper+2BT+CR+PP formula is pretty D&D specific, it holds for other sorts of games that have similar combat scenarios. Even in very narrative games, where combats are handled with less mechanical rules, the formula still holds, in theory. It may not be 2 squishy enemies per PC, but one because Squishy enemies are not as much of a concept in deeply narrative games and mechanical combats tend to be less of what drives the game along. In these cases, you still want enemies that are easier to defeat, an enemy or two that are bigger threats, rewards that feel commensurate to the challenge, and progression of the plot.Your Take
This is all based off of games I’ve run and played and thinking about what the first combat means to the player perspective, but what is your take from your experiences? What was the best first combat scenario you ever played or ran, why was it good, and does it fit the idea behidn this formula? What would you change about the formula to make it fit the vibe of your games better?
Checking conversion factor values between units can be cumbersome, as we have to edit every unit to see that value, and you can't see all them at the same time.
This module extends Units module to show those conversion factors in all unit table list screens. See attached image for details.
Provides a per group theme functionality for the Group modules. In many ways, it is equivalent to OG Theme module for Organic Groups.
Dependency : https://www.drupal.org/project/group
This is part 7 of our series processing the results of the Amazee Agile Agency Survey. Previously I wrote about defining work, this time let’s focus on estimations. How do you estimate and who does estimations in your teams?Josef Dabernig Fri, 12/15/2017 - 11:46
First, we asked about how teams estimate. 43.3% of the contestants answered “Estimation is done in days/hours”, 20% say “Estimation is done in story points based on complexity” and 16.7% mentioned, “Estimations in done in story points based on effort”. The remaining answers of 3% each varied in different degrees of combined estimations, i.e. teams would estimate on a higher level using story points and compare then against hour based task estimations. Also one of the 30 contestants answered that they don’t do estimates at all. For some background information, you can refer to this article on story points.
At Amazee we do two different kinds of estimations. We estimate in days for the offers that we create and put a general price tag below the contract. This is intended to fix a budget but not to guarantee an exact feature set to be delivered. When we go to the implementation phase, teams estimate Jira tickets using story points. The story points are based both on complexity and effort, based on our velocity we can related story points to a price tag and compare against the initial offer and how much budget is left.
We also asked about who is involved in estimation. 50% say that “the entire team does all estimations”, 36.7% mentioned that “a tech lead does high-level estimates, the team estimates on a lower level”. 6.7% say that “a tech lead does all estimates”.
For us, at Amazee we tend towards having a tech lead doing high-level estimates and having the team estimate on individual stories and tasks which get prepared for a sprint to work. The tech lead role can be fulfilled by any developer of a Scrum team and may change however the team and the team lead decide it would work best. More complex offers get challenged by multiple developers, more straightforward suggestions will be estimated by only one developer together with the PO. All proposals get reviewed by management. When the team does estimations, we do them along with the entire Scrum team. In some instances, we will limit the number of people in estimation meetings to find a balance between shared knowledge and how much time can be spent discussing as a group of people.
How do you estimate? Please leave us a comment below. If you are interested in Agile Scrum training, don’t hesitate to contact us.
Stay tuned for the next post where we’ll look at client interactions.
This Drupal module extends the CultureFeed Drupal module suite.
It adds the functionality to create a personal list of events a person would
like to attend.
Note: Items are automatically removed once they are passed via a cron hook.