Excalibur's Zone

Today, I tried a few different things with the playtest, which was a 2-player game with my friend D.

1. I set the number of techs to the number of players +1 per tech level,
2. I drew a number of techs equal to the number of players -1, and
3. Extra white dice were added only when a player got a cube on the next level tech.

What did this accomplish? Not much that was good. First, the player who finished the face-up tech first was able to pull away with points much faster than the other. Second, this did nothing to speed up the game. At. All.

Also, some things where highlighted: while Production Dice had something they did whether they were successful or not, research dice did nothing. There was no use in the research dice at all except to use for other game actions.

It is of my opinion that dice need two functions. One that relies on successes and another that relies on face value. To that end, I’m going to utilize research dice in another fashion which will help speed up tech acquisition.

I think what I’m going to do is make it easier to acquire techs. I found it was rather difficult to score the number of successes needed, even with the failure mechanic (luck mitigation). Basically, you can store a die as a failure and after a certain number of failures plus an amount of production points, you can get a success of a certain type needed for the tech you’re working on. While this is awesome, in theory, in practice it was a bit slow.

Also, the number of successes and production points required for a card are a bit over-inflated. Basically, I want to be able to make tech purchases possible, but not dirt easy.

To make tech purchasing easier, I’m going to employ the first of the ideas bandied about tonight. You’ll be able to use the face value of the research die to use as research points if it is not a success. After a certain amount of points, you gain a success on the card. It might make it a bit faster since you’ll be able to stockpile the points on the card for what you’re looking to get if you can’t roll a success to save your life. I’m thinking the average of 2 dice, each rounded up. Since the average is 3.5, that would round to 4 x 2 = 8 points to buy a success instead of rolling a 6 to gain a success immediately. The points you can spend would be limited by your white dice as normal and you would still need production points (reduced from current levels) to purchase the tech.

So, you’ll be given a choice, use that research die to put into buying a success or use that research die toward production points to buy the tech when you’re ready. Also, white dice become more important. This also gives research dice added reason to be in the game.

We’ve found that white dice and pink dice (the two production dice in the game) work very well the way they’re set up as limiters and how successes are utilized. The dice are meaningful when they’re rolled and that’s what I’m aiming for with all the other dice.

So next playtest:

1. Research dice produce an automatic success (a 6) or
2. Research pips can be used to purchase success at a higher price, probably 8.
3. Number of techs in the deck is equal to 1 per player per tech level and
4. Number of face-up techs is equal to the number of players.
5. Production points to purchase a tech will be modified to account for the use of research pips as research points or production points.
6. The number of successes for lower-tier techs should also be looked at, maybe that plus #5 above will be tied together…

Victory points, Tech powers, Wonders, and Achievements will all need to be examined. I want techs, Wonders, and Achievements to be interconnected somehow and I want one achievement to deal with victory points.

For now, I’m going to concentrate on the 6 elements for the next playtest. I am also going to be doing a lot of single-player playtesting to see what kind of appeal this might have for solo gamers.

Hello, everyone!

Just wanted to drop a short post about the new wiki! This is going to be a place where I can update episodes, series, and the like without having to deal with reddit’s posting issues. I keep having to moderate my own posts even though I’m logged in. They get marked as spam and I have to re-approve them. Quite irritating. So, here’s a wiki to keep you up to speed and to make things far easier for me to deal with!

Right now, I only have a few series up dealing with Magic: The Gathering under my “A n00b’s Guide to Magic: The Gathering” label. Just like reddit, the site won’t update any of my social feeds so you have to check often. Or you can use it as a reference later on.

I really want to make sure all my videos are indexed in a categorized manner. Hopefully the wiki will let me do that!

Until next time, enjoy playing games, check out my wiki! I am out!

Today, in addition to playing some FUN commander games, I was able to sit down with my friends L and C (until I get permission to use names, I’ll use letters for the playtesters) for another pre-alpha playtest. The focus of this game was to see how other players felt about what was going on with the core mechanics of the game.

The results? It took a few turns for everything to click, but luckily I was there to explain things. I believe the core mechanic is sound but there needs to be a concrete, documented explanation of the terms, zones, and actions that can be taken during a turn. I had to explain how the dice worked more than a few times and I kept going back to the core mantra that I set for the game. I was hoping it was a simple one…

The big hurdle was understanding what active dice were and how limiters worked. After a bit, we were able to push a turn around and go. There were still questions about what should be done with dice, what order things should be purchased in, what is the strategic value of this or that. But, after a while, I started seeing L and C start to think about where their dice should be spent, given their limited resources at times.

L said he had a fun time and enjoyed the game. C said the game was something he’d play if it was offered but he wouldn’t rush out and buy it. Mainly, C only saw a small portion of the game and we didn’t get to any of the stuff I’m still working on.

We were able to:

1. Gain 2 VPs each by completing a technology,
2. each research a tech,
3. use the Wonder cards for their start player effects,
4. and see all of the Tech Level 1 techs.

Some lessons learned:

• There are still too many technologies being displayed for each tech level in order for the game to be considered speedy.
• Players are initially very confused about the core success/failure mechanics and the value mechanic.
• Players are initially very confused about how to use dice as successes on technologies (as Research Dice) and when to use them for actions (Action Dice).
• Players are confused as to what can be done with dice if you don’t have any successes or are severely limited by the number of successes allowed.
• More of the game has to be designed (the technologies and wonders at the very least) so that players can have a better view of the game.

To that end, here is a short intro about the game I’m working on. Not the particular mechanics, per se, but an overall description of the beast:

Die Civilization is a game about civilization building using dice. Dice represent production, manpower, military prowess, espionage, agriculture, think tanks, and other aspects of a civilization. Technologies are cards that represent milestones in human development from the stone age to the medieval era. And finally, you can build the seven wonders of the ancient world.

You win the game in one of three ways: Collecting the most victory points by researching and acquiring technologies, finishing your wonder before anyone else, or by completing the majority of the achievements available at the end of the game.

I’m still up in the air about achievements. Initial plan is to have them face down and hidden throughout the game. You can use dice and production to look at them throughout the game, but I’m not sure if this is a good thing or not.

The number of technologies available aren’t moving fast enough on a per-tech level basis. I think I’m going to revamp the initial deck to have less techs in the “play deck”. Currently, you draw twice the number of players for each tech level, shuffle them, then stack them with tech level 1 on top and 5 on the bottom. I think I’ll go to number of players + 1. That might be a better route to go and speed up the game. Everyone advances tech level at the same time–when a higher level technology hits the table. I think this is the most balancing way to do it, though the person who starts their turn with the new tech in play is going to have a small leg up over everyone else. But I have to see how well this works before I make the final call.

Technologies really need to be designed next. I want them to have two benefits that the player has to choose from when they complete it. Then they place their tech under their tableau in such a way that the benefit they chose is displayed. Other players still need to be able to research the tech as well. So I have to figure that one out. Technologies give a free die and 2 benefits for completing it. The die is for the one who completes it first. You’ll want to complete it for the benefits and possibly for the achievements as well.

Wonders need to be designed. They are an ongoing project which is another place to dump dice. Each has a number of stages that need to be completed and each stage provides something interesting to the player completing them. I was going to have players draft their wonders, but then I realized that may break balance if someone has played a particular wonder enough to figure out tricks and grabs it every time they play (to go first, second, last, whatever). Random distribution is the best bet here.

One last thing on the dice: I’m debating making dice a limited resource and it may enforce player interaction to gain those resources. I like the idea, but I have to figure out if it’s feasible.

I hope with the initial game that there is enough randomness and components that the game has a lot of replayability. The game is being designed for 2-4 players with a customized 54-card deck of cards, a number of dice, and 10 cubes (or meeples) per player. That’s quite a number of components. So I may look at going into a digital version first and a physical version after. Again, something I’m examining.

Back to dev and work! Hope my meanderings are somewhat interesting to you!

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.