This week is a bit unusual. I'm taking a planned vacation on Friday and will be gone for two weeks. All I see is costly expenses and that's causing me to grit my teeth a bit, but I'm trying not to be too concerned about it. Life is too short to not take a moment to relax and enjoy it, right?

So, I finally tabulated all of my business expenses for the month of June 2014. I thought I'd share them so that anyone who wants to get an idea on costs can use my experiences as a measuring stick:

[table][th]Line No.[/th][th]Line Item[/th][th]Cost[/th][th]Payer[/th][th]Purpose[/th][th]Date[/th][tr][td]1[/td][td]Artist Computer Parts (Online Purchase)[/td][td]$740.42[/td][td]Eric[/td][td]Artist's work computer[/td][td]6/5/2014[/td][/tr][tr][td]2[/td][td]External Hard Drive Enclosure[/td][td]$15.95[/td][td]Eric[/td][td]Work File Backups[/td][td]6/9/2014[/td][/tr][tr][td]3[/td][td]Artist Computer Parts (Fry's Electronics Purchase)[/td][td]$1,131.03[/td][td]Eric[/td][td]Artists's work computer[/td][td]6/9/2014[/td][/tr][tr][td]4[/td][td]Prorated Office Rent[/td][td]$550[/td][td]Eric[/td][td]Work place facilities[/td][td]6/10/2014[/td][/tr][tr][td]5[/td][td]MSI 1333 LGA Motherboard[/td][td]$183.94[/td][td]Eric[/td][td]Eric's Computer Upgrade[/td][td]6/10/2014[/td][/tr][tr][td]6[/td][td]Intel i7-4770K CPU[/td][td]$314.99[/td][td]Eric[/td][td]Eric'sComputer Upgrade[/td][td]6/10/2014[/td][/tr][tr][td]7[/td][td]Parking Fee[/td][td]$27[/td][td]Eric[/td][td]Transport Computer Equipment to Office[/td][td]6/11/2014[/td][/tr][tr][td]8[/td][td]Artist's Wages (40 hours)[/td][td]$961.54[/td][td]Eric[/td][td]Employee Paycheck[/td][td]6/16/2014[/td][/tr][tr][td]9[/td][td]Orca Card Load up[/td][td]$50[/td][td]Eric[/td][td]Train Tickets for transport to/from work[/td][td]6/21/2014[/td][/tr][tr][td]10[/td][td]Maya 2015[/td][td]$4,024[/td][td]Eric[/td][td]3D Modelling Software for artist[/td][td]6/21/2014[/td][/tr][tr][td]11[/td][td]Mudbox[/td][td]$542.03[/td][td]Eric[/td][td]3D Modelling Software for artist[/td][td]6/21/2014[/td][/tr][tr][td]12[/td][td]Unreal EngineMonthly Payment[/td][td]$19[/td][td]Eric[/td][td]Software Subscription Payment[/td][td]6/30/2014[/td][/tr][tr][td]13[/td][td]Artist's Wages (96 hours)[/td][td]$2,307.69[/td][td]Eric[/td][td]Employee Paycheck[/td][td]7/1/2014[/td][/tr][/table]

Final Total: $10,868

Keep in mind that a lot of these expenses were one time expenses which are involved in the setup of a new workspace, so I won't be spending $11k on a monthly basis. My projections for the next month are as follows:

$750 - Office Rent
$4,600 - Wages
$19 - Unreal Engine Subscription

Which puts me at around $5400 / month.

Taking a two week vacation doesn't mean my expenses take a vacation too. I'll be paying $2700 in proportionate expenses while I'm gone and I won't be there to work. Add on top of that the costs of the vacation (air fare, food, transport, etc) and it becomes another expensive month. Those are the direct costs, but the opportunity cost of me not working will probably increase that spread even further. So, I have to mentally check myself to make sure I'm relaxing and not feeling guilty ("Hey! Are you relaxing?! feeling relaxed yet? how 'bout now?"). Luckily for myself, I have a pretty easy-going temperament so it shouldn't be too much of a challenge.

Enough talk about money for now. Let's talk about the game project.

I realized I will need an object manager for my prototype. So, I spent the beginning half of the day moving all of my game object code into an octree (related article) I had coded up a few months back. Then, I found bugs. Mysterious bugs! The problem with heavy code reorganization is that when you get bugs, you don't know if its a bug caused by the moving around of code, if its a bug in the underlying system (octree), or if its a legitimate bug in the prototype code which I overlooked or ignored. The problem was that on some seemingly random occasion, a single creature would disappear completely. The first challenge is to replicate the bug consistently when it occurs at a seemingly random time. After the bug can be replicated, the next challenge is to insert a breakpoint into the code and dig into the memory to see if there is any funky stuff going on and try to figure out what's causing the funkiness. Well, after about two hours, I found the cause of my bug. It was being caused by a special feature my octree implementation which didn't show up during my very light testing. I had this "brilliant" idea that memory allocation costs a bit of time and I should try to shave some of that time off. So, if I can borrow an idea from memory pools and "hot memory", I can delay deleting an unused octree node. If that node becomes used again, I didn't have to allocate new memory again (and time is saved!) -- but, what about the extra CPU costs in maintaining this additional overhead code? Did I actually save CPU cycles, stay the same, or did my optimization backfire? Who knows, because I didn't run any rigorous testing and profiling to find out! Lesson: Learned.
Anyways, the bug sat in my node decay code. After the node became empty, a count down timer would be initialized. If an object entered the node while the timer was active, the object should reset the timer, double its duration, and pause it. One of those things was not happening correctly, so an object would move into the node space and then the node would continue counting down, as if it were empty, and then delete itself, even if it contained objects. Hence, on rare occasions, objects would just disappear without explanation. Fixing it "correctly" wasn't that important since this is just prototype code now, so I just put in a simple "If node is not empty, don't delete it!" instruction.

On Tuesday, my artist was still confused on the ambiguities in my game design idea. I'm learning an interesting lesson here as well. People aren't mind readers. They can't just tap into my head and figure out what I'm thinking and then build it. I have to communicate this stuff as clearly as possible and with as much vivid detail as possible. At the end of this communication process, I should have a detailed document which someone else can take and build a game out of it, exactly as I've envisioned. If I get hit by a bus, it should not be a problem for the project progress -- the final product lives in the design documentation, not in my head. This starts to sound very much like a "waterfall SDLC" instead of agile documentation. I was told in university that waterfall sucks, and we were told to explain why. And then the professor caveats it all by saying, "Waterfall has been successful on many projects, just be aware of its weaknesses". Well, okay, if we put documentation on a gradient with one extreme being "full design up front" and the other being an agile "design as you go", then we're moving more towards the "full design up front". But hey, the sweet spot for agile documentation is "Just Barely Good Enough" (JBGE), which in this case, may actually mean that the JBGE state is actually a lot more documentation and design than I thought. So, the interesting epiphany I'm having is that the JBGE amount of documentation for a single, solo developer (me) was 25 pages of somewhat detailed hand waving. That would work for a solo developer since the purpose of the documentation would be to nail down the ideas and the small missing gaps would be figured out during the course of development. For a project with two or more minds (and no mind readers on the team), the JBGE point is much, much more detailed design specs. There should be zero confusion about what's being built.

It's time to start story boarding with a lot more detail. My artist comes from an animation and film background, so his idea of story boarding is a bit different from mine. He thinks that we need a separate frame on the storyboard for each and every action, to the point of detailing mouse roll overs for buttons. I don't have much experience story boarding to counter this absurdity, and more detail is always better, but I'm still a devout follower of JBGE. The approach I'm taking is to do quick, high level story board sketches of the game play, starting from "New Game" all the way to the end of "Teach the player how to play your game". Then I show it to my partner to get a sanity check. Am I going way to crazy with this aspect of the game design? Is this the direction we should go? Once I have a pretty good idea on each step in the game play and how it transitions to the next step and makes sense, I can go back through and spend more time and detail on each storyboard frame, indicating things like "These are were the buttons go, this is the GUI which shows up when you click on it. This is what happens when you do action X". Then, the work is not wasted time because its on track and not insanely over-scoped.

So my goal for the remaining days of this week are to get really detailed design documentation on all of my game systems so that there is no confusion on what's being built and how it works together. This should give my absence a little less impact on the project progress. When I get back, it's time to hit the prototype implementation hard. That may take up to a month of work. Then comes some quick play testing and refinements, and then we tentatively move into production. We start building the game in Unreal Engine 4, of which I'm still uncomfortable with due to my inexperience with it. That'll be okay though, the challenge there will be focused on "how do I implement this prototyped game code in UE4?" instead of "What am I trying to build? How do I build it in UE4?" which is a recipe for confusion and fiddling around. We'll see how things go!

As far as journal entries go, the next update will most likely be at the end of July 2014.