Thursday, May 23, 2019

Tech Book Face Off: Effective Python Vs. Data Science From Scratch

I must confess, I've used Python for quite some time without really learning most of the language. It's my go-to language for modeling embedded systems problems and doing data analysis, but I've picked up the language mostly through googling what I need and reading the abbreviated introductions of Python data science books. It was time to remedy that situation with the first book in this face-off: Effective Python: 59 Specific Ways to Write Better Python by Brett Slatkin. I didn't want a straight learn-a-programming-language book for this exercise because I already knew the basics and just wanted more depth. For the second book, I wanted to explore how machine learning libraries are actually implemented, so I picked up Data Science from Scratch: First Principles with Python by Joel Grus. These books don't seem directly related other than that they both use Python, but they are both books that look into how to use Python to write programs in an idiomatic way. Effective Python focuses more on the idiomatic part, and Data Science from Scratch focuses more on the writing programs part.

Effective Python front coverVS.Data Science from Scratch front cover

Effective Python

I thought I had learned a decent amount of Python already, but this book shows that Python is much more than list comprehensions and remembering self everywhere inside classes. My prior knowledge on the subjects in the first couple chapters was fifty-fifty at best, and it went down from there. Slatkin packed this book with useful information and advice on how to use Python to its fullest potential, and it is worthwhile for anyone with only basic knowledge of the language to read through it.

The book is split into eight chapters with the title's 59 Python tips grouped into logical topics. The first chapter covers the basic syntax and library functions that anyone who has used the language for more than a few weeks will know, but the advice on how to best use these building blocks is where the book is most helpful. Things like avoiding using start, end, and stride all at once in slices or using enumerate instead of range are good recommendations that will make your Python code much cleaner and more understandable.

Sometimes the advice gets a bit far-fetched, though. For example when recommending to spell out the process of setting default function arguments, Slatkin proposed this method:

def get_first_int(values, key, default=0):
    found = values.get(key, [''])
    if found[0]:
        found = int(found[0])
    else:
        found = default
    return found
Over this possibility using the or operator short-circuit behavior:
def get_first_int(values, key, default=0):
    found = values.get(key, [''])[0]
    return int(found or default)
He claimed that the first was more understandable, but I just found it more verbose. I actually prefer the second version. This example was the exception, though. I agreed and was impressed with nearly all of the rest of his advice.

The second chapter covered all things functions, including how to write generators and enforce keyword-only arguments. The next chapter, logically, moved into classes and inheritance, followed by metaclasses and attributes in the fourth chapter. What I liked about the items in these chapters was that Slatkin assumes the reader already knows the basic syntax so he spends his time describing how to use the more advanced features of Python most effectively. His advice is clear and direct so it's easy to follow and put to use.

Next up is chapter 5 on concurrency and parallelism. This chapter was great for understanding when to use threads, processes, and the other concurrency features of Python. It turns out that threads and processes have unique behavior (beyond processes just being heavier weight threads) because of the global interpreter lock (GIL):
The GIL has an important negative side effect. With programs written in languages like C++ or Java, having multiple threads of execution means your program could utilize multiple CPU cores at the same time. Although Python supports multiple threads of execution, the GIL causes only one of them to make forward progress at a time. This means that when you reach for threads to do parallel computation and speed up your Python programs, you will be sorely disappointed.
If you want to get true parallelism out of Python, you have to use processes or futures. Good to know. Even though this chapter was fairly short, it was full of useful advice like this, and it was possibly the most interesting part of the book.

The next chapter covered built-in modules, and specifically how to use some of the more complex parts of the standard library, like how to define decorators with functools.wraps, how to make some sense of datetime and time zones, and how to get precision right with decimal. Maybe these aren't the most interesting of topics, but they're necessary to get right.

Chapter 7 covers how to structure and document Python modules properly when you're collaborating with the rest of the community. These things probably aren't useful to everyone, but for those programmers working on open source libraries it's helpful to adhere to common conventions. The last chapter wraps up with advice for developing, debugging, and testing production level code. Since Python is a dynamic language with no static type checking, it's imperative to test any code you write. Slatkin relates a story about how one programmer he knew swore off ever using Python again because of a SyntaxError exception that was raised in a running production program, and he had this to say about it:
But I have to wonder, why wasn't the code tested before the program was deployed to production? Type safety isn't everything. You should always test your code, regardless of what language it's written in. However, I'll admit that the big difference between Python and many other languages is that the only way to have any confidence in a Python program is by writing tests. There is no veil of static type checking to make you feel safe.
I would have to agree. Every program needs to be tested because syntax errors should definitely be caught before releasing to production, and type errors are a small subset of all runtime errors that can occur in a program. If I was depending on the compiler to catch all of the bugs in my programs, I would have a heckuva lot more bugs causing problems in production. Not having a compiler to catch certain classes of errors shouldn't be a reason to give up the big productivity benefits of working in a dynamic language like Python.

I thoroughly enjoyed learning how to write better Python programs through the collection of pro tips in this book. Each tip was focused, relevant, and clear, and they all add up to a great advanced level book on Python. Even better, the next time I need to remember how to do concurrency or parallelism or how to write a proper function with keyword arguments, I'll know exactly where to look. If you want to learn how to write Python code the Pythonic way, I'd highly recommend reading through this book.

Data Science from Scratch

I didn't expect to enjoy this book quite as much as I did. I went into it expecting to learn about how to implement the fundamental tools of the trade for data science, and that was indeed what I got out of the book. But I also got a lighthearted, entertaining, and surprisingly easy-to-read tour of the basics of machine learning using Python. Joel Grus has a matter-of-fact writing style and a dry wit that I immediately took to and thoroughly enjoyed. These qualities made a potentially complex and confusing topic much easier to understand, and humorous to boot, like having an excellent tour guide in a museum that can explain medieval culture in detail while cracking jokes about how toilet paper wasn't invented until the 1850s.

Of course, like so many programming books, this book starts off with a primer on the Python language. I skipped this chapter and the next on drawing graphs, since I've had just about enough of language primers by now, especially for languages that I kind of already know. The real "from scratch" parts of the book start with chapter 4 on linear algebra, where Grus establishes the basic functions necessary for doing computations on vectors and matrices. The functions and classes shown throughout the book are well worth typing out in your own Python notebook or project folder and running through an interpreter, since they are constantly being used to build up tooling in later chapters from the more fundamental tools developed in earlier chapters. The progression of development from this chapter on linear algebra all the way to the end was excellent, and it flowed smoothly and logically over the course of the book.

The next few chapters were on statistics, probability, and their use with hypothesis testing and inference. Sometimes Grus glossed over important points here, like when explaining standard deviations he failed to mention that this metric only applies to (or at least applies best to) normal distributions. Distributions that deviate too much from the normal curve will not have meaningful standard deviations. I'm willing to cut him some slack, though, because he is covering things quickly and makes it clear that his goal is to show roughly what all of this stuff looks like in simple Python code, not to make everything rigorous and perfect. For instance, here's his gentle reminder on method in the probability chapter:
One could, were one so inclined, get really deep into the philosophy of what probability theory means. (This is best done over beers.) We won't be doing that.
He finishes up the introductory groundwork with a chapter on gradient descent, which is used extensively in the later machine learning algorithms. Then there are a couple chapters on gathering, cleaning, and munging data. He has some opinions about some API authors choice of data format:
Sometimes an API provider hates you and only provides responses in XML.
And he has some good expectation setting for the beginner data scientist:
After you've identified the questions you're trying to answer and have gotten your hands on some data, you might be tempted to dive in and immediately start building models and getting answers. But you should resist this urge. Your first step should be to explore your data.
Data is never exactly in the form that you need to do what you want to do with it, so while the gathering and the munging is tedious, it's a necessary skill that separates the great data scientist from the merely mediocre. Once we're done learning how to whip our data into shape, it's off to the races, which is great because we're now halfway through this book.

The chapters on machine learning models, starting with chapter 12, are excellent. While Grus does not go into intricate detail on how to make the fastest, most efficient MLMs (machine learning models, not multi-level marketing), that is not the point. His objective is to show as clearly as possible what each of these algorithms looks like and that it is possible to understand how they work when shown in their essence. The models include k-nearest neighbors, naive bayes, linear regression, multiple regression, logistic regression, decision trees, neural networks, and clustering. Each of these models is actually conceptually simple, and the models can be described in dozens of lines of code or less. These implementations may be doggedly slow for large data sets, but they're great for understanding the underlying ideas of each algorithm.

Threaded through each of these chapters are examples of how to use each of the statistical and machine learning tools that is being developed. These examples are presented within the context of the tasks given to a new data scientist who is an employee of a budding social media startup for…well…data scientists. I just have to say that it is truly amazing how many VPs a young startup can support, and I feel awfully sorry for this stalwart data scientist fulfilling all of their requests. This silliness definitely keeps the book moving along.

The next few chapters delve a bit deeper into some interesting problems in data science: natural language processing, network analysis (or graph algorithms), and recommender systems. These chapters were just as great as the others, and by now we've built up our data science tooling pretty well from the original basics of linear algebra and statistics. The one thing we haven't really talked about, yet, is databases. That's the topic of the 23rd chapter, where we implement some of the basic operations of SQL in Python in the most naive way possible. Once again it's surprising to see how little code is needed to implement things like SELECT or INNER JOIN as long as we don't give a flying hoot about performance.

Grus wraps things up with an explanation of the great and all-powerfull MapReduce, and shows the basics of how it would be implemented with mapper and reducer functions and the plumbing to string it together. He does not get into how to distribute this implementation to a compute cluster, but that's the topic of other more complicated books. This one's done from scratch so like everything else, it's just the basics. That was all fine with me because the basics are really important, and knowing the basics well can lead you to a much deeper understanding of the more complex concepts much faster than if you were to try to dive into the deep end without knowing the basic strokes. This book provides that foundation, and it does it with flair. I highly recommend giving it a read.


Both Effective Python and Data Science from Scratch were excellent books, and together they could give a programmer a solid foundation in Python and data science as long as they already have some experience in the language. With that being said, Data Science from Scratch will not provide the knowledge on how to use the powerful data analysis and machine learning libraries like numpy, pandas, scikit-learn, and tensorflow. For that, you'll have to look elsewhere, but the advanced, idiomatic Python and fundamental data science principles are well covered between these two books.

Suzy Cube Update: Wish List, Pre-Registration And Release Date!

#SuzyCube #gamedev #indiedev #madewithunity @NoodlecakeGames 
I promised you all a big update mid-week, well here is a HUGE update! Suzy Cube is now available to Wish List on Steam and Pre-Register on Google Play!
Read more »

(270 MB) Download Hitman 4 Blood Money Highly Compressed For Pc

(270 MB) Download Hitman 4 Blood Money Highly Compressed For Pc


Screenshot



Hitman 4 Blood Money System Requirements

Following are the minimum system requirements of Hitman 4 Blood Money.
  1. Operating  system: Windows XP, Vista, Windows 7, Windows 8 and 8.1
  2. Processor: Core 2 Duo
  3. Setup Size: 270 MB
  4. Ram: 1GB
  5. Hard disk space: 5 GB







Crowdfunding A Game's Development (LTUE – Panels 3 Of 4)


Crowdfunding has become a viable option for raising capital to complete a project. The tabletop gaming industry has a strong presence in crowdfunding. For game developers this presents great opportunities and unique challenges. Not every crowd funding campaign is successful. So how do you determine if crowdfunding is right for you and how does it work?

Two weeks after LTUE (website), I moderated a panel on this crowdfunding at SaltCon (website).

To Use or Not To Use, That is Your First Question

You should first decide if you want to use crowdfunding, and if it is right for you. It is not for everyone. There are several criterion to consider in deciding if crowdfunding is something you want or should do. You might even decide to change your mind as you work through the process in one direction or the other.

Crowdfunding takes time and energy. Not everyone is suited for or desirous of running a business. This might not seem like part of crowdfunding. However, crowdfunding is part of marketing, which is part of having a business. If you're looking at starting a campaign to raise money, then you are going to be involved in the other parts of business management. Some developers want to focus on designing games; therefore licensing or having someone else publish their game might be a better option.

Are you looking to create a one-off sale or build a business? The campaign you are looking to run will be different if you are working to create a brand that goes into other projects. How you invest your money in the campaign and from the campaign will be different along with how you want to manage your communications and growth.

How much control do you want, or can handle? This is along the same lines as having time. I've met developers who want full control of their final product. Those who want that level of control like self-publishing and building their own business. Others don't want to have to be involved in concerns that are not about game design. Again, licensing and finding a publisher or partnering with someone who wants to do that has worked for them.

Some projects are not well suited to crowdfunding. A good project for crowdfunding meets the needs of price point, availability, and the ability to create buzz in the desired community. One point emphasized was your product needs to meet expected return on value. If your game has a $20 value and the cost of making a copy is $50, you most likely won't have a successful campaign. If you do get the funding and you haven't priced it correctly in the campaign, which leads to availability problems.

Some crowdfunding campaigns are about getting sponsors who will invest in the development of a project, like a movie. For games, running a campaign is more like placing pre-orders. You should have a product ready to move into production. You can find many stories about how people and companies have been blackballed by the gaming community because they weren't able to meet the dates they promised. Those projects created excitement and then a major let down.

Consider if you have a project creates excitement, and to what level. Do research on similar games that have been campaigned on your chosen platform and other platforms. You should be looking to create a buzz about your game and your campaign which will get people talking about what you have—create enthusiasm through the community by talking about it in other locations. Your campaign needs to meet the expectations created in the buzz, so be certain that you are able to deliver on any promises made.

Before Going to a Platform

Know what your short and long-term objectives are. Before you start your campaign, you need to know if you're working to sell this one game or if you are starting a business to sell future games. If this is a one-time project, you are going to need to approach it differently. One-time events will have different levels to consider and will have a different business plan. Again, this seems like a simple question to answer. Remember that a crowdfunding campaign is part of your business, providing a level of marketing, no matter which way you are planning. It needs to be integrated into what you want to do. It is not the end all of your project, only one of the steps.

After you build a plan for your project or business you need to determine who is going to take which actions. You might want to do everything yourself, get a few select people, or hire someone as an employee or contractor. The only right way to do this is to know what you want to accomplish. Matching people's skills to your needs can be difficult, but the rewards of putting this all together can pay off.

I've interviewed several developers on their Kickstarter campaigns outside of these panels. The main reason given for unsuccessful campaigns was not having a clear understanding of what they wanted and a plan of how to get there.

Incentives

Don't give everything away. Pricing is an area you need to research. How much is everything going to cost to produce, print, package, ship, etc. There are horror stories out there of people who undersold their products and then ended up not being able to fulfill their commitments. Some have even driven successful businesses into bankruptcy. This goes for not only the basic product at the base backing level, but for the incentives you plan on providing. Know what you have and how you are going to deliver to your backers.

Don't promise something you don't have. Stretch goals are a part of many fund-raising campaigns. They can bring in a lot of extra money into a campaign. At the same time, those incentives can kill your project on the backside. If you don't have something ready for delivery, you might want to hold off promising it as an incentive. Promotional materials need to be delivered when promised to build your credibility.

I have an experience with a backing I did when everything was delayed. The game came out late. The promised special pieces were later, the promised expansion was even later. It wasn't until after all that happened that backers found out the project had been delayed because the developer ran over cost (bad plan and price point). They produced some games to start fulfilling their commitments and others to sell to raise money so they could fulfill the rest of their obligations. They also informed us the promised expansion had challenges that came out during playtesting and needed to be redesigned. I felt slighted on multiple levels.

This is also an example of needing to keep in touch with the people who are interested in your game.

Communication

Before the campaign begins, communicate to your base of supporters about the upcoming events you have planned. That means you need to collect contacts. To collect contacts, you need to be playtesting and sharing your game. Schedule time with local game shops. Attend conventions. Find those people who are interested and like your game and how to keep in touch with them. Then let them know about the progress you are making in the development.

Before the campaign begins is when you need reviews done. Reviews help people make a decision. Find good ones and get the game in their hands so they can get the review out. My fellow panelists at SaltCon urged having video reviews. They also agreed with me that you should look for other outlets like podcasts and written ones. These all address different audiences and usually focus on different aspects because they are produced in different media. There is also a difference of opinion about paying for a review. Some were for it while others pointed out that a paid review is an advertisement. You have to decide what is best for you—so research reviewers.

During the campaign, you should be sharing new information daily. This is work time. This is really important if this is your first campaign and haven't built credibility with a large audience. Be responsive to questions and concerns. Work with your team to spread the word as far and wide as possible. The objective of communication during the campaign is to keep people talking about (buzz) and coming back to check on the campaign. If you hit new levels in backing, tell everyone. Remind them what is now part of the release and what the next level has. Some people will go back and increase the amount of their backing if the campaign is closing in on something they want.

After the campaign closes you still need to keep in contact with everyone who showed interest and who has backed your project. The next few days can mean a lot in terms of additional sales of the original items and associated material. It was reported with the proper follow up, some campaigns increased by 50% with after campaign sales. You also need to make sure you have correct shipping addresses for all of your backers. But don't stop there.

While the project moves forward, keep everyone updated on the progress. People have now invested their money in your project and many of them will look at it as their project. Treat them that way. Let them know the progress and set backs as you get closer to fulfillment. This information will go a long way in providing satisfaction and building a reputation for your next campaign.

Final Thoughts

This is a time when all sorts of products and services are raising money through crowdfunding. Some of them are solid products and projects while others are nonsensical. None of that really matters though because your project is yours. You have to feel right about what you are doing.

Crowdfunding is an option you can use. If it is a viable option or not, is dependent on what you want to do with your project. There are people and companies who can help with a campaign in terms of coaching and providing resources. Go into a campaign after doing your research and developing a plan.

No matter which path you take, total self-publication, licensing, or selling the game outright, I wish you the best and hope your desires are fulfilled. I look forward to seeing your name on the game shelf.

Fellow Panelists

LTUE (information from program guide)

Marion G. Harmon is the author of Wearing the Cape series and the writer of Wearing the Cape: The Roleplaying Game and the Barlow's Guide to Superhumans sourcebook. wearingthecape.com.

William L. Munn is a writer and tabletop gamer. Will has written for gaming companies lie Gallant Knight Games, where he contributed to Tiny Frontiers: Revised and Cold Shadows. Currently, he's working on Zorro the RPG as a writer and producer. Will has a deep passion for storytelling, gaming, and writing. In his free time, you'll find him playing and running tabletop games with family and friends. liamwrites.com.

L. Palmer is the author of The Pippington Tales, where motorcars bump down old city lanes and fairy godmothers are disguised as high-society gossips. In between exploring fantasy worlds, she works in public service and lives in South Texas. lpalmerchronicles.com.

Daniel Yocom runs Guild Master Gaming, which has supported tabletop gaming and other things geek. It includes reviews of games, books, and movies. Articles also appear on other websites. He has short stories published and is working on his first novel. guildmastergaming.blogspot.com.

If you have a comment, suggestion, or critique please leave a comment here or send an email to guildmastergaming@gmail.com.

You can also join Guild Master Gaming on Facebookand Twitter(@GuildMstrGmng).

Tuesday, April 2, 2019

Getting A Bit Of Everything In Guild Ball: The Union




Tuesday night is our game night out at Top Deck Games (aka Card Titan online if you're into Magic the Gathering) and last night was the first time I've been able to make one in a while. 

It was also the first night in a long time where I was able to get two whole games in, and it ended up being two Guild Ball games for me as the other Warmachine players had already paired off when I was done my first match. 

I decided I wanted to play more of my newly fleshed out Union as I'm probably most excited about playing them.  I figured I'd post about why I'm personally excited about them given my history and what I feel makes them strong. Please keep in mind, I'm no expert at the game so this is more of a layman's perspective. 

Why I'm Excited About Union

I can't talk about what makes me excited to play Union without talking about my previous teams in Guild Ball.  I started the game playing Brewers, and then picked up Engineers because well, I like beer, and I'm an Engineer.  

Brewers, especially when I picked them up, were more of a fighting team, and Engineers once they got reworked were more of a goal scoring team, so they'd make excellent compliments to each other, or so I thought.  Both teams also generally rely on a single captain more than the other. Brewers generally want to be playing Tapper and Engineers generally want to play Ballista. 

What I've found from playing both teams is that it's like playing the two extremes of the game. It's not quite as opposite as playing Butchers and Fishermen, but it's close enough to feel limiting.

Union by contrast can more easily play what the developers call a balanced game, looking to get 2 goals and 2 take-outs to get the 12 points to win the game.   This is probably why I'm more excited to play Blackheart as my Union captain compared to playing what most people consider to be the stronger Veteran Rage as my captain, though I do enjoy playing both. 

My First Dream Team

I wanted to make a team that had as much 2" Melee as possible while also being balanced.  Back in June of last year, it appeared that Union had a good 6 player lineup for this:

Blackheart, Strongbox, Harry, Mist, Benediction, Gutter

Then in July the nerfs came for Harry which toned the team's damage output way down, but I still feel as though these 6 players can make for a hell of a team. 

Blackheart can still score from very far away, using all kinds of dodge shenanigans to get in range for his 6" kick to nail a goal, quite likely at Tap-In range.  He also has Butchery which can give you +1 to damage results against the model hit, and with all non-mascots having 2" melee, it's not hard to stack crowd out's on the player you've hit with Butchery.  Strongbox add's +1 TAC in a 4" aura, which again can allow someone like Gutter to get in and do a massive amount of damage, but nearly anyone on the team can be made to hit hard enough to be a problem with that kind of setup. 

And then there's Mist. He's got to be one of my favorite models coming from playing Brewers and Engineers. Now that Slothecian models have been released, he gets a free 2" dodge if he's within 6" of Grace or Benediction. He has Acrobatics, so he's got a guaranteed 2" dodge.  He has 2" Melee which is fantastic on a striker, and he's got dodges for days.  A turn 1 goal with him when you're receiving is extremely easy to bang in, and with him kicking off it's not impossible to get in that scenario either if your opponent isn't very careful about it. 

The Extended Roster

Blackheart wasn't my first Union captain, that went to Veteran Rage, since I could buy him and Strongbox cheaply in a blister and I already had all the other models necessary to make a team with him at the time (a friend had given me an extra Mist model he had as payment for splitting a pizza on game night – damn Guild Ball is a cheap game to get into).  This gave me a 6 man of:

V. Rage, Strongbox, Avarice & Greed, Gutter, Mist, Harry

This team was far better before Harry and Avarice & Greed were nerfed, but now that I've fleshed out the guild there's a lot of flexibility on how you can build a solid Vet Rage team.

My 10 player lineup is now:

Blackheart, Vet Rage, Strongbox, Avarice & Greed, Gutter, Mist, Harry, Grace, Benediction, Decimate



As of last night, I tried out the following team for Rage and it worked well into Engineers:

Vet Rage, Strongbox, Mist, Gutter, Decimate, Grace

With this, I have three models with 3 dice kicks, and two models with an 8" kick.  While it seems like a lower Influence team at only generating 11 influence, it gets 2 influence for free to fuel Grace every turn.  This allows her to give a "free" Quick Foot to extend Rage's personal threat or to make Mist go even further to score a goal. 

Since it's a Vet Rage team, few people want to fight into it and so go for goals, allowing me to easily get snap back goals with Mist or if I'm receiving, get a very easy turn 1 goal with Mist.  Getting an early goal is a big deal for the team since the extra goal Influence goes a long way to helping Rage do what he wants to do.

It's hard to understate how deadly the team can be with Rage's Heroic or Legendary play and Strongbox's 4" Aura.  Last night I had a setup where Colossus (DEF 2, ARM 2, Tough Hide) was crowded out by Mist, Grace, and Strongbox. Rage popped his Legendary play and then charged in for free with Furious. On the wrap I got a Knockdown and did 4 damage.  I then spent 4 Influence on Red Fury, not making Rage attack, but making Strongbox, the friggin Turtle attack.  

The amount of damage it does in this situation is outrageous: 2 Base Attack, +1 from Shelling Out Aura, 3 Crowd Outs, +1 from Legendary Play, +1 dice from a DEF 2 model being knocked down is 8 total Dice for TAC and +1 to all damage results.  Since Strongbox only has a 2 deep playbook, he is able to wrap many times. Even with Tough Hide taking damage off of each result, I was still regularly pulling 5-6 damage per attack after Tough Hide. With 4 Red Fury attacks I easily took down one of the biggest models in the game with a little turtle.  He's like an honorary Teenage Mutant Ninja Turtle, I should try and paint a mask around his face.

Strengths and Weaknesses

One final thing that Union has over my other teams is that with my lineup I really can pick either Blackheart or Vet Rage and play two very different games, which is something relatively rare in Guild Ball. 

This isn't to say that the team is nothing but a power house, I actually lack a significant amount of resiliency that I normally have with a lot of Tough Hide models.  As it is a lot of my models are either 4/1 or 3/2, which is possibly better than average, but once they get knocked down or debuffed they will take a lot of damage very quickly.  So far my games with them have been good, but I intend to play a lot more with the team.

The only thing is…I really want to play more with my Engineers and even my Brewers since it feels like so much has changed in the game since I last played.  I'm definitely riding high on Guild Ball in general right now and it feels pretty good.

The Obscure Ultima, Ultima: Escape From Mt. Drash


Back in Ye Olden Days, I knew nothing of blogs and was content to post materials on forums and newsgroups and the like.  I contributed a few writings to GameFAQs back before the days when it was purchased by GameSpot.  The only actual FAQ for a video game I ever contributed that described how to beat a game was for the VIC-20 game Ultima: Escape from Mt. Drash.  When GameFAQs took over, I removed all my content from that site.  Now, having finally been able to play the game on original hardware, I think it is time to revive the old FAQ.  Moreover, no longer limited to plain, monochrome text, I can do more now that I have my own blog and the ability to add images, color text and link video.  Let's take a trip into a rarely visited part of the Ultima Universe.

Read more »

Monday, April 1, 2019

The 3 R's Of Wargaming

Reassess, Reorganize, Rebase.

Its only been a couple of years since I popped my 54's off their 1" washers and reorganized the 8 single figure units into units of 2x3 figure bases.


Shouldn't take long to make that right for the older units. Bringing the newer 6 man units up to scratch will only take a little longer.