The announcement is going to be pretty short. Here is the lowdown: I'm going to GDC. That's right--in 2 days I'll be heading on over to SF and taking in all the things the annual event has to offer!
That's all, as far as announcements go. Now for the real topic of conversation--
Perspective
In a small studio, most people wear multiple hats during the development process. For teams of less than 10 people, game design is often a decision made by multiple members, not all of whom hold the title "game designer." Similarly, a small studio may not hire a specific person to deal with all PR material--it may be a joint venture by some programmers and artists. This is perfectly acceptable given a lack of resources and time. But visual and sound artists as well as programmers have decisions to make too. So why aren't things like game architecture or implementation decisions discussed with people not in the discipline? I believe we can attribute this to a lack of perspective.
In a game jam I recently participated in, I had my first real experience with a game engine (Unity, to be specific). I had written 2 games before in game jams, but they were HTML5 games written with JS libraries. Those aren't exactly engines, if you will. That having been my first real experience, I came across decisions that I thought wouldn't even be relevant in developing the game. For example, a score multiplier was received when the player takes the thinner path. How would I know? My initial idea involved checking the collision between the ball and the current platform it is touching to examine the width of the platform. This would occur for every platform, for the rest of the game time. That's a lot of collision checking to do, and probably not a smart idea. So I asked my brother how he might do this, and of course, the answer came to him naturally--create a block at the start and the end of every thin path with the same width as the path, and let them be triggers. If the start block detects a collision, then a score multiplier is given based on the width of that block. When the end block is triggered, the score multiplier is reduced to 1. It was a no mess-solution. Clean and simple.
Why hadn't I thought of that? Because I lacked perspective, and perspective enables a way of thinking. I'm a computer science major, so I'm not new to the rodeo, but where games are concerned, I'm the artist--I never learned the methodologies and thought processes that are involved in designing a game from the code side. We both discuss game design, sure. However, when my brother runs into a coding issue that isn't an error or a bug, but rather a design issue of the architecture--now I can help too. Maybe not immensely or immediately, but experience enables. No part of the pipeline ought to be thought about in isolation.
So what am I trying to say? Should artists learn to code, and progammers learn to create works of art? No, not quite. But I do believe that artists ought to take the effort to see the world of game development through the eyes of the programmer, and vice versa. The programmers can take steps to learn the troubles and decisions of the artists, without having to learn so much about the technical detail. Similarly, artists can learn some of the peculiarities of the engine and tools without learning how to proram. Having people more informed about the decisions other disciplines face in the pipeline leads to more collaborative thought and a distributed burden. Better decisions are made when the programmer isn't the only one thinking about architecture, just as game design is improved when there isn't only one person designing. Game design is a collaborative process; other disciplines ought to be as well.
Now, it is true that I might not have a leg to stand on because, being a programmer, it was very easy for me to understand the other perspective. However, how easy it was doesn't change the value of the lesson learned. I understand how intimidating it can be to program without any knowledge beforehand, especially when trying to make a game. I had to deal with the opposite--learning about the process of 2D and 3D art, when all I knew was programming. What's important is to learn how to think, in ways which your worflow does not involve.
So go forth and learn. Learn about what you don't know. You don't need to learn so much that you could get a job. Just learn enough to gain perspective, so you can be helpful even when you aren't the expert.