RedBeard's Dev Blog

Archive for September, 2011

Indie Production Process

Posted by redbeard on September 15, 2011

I’ve fielded a few questions about and discussed my production process recently, so I felt compelled to document it more permanently. I’ve developed this process after a number of projects both failed and completed, independent and professional.


  • Paper Notebook: Before I start typing anything into a word processor, spreadsheet, or compiler IDE, I capture some concepts on paper, both high-level and low-level, related to design, art, technology, whatever. It’s easy to sketch out all sorts of random stuff on paper like UI, art concepts, gameplay or code logic flow charts, and of course just writing. I’m also fairly forgetful but can carry a paper pad around with me so I can capture whatever fleeting genius might strike me.
  • Design Doc: Once I have a good idea of the high-level concept and some details, I try to capture them in a more sensible and editable format; Word, OneNote, Google Docs are all good choices. The purpose of the design doc is to describe in detail all the ideal features and systems as they would be in a final product, but not necessarily in a technical manner. I don’t describe APIs or algorithms in this document unless they’re essential to the concept and are novel or original.The design doc is a living document and may change drastically over the course of development, so don’t get too mired in details when you’re still prototyping. Here’s my design doc for Cube Fortress.

Product Planning and Development

  • Production Spreadsheet: I use a spreadsheet to track all the production details of my project. This includes development tasks, art and other assets, bug tracking, publication submission details, free download codes, review links, sales numbers, and whatever else is related to the project. The largest chunk of manual work needed here is managing the task list, which is divided into milestones of “coherent functionality” such as a visual or technical prototype, basic gameplay, network multiplayer, final polish, title update, etc. Here’s my production spreadsheet for Cube Fortress.
  • Milestones: The idea of a milestone is to have something presentable and coherent at the end, without tons of unimplemented stub functionality or useless disconnected features. Milestones are composed of tasks, where each task is ideally 1-4 hours long so it can be completed in a single development session; examples of good tasks: cube rendering, player respawn, weapon firing, raycast collision detection, scoreboard; some tasks which would be too broad or nebulous: netcode, guns, HUD UI, Clone Angry Birds. I prefer to focus on and complete a single task at a time, since this gives a good tangible result and also allows for better bug tracking if you keep your code & assets in a source-control system like SVN.
  • Task Estimation: For scheduling production, it’s essential to capture good tasks, break them into reasonable sizes, and make good estimates of their time complexity. Time estimation is a skill which comes poorly to most programmers, because we tend to be optimistic about our ability to write perfect code quickly. In reality, new requirements will typically be discovered halfway through implementation and the result will have a few bugs which take significant time to track down and squash. Really, the best way to be good at estimating task times is to do it a bunch and learn through experience.

Posted in CubeFortress, XNA | Leave a Comment »

Multiplayer Milestone Complete

Posted by redbeard on September 14, 2011

I’ve completed my self-imposed “multiplayer milestone”, which means two things: the game has reached a state of coherent playability, and I can now start working on making the game deeper and broader. According to my task & time tracking spreadsheet, I’ve spent over 150 hours on this milestone (and 350 total on the project). My previous milestones were “experimental cube-world rendering” and “basic networked gameplay”. Here are some of the features and tasks which I completed for this one:

  • Winnable game mode “team treasure grab”
  • Explosive grenades and rocket launcher
  • Limited ammo magazines & weapon reloading
  • Teams: spawning, scoreboard, player balance,
  • Robust object state replication and RPC over reliable UDP
  • Dedicated host/client separation, which makes the code more sane and opens the option of dedicated servers
  • Client-side movement prediction (essential to avoid laggy player movement)
  • Network bandwidth profiling (invaluable for tracking down overactive network objects)
  • Player feedback sounds & visual effects for various actions, and incoming damage indicators
  • Various UI functionality like compass, health, and weapon info
  • BRDF rendering experimentation
The most time-consuming task was probably the client-side player movement prediction. I referenced a few different papers/articles which helped get the concept clear in my head:
My next milestone involves several main categories of work:
  • AI helpers, such as builder & tunneler bots, sentry turrets, and patrol bots
  • Weapon variety: machine gun, sniper rifle, pistol, etc
  • Support items: medic kit, ammo box, repair wrench, etc
  • Player class build or economic systems for selecting from the various weapons & support items
  • Enhanced rendering effects like ambient illumination, motion-detector vision, and other
  • Performance improvements, specifically targeted at Xbox 360 (I’d like to run at 60 fps @ 720p, at least on clients if not the host)
  • Polish & style improvements, it would be nice to start using more aesthetically appealing art & sound assets
If you’d like to take the milestone build for a spin, download here. You’ll also need to install the XNA 4 runtime if you haven’t already. Consider it alpha-quality code, it’s probably full of bugs… but if it doesn’t crash, hopefully you have some fun with it!

Posted in CubeFortress, XNA | Leave a Comment »