Alright, I have some bad news.

In light of last weeks realization about what a "prototype" should look like and what my existing "prototype" was (a pretty tech demo with game elements), I decided to readjust radically on how I prototyped my game. Let's reflect for a moment on the past: I've been working on building a prototype of my game in C# and XNA for 5 months using my home-brew engine. The prototype is throw away code, though many aspects can be usable and ported over to the production version of the game in UE4. So, there's no point in spending any more than the minimal amount of time and effort to build the prototype since it's not going to be used. The whole point of prototyping is to build something as quickly as possible to test game design ideas so that you can fail as quickly as possible and iterate. If it takes 5 months to build a "prototype", you're probably doing it wrong. So, that was humbling realization #1.

Design approach:
Epiphany: I can build the game prototype using paper, pencils, crayons and index cards. So, that's what I did. The first iteration of the prototype was a turn based simulation of the real time game battles between units. That was hard -- simulating real time in turns. How did I do it?

My game calls for units of creatures within a formation positioned on a battlefield. Each creature has some basic statistics (health, attack, armor, move speed, etc). The unit contains a number of ranks and files, so a unit of peasants would be a 10x3 formation. So, I cut a 3x5 index card in half, drew each creature in the formation, and wrote down their stats on the card. To use the peasants on the battlefield, you just place the card on the table where you want them to be positioned. I also had an index card which acted as a measuring stick, with tick marks marked off at about 1cm intervals. Each tick mark corresponds to one movement point, so if a peasant unit has 6 movement points, they can move 6 cm in 1 turn. The battlefield can contain 20+ units at once, so that's a lot of cards to make. The formation position, rotation, and dimensions matter as well. If a unit fights another unit, each creature in the units front line needs to be matched up against a creature in the front line of another unit. So, if your front line contains 10 creatures and the other front line contains 8 creatures, 2 will be free so they can gang up on other creatures. I also calculated damage per creature and health per creature. If you're doing this manually for each unit, it starts to take a while and gets pretty complicated and tedious quickly. Calculating the results of a fight manually would take about 5 minutes per fight, and if you have lots of units on the battlefield, and it takes multiple fights to kill a unit, it can take an hour or so to manually resolve the outcome of a single battle. This was super tedious and detracted from the game play a bit, so I decided to build a fight calculator in C# using Win forms. That took two and a half days to complete.

First run:
In the first iteration of the card version, a lot of units were either overpowered or under powered. Archers were easily the most overpowered units, because every archer in the unit could shoot and scoot and they did insane amounts of damage. They could essentially one-shot the king unit if they got in range, which isn't supposed to happen. The dragon spell is supposed to be an expensive spell which is hard to cast but creates a mighty dragon on the battlefield which is hard to deal with. Nope! archers wrecked the dragon without any issues. So, why were the archers so powerful? two reasons: Their stats were too good and the game mechanics were flawed to favor archers too much. Interesting...
So, I made some rule changes to the game play mechanics and tweaked the archer stats. The ideal I'm aiming for is a bit of a "rock, paper, scissors" approach, where some units are extremely strong against other units, but very weak against others, so you have to have a varied unit composition and be tactical about unit placement. Archers broke this too hard.
Once I built my calculator, I could quickly run fight simulations to see exactly how an engagement would play out. By tweaking the stats a little, I could approach the ideal engagement results better by seeing what works and what doesn't.

The good:
#1: By using index cards (use pencil, not ink pen!), I can quickly change game mechanics and game rules without writing any code. I can test those mechanics out to see if they work and are fun. If they don't work, I can change them with next to no cost. Once you start writing code, you start investing lots of time and energy into something which you're not sure may work, which may then cause major refactoring and additional time waste.
#2: I also kept my rules written down in a notepad++ document with bullet points. Keep it lean.
#3: My strategic game map was just a photoshop document with layers for game board pieces. This was good enough, though it bound me to a computer terminal.

The bad:
One thing that sucks about using index cards to simulate unit formation positions on the table is that the cards are unwieldy. Cards can overlap too easily and they can be bumped while you're moving another card. The only important part of a card was the unit formation type and position, so I created cutouts of the formation instead and we moved those around. If you needed to see the stats of a formation, you could pull up the card and look it up.

Another challenge to consider carefully are the issues you get when you're trying to do a turn-based simulation of a real time battle. You have to ask, "Is this a problem which results from the turn based simulation limitations, or is this a problem which results from poor game design mechanics?". It's a hard call to make. In my case, if a unit got injured and you wanted to run away to heal, how do you do that if you're engaged in a fight? It depended on who went first. If unit A (A) is engaged with unit B (B), and A wants to run away from B... If B goes first, B attacks A, and then A retaliates and is locked in combat. This is unfair to A. If A goes first, then A runs away and B wastes a turn attacking air instead of chasing A. This is unfair to B. So, fights became a contest to see who goes first. Initiative wasn't something I had designed for, but turns out is kind of important -- at least for a turn based game. If the battles happen in real time, a lot of the issues are automatically resolved except for a one: how does retreating work?

I also added in the "strategic map", which added another dimension to the game play. It's similar to a risk style game board. By capturing a territory, you gain a corresponding mana color for casting spells. This slows down the beginning battle complexity. You also have to spend turns researching spells or recruiting units for your armies. This adds some additional complexity and interesting decision making.

The play test:
So, last night I brought in a game designer who works for a game studio a few blocks away and we played through this game scenario. We started at 7pm and played through about 15 turns on the strategic map. He went through two battles against neutral armies. By the end, it was 10pm. The battle simulator I built helped speed things up a lot, though there were a few minor bugs I had to work around. The biggest problem with the battle simulator was user error on my part ("Oh, these guys weren't fighting? shoot... okay.) It was kind of fun. I was never able to raise an army since my wizards spent all their efforts researching spells I couldn't use. My opponents army just won battles without ever using a spell, which made the wizard a bit useless. Hrmm..not quite what I was aiming for. Is that something I need to rethink in design?

I told him that the table top prototype we played through is not even the full game I'm trying to make, and that set off some red flags. It's already quite complicated, and I'm trying to add even more complexity?! After I explained what I'm trying to build, he told me that I'm essentially trying to build three different games. Each game adds an order of magnitude more work. This is what I was afraid of. I have a limited amount of time and people power at my disposal. I *could* build what I'm envisioning, but to do it "right" would take more than my schedule allows. We started talking about alternatives, and that got me depressed. The bad news is that last night I realized I don't have the resources to make the game I've been working on for the last year and a half. I need to drastically pare back my game features if I want to meet my deadline and have a chance at commercial success.

The result:
I went home and made an estimate of all the work that would need to be put into the game I've envisioned. Who would I need to hire to build the game? How much would the yearly salary be, per position? How many years do I need to build the game? When would I bring each person into the project? What are my overhead costs to manage the project and team? What would be the facility and equipment costs for the team? How much would I budget for cost overruns? After I put it all together, I'd need at least 13 people on my team and it would take 3 years to make the game (I could be totally off on that though, but it's a ball park estimate). With all costs factored in, I'd be looking at a price tag of about $1.8 - $2.6 million to make this game. There's no way I have that kind of capital, nor any way I could get that (nobody is going to risk putting that kind of money down on someone who has never shipped anything). If the project was a success, I'd need to sell about 90,000 copies at $30/each to break even. I'd have to compete against the AAA studios who made similar games with more resources and bigger budgets, and I can't do that. Well, shit. Now what?

Time to change direction a bit. It's better to realize now rather than later that the goal is unattainable with the limitations I have. I need a more attainable goal which can still be a commercial success. My thinking right now is that it is better to build something simple and highly polished which can be sold than it is to build something grand, complicated, half finished and can't be sold. Critics and arm chair idealists be damned.

Popcap is a shining example of how you can build around a simple game idea and polish the hell out of it and still be a commercial success. Just look at Peggle. That's the new target to aim for. I don't have to completely discard my whole game, I just have to radically redesign it so that I can build the core game play and spend the rest of my time polishing. The original game idea I had was very detailed on its nuances and really appealed to the engineer mind in me, but... it probably wouldn't appeal to a broader audience. I can't risk alienating 85% of my market by building a niche game -- I can't afford it -- not yet at least.

I'm currently at a loss on what to create. I've got a four day weekend to think on it.

In other news, my uncle died yesterday morning from cancer. He was 55.