If I was to build an open source game development system, what would I focus on? I'm not a graphics whiz, but I know about simulation, OO, distributed systems, MMOs, and picky developers. Let's see here...
- Pick a primary development language. But realize that not all developers will love it. Is there a way to support multiple languages?
- Rapid iteration is key, so game logic must be able to be written in a scripting language. But it must also be possible to hard code parts of it for performance.
- Tools are key. In a good game development project the majority of the effort of the team should feed through the content tools, not the compiler. Wouldn't it be ideal if you could build a great game without any programmers?
- It must be debuggable. In a distributed system, this requires some thought.
- The world size must be able to scale. A lot of projects are bending their game design to avoid this problem, and that is definitely the least expensive approach. But if your infrastructure supports large scale on day one, what could you do?
- You want reuse of game logic, realizing different developers/designers have different skills. This means you want a hierachy of game elements that are developed by appropriate experts, and snapped together by others. This game object and level design effort should be efficient and fun.
- The team size must be able to scale; both up and down. This is a matter of content management. You don't want central locked files everyone contends for, and you don't want burdensome processes if you are a small team.
- It should be runtime efficient in space and time. This enables use on games that have huge numbers of game object instances.
- It is easy to ask for dynamic object definition, but that can work against performance. How often is that used? And what other ways are there realize that effect?
- The framework should be intuitive to as many people as possible. This means being very careful about terminology.
- Now we enter an area I don't know much about. How do you structure the infrastructure development project itself? You want buy in from lots of people, but you also need a single vision so the result is consistent. You need a means to adjust the vision without blowing up the whole effort, and without encouraging people to fork the effort.
- What will be the relationship to other open source projects? We can choose to use various utility libraries. But what about using other game projects for graphics? Issues will arise at the boundaries.
- The system should be useful and get some adoption even without being finished. Because it will never be finished.
- It should be modular enough. That allows a developer to use the parts they want, and replace the parts they must. It allows broken parts to be replaced.
- We will need a demo game. How ambitious should it be?
- We need a name. And a vision statement.
I think the first thing to do is a survey the current state of open source game systems.