   Biggest SE challenges in Game design
  After reading the wonderful postmortems from game developer book I wondered what are the biggest SE challenges in the games domain? I think from a SE perspective these four areas seem to be the biggest problems (summed down in order of importance)1.Organisational issues; Half of the problems with developing games described in the postmortems book are of an organisational nature e.g. planning, collaborating between disciplines etc. 2. The content generation problem - art used to be cheap and game engines expensive now it’s the other way around. Developing games is a content generation problem. Can we develop tools that allow us to create content cheap? Is it possible to reuse content in different games? 3. Game quality - Game quality is an ephemeral aspect, how can we specify and test game quality? Testing is often only limited to underlying technology libraries. 4. Architectures for games - Software architectures have always drawn a lot of research. What are the best or common “software architecture" styles for different game genres? What are the building blocks of games? How can we design for reuse? Anyone have any ideas about other challenges ?    
  1) "Project Pipeline". Ensuring a flow of projects into the pipeline so you can keep your staff around and keep a constant cash flow stream. May not seem strict SE issues, but believe me, knowing what's in the pipeline ahead of time makes a big difference in your design choices.2) "Process Pipeline". Ensuring the projects have some continuity, whether in leveraging the game assets, in the technology, or in the way the games are assembled; jumping from a kids platformer game to an MMORPG is usually asking for failure, but going from a combat RPG to an action game is not that big of a jump. This is probably the biggest challenge because the market shifts in sudden jumps, forcing studios to reinvent themselves every five years or so.3) "Technology Pipeline". Dealing with evolving technology; the game you design today will probably have to be rewritten in large parts tomorrow because of the advances in graphics hardware, AI & Physics know-how, etc.The main strategic issue for game studios is as follows: do we want to specialize to lower costs and control the development schedule better at the risk of becoming a roadkill when the market shifts, or do we want to be a 'generalist' studio to offset market risks but have a higher cost structure and moving schedules? The strategy you pick will determine how you need to setup your "pipelines" and determines what kind of SE issues you will likely be facing (you have listed them already).   ;  Collaboration is the big one in my experience. It's actually a human issue I think, but it can have huge effects on the software engineering. There is a massive need for the programming team to be able to work independently and all make progress simultaneously, even if a certain area gets held up (and, inevitably, something will get held up). That means that there needs to be a high degree of orthogonality in various aspects of the design; it must be possible for one aspect of the project to continue forward unhindered even if another area is completely broken. The ability to make private builds of the code with missing or incomplete features disabled is vital, for instance.This also has a huge effect on planning and task coordination. Unless everyone knows precisely what has to be done, who is doing it, how far along it is, and what exactly is not yet working right, then a huge amount of time will get wasted: team members will deadlock waiting for each other to finish jobs that neither of them feels they can complete; entire features can simply disappear because nobody knows who was working on it last; even worse, entire features can appear in duplicate because nobody knew that someone else was doing it already, etc. These are all very severe cases, but they can and will happen without a very usable collaboration toolkit. People have to know the status of the rest of their team, and they have to be able to make progress in spite of unforeseen delays.Some of the practical manifestations of this are obvious in hindsight, but may not be clear in the middle of the chaos of Crunch Time: - Physical architecture is important. Huge modules are hard to share between many programmers, no matter how friendly and granular your source code control system's locking mechanisms are. - Clear specifications are vital. It's no good for one programmer to tweak a module to do what it should be, and break 60% of the code base because the rest of the code was built around an unwritten (and false) assumption that the module was supposed to do something different. This is even worse when nobody knows what the module was actually supposed to do. - Orthogonality is your king. Modules must be designed so that they can be built, tweaked, refined, debugged, and enhanced without affecting an undue amount of other code in the project. - Duplication is your worst enemy. Repeating information, knowledge, specifications, logic, and even functionality is evil, evil, evil, evil, evil, bad, bad, bad. - There must be control. It's no good for any junior coder on the team to bung in a bunch of classes that he thinks are needed, and write code around them. Design absolutely must be centralized and controlled by no more than two or three veteran team members who can ensure that the design stays clean. We've historically not done this very well at Egosoft (which is currently being addressed); an uncontrolled design leads to non-orthogonality, lack of specifications, duplicated or nearly duplicated functionality, and all manner of other evils. - Abstraction is your friend. Always being able to code at the highest possible level of abstraction will help ensure orthogonality, minimize duplication, eliminate redundancy, reduce the likelihood of errors introduced by repeated instances of similar logic, and make things much cleaner and simpler to maintain over time.   ;  One major challenge for me, which is probably more derived from my personal design style, is UI/Game integration.My design style is very much about transitions.  In Rumble Box, the goal was to ensure that the transitions between the game and the UI were perfectly seamless, and the SE problems that arised were pretty crazy.  Every transition had different needs, and with over 15 transitions, coming up with a system to handle them all was quite a task in itself.In the end, the UI/Game code got pretty ugly, but I have since come up with systems that I'm using in my new games to integrate the GUI more seamlessly into the gameplay.   ;  I personally think the biggest challenge to most game related SE projects is DOCUMENTATION.  It seems game developers are dismissive and allergic to the 80/20 concept (80 planning/20 percent producing).The reason this is a challenge is because it's hard to imagine that a complex game could be documented in less than 10k pages worth of stuff.  It's also hard to imagine, when you are knee deep in the project, why one should take ANY time off to write stuff down that is, at least in the moment, "obvious".  But documentation, especially during the requirements and analysis phases is, IMO, critical to the smooth success of any project.  A person loses about 80% of their knowledge in one month in they are not actively using it (try to remember what you watched on TV last month) and documentation is the only way that a person can come back (or come into) a project and know what's going on.Furthermore, documentation is the ONLY way to know if your project is headed in the right direction.  Feature Creep will come and it will derail your project if it's not on paper...hence my motto "If it's not on paper, it's not real".A second related challenge is that of using Project management Techniques.  I'm sick of hearing how some game developers wear their 100 hour crunch weeks as a sign of pride when all it is is a failure by the Project Manager to manage the project.  I feel if more people paid attention to PM and Documented every critical step, SE wouldn't be such a beast in Games.   