Philosophy Archives - Games Architecture

In indie game development, roles in a team aren’t as purely diverse as they are in bigger studios. In a crew composed of several people most of them are probably doing more than one thing. When you’re working alone, this is unavoidable. I noticed that the role that is the most often distributed over the team members is designer. The general underestimation of that function may be the reason. The designer’s profile is often reduced to the ‘idea-guy.’ Most of us have many excellent ideas, so what’s the point in having a designer, right? Whether your crew has a designer or not, you probably have some kind of design document or game vision that you and your partners share. Or you may think that everyone has the same image of the project, while the truth may be quite different. On the second hand, you all may be very insightful designers, that have an accurate design document, but it may be just a waste of your time and effort. The 90% of it may be just rubbish. Yes, that’s a bit harsh, but I’m not telling you that IT SURELY IS trash. I’ll just try to explain how can you find out without so much work being wasted.

Continue reading “When to stop preparing design and get to work?”

Many of the code problems come from airiness during writing. We add features to the game not exactly in the best place with the thought that we’ll improve it later (yeah, sure…). And after a while, we don’t know which class does what. Maybe some classes do a bit of everything. We don’t know where to add another feature, so we pick a random class that already has the most of the needed references. Classes become just files with loosely connected methods and fields. Soon enough you’ll find yourself in a place, where you’ll have to change the current functionality. And that’s when everything fucks up. If this scenario sounds somehow familiar, read on. Continue reading “Cohesive abstraction – solving most of your dilemmas in an easy way”