?Tuesday:
It's Tuesday night, I'm sipping a beer and barely feeling it. Let's do this!

My artist (Dan) and I started building the initial prototype for our game this week. The first thing we did is put together a user interface storyboard which explains how the magic casting system works in real time. I decided to build the prototype in C#/XNA because it would give me the most rapid development possible because it's a dev platform I've worked with extensively. And, rather than starting the prototype completely from scratch, why not use the existing game engine I had worked on for 10 months? It's got all of the libraries and utilities I could hope for to speed up my development immensely. Not only that, it's already got a bit of a skeleton class architecture. So, I just created a new DrawableGameComponent and slapped it on top of my existing game engine and started building the GUI for spell casting. By the end of Monday evening, I had almost completed the initial GUI. There were just a few small, teensy bugs that needed to be ironed out.

In a slightly interesting change of thought, I shifted the way I thought about how I was going to build a prototype. The whole time, I believed that I was pretty much writing throwaway code which would never see the light of day in a production release, so I could be as sloppy as I wanted and could hack stuff together as fast as I could type. There was only one thing that was important, more important than anything else, and that is getting a prototype working. Doesn't matter how rough it looks. Just build it. If something slows you down because you're sweating over non-essential details, skip it! If its essential, find an uglier alternative. For example, I had colored mana balls on a white background which needed to fill up over time. Rather than monkeying around with source rects and destination rect coordinates, I just created a white texture and overlayed it on top of the mana ball and gradually moved it upwards. Same effect, less work!

On Tuesday I finished up the spell casting GUI and showed it to Dan. I think after he saw the mana system it in action, it really made a lot more sense to him. And it was a bit exciting to get something rudimentary working, something to show for all our work and design efforts. The small accomplishment added a bit of fuel and extra motivation to work harder, to knock out another accomplishment as fast as possible. I decided to start building on the next logical step, the spell casting system which uses the mana system I built. But, before we can create spells, we need a spell book to store them in. And to get spells into a spell book, we need a spell library in the wizard tower. And we don't have a wizard tower. So, I started trying to design the wizard tower, trying to imagine all of the different rooms in the tower and their game functionality. It seemed like it out take a lot of work, so I asked Dan what he thought. We talked about it for a bit, and then he said that it wasn't really the core essense of the game play. While its valuable work, it's not a priority. Instead, I should work on getting unit formations onto the battlefield and getting them to fight. Critical questions to be discovered through prototyping:
1. How fast do the units move on the battlefield?
2. How fast can the wizard become overpowered?
3. How fast do units on the battlefield die when engaged?
4. How does the spell system ramp up while attrition ramps down unit formations?
5. How does adding a few spells to the mix change all of this?

Since I had been using my old home brew engine and had some idea on the class architecture, I was able to get really rough units rendered in formation on a white background by the end of the day on Tuesday. It's all just being done with sprites on a 2D surface, so no need to worry about the third dimension... though, I could swap to 3D in less than an hour. It's all super fast, go, go, go. Build it now, don't optimize, let the CPU sweat. Does the idea and game mechanic work? That's what's important right now.

As I was leaving the office, I met a guy who was leaving our office as well. He heard we were building a game and asked about it. I introduced it as "It's Total War meets Magic: the Gathering", and he was an avid TW player. He mentioned that he does 3D modelling as well and was very interested in what we're building. That's really awesome. It's like, every other day in Seattle, I'm bumping into new people who are in the game development industry. I got his email address and said that I might be able to throw some work his way.

Wednesday:
I was on a roll today! The goal was to get unit formations working correctly. I like the way the Total War series does their unit formations, so I copied some design ideas from them. I have a "Creature" class which "Peasant", "Wizard", "Archer", and "Swordsman" inherit from. I also have a "Unit" class (which would probably be better named as "Formation") which contains a list of all of the various creature types which compose the formation. So, I've got a "Hero" unit which contains the player wizard, a "Mob" which contains 100 peasants, 25 archers, and 40 swordsmen. You can draw selection boxes around any unit to select it and then right click and drag out a "ghost" unit formation. While you're dragging, you can select the width of the formation and the ghosts automatically rearrange themselves to fill the ranks. Once you let go of the right mouse button, the selected formation units all move to occupy the ghost unit positions and orientations. It's kind of cool to watch. I got it all up and running in a day too! My goal is to have a very rough prototype ready by Friday. Tomorrow, I'm hoping to put the various formations into factions, send the units to attack an enemy formation, and get a fireball spell working which costs mana to cast. I'm hoping I don't get stuck on any hang ups or bugs tomorrow.

Dan made a lot of good progress on creating the first human model. He's going through the production pipeline process to see what exactly is involved with getting a finished and animated model into UE4, from concept to finished product. He was also a bit surprised to see how fast my prototype is coming along. I think we're right on track.

Friday:
It's the end of Week 3. It barely feels like three weeks have already passed. However, that's because I've been incredibly busy and quite productive. It's a good time to pause and reflect. What's been working great for me is having a remote office to work from and having someone to work together with. I have had no problems staying focused, on task, and motivated. At 4:45am this morning, I actually woke up to look at the clock to see if it was time to go to work yet. I was eager to get up and get back to coding, but my practical side tells me that sufficient sleep is also incredibly important to being optimally productive. My daily routine has become a routine of mostly getting up, eating breakfast, walking 15 minutes to the train station, working all day, late lunch at 1:30pm, work until 6pm or later, train home, eat a sandwich for dinner, relax for 2-3 hours, go to sleep, repeat. I was shooting for 40 hours/week of work, but I think in truth I'm putting in about 60 hours/week. I just get immersed in my work and lose track of time, only to see in dismay that it's a few hours away from the end of the day. I am usually the first to arrive and last to leave. The lingering worry I have in my mind is "burnout".

In terms of the project, I've made really solid progress on a playable prototype. I learned a few important lessons while creating the prototype.
1. Just because you're prototyping doesn't mean you can get super sloppy with your code. It doesn't have to be perfect, but you should still pay close attention to class architecture. If you're hacking stuff together (as I was) and you complete the task, and then your next task is to expand the system you built, you'll find you save more time by doing it right the first time than having to go back and reorganize code. Don't sweat the potential need to refactor your hacked code though, write it so it works first, and if you need to do it in the future, go back and refactor it.
2. Testing is kinda important. I wrote some mathematical helper functions using trig and linear algebra to be used in my prototype. I just slapped the functions together quickly, did some rudimentary tests which appeared to perform as expected, only to find that when I ran the prototype, I'd get odd unexpected behavior. I could spend a lot of time trying to debug the prototype logic and write some hackish "fixer" code, but the underlying cause is the helper code. I need to have complete confidence that my underlying functions yield the correct results, so I've started writing more rigorous test cases. An example from earlier today would illustrate this better...
I have a creature with a facing direction represented by a radian angle. He needs to face an arbitrary direction chosen at random. To get to that arbitrary facing direction, he needs to turn either left or right by an unknown radian amount. I have to write a function which receives the facing direction and the desired direction, and returns the shorter turn angle. Keep in mind that if you're facing 45 degrees and need to face 315 degrees, its shorter to pass through 0 degrees.
So, the function signature would look like this:public static float TurnDirection(float currentDirection, float desiredDirection);
I had a small bug in the implementation (used pi/4 instead of pi/2) which I didn't notice.
To correctly test this, you'd want to write a small function to test every angle against every other angle and see when and if the results get funky. Initially, I didn't do this. Instead, I chose to just test 45 degrees, 90 degrees, 135, etc. Which didn't show the bug. This is a better test:for(int baseAngle = 0; baseAngle<360; baseAngle++){ for(int testAngle = 0; testAngle<360; testAngle++) { Console.WriteLine(baseAngle + ":" + testAngle + " -> " TurnDirection(DegToRad(baseAngle), DegToRad(testAngle); }}
The underlying bug became obvious quickly and fixing it fixed everything else.
3. Carefully monitor what you're working on and spending lots of time on. Are you trying to tweak little things that really don't matter in a prototype? Or are you building core functionality? Periodically, stop and pause and ask yourself this question and try to be honest with yourself. Skip the teeny tweaking which doesn't add anything (resist the urge for perfection!).

Looking ahead to next week, I've got a four day work week. Next Friday is going to be an american holiday, in which I will be taking a planned vacation for 2 weeks (Iceland, Finland, Estonia). I had been planning to do this several months back, so the vacation has precedence over work. It's going to put a big slowdown on the project progress on my end. Dan will continue working alone in the office for the two weeks I'm gone. I'm going to have to make sure that there aren't any missing details in the design document and he's got sufficient work to keep him busy during my absence. I can't verify that he's showing up to work, but I believe in him and have faith that he'll be honest and hard working. I'm choosing not to worry about it.

Here is a screenshot of the prototype I've built:


It's rough, but you can select unit formations, give them movement orders while setting the formation orientation and length, and send units to fight the opposing faction units. You can also open up mana links and then activate mana balls for spell casting, though there are no spells yet. There's still lots to do, so this is rough and incomplete.