Excalibur's Zone

While looking at my notes for Die Civilization (DieCiv), I began to feel like I was burying myself in bricks and concrete in an effort to build a house. I was trying to assign actions and effects to all the research dice and production dice, effects for the technologies, benefits for not rolling flat-out successes, and a whole slew of other things.

In essence, I was looking at the trees and ignoring the bear barreling down on me from behind…

So, I took a step back and asked myself a few questions:

• What do I want to do with this game?
• What roles do the dice play?
• What roles do the technologies play?
• Are technologies and achievements worth it?
• Are the dice worth it?

And I asked myself a few others. I thought about the questions at hand and tackled them individually instead of all together. I applied a principle I learned years ago in programming called functional decomposition. Generally, you take all the stuff that does the same thing, create a function then when you need to do that thing, you call the function. So I pulled out everything that was doing the same thing and set that stuff aside.

I sat back and looked at what was left over and realized that what I was making the dice do more than necessary. Two dice act as limiters in addition to their normal functions and I really like that idea. But what about the other dice?

I realized that those benefits would be better served as bonuses provided by the technologies! Wow, now technologies have more of a reason (I’d spoken with a friend about this previously) to exist and dice are FAR less complicated.

Imagine that, even though I’m microscopically attuned to the game, I was able to take a step back, look at things from a different perspective (thanks to my programming experience) and rework things so that the game would turn out even better than the pre-alpha playtest turned out!

I’ll be working on this one for a long time, but I have at least 7 level 1 technologies that will start off with some good abilities! Now I just have to figure out which research matches which technology and to which color the technology belongs.

I am, by no stretch of the imagination, not a mathematician. My brain doesn’t quite work with O(), derivations, integrations, Omega, or natural logs (or any kind of logs, really). But when designing a game, unless you have a number monkey on your team, you have to sit down and hammer out equations, checks, and balances to ensure one player can’t overrun everyone else through mathematical exploits.

Since I am not a mathematician, I generally lack the patience to research proper theory about statistical analysis of randomness in games. I find reading proofs boring and I subconsciously ignore any and all math equations. This isn’t helpful when trying to figure out the best cost-to-player ratio of in-game assets, or how many dice is appropriate for the start of a game. I have to rely on the games I’ve played and a cursory glance at how the mechanics for these issues were designed (from a player’s perspective) for those titles.

That being said, I am by no means a slouch when it comes to understanding mathematics. I needed quite a lot of it for my graduate work in computer science. I’ve found that some basic knowledge in statistics and algebra will go a long way to a pre-alpha or prototype version of a game.

I’m going to use Die Civilization (DieCiv) as my example game since I’m working on it as we speak. The original game required a LOT of custom dice—ten with different colored faces. Each die was somewhat unique in that I used frequency analysis on the cards for a game called Innovation (by Carl Chudyk). I went through each age the cards represented and figured out the frequency of each color icon as it appeared in that age. With that frequency analysis, I was able to determine how many faces on each of the ten dice were of any particular color. Each die represented an age in Innovation, so I had a way to collect resource cubes with dice.

It was pretty exciting! The problem came when players began to interact. It was done through combat, posturing of red and green cubes, actions that happened during, before, and after combat, and a whole slew of other complications. The resource market was meant to be both functional and thematic in that you built a pyramid of the resources and had to spend resources to get more. The game became slow and sluggish. Not fast and sleek like Roll Through the Ages.

So I went back to the drawing board. I’d done a lot of footwork and guesswork with the previous incarnation (I believe v1.1a), but the game didn’t feel right. I wanted a push-your-luck game. I wanted a game that allowed you to do things with the dice, not with a bajillion cubes.

Enter DieCiv version 2.0a. There will be a lot of dice in the initial game (approximately 58) that represent concepts such as production and manpower to agriculture and combat units. The majority of the game’s mechanics rests on two different concepts: success/failure and point accumulation.

The problem with balance is introducing technologies which will cost research and production points to claim. Also, the type of research needed, how much the technology costs, and the benefits the technologies provide. In addition, each type of research die provides a benefit if the success doesn’t happen.

That is a lot of probability, luck, and math. We have to look at luck mitigation techniques in case someone just has a bad time with the dice. We have to look at limiters in case someone is having a wonderful time with the dice. And we have to weigh in the probability of the draw of cards from the technologies, wonders, and achievements.

This is not a light game. During the first playtest, the pre-alpha (of which there will be many), the game lasted for over one-and-a-half hours. The interesting thing about the experience is that even though we were tweaking and talking about what was going on as we played, it felt like twenty to thirty minutes. We had fun, never got bored, and played strategically. The rules as written (RAW) made us think about nearly every move. I wish all playtests were like that.

In any case, to balance the game for the playtest, we used Innovation’s cards as the technologies (because that’s what they are). We found that the lack of certain icons on these cards was keeping us from even looking at the majority of the components for DieCiv. We also discovered that purchase prices for the technologies were rather…low. Victory points were…OK (twice the technology level for the first one to complete the tech’s acquisition, the tech level otherwise). And the cards were definitely large enough for the size cubes we were using.

I need to look into balancing seven dice across eight cards (eight per tech level) so that there’s a chance that players will see most, if not all, of the dice in the game. There are ways to acquire all the dice which are a part of the catch-up/luck mitigation mechanic. So their abilities can be used once acquired.

To that end, I have decided there are three total requirements to purchase a technology:
1) A research success for each color shown on the card,
2) Production points of a certain amount, modified by tech level,
3) and at least one production point produced by a die that matches the card’s color.

Now it’s a matter of choosing the colors of the cards, the colors of the icons, the cost of the cards, and whether or not I have variable numbers of required research icons on them. Additionally, do I want to add a tech tree to ensure players progress through certain technology chains? Well, that’s a question to answer another day. For now, I’m just going to make my closing remarks.

When you’re working on a game for the first time make sure you play a lot of pre-alpha and alpha playtests before you move into the beta state. Refine your rules as you go along and observe any outliers which may cause the game to break down.

In terms of balance, it’s important to know approximately what you’re looking for in the components. Nothing has to be laid out in a plan or set in stone! You’re trying to get a feel for how the game plays, how long it takes, and what you need to keep your eye on. Balance can be as simple as using another game’s components and expanding from there. It can be more complicated by studying up on the mathematics behind all of your mechanics.

Me? I carry a notebook and pen with me when I’m designing to jot down ideas whenever they show up. I sketch out layouts and how things may look down the road. I draw a lot of diagrams trying to figure out placement, how many things of something I need, averages of dice rolls, and point systems.

This may have been a ramble, but I hope you walk away with a little insight into what I’m doing and maybe some of it can help you…

This update is about DollarCon, a gaming convention in the RVA area. Scheduled for November 14-15, 2014. You can find more information at http://dollarcon.nevermoregames.com/.

To RSVP, please contact Wendy Seitz at wendyseitz@yahoo.com.

I’ve been playing games for quite some time. Many of those games have a card component where you either follow the instructions on the card or you add values together from one or more cards.

Games like War, Hearts, Spades, Cribbage, Poker, Go Fish!, and others have been staples in my gaming pantry for years. It’s pretty easy to pull out a deck of Bicycle cards and play Solitaire, Tri-Peaks, or Old Maid. And games like these tend to be “time passers” rather than for excitement.

In the nineties, Magic: The Gathering changed all of that for me. Cards were no longer about a value or a suit. They were instead creatures, spells, enchantments, and artifacts. Taking my love of fantasy into a new realm and making cards a part of a strategic game more akin to my beloved Stratego.

Since then, I’ve discovered other games that use cards in ways different than the traditional value comparison, set collection, or point accumulation games. I’ve seen games where cards represent units in an army (Summoner Wars), creatures (Talisman, Magic), or abstract ideas (Dixit).

My favorite, thus far, has been from Innovation. Cards represent technologies during certain ages of human history. But that’s not the mechanic. Splaying (or fanning cards in a particular direction) is where this game is unique.

We’ve seen splaying when people hold their cards or when a prestidigitator fans cards out on the table for someone to choose. But innovation does this in an interesting way.

Each card has four icons on it. One hexagonal and three square icons. Each icon represents something, an abstract something, about human culture, society, religion, or other ideal. The splaying mechanic is what makes these icons, or rather the placement of the icons, unique and interesting.

If the pile of cards you are splaying (a single-card pile cannot splay) is splayed left, the pile shifts to the left until the right-most icon on each card is displayed. If the cards are splayed right, the two icons on the left of the card are displayed. And finally, if the cards are splayed up, then there are three icons at the bottom of the card that are displayed.

Each time you splay your piles (Innovation has from one to five piles per player) your civilization becomes stronger. The more icons of a particular type that are visible, the more adept your civilization is at performing card actions associated with that icon. This means that your attacks will work more often, or that you will share your actions far less. But this also means that you get to partake in other player’s shared actions, which gives you board and/or card advantage in many situations.

I enjoyed the splaying mechanic so much, I designed a game called GalaXism off of that mechanic. In this game, you are piloting a starship. Each part of your ship is a stack of cards (starting at one card per stack) with one stack in the starboard, port, aft, fore, and command sections of the ship. Each card has icons which represent weapons, shields, armor plating, thrusters (a fast ship), maneuverability (an agile ship), and initiative (a trained crew). You ready weapons by choosing a stack and splaying that stack to a level equal to the number of weapon icons on the top card. So, if you have one icon, you splay to “Shift Level One” which equates to splaying left. If you have four weapon icons, you splay to “Shift Level Four” which shows all icons on all lower cards. This is slightly expanded from Innovation.

Overall, the mechanic is pretty awesome and I believe very usable for different genres of games. GalaXism suffers from an unbalanced set of icons (one player can turtle so effectively, nobody can hit him) and a cumbersome tableau. Shifting all those piles of cards around then back again makes it somewhat sloppy to play. I consider this game to be a success at re-purposing a mechanic, changing the theme if you will, but a failure as a fast, fun game.

The game has gone back to the drawing board to be redesigned for more components and to allow for some balance to be added. Until those rules are ironed out, I’m going to enjoy playing Innovation, well when my gaming crew is in the mood for it that is.

It seems that I’m releasing an Indie Game Let’s Play & Review (IGLPR) video every day now. What started out as an attempt to break into the world of Let’s Plays and Minecraft has instead turned into applying my computer science education to indie game reviews.

You see, an IGLPR isn’t a method for me to get new games to play. It’s all about providing feedback to the game developer by using elements of a usability test. This is a type of analytic tool that developers employ to better understand how users interact with software. Usually, a person who is taking a usability test is given a script to follow that asks for specific actions to accomplish. “Open a document from the USB drive”, for example. The user is expected to perform the action and describe what they’re doing, what they’re thinking about, and other factors in their experience in performing the task requested. There are usually several tasks, questionnaires, and maybe a short survey. All of this data is recorded, whether it’s a good experience, bad experience, how difficult or easy the tasks were, and things of that nature. The developer then has information that can be acted upon to make an interface easier or more intuitive to use. You see, usability testing is a valuable tool that allows a developer to improve a product and make the user experience (or UX) more “enjoyable” for those who are the intended audience.

Usability testing is not the same thing as alpha or beta testing. These types of tests are used to find and report bugs, for the most part, and are usually not set in a controlled environment.

From my time as a game dev (very limited at that), I usually had one or two people to bounce ideas off of and check out my game’s interface or limited functionality. Usually, I got feedback that was meant to make me happy or to encourage me to continue. I love my friends for thinking of my feelings like that, but as a developer, I want the good, the bad, and the ugly for what I’m presenting. If a feature sucks, tell me with all the vitriol in the world if that’s how it makes you feel. If something is awesome, praise it if that’s what you want to do. If something needs work, give it the praise or hate you feel fit to provide and then suggest alternate methods to how you would like to see the interface handled. I didn’t really have that. And any time I got a partner to work with, I did the communication, the work, and then things fizzled with me holding the project and doing it by myself anyway. Which ultimately lead to failure. Which is not a bad thing, in and of itself, just something that kept me from getting something out there in a more permanent fashion.

The long and the short of it is: If you’re working as a solo developer, it is really, really frustrating and difficult to get good, honest feedback. Especially if you don’t have presence in the indie dev world. It is very hard to do everything yourself. It is very easy to become invested in the way you present a game, design the interface, apply the mechanics and physics of the world. You become too close to what you’ve created and that means you generally don’t see things as clearly as an “outsider” might.

So, with my IGLPR videos, I provide a valuable service. First and foremost, I provide a first look/first play of a game. I refuse to do an IGLPR for any game I’ve played before. Why? Because that initial reaction you get from a new player can’t be captured after the first time the game is played.

I play many games without reading the instructions first. Why? Because that’s how an average person is going to play the game. They are going to start it up and jump right in, feet first, shouting about their new game all the way until they hit that wall. If there are in-game instructions, that makes things easier. Though, if it’s a lot to read, I’ll skip right to the action and start playing, using the in-game instructions as a reference. This shows how intuitive the game is to play, how easy it is for a new user to start the game and just go.

I ignore the graphics, audio, technical aspects, and gameplay when I give a rating. Sure, I comment on how they look, whether they’re pleasing or whatnot, but these things are superfluous and can change at the drop of a hat. The only thing I harp on is the ability to customize a user’s controls. There are many people who aren’t right/left handed, that are handicapped, or have issues with certain control setups (WASD irritates me). Without giving the users the ability to change how they interact with your game is a sure-fire way to lose those players.

I play the game for roughly twenty to thirty minutes, though sometimes the length can get out of hand if I’m really enjoying a game or if the game is really complex. Even games that are simple to play and have rounds that last only a minute or so get at least a full twenty.

And why do I do this? Why do I do it free of charge? Well, it’s my hope that I can help devs improve their games and make them more fun. A lot of indie devs can’t afford to pay for proper usability tests and, to be honest, I don’t think many even realize that they can do this. They’ve heard of playtesting (alpha or beta) or unit testing but may have never even heard of a usability test before.

In the end, I hope this helps get my name out there, that I’m here to help others, and that I can become a successful game reviewer. I hope that one day I can do this for a living, devote more time to it, and have fun doing it.

Well, this was a bit of a chaotic read. I hope you got a bit out of it. And, as always, this is Excalibur. And I’m out.

Most episodes go out at 6PM on the day scheduled.

Monday:

• FLGS News & Events Podcast (audio only) and is available on YouTube and excaliburszone.com
• Modsauce Mondays (massively modded Minecraft)

Tuesday:

• Tyken SMP Adventures (lightly modded Minecraft)
• Indie Game Let’s Play & Review, Revisited (Midnight Livestream)

Wednesday:

• Magic: The Gathering – What’s the Combo?

Thursday:

• Excalibur Plays FTL
• Indie Game Let’s Play & Review, Revisited (Optional Livestream)

Friday:

• Excalibur’s Vanilla Adventures (100% vanilla Minecraft)

Saturday:

• FNM Reports (When Friday Night Magic is played Friday night)

Sunday:

• Apollo’s & Excalibur’s Survival Sunday (AM Livestream)

Additional Series and Info:

• Indie Game Let’s Play & Review episodes happen all the time at various times during the day.
• D6 Crack Pack is sporadic and can happen at any time.
• Magic: The Gathering Deck Techs are sporadic and can happen at any time.
• Unboxing videos are sporadic and can happen at any time.
• Channel Updates happen every month on the 1st or 2nd.
• D&D Session Reports happen once per month, usually on the first Monday following the first Sunday of the month. Podcast (audio only) that is available on YouTube and excaliburszone.com.
• Game reviews are sporadic and can happen at any time.

For more information on each show, you can visit my subreddit at https://www.reddit.com/r/ExcalibursZoneGaming where I describe the shows and provide episode guides.

More series are planned as are more podcasts, reviews, and other gaming-related media.