Rotating development
On July 05, 2007 in
“As love and effort increase, the probability of self destruction approaches 1.” - Kyle’s Theorem of Destruction #2aOr, the more you care about what you’re working on, the less likely you’ll actually turn it into something totally awesome.
The more you work on something, the more personally invested you become. The more personally invested you are, the less likely you are to look at it objectively and trash or rethink problem areas. The product suffers. This applies to any type of development, but it’s especially true for game development.
How to fix it? 2D Boy suggests occasional distraction with side projects. I have some more thoughts for large teams…
First: organize your staff into small, independent, Scrum-ish) groups. Each group must be self-sufficient, with an artist, programmer, etc. When assigned a task, it must be able to create a playable product without outside interaction with other departments.
Next: identify the areas of development for the project. For example, in Battlefield 2142, these might be: infantry, vehicles, conquest gameplay, titan gameplay, statistics and awards, and user interface.
Finally: each group works on one specific area for one iteration of your Scrum development cycle. In the next iteration, rotate the group to a new area of development.
This results in:- Fresh eyes looking over the important parts of your game each iteration of the development cycle.
- Less competition between departments.
- The game won’t suffer because one group doesn’t want to make changes to the precious content they’ve been slaving over for the past 9 months.
Relative, z-index, and IE
On May 16, 2007 in
I ran into a really annoying IE6 bug today: the z-index of a positioned element is dependent upon the z-index of parent elements.
Start with the front end
On May 10, 2007 in
As a programmer, I have the tendency to break things down from an engineering perspective. It’s a compulsion. Hearing a concept compels me to turn it into a specification in my head.
Specifications can be fundamentally flawed. Theoretical design can be useful, but the sooner you can start building an application the sooner you will find how it actually works in the wild. By creating the specification first, you may find yourself feeling obligated to adjust your frontend to work with the backend you’ve already designed. This is a bad idea. Things never work exactly as you expect. You want to quickly find the errors in your design.
An example from a project of my own: there was an area in our application where the user was creating start-to-finish timed sessions, with timed “breaks” during the session that the users could record. From the eye-in-the-sky perspective, it made sense to store these breaks as a start time and end time.
But by starting with the interface, I realized that entering breaks was a cumbersome process. It caused us to reevaluate it and realize that a simple number of minutes on break during the session was all that was really necessary, not groups of start and stop times. By catching it early on, we avoided the backend work that would have been scrapped in the end.
Interaction with the product is the most important to a user. If you can keep this in mind during your development your product will benefit tremendously from it. The user doesn’t care how your backend is designed, as long as it works for them. Your product should be designed around the frontend. It’s the responsibility of the development team to make sure the backend performs as needed to support the interface.