Monday, May 12, 2008

An ideal software design (1)

Normally, we try to decide software design before a team begin writing program. That may be simple block wiring diagram or UML. Many programmers gather to your team for rapid development. The thing that you must do is software design. For that, you divide software in modules. That is a good design for program.

But your mission is that each programmer becomes able to bear part of programming. Can your design realize it?

A logical design for program and a logical design for programers have difference. If you design software and write its program yourself, you perhaps don't notice this truth.

An ideal design that have many modules for program often blocks specialized programers. That makes it impossible to start productive development.

There are many specialized factors of program --- makefile, memory management, resource management, peripheral, hardware control, content-pipeline, parallel processing, shader, effects, particle, animations, graphics, audio, cinema sound, AI, physics, geometry, procedural technology, script, network, debug system,third-party middleware and so on.

Can you design software by combining these specialized factors systematically? Perhaps, you can do it. But, an ideal software design that you've designed for program is bad news for programers who gather to a project. A game system requests a composite of their knowledges and their code from thebeginning. So a project becomes tangled.

No comments: