Storium Theory: Inaction In Action

Sometimes, I see players make comments in a game, explaining why they haven't made a move in a challenge so far:

"I don't think this is something my character knows how to deal with."

"I'm not sure she cares about this."

"I think he's just kind of stunned right now.

"She doesn't know what to do."

Sometimes these are indications of a problem in the story - if all of a narrator's players are telling him their characters don't care about the current situation, it is probably time to revise the situation and figure out how to better relate it to the story at hand.

But...more often, they're a statement that is actually pointing directly at a very interesting opportunity for the character: A chance to make inaction your action.

When you're writing the story of a challenge, things are happening, whether your character is acting on them or not. Each move drives the timeline of the challenge forward. When a card is played, something happens, and the challenge moves positively or negatively, or just towards the end of its story.

So...if your character, for instance, doesn't know how to deal with something, and chooses not to act...that's a choice. And that's his "action" for that moment in the tale.

So let it be an action! Make your move! Show your character's uncertainty or confusion about what to do! Show how your character hasn't cared about the situation, if that's the case, and chooses to ignore it! Show how the situation has left your character stunned, or how he's tired and needs rest, or how his injuries prevent him from joining the battle!

Sometimes, those things are treated as reasons not to make a move, but...that's not what they should be. They are, in fact, excellent opportunities to make moves.

Especially...especially...if you have either Weakness cards to play, or a Subplot.

I'm stunned. I'm confused. I'm shell-shocked. I'm injured. I'm exhausted. I just plain don't care about this.

Those are all excellent weakness plays.

When a situation is ongoing and your character chooses not to do anything about it, that's a great opportunity to show what starts going wrong with the situation because your character is not preventing it. Philosophically, there's nothing really different here from if things start to go wrong and your character tries to prevent it and fails because of a Weakness, right? Something goes wrong either way. The difference is just that your character, in this case, didn't do something to stop it instead of doing something but getting it wrong.

What about Subplots? Well, Subplots are great for these situations too! When a character is shocked into inaction, when she finds something she doesn't care about, when he struggles to understand what he's supposed to do in a situation...those are great times to explore the other mysteries in a character's life or the things the character does care about. There are some excellent subplot moves available that show how the character withdraws into themselves, or starts thinking about how all this ties in with their personal problems, or tries to examine where they are right now...and because of all that, something starts to happen in the current situation, and they're not really sure what to do in the face of it...or even if they should do something.

A subplot isn't a weakness play, mind, so chances are nothing ends up going outright wrong right away, but you can certainly hint that something will! While your character is distracted by his own thoughts, or full of self-doubt, or struggling with what he's supposed to do, or disinterested in what is happening, how does the situation evolve?

If your character doesn't seem certain of what's going on, or doesn't know what to do, or just plain doesn't care...don't just drop out of the challenge. Use that to advance the challenge.

Now...one more point on this. Especially in the case of a character that "doesn't care" about a challenge, this can actually be a great way to figure out what would make them care, and therefore explain how a Strength comes into play, or at least how they get involved in the challenge despite their feelings. If you find yourself thinking that your character just wouldn't get involved for some reason or another, put a little time into thinking about what might happen because of that decision.

Then, write a move based on that...and maybe, maybe midway through the move, you'll realize the character now does know what to do, or does care about the situation, as she sees what is about to happen, or starts watching something she does care about slip away.

Maybe that leads to the character using a Strength and turning things around after all. Or maybe the character ends up doubling down on fear or uncertainty, or just takes the wrong action, using a Weakness. Or maybe, the character's Subplot drives him forward, making him engage with the challenge now that he's seen what it could mean if he doesn't.

Now...this isn't something you need to pull in all the time. (And to be clear, if you find yourself constantly trying to figure out why your character would get involved in something, it may be time to talk to the narrator about how to make your character mesh better with the story.) But there are times when an inability to think about something that your character would do can itself be precisely what drives the story forward and makes an interesting situation.

Don't overuse this, but...keep it in the toolbox. It's a handy trick to pull out and it can lead to some astonishingly interesting moments for a character if used properly.

Remember Spider-Man and Uncle Ben...sometimes, when your character doesn't take action, that ends up driving his story more than anything else.

Come And Play Oceanhorn 2 At GDC 18!

This year we travelled to a (not so) sunny San Francisco on Epic Games' invitation to show Oceanhorn 2 at the Unreal Engine venue at GDC 18. What an amazing opportunity! We prepared a great demo to show at the expo, so if you're an Oceanhorn fan, make sure to drop by and play the latest build of our game. You will also meet us, the developers, and have a chat!


Look at that! Our latest demo takes you to the Great Jungle of Pirta, where the Owru nation is divided by an old grudge. Will our heroes be able to unite the owrus and get them to join the fight against Mesmeroth's Dark Army.

Yes, I said heroes! One of the defining features of Oceanhorn 2 is the party members, who will be on your side through the adventure. Trin, the granddaughter of Arcadia's leader Archimedes and Gen, a mysterious robot wielding an old samurai weapon eki.

The game is still far from being finished, but it will be worth the wait!

Tech Book Face Off: Facts And Fallacies Of Software Engineering Vs. Programming Pearls 2

Since I've been hitting the tech books pretty hard for a while now, for this Tech Book Face Off I wanted to take a bit of a breather and do a couple of relatively easy reads. These books have been on my to-read list for some time, so I decided to finally check them out. The first one, Facts and Fallacies of Software Engineering by Robert L. Glass is a book in a similar vein as The Pragmatic Programmer in that it relates various tidbits of advice on the craft of software engineering. As for Programming Pearls 2 by Jon Bentley, this book surprised me. I thought it would be somewhat similar to Facts and Fallacies, just more directly related to instructive programming examples than to the software engineering field at large, but it turned out to be quite a bit different, as we'll see in this review.

VS.

Facts and Fallacies of Software Engineering

Robert L. Glass is an odd duck. His writing is at the same time strongly opinionated and calmly easygoing. He adamantly argues for each of his observations as 55 facts, with 10 fallacies thrown in at the end, but his discussion of each one is quite conversational. He admits that not everyone will agree with his facts, even though he provides evidence and sources for them. (Well, he does for a majority of them, at least.) I found this book a quick, enjoyable read, and it was worthwhile even if I didn't always agree with his propositions because they always made me think. I'd much rather read a book that I sometimes disagreed with if it challenges me, than a book that's poorly written and says everything I want to hear.

I'm not going to relate every fact and fallacy from the book here, since that would make this review nearly as long as the book, but they do cover the gamut of software engineering. I'll describe them in broad strokes and discuss a few that I found especially interesting.

The first chapter deals with software management related things. The facts are broken up into smaller sections of people (the software engineers), tools and techniques, estimation, reuse, and complexity. A full 22 facts are covered in this chapter, including one about how tools and techniques are over-hyped that I found particularly thought-provoking. Even back when this book was written in 2002, tools were being promoted as a panacea for software development problems while they were simultaneously showing diminishing returns, and Glass was having none of it:

Time was, way back when, that new software engineering ideas were really breakthroughs. High-order programming languages. Automated tools like debuggers. General-purpose operating systems. That was then (the 1950s). This is now. The era of breakthrough techniques, the things that Fred Brooks (1987) referred to as silver bullets, is long since over. Oh, we may have fourth-generation languages ("programming without programmers") and CASE tools ("the automation of programming) and object orientation ("the best way to build software") and Extreme Programming ("the future of the field") and whatever the breakthrough du jour is. But, in spite of the blather surrounding their announcement and advocacy, those things are simply not that dramatically helpful in our ability to build software.

What's most interesting is that 17 years later, the hype machine hasn't stopped, and it shows no signs of slowing down. I wouldn't say that's surprising, given that software engineering is such a massive sector, and people continue to try to make money off of it however they can, but it shows how relevant this book still is. Advances in software engineering ideas do still happen, but they are still incremental. It isn't that incremental is bad, but it is all that we should expect now. Productivity free lunches aren't likely to come about anymore until the next breakthrough technology happens, and that may not be software but something else entirely.

Chapter 2 is about the software life cycle with sections on requirements, design, coding, error removal, testing, reviews and inspections, and maintenance. Maintenance in particular is a fascinating subject in software because it ends up taking the majority of the time and cost of any given project, mostly without our realizing it. It's also quite difficult and no one wants to do it because the documentation sucks. There's a reason for that:

To solve those problems, software people have invented the notion of maintenance documentation—documentation that describes how a program works and why it works that way. Often such documentation starts with the original software design document and builds on that. But here we run into another software phenomenon. Although everyone accepts the need for maintenance documentation, its creation is usually the first piece of baggage thrown overboard when a software project gets in cost or schedule trouble. As a result, the number of software systems with adequate maintenance documentation is nearly nil.

Here we can see both Glass' conversational writing style and the reasonable way of thinking that he shows in most of his facts and fallacies. It's hard to argue with this one, especially because I think most of us have been in similar situations.

The next chapter is about software quality, including sections on quality, reliability, and efficiency. Like the other chapters, these facts are mostly obvious to anyone who has been working in the field for more than a few years, but it's always good to refresh your memory on these ideas. The last chapter of facts is just a single fact on research: many researchers advocate rather than investigate. I can't say whether or not this is true from my own experience or reading, but I'm not too concerned about it.

Starting with chapter 5, the next three chapters deal with the 10 fallacies. Chapter 5 loops back around to management with similar sections to the first chapter. The fallacies include things like, "you can manage quality into a software product," and "software needs more methodologies" that are hard to argue with. You can't, and it doesn't. The next chapter mirrors chapter 2 with some fallacies on the software life cycle. I thought he was unfair in his discussion of the fallacy, "given enough eyeballs, all bugs are shallow" by saying:

This is probably just wordplay. But it is patently obvious that some bugs are more shallow than others and that that depth does not change, no matter how many people are seeking them. The only reason for mentioning this particular reason here is that too many people treat all bugs as if their consequences were all alike, and we have already seen earlier in this book that the severity of a bug is extremely important to what we should be doing about it. Pretending that turning scads of debuggers loose will somehow reduce the impact of our bugs is misleading at best.

This seems like a deliberate misinterpretation of the idea of the quote. It's not saying that more eyeballs will make bugs less critical. It's saying that any given bug is easier to find if more people are looking for it because the more people that look for the bug, the more likely that a person with the right expertise will see it and be able to fix it quickly. Or it will be more likely that someone looking for the bug will randomly happen to look in the right place and spot its signature quickly. However, I think there are still issues with depending on this approach for open source software development, but for other reasons. Most open source projects don't have the luxury of having hundreds or thousands of programmers working on it. Frankly, most projects are lucky to have more than one programmer working on it, so the responsibility of finding and fixing bugs still falls on the programmer writing the code. Even if the project has high visibility, pull requests need to be of high quality, or more bugs will be introduced over time than will be fixed and the whole project will degrade.

I also took issue with the fallacy in the last chapter: "you teach people how to program by showing them how to write programs." Don't get me wrong, I do think this statement is false, but for different reasons than Glass gave. He thinks it's more important to teach budding programmers how to read code and that academia isn't doing that:

I know of no academic institution, or even any textbook, that takes a reading-before-writing approach. In fact, the standard curricula for the various computing fields—computer science, software engineering, information systems—all include courses in writing programs and none in reading them. 

I disagree on three counts. First, let's get the easy one out of the way. Programming is about more than writing or reading code. Teaching programming involves teaching critical thinking skills, problem solving, systems thinking, user psychology, and so much more! Second, and more directly related to his reasoning, the exact same approach is used in mathematics. Schools teach students how to write math solutions well before teaching them how to read math solutions. Most people will never get to the point of reading and understanding mathematical proofs, but everyone starts with solving basic arithmetic problems. That's how we start in programming, too—by writing basic programs.

Third, I would argue that universities and textbooks are, in fact, teaching students to read programs at the same time as writing them. The examples in the books are all there to read, and the student must read and understand them in order to write their own functioning programs. The first example programs may be short and simple, but I would hardly expect someone brand-new to programming to read hundreds of lines of code without first being taught the syntax. Learning to read is unique in that the student is being taught a skill that is required in order to learn most other skills, so of course we learn to read before we learn to write, but not much earlier. We start learning both in kindergarten, right? Besides, most people don't know how to read effectively anyway, even though they technically learn to read first, so I don't see why a pure reading-before-writing approach to programming would necessarily be better than what is currently being done.

As you can see, some topics in this book are quite controversial, and that's why I really enjoyed it. No one who reads this book will agree with everything, and that's okay. It's meant to raise a debate, and Glass does a great job of presenting a strong case that you can take a stance against if you disagree. It got me thinking over ideas that I've held on to for a long time, and we all need that from time to time. It's also a fairly short book, so there should be no excuse to not read through it. I highly recommend it.

Programming Pearls 2

In the introduction I said this book surprised me, and what I meant by that was that it was not at all the book that I expected. From the title alone, I was expecting a book similar to Facts and Fallacies of Software Engineering in that it would relate a number of experiences and advice from Jon Bentley's career about how to do software development more effectively. I suppose that's what this book is, in a way, but it's more of a combination of an informal algorithms book and a practice set of programming problems.

It's not nearly as thorough or rigorous as Introduction to Algorithms (CLRS) or Algorithms by Sedgewick, but it gives a passable review of most of the fundamental algorithms for sorting, searching, and storing data. The first chapter starts off with an interesting little algorithm that I had never seen before on sorting a list of numbers with a restricted range using an array of bits. In this case it was telephone numbers, and it was accompanied by a story about how he was helping a new colleague with a problem, but the algorithm itself could be useful in plenty of situations. 

The next chapter continued the thread from the first chapter with a few more problems that could be neatly solved with novel algorithms, like finding all possible anagrams or swapping unequal halves of an array. The third chapter covered ways to make programs much more efficient by correctly structuring the data that was being manipulated. The classic example is using an array instead of a set of numbered variables, but Bentley gave other examples as well, like creating a simple template language for form letters. 

Chapter 4 was all about program correctness, using the binary search algorithm as a conduit for discussing the pitfalls of complexity and how to formally verify a program (or at least a function, since formal verification just doesn't scale). The last chapter in this first part of the book quickly covers testing, debugging, and performance timing. That completed the preliminaries, which is what the first part of the book was about, and throughout these chapters Bentley had short, direct advice about how good programming was about balance:

Good programmers are a little bit lazy: they sit back and wait for an insight rather than rushing forward with their first idea. That must, of course, be balanced with the initiative to code at the proper time. The real skill, though, is knowing the proper time. That judgment comes only with the experience of solving problems and reflecting on their solutions.

I think some later writers in the field took this idea of the lazy programmer to the extreme, but I like this nicely moderated perspective more. He had a similarly measured view about performance optimizations:

Some programmers pay too much attention to efficiency; by worrying too soon about little "optimizations" they create ruthlessly clever programs that are insidiously difficult to maintain. Others pay too little attention; they end up with beautifully structured programs that are utterly inefficient and therefore useless. Good programmers keep efficiency in context.

There are no universal answers in programming, so there shouldn't be any universal advice, either. These comments make the point that you can't turn off your brain when programming. You have to constantly consider everything that would have an effect on the problem at hand in order to come to a more optimal solution.

The second part of the book is all about performance. Chapter 6 kicked things off with a look at the n-body problem in physics for simulating the forces that bodies exert on one another. Making the simulation fast was not only about developing a good algorithm, but also using the right data structure, tuning the code for the machine it was running on, and optimizing performance critical loops in assembly. A recurring theme in the book was that there's no silver bullet, and this case study exemplified that with its multifaceted optimization process.

The rest of the chapters in this section expanded on the ideas brought up in chapter 6. Chapter 7 talks about how to estimate with back of the envelope calculations. Chapter 8 discusses various algorithm design techniques including the all important divide-and-conquer approach. Chapter 9 delves into when and how you should do code tuning to get the biggest benefit. Chapter 10 looks at how performance can be improved by reducing space, both of the program code and the data that it operates on. Every chapter had succinct little examples and highly condensed code to show the essence of optimized programs, along with interludes of advice like this:

[E]very now and then, thinking hard about compact programs can be profitable. Sometimes the thought gives new insight that makes the program simpler. Reducing space often has desirable side-effects on run time: smaller programs are faster to load and fit more easily into a cache, and less data to manipulate usually means less time to manipulate it. The time required to transmit data across a network is usually directly proportional to the size of the data. Even with cheap memories, space can be critical. Tiny machines (such as those found in toys and household appliances) still have tiny memories.

It's good to remember that not all programming is done on massively powerful processors, even today with a supercomputer on every desk and in every pocket. We have just as many small processors with limited memory and a tight power budget doing plenty of complex calculation tasks.

That brings us to the last section of the book on five interesting programming problems. The first one is on sorting with quicksort. The second one is about how to draw a random sample from a larger collection. The last three are on searching, heaps, and strings. The last problem dealing with strings was a great way to end because it was actually about how to teach the program how to generate english words and sentences using example material. It was a chapter on machine learning written before it was cool.

On the whole, this book was a fairly enjoyable, quick read. Bentley is clear and to the point, even to the point of being abrupt. As an algorithms book, it's not up to the level of the more formal algorithms books, and it wouldn't be very useful as a first book on that material. It is a good summary of the basic sorting and searching algorithms with some interesting unique algorithms thrown in to spice things up, making it a decent review for the more experienced programmer. If you're looking for an easy second or third book on algorithms to peruse, it's worth picking up.


So it turned out that these two books are not directly comparable, but hey, it happens. They were both enjoyable reads. I would say Facts and Fallacies of Software Engineering was somewhat more enjoyable than Programming Pearls 2 with Glass' way of challenging your assumptions and long-held beliefs, but both books are worth a look in their own right. Programming Pearls 2 does a good job of reviewing the field of algorithms with a few novel ideas thrown in the mix. It all depends on what your interested in at the moment: high-level software engineering issues or algorithmic programming problems.

DE: Tips And Tricks On Movement

Archon School is the best School.

I'm going to be traveling on business soon so I want to get this one out to you guys ASAP.  This is a quick article on some tips and tricks when it comes to vehicle-heavy play.  As you can see in a lot of my lists, it has a lot to do with vehicles.  However, in order for DE players to get the most out of their vehicles and the units inside them, you have to be very careful in how you play them.

Dark Eldar vehicles are powerful because they have Fly and great movement, however, they are fragile and if you use them incorrectly, they will die like bitches and so will your dudes.  If you're going to die, you better kill a lot of shit to make your death worthwhile.

Before we begin, here are some useful terms for you to remember:

Falling Back
Units starting the Movement phase
within 1" of an enemy unit can either
remain stationary or Fall Back. If you
choose to Fall Back, the unit must end its
move more than 1" away from all enemy
units. If a unit Falls Back, it cannot
Advance (see below), or charge (pg 182)
later that turn. A unit that Falls Back
also cannot shoot later that turn unless it
can FLY.

Open-topped: Models embarked on this model can attack
in their Shooting phase. Measure the range and draw line
of sight from any point on this model. When they do so,
any restrictions or modifiers that apply to this model also
apply to its passengers; for example, the passengers cannot
shoot if this model has Fallen Back in the same turn,
cannot shoot (except with Pistols) if this model is within
1" of an enemy unit, and so on. Note that the passengers
cannot shoot if this model Falls Back, even though the
Raider itself can.

Hovering: Instead of measuring distance and ranges to and
from this model's base, measure to and from this model's
hull or base (whichever is closer).

Airborne: This model cannot charge, can only be
charged by units that can FLY , and can only attack or be
attacked in the Fight phase by units that can FLY.

Look at this threat range man.

OK, now we're ready to begin.  First, I want you to look at this picture for at least 5 minutes.  Look at the measuring tape, and then bask in the glory that is DE movement and threat range.  You get out of the vehicle by measuring from the hull (including the tip of that Shock Prow) for 3".  You move 7" with your Warriors and 8" with your Wyches.  You then have roughly 1" because you measure to the edge of your 25mm base, so you have a total movement hull to edge of base of 11".  You then have a Rapid Fire range of 12", your Blasters reach out to 18", and the rest of your shit that matters literally hits from a mile away.  Just with Rapid Fire Splinters mean you have a total threat of a little over 23" out of a transport when you measure from the base.  This is why Obsidian Rose is so worth it to me, because it extends the threat range of this bullshit even further.

Before we continue, I want to say that if you're playing with Warriors in a gunboat, you want to stay in that gunboat as long as possible.  This is because the Raider is Open-topped and you can get much more mileage out of it with better durability (T5 10W 4+/5++/6+++) than shooting at paper armor Warriors out in the open.  You have much greater threat range inside a Raider as well, since the damn thing can move 14" and you can still Rapid Fire out of it measuring from the hull.  That means you have a threat range of 26" of threat, which is a few inches greater than your Warriors walking on foot.  Yes, you heard that right, your Warriors move almost as fast as your Raiders.  Let it sink it good and long.

So why get out?  Because your Archon's aura doesn't work while you're inside the Raider.  It only works when you're outside which is why it's very worthwhile to sometimes unload all of your shit within 3" of your Raider (so they can quickly jump back in next round), get within 6" of that sweet ass bubble of the Archon, and then unload like crazy.  It's like having Flayed Skull's re-roll 1s for all of your weapons.  If you have Writ of the Living Muse while using Black Heart, here's all those crazy re-roll 1s to Wound as well.  However, if you don't need the re-rolls, just sit in the Raider for as long as possible because even if the Raider is engaged, you can still disembark from it and not count as Fallen Back for your Warriors.  You just have to get out first before your Raider Falls Back.

Get out, get buff, shoot, get scooped.

This is what I mean when I say get out, get the bonus from the Archon, and reap the whirlwind.  You're still within 3" of your Raider so you can taxi back in next movement and your Archon is still in range because 6" from base to base is actually ridiculously long.  The biggest thing I want you to take away from this picture is that I angled the camera downwards deliberately here.  Your Warriors can fire from beneath your Raider because Line of Sight is a real thing (model's point of view).  Sure, they can probably only see something in front of them, but LoS is one of those things I will bring up time and time again with Dark Eldar.  LoS really matters for them because denying damage while doing damage is the key hallmark of the faction.

Another subtle tip from this example is that the Archon has 2 units in front of him before he can be shot at if your opponent doesn't have any flyers of their own.  Be very wary when there are flyers on the map because they can zoom across the battlefield and eat you alive if you're not careful.  Those damn Hemlocks of mine have claimed so many careless generals' lives.

Weapon ranges are important.

There is a lot going on in this picture so I'm going to try to explain piecemeal.  The first thing I want you guys to look at is the range and coherency of the models.  Note that all my units in the front drawing red are in Rapid Fire of that unit of Wraithguard while the most valuable damage weapons, the Blasters, are in the back marked yellow.  The reason why I chose to show this off is that when you pull models, you can pull the extra rifles from the front to possibly deny a charge, and to preserve your longer ranged weapons whenever possible.  As a shooty army, you should preserve as much damage whenever you can, however you can.

The second thing I want to show here is the placement of the Raider in front of the Wraithguard.  Yes, I know they're WG and they shoot like crazy, but pretend they aren't for a second and I'm just using them as models.  The Raider is long, a little over 7" and acts as a perfect defensive obstacle for units that want to charge your paper armor duders in the back.  By putting a Raider in front of them, you form an artificial wall for your opponents to go around.  Therefore, you prolong the charge distance of your enemies and keep your Warriors alive another round (possibly).  Sometimes, this means you have to make sacrifices.  For Dark Eldar, I strongly encourage you to employ such tactics because, for us, it's any means to the end.  It's both fluffy and is perfectly applicable in-game.

Here's where Fly comes in handy.  If you have units inside the Raider, once you Fall Back with the Raider, they cannot shoot.  What you do here instead is:  Disembark your Warriors out of the Raider first and then Fall Back with your Raider so they can both shoot.  You just need to be mindful that you're more than 1" away from the enemy when you get out.  If your Warriors are caught in the open and are now in melee, they can't Fall Back and shoot (not conventionally at least).  Try and avoid this at all costs.  Your Raider, however, has the Fly rule and can Fall Back and shoot.  This is why if they don't kill the Raider, they won't stop it from firing on them.  The same applies to our Ravagers as well.

Now you're in range, now you're not.

Next picture is just more salt to injury.  Let's pretend those WG don't auto-hit the Razorwing and therefore will murder him.  Instead, let's treat them like TH/SS Terminators or something.  They see a juicy target, or rather, multiple juicy targets to charge.  Hmm, that Raider is 9" away, and those Warriors are a little under 12 so it's not impossible.  Oh boy, here comes a flyer 1" away.  Yup, I just increased the charge distance of those Terminators to barely possible on the Raider and not possible at all on the Warriors.  It gets even sadder because if you declare the charge because you're not careful and account for the distance traveled, I can still Overwatch even if you fail.  This is the advantage of the Airborne special rule that flyers have.  Unless that unit has Fly, you should do this and make your opponent really upset.

MSU is wonderful when used correctly.

OK, this little picture shows you the value of having multiple units in a Raider.  The above there is 2 units of 5 Warriors (2x5 config) with Blasters in a single Raider.  Everything is in Rapid Fire range and the Blasters are slightly in the back (like they should be).  Red and blue symbolizes the first movement action I take, then the second, and yellow presents where the Raider goes everyone disembarks so I can scoop up blue squad next round if they're still around.  Always have an exit strategy and a follow-up plan.  Too many times I see players just do what's in the moment and not plan ahead.  This is not how Dark Eldar plays because misplays or stupidity can literally end the game for us.  You have to be methodical, cunning and smart with how you play the game.  Now that my plan is laid out, I lay into my targets with firepower.

MSU is an abbreviation for Multiple Small Units.  This has been around forever and I've played way too many years of DE, High Elves, Dark Elves and other MSU-based armies to understand the value of it.  For Dark Eldar, this has some great uses because it allows you to do shit like the above picture.

Here are some of the other benefits of having 2x5:

• Can split up squad as and when needed
• Same number of Blasters as 10-man units
• Can double up on PGLs or other sergeant weapons
• Less vulnerable to Ld
• Can build Brigades fast, but you also fill slots quick

The biggest boon is your ability to split up:  Your opponent has to shoot one squad to death instead of 2 so he can oversaturate fire and potentially waste shots.  This is mainly because when you declare targets, you have to declare where all your shots are going and from which guns before you roll dice.  This means if you really want a squad dead, you have to commit.  Not that it takes a lot to kill off DE infantry units in the open, but being frugal on shots or some lucky 6+++ saves means that a sole Blaster dealing S8 AP-4 D6 damage is going to go around shooting you in the dick.

Likewise, if you spread wide enough, he now has 2 targets to charge instead of 1.  Look at the distance between the two units above.  He's definitely going to commit to one side if he wants a good chance, and even if he charges one squad, that's still another Blaster that's free to shoot and not in Fall Back mode.

It all comes together to make your opponents' life miserable.

We're almost done guys, hang in there.  Look at this example above:  I placed the Archon within buff range of both units while placing two Raiders there to form the Great Wall of bad decisions.  They obviously cannot go around to assault my dudes because that's an impossible charge.  They can't fire on the Archon because there are multiple units in front of him.  The only logical target there is the Raiders, and if they charge into them, Raiders are wide enough (almost 3") to stop any follow-up Consolidation prize in the Warriors in the front.  The only thing they can do is Consolidate into the other Raider, in which case I'll Fly away and shoot him with my entire army next turn.

Now imagine I had about 4 more squads of Warriors in the back there by my Archons ready to go too.  That is a lot of units now ready to follow-up, amplified damage via the Archon's bubble, and ready to lay waste to the units who over-extended and are now in Rapid Fire range of a lot more guns.  This is an instance where charging the enemy is actually bait because it draws them in closer to the kill.  What looks like suicidal Raiders at first are now very worth it because you might have traded an 85-point Raider that is now fodder, with 225 points of key damage dealers.  That is a huge points swing in your favor.

Great, now you're playing like Dark Eldar, or in fact, any Eldar:  There is a reason why you think you're superior to all your enemies and have this outrageous arrogance around you.  You want to force as many decisions for your opponent as possible because the more decision trees you construct, the more paths there are to failure.  Shore this up with baits, feints, LoS, cover, outranging, and movement shenanigans, and you're one step closer to becoming a better Eldar player.

Be mindful of your opponents' most potent weapons and their range.

We're going to take a brief moment here and explore what it means to charge the right way and charge the wrong way.  This is because we have to be constantly reminded me of our opponents' weapon ranges and what that means for our more fragile units.

What I'm going to attempt to do here is to charge my Raider first so I can tie up those units so my lightly armored Wyches can get in there unhindered and do their thing without having to worry about Overwatch.  This is very important for all Dark Eldar players unless you're playing Coven; in which case you probably don't give a fuck because T6 4++ FNP 4W Grots are balanced units.

For example, the Wraithguard up there all have 8" D-Scythes.  They will eat me alive if I charge in there while I'm in range of all their weapons.  Likewise, picture a unit of 10-man Space Marines with Meltaguns in there as well.  This is where your knowledge of weapon ranges come into play.  You know the range of the Meltagun (12", 6" melta range) and you know where the meltas are located.  Great, now don't be within their melta range and position your Raider so that you outrange his greatest chance to hurt you.  Bolters aren't shit compared to a lucky melta shot.

This is how you do it.

Vroom, 14" of movement later, now we're talking:  Look at the position of the Raider here after I relocated.  Now, only ONE of the FIVE Wraithguard with D-Scythes have range onto my Raider.  If I'm feeling extra cheeky, I can be at 8.1" away from him so he can't OW me at all (if you're out of range, you can't declare OW).  But then again, my charge will be a little longer, so there's a risk vs. reward scenario there.  However, I want to mention that my Wyches are positioned the same way, concaved a little because now only 2 of the WG can hit the closest Wyches vs. everyone else who was conveniently placed 8.1" away.  I will pull from the back, of course, allowing my closer Wyches to get the charge and bring the rest of the girls in.  If I'm running a 2x5 squad of Wyches, the principle here still stands.  To min-max, you move the Wyches in a checkerboard formation so both squads have the same chances to get in.  Remember again; measure twice, move once.  That is the Dark Eldar way.

Alright guys, this should be good for now.  Of course, there are a bunch more tricks that I know, but I think these are the main ones that'll help get you stated.  Keep in mind that I'll be more sporadic in the next week when it comes to posting!

The Sinking City Necronomicon Edition CorePack Free Download

The Sinking City Necronomicon Edition CorePack Free Download PC Game setup in single direct link for Windows. It is an amazing action, adventure and indie game.

The Sinking City Necronomicon Edition CorePack PC Game 2019 Overview

The Sinking City is an adventure and investigation game set in an open world inspired by the universe of H.P. Lovecraft, the master of Horror. The half-submerged city of Oakmont is gripped by supernatural forces. You're a private investigator, and you have to uncover the truth of what has possessed the city… and the minds of its inhabitants.
* An oppressive atmosphere and story inspired by the universe of H.P. Lovecraft.
* A vast open world that can be explored on foot, by boat, in a diving suit…
* High replay value thanks to an open investigation system: each case can be solved in a number of ways, with different possible endings depending on your actions.
* An arsenal of weapons from the 1920s with which to take on nightmarish creatures.
* Manage your mental health to untangle the truth behind the madness.

Mature Content Description

The developers describe the content like this:

This Game may contain content not appropriate for all ages, or may not be appropriate for viewing at work: Frequent Violence or Gore, General Mature Content

Technical Specifications of This Release.

• Game Version :
• Interface Language: English
• Audio Language : English
• Uploader / Re packer Group:
• Game File Name : The_Sinking_City_Necronomicon_Edition_CorePack.zip
• Game Download Size : 12 GB
• MD5SUM : ae4eb00b11b05e5cac11aca408c0c84f

System Requirements of The Sinking City Necronomicon Edition CorePack

Before you start The Sinking City Necronomicon Edition CorePack Free Download make sure your PC meets minimum system requirements.

• OS: Windows 10 64-bit
• CPU: Intel Core i5-2500 3.3 GHz or AMD FX-8300 3.3 GHz
• RAM: 8 GB System Memory
• GPU RAM: 4 GB Video Memory
• GPU: GeForce GTX 770 4GB or Radeon R9 380X
• DX: DirectX 11
• HDD: 40 GB Available Hard Drive Space

The Sinking City Necronomicon Edition CorePack Free Download

Click on the below button to start The Sinking City Necronomicon Edition CorePack. It is full and complete game. Just download and start playing it. We have provided direct link full setup of the game.

Download Link:::Link

Size:11.36 GB

Price:Free

Virus status: scanned by Avast security