السبت، 28 مارس 2020

New Year, Fist Update....


Hello all,
 

Just wanted to drop in and give an update. The transition from WGF is complete, we have our warehouse and have been shipping from that location for about two months. We have worked out the software issues for the wholesale orders and have been filling them.
 
We have about a year's supply of product on hand and OOS items such as the Panzerjäger are on the water heading here now.
 
I have been working on the day to day business aspects, cost analysis, product restocks back end implementation issues, etc. so not a lot of glamorous items to give an updated on for that front.
 
We have two restock orders incoming from China, the cost has been educational. The cost of shipping is not just crazy expensive for my customers but for us as well. In some cases, it costs more to ship a product than it does to produce it, in other cases the cost to produce a kit was not in line with what it is being sold at into distribution. Some kits were being sold at a net loss once shipping was factored in. Unfortunately, this will mean a price increase, some kits will see a marginal increase, other will be a bit more drastic.

I will give a detailed SKU by SKU run down and explanation later this week.
 
We have two new SKU's that will be offered once they arrive. The 15mm scale Capacitor cooler and a 60mm tall display model of one of our Assault Troopers. We should have these in hand sometime next month. We are putting the final touches on the files for the Shadokesh main trooper box set. No eta on a release date yet for the Shadokesh, until they are on the water and heading here it is simply impractical to give an estimate.

 
That's it for now.
All the best!

Mark

الاثنين، 23 مارس 2020

OpenGameArt Summer Game Jam #3 Has Begun


One of our affiliate websites OpenGameArt (OGA), a free repository for public domain and copyleft licensed art, has just begun hosting this year's Summer Game Jam. To all libre developers looking for a challenge, this is your call to arms.

The rules are simple: participants are to create a game which independently of length and genre must use 6 art assets already available at OGA. The type of engine or code license used is up to the creator, but any artwork from the repository employed, along with any derivates, must comply with the specific licensing of each.

While this does not mean any game submitted to the jam will be libre, there's a good chance some will be, so regardless of whether you are a game developer or not, it would be wise to keep an eye on the contest results. It is also worth applauding OGA's initiative as a way of fostering usage and creation of Creative Commons licensed assets, and to spread word of the cultural benefits of open development.

Further information regarding regulations and prizes can be found on the jam's official page here.

OpenGameArt is ran entirely as a volunteer effort. Should you wish to contribute, you can check their forums for volunteer openings or help support server costs by donating to their Patreon.


Comments and questions? Post them on our forum thread.

الجمعة، 20 مارس 2020

ASOIAF: Deployment And Activations

Get ready for some hard lessons.

One of the best things about this game how in-depth alternate deployment and activations work.  All of this is outlined really well in the main rulebook, but I want to take a moment to stress the importance of how greatly this affects overall gameplay.  A lot of this harks all the way back to my WHFB days where "drops" and chaff really meant something when it comes to deployment.  Having more drops than the opponent allows you to see where their most crucial units get placed so you can better deploy against them.  Keep in mind that when it comes to "drops", this is strictly limited to combat units.  It doesn't matter how many NCUs you have when it comes to deployment, but this will matter when it comes to overall activations.  Activation order and the number of total activations matter because the more you have, the more you can "force" your opponents to activate their units so you can better counter them.

Alright, so let's dive into deployment first.  Going forward, I'm just going to call these drops because I'm an old-school WHFB player and you're just going to have to deal with it.  I'll start by using my Robb Stark list vs. the previously posted Ramsay list.

Faction: House Stark
Commander: Robb Stark – The Wolf Lord
Points: 40 (4 Neutral)

Combat Units:
• House Umber Greataxes (7)
  with Robb Stark – The Wolf Lord (0)
• Grey Wind (0)
• Stark Sworn Swords (5)
  with Bran and Hodor – Protector and Ward (3)
• Summer (0)
• House Umber Berserkers (7)
  with Sworn Sword Captain (1)
• Stark Outriders (7)
  with Brynden Tully – Vanguard Infiltrator (3)

Non-Combat Units:
• Sansa Stark – Little Bird (3)
• Lord Varys – The Spider (4)

Made with ASOIAFBuilder.com

vs.

Faction: House Lannister
Commander: Ramsay Snow – The Bastard of Bolton
Points: 40 (20 Neutral)

Combat Units:
• House Clegane Mountain Men (6)
  with Ramsay Snow – The Bastard of Bolton (0)
  and Theon Greyjoy – Reek (0)
• House Clegane Mountain Men (6)
  with Dreadfort Captain (1)
• Bolton Cutthroats (5)
  with Assault Veteran (1)
• The Flayed Men (10)
  with Gregor Clegane – Mounted Behemoth (3)

Non-Combat Units:
• Tywin Lannister – The Great Lion (4)
• Lord Varys – The Spider (4)

Made with ASOIAFBuilder.com

Before we talk about anything else, keep in mind that after the battlefield is set up, you roll a die with your opponent and you see who gets to pick their deployment zone (winner chooses or passes).  The player who does not choose their Deployment Zone will the First Player.  The player who chooses the deployment zone puts down their first combat unit.

As you can see in the example lists above, Robb's army has a total of 6 drops compared to Ramsay's 4 drops.   This is one of the best things about the Stark Dire Wolves and that's because it comes with good 0-point chaff that are combat units.

If you choose Deployment and therefore starts deploying first, it would look like:
  1. You put a wolf down
  2. They put down a combat unit
  3. You put another wolf down
  4. They have to put another combat unit
  5. You put down some Stark Swords
  6. They put down another combat unit
  7. You put down some Berserkers
  8. They have to put down their Flayed Men with Ser G
  9. Now you counter-deploy your Greataxes to meet his knights
  10. ...and you can put your Outriders somewhere that best suits your needs

Hell, if you count his drops ahead of time, you can even choose to Outflank with your Outriders because you know the drop advantage is yours.  Always count the number of drops your opponent has and take note of any units of significance.

Do you see the power of having more drops than the opponent?  This is actually one of Stark's most powerful tools and that's the free Dire Wolves with Robb and Brann.  Once Shaggydog gets up in here, it's going to be a hoot.  Even having one drop over the opponent can mean a big difference because it allows you to better set up your slower moving speed-4 Greataxes somewhere that's going to scare those Flayed Men.  If you end up tieing with your opponent when it comes to drops, consider letting them choose deployment so they drop first.

Activating in the most optimal order is key.

Next, let's talk a little bit about activations.  For the most part, I'll try and keep things as generic as possible.  Knowing the when and why you activate your units will mean the difference between victory and defeat.  This is where most of the complexity of the game comes from.  By understanding that your NCUs count towards total activations and directly interact with the game through the tactics board, this greatly enhances how you play the game.  While most units interact directly with tactics cards, there's also a ton of ways to cheat out free actions.  To explain all of this is going to be really complex because it's simply impossible to predict any and all events that are going to happen in a game.  No worries though, I'll try and give out some hints based on the games I've had so far.  Keep in mind that who is First Player also matters greatly.

Here are some helpful tips:
  • NCUs tend to activate first to either stifle the opponent's zones or take advantages for themselves.  For example, as First Player, taking the Tactics zone can be super useful, or robbing the Stark player of free maneuvers can also be strong, especially when there are plentiful objectives on the board.
  • Whenever you interact with the tactics board, you should first consider if you're planning to give a direct benefit to yourself or to disrupt the opponents' plans.  Every decision you make should be deliberate and has a significant impact on the game.
  • When units are already engaged,  claiming the Combat zone is very strong and should be claimed if you have First Player.  This is essentially a free combat action, which is just incredible.  Anything that gives free anything is highly-sought after.
  • Activating your Dire Wolves first before your main combat units allow you to better move units in response to what the opponent is going to do.  They have to activate their units and cannot choose to just pass.  They can, however, put an activation token on the unit and just not do anything.
  • Always look for low-risk activations first if you want to bait your opponent into doing something so you can counterplay it.  However, you need to prioritize high-value activations if you absolutely need something to go in your favor.  This is how tempo is set by the player:  If everything you're doing gives you an advantage some way or another, you will always be ahead.  An example of this could be deciding to put an NCU down first to disrupt the opponent or to activate a unit.  You want to choose the one that will put you ahead while leaving the opponent unable to respond.  The best type of activation is getting to do something that gives you advantage while the opponent gains nothing.
  • As the game progresses, this is where the true chess element of the game comes in:  Choosing the wrong activation order can literally mean victory or defeat.  Everything is a risk because both you and your opponent has a hidden hand of tactics cards, and with NCUs being different every game, there's always going to be calculated risk.  This is why Varys is one of the strongest NCUs in the game currently:  He has 4 tries to foil your opponents' plans with the tactics board or their NCUs.
  • Once combat is joined, the focus of the game shifts a bit from NCUs to actually fighting the battle.  Otherwise, you risk skipping pivotal combat and your opponent might just tactics your unit into the ground before you get a chance to swing.  If you see the opportunity to inflict damage, it's almost always worth it to take it unless you have the appropriate counter.  Look for unit activations that will give you the battlefield advantage.  NCUs are not the ones fighting over objectives.
  • Typically when you're a couple of turns in and the battle is joined, you should look for opportunities for free actions first, then combat, then NCUs in that order.  There are many factors that will change this order around, but that's completely up to you to analyze the opportunity cost.  Since there are a lot of things to keep track of once battle is joined so it's important for you to get comfortable with your units, your commander, your NCUs, and your tactics cards.  Else, you risk missing vital opportunities or triggers that can win the game for you.

Alright, that's pretty much all I have to say about activations.  There are just a billion examples and each one of them is unique.  However, I think mastering your activations is the most difficult, most complex, and most rewarding part of the game.  It's probably the biggest factor in identifying player skill and experience, so it's definitely worth practicing.  Good luck!

الخميس، 19 مارس 2020

GTA 5 DOWNLOAD HIGHLY COMPRESED





Grand Theft Auto V is an action-adventure video game developed by Rockstar North and published by Rockstar Games. It was released in September 2013 


GAME HAS NO ANY PROBLEM  CHED IT BY Y.YADAV




                                                           ADVANCE THING TO DO


PLAESE ALSO DOWNLOD WINRAR NET FRAMWORK   AND PASSWORD FILE


                                                            REQIRMENT TO READ
  • Processor: Intel Core 2 Quad CPU Q6600 @ 2.40GHz (4 CPUs) / AMD Phenom 9850 Quad-Core Processor (4 CPUs) @ 2.5GHz.
  • Memory: 4GB.
  • Video Card: NVIDIA 9800 GT 1GB / AMD HD 4870 1GB (DX 10, 10.1, *11)
  • Sound Card: 100% DirectX 10 compatible.
  • HDD Space: 65GB.
  • DVD Drive.

                                                        

                              ALL DOWNLOAD PART ARE OF GTA 5

                          PLEASE DOWNLOAD PASSWORD 

   PLAESE ALSO DOWNLOD WINRAR NET FRAMWORK   
                                                       

           IF GAME WAS LAGING

CHECK THE VERYFY BIN IN YOUR GT5 FOLDER

AND SECOND YOU WANT TO OPEN GTA 5 MAIN FOLDER

AND COPY ALL FILE FROM MD5  FOLDER THEN PASTE

N GTA5 SHOTCUT FOLDER

OUR GAME START RUNNING                                          

                                      VISIT YOU TUBE



                                                            DOWNLOAD PASSWORD


                           
                                                           GTA 5 DOWNLOAD BUTTON
 ALL PART ARE 2 GB

DOWNLOAD PART 1

DOWNLOAD PART 2

DOWNLOAD PART 3

DOWNLOAD PART 4

DOWNLOAD PART 5

DOWNLOAD PART 6

DOWNLOAD PART 7

DOWNLOAD PART 8

DOWNLOAD PART 9

DOWNLOAD PART 10

DOWNLOAD PART 11

DOWNLOAD PART 12

DOWNLOAD PART 13

DOWNLOAD PART 14


DOWNLOAD PART 15





                                            

Blast From My Purple Past


A confluence of events has deemed The Islands of Purple-Haunted Putrescence worthy of two new reviews... even if it has been 6 years since I birthed it.

I remember fondly my time writing, running, and witnessing peoples' reactions to that book.  Without further ado, you can listen to the 2 part podcast here.  Dan Davenport, GMshoe, has a text review here.

Want to go straight to the PDF?  Here you go.  But if you prefer the b/w softcover, I recommend buying it on Amazon.

That campaign setting hexcrawl paved the way for Cha'alt, so for that alone I'm happy to see it mentioned on the internet.

If anyone has a purple islands story they'd like to share, I'd love to read it.  Comment below!

Thanks,

VS

Tech Book Face Off: The New Turing Omnibus Vs. Patterns Of Software

I'm churning through tech books now, finishing off a bunch that I had started a while back, but couldn't find the time to finish until now. The pair that I'll look at here are a couple of older books that I picked up through recommendations on blog posts. The first one, The New Turing Omnibus: 66 Excursions in Computer Science by A.K. Dewdney, is a survey of 66 topics in a wide range of areas of Computer Science. The second book, Patterns of Software by Richard P. Gabriel, is about advice and experiences on a variety of topics in software development. Whereas NTO is of a strictly technical nature, Patterns of Software has much more of the human aspect of working with computers and software. Let's see how these older books hold up today.

The New Turing Omnibus front coverVS.Patterns of Software front cover

The New Turing Omnibus


With the new edition published in 1993, this is definitely an older computer science book. That can be okay, if the author sticks to the more timeless aspects of computer and software design. For the most part, this is the case in NTO, but a few of the chapters—especially the ones on VLSI computers and disk operating systems—are definitely dated and nearly beyond usefulness. The topics vary far and wide, though, and are generally grouped into eleven subject areas with the following breakdown:
  • Analysis of Algorithms (8)
  • Applications (7)
  • Artificial Intelligence (5)
  • Coding and Cryptology (3)
  • Complexity Theory (6)
  • Computer Graphics (3)
  • Data Structures (6)
  • Automata and Languages (5)
  • Logic and Systems Design (9)
  • Theory of Computation (9)
  • Miscellany (5)
The miscellany chapters could honestly been grouped into the other categories, and the three computer graphics chapters were just as much algorithms or data structures as anything, so nine categories would have been sufficient. That's fairly inconsequential, though, because the topics were presented completely haphazardly anyway. The chapters would go from Karnaugh Maps to the Newton-Raphson Method of finding roots to minimum spanning trees without any ceremony whatsoever, leaving the reader grappling for a solid structure to hold on to.

Each chapter is a brief 5-7 page discussion on the given topic followed by two or three problems related to the topic as practice for the reader. These problems commonly explored points glossed over in the text. The topic discussions read like blog posts and don't give more than a cursory introduction to the sometimes deep and complex subjects they are covering.

I had high hopes for this book, considering the glowing recommendation that Jeff Atwood gave it back in 2007 on Coding Horror, but I just couldn't get into it the way he did. I found the treatment of the topics that I had already learned in much more depth, mostly from studying in college, to be tedious and unremarkable. The remaining 25% of the topics, mostly on the theory of computation and automata, was quite difficult to understand from the short expositions given, and I would have to do more extended studying with a book like the Introduction to the Theory of Computation to get enough of a handle on the subject to answer the more difficult end-of-chapter problems.

I may not have been the right audience for this book, but I had a lot of trouble figuring out who the right audience would be. The material was so superficial that I didn't find any additional insights or valuable practice from any topics I already knew about, and those topics that I had little exposure until now were nearly completely opaque from the text. It was weird. The book didn't seem to fit for either a novice or a (moderate) expert on any of the topics, and the fact that related topics were strewn throughout the book, separated by completely unrelated topics, made it even more frustrating and less helpful. Maybe if you were using it as a supplement while studying some of the broader subjects for extra practice, it would prove to be of some use, but I'm not even convinced of that. I have to give this book a solid "no" at this point. There are much better books out there on the subject areas covered here.

Patterns of Software


This was an odd book, and not at all what I expected. I had expected a book relating advice to the reader on how to design and develop software. What it is instead is an extended comparison of Christopher Alexander's work on patterns in architecture to patterns in programming followed by speculations on programming languages, advice on learning to become a good writer, and a significant part of Richard P. Gabriel's life story. It was a strange mishmash of things that didn't quite hold together as a cohesive book.

Throughout the first part on how Alexander's books—the most well-known being A Pattern Language—relate to programming, Gabriel quotes Alexander extensively, to the point where I almost felt like I was reading Alexander more than Gabriel. He also did not spend enough time tying all of these quotes into programming and software, so much of the time I was left wondering if the book was just a review of Alexander's works.

Gabriel did have some insights into programming that resonated well, such as
Maintaining compressed code requires understanding its context, which can be difficult. The primary feature for easy maintenance is locality: Locality is that characteristic of source code that enables a programmer to understand that source by looking at only a small portion of it. Compressed code doesn't have this property, unless you are using a very fancy programming environment.
We must be careful to strike the right balance when coding so that we don't unnecessarily obscure things that should be simple and easy to understand just for the sake of abstraction. Sometimes it's better to lay out a process linearly so that it can all fit on the screen at the same time instead of slicing and dicing to the point where the poor sap who has to debug the code needs to chase the flow of execution through dozens of functions and variables across tens of files. This insight gets at one of the themes of the book on making code habitable:
Habitability is the characteristic of source code that enables programmers, coders, bug-fixers, and people coming to the code later in its life to understand its construction and intentions and to change it comfortably and confidently.
This idea of habitability is a worthy goal, and Gabriel returns to it often in the context of Alexander's architecture patterns:
What Alexander seems to be saying is that if we try to use modular parts (solid building blocks not easily molded to the current circumstances), then the overall structure of the thing built with them may become overly constrained by their shape. In programming, if a set of large abstractions does nearly the right thing, it is tempting is [sic] to use them and to bend the structure of the surrounding program to fit them. This can lead to uninhabitable programs.
It seems like much of modern software development has become exactly this, where we as programmers have been reduced to searching for and slapping together all of the packages we need to meet the given software requirements. In this process of moving towards extreme reuse, something has been lost in software development, and this is speaking from a perspective more than twenty years after this book was written, with reuse being much more common and extensive than it was then. This thing that has been lost is Alexander's "quality without a name."

Both Alexander and Gabriel spent a lot of time trying to define this quality without a name, but neither succeeded very well. Gabriel critiqued Alexander's choices in descriptive words, like "simple" and "cohesive," but while he was right that the word choices did not do the concept justice, he did not do much better in clarifying what the quality was. Even more troublesome than defining it, Alexander found that he couldn't replicate this nameless quality by enumerating the patterns of architecture. It's not something that you can create simply by combining known good patterns in a building.

This difficulty of codifying quality is true for almost anything we do. It's as true for architecture as it is for programming as it is for every form of craftsmanship, and it seems obvious that this would be so. We can't package up and mass produce quality that simultaneously exhibits beauty, elegance, efficiency, and function. Reaching the point where you can produce things of such a high level of quality takes decades of experience, creativity and experimentation. Most people will never reach the level of craftsmanship where their work is elevated to an art form.

It was frustrating that Gabriel danced around that conclusion for most of the book, but never really committed to it. He did spend a fair amount of time on silly tangents, like the chapter where he claimed that the development of programming languages was at an end, and C was the ultimate answer. That prediction looks mighty short-sighted today.

The rest of the book, detailing Gabriel's struggles through college and running a software business, was sometimes interesting and sometimes not, but it didn't have much to do with the first half of the book on patterns and code habitability. In general, his writing was quite repetitive and disorganized. He would introduce a new topic or part of a story by giving away the conclusion as if it was a stand-alone statement, and then proceed into an extended discussion on it. A few pages later I would realize he was talking about the details of a story that I had thought was just an isolated observation and we had moved on. This writing style was quite disorienting, and the constant repetition of certain observations or narratives, each time stated as if it was the first, became fairly annoying.

Between the sparse real insights and disjointed structure of the book, I can't recommend Patterns of Software at all. The software development advice can easily be had in much better books without the extended and largely irrelevant fluff. It's unfortunate. I feel like I really struck out with this book and The New Turing Omnibus, but sometimes that happens. Maybe the next couple books I read will be much better.

الاثنين، 16 مارس 2020

Storium Theory: Limiting Your Limitations

Today, I'd like to write a bit about something that I think we all do as narrators from time to time: Limiting the options that players have for writing about a situation.

Limits are good. Limits, at their base, are a way of ensuring that the scene has focus. When we set up a challenge at all, we are putting limits on the scene in general - limits of saying "the scene is now about this problem, and it needs to be addressed." We're defining what the actual problem is, and to some extent unavoidably defining the sort of things that can be done to address the problem.

But it's important to recognize when we take these definitions too far.

I've been playing a roleplaying game outside of Storium recently, using some pre-prepared scenarios that I found, and I've been struck by something in reading those scenarios: Oftentimes, they focus extensively on what definitely won't work. They spend a lot of time discussing why the players should absolutely not try a particular tactic with a situation, and how many brick walls can be thrown in their way should they dare to attempt such a thing. They're not quite set up to allow only one path forward, but they dwell a lot on why solutions A, B, C, D, E, and F are all terrible ideas that will only increase the scenario's difficulty. They show the walls, not the paths forward.

I've noticed a similar mindset subtly sneaking into Storium games at times. In our challenge setups or narration, we can sometimes spend time focusing on what won't work - on the walls set up in the way of particular solutions. Maybe we show the player characters trying a solution and discovering it won't work in the opening narration. Maybe we just describe something as impossible on the card or in the outcomes or in the narration.

Sometimes, this is fine. Sometimes, this is appropriate.

But it is definitely something we should question.

Storium works best, I have found, when players have enough information to focus their writing without limiting their ideas. That is: The problem is well-defined, but the solutions are left as open as possible given the problem at hand.

If the problem is a powerful wizard who the heroes need to get past to get to their goal, the solutions could potentially involve all sorts of things - maybe the heroes manage to fight the wizard and drive him away, maybe they evade his attacks and race beyond him into the fortress. Sometimes, limiting those options is perfectly appropriate...but it's important to be careful just how far you take the limitations. For instance, it might be appropriate to say that the party has to fight the wizard, because he's set up a magical barrier over the exit or because it's just too dangerous with him raining magic around the area. But further defining that the wizard is absolutely invulnerable to non-magical attacks himself is probably going to take it too far - it'll most likely make players of non-magical characters struggle a bit to figure out how to participate in the fight. Or, alternately, it might be appropriate to say that the wizard can't be killed and the characters need to escape - the wizard is just too powerful and his defenses too strong. But it'd take it too far to say that his attacks are unstoppable and his defenses are so strong he can't even be shaken by the characters at all, most likely, because again, it seriously limits what players can write and the ideas they can come up with for the scene. Some characters might have things they can realistically write to make just running away interesting, but others might really need to be able to provide some cover for the others or manage to disrupt the wizard for just a moment (or at least, attempt to do so and get turned aside, if they're playing a Weakness).

Similarly, consider an investigation. Maybe you're asking players to find information on a criminal gang that has troubled the area. That's fine. But if you go to the extent of saying that the other gangs in the area definitely won't share their information, or that police contacts are totally mystified and have no knowledge of the gang at all, well, that's probably going to cause people some trouble. You're limiting the ways that players can write the scene, and that's likely to make it tougher for them to come up with ideas.

Remember: Storium is about helping people write. The things that you put in your narration should encourage writing, not oppose it.

That's not to say that you should totally avoid limitations. Yes, there are times that they fit the story. If it's expressly established that the gang is totally new to the area, for instance, it makes sense that the heroes might not be able to trust contacts that would be working from existing knowledge...but how are the heroes able to get the information? Word the challenge in such a way that you reveal the possibilities rather than set up the walls. And don't just give one option! Show a wider field of openings, something that lets the players still have room to get creative on their own.

And remember to ask yourself: What is this challenge actually about?

In the case of the gang, for instance: Is the question really about who the heroes are able to go to for the information they need? Or is it just about what they are able to find out? If the latter...does it really matter whether they are able to use their contacts with the police? Or is the question just about whether they find information about the gang in the first place?

I want to be clear: Sometimes it does matter how the players are able to accomplish something. Sometimes that can be a problem you need to address as narrator. Sometimes it can cause trouble for a plot if players are allowed to do things a certain way, even if that way fulfills the overall concept of the challenge. That's very true.

But not all the time.

Not even the number of times we as narrators think it is true.

So...when you're setting a challenge up, take a good look over the card and narration associated with it. Look over what you've written, and ask yourself:
  • Have I set up any limitations here I didn't intend to? Are there places where I suggest something is impossible where I didn't mean to?
  • Have I set up limitations that I intended to...but that on second thought, really don't matter? Are there places where I have put limits that will make my players struggle to write, rather than providing useful focus?
If the answer to any of those questions is "yes," think about what you can do to open things up for the players. You still want the challenge to be focused...but focused and limited are two very different things.