Jump to content

  • Log In with Google      Sign In   
  • Create Account





New Studio: First month in review

Posted by slayemin, 02 July 2014 · 701 views

business gamedev production software engineering finances
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:

Line No.Line ItemCostPayerPurposeDate
1Artist Computer Parts (Online Purchase)$740.42EricArtist's work computer6/5/2014
2External Hard Drive Enclosure$15.95EricWork File Backups6/9/2014
3Artist Computer Parts (Fry's Electronics Purchase)$1,131.03EricArtists's work computer6/9/2014
4Prorated Office Rent$550EricWork place facilities6/10/2014
5MSI 1333 LGA Motherboard$183.94EricEric's Computer Upgrade6/10/2014
6Intel i7-4770K CPU$314.99EricEric'sComputer Upgrade6/10/2014
7Parking Fee$27EricTransport Computer Equipment to Office6/11/2014
8Artist's Wages (40 hours)$961.54EricEmployee Paycheck6/16/2014
9Orca Card Load up$50EricTrain Tickets for transport to/from work6/21/2014
10Maya 2015$4,024Eric3D Modelling Software for artist6/21/2014
11Mudbox$542.03Eric3D Modelling Software for artist6/21/2014
12Unreal EngineMonthly Payment$19EricSoftware Subscription Payment6/30/2014
13Artist's Wages (96 hours)$2,307.69EricEmployee Paycheck7/1/2014


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.




RE: documentation, I've often found that there's a way to write less and yet give more information. A dangerous pitfall is to try to type it all down, and totally miss the point.

 

I generally focus on giving everybody the 'general vision' of the project. I'm ok with them coming to me (or to more in-depth doc) for the answers, but they still need to have that context so that this knowledge sticks.

 

What I tend to do when I type documentation is build a document 'screen by screen'. I depict a bunch of quickly-made wireframes for each game screen and describe the purpose of the screen (below which I include the interactions). So the doc reads something like that:

 

Title Screen

(Visual mock-up)

The title screen is meant to be the main point of contact with the FTU.

Interactions: Any input will allow the user to proceed to the Lobby.

 

Lobby

(Visual mock-up)

The Lobby allows the user to select a gameplay mode.

Interactions:

- The player can initiate a single player session [Campaign] (see Campaign setup screen)

- The player can initiate a multi player session [Skirmish] (see Skirmish setup screen)

- The player can change his preferences [Options] (see Options Menu)

etc.

 

This might sound a bit silly to have this skeleton laid out first, but it helps the others understand the 'flow' and logic that connects all of the pieces together. Once you go more in-depth with your actual game mechanics, it helps that these 'core elements' are clear for everyone new coming in.

 

Thanks for the numbers btw! Very intersting!

Hi,

 

How's the project going? I've been anxiously stalking this feed for updates.

October 2014 »

S M T W T F S
   1234
567891011
12131415161718
192021 22 232425
262728293031 

Recent Entries

Recent Comments

PARTNERS