NetDroids is a game which one of the key points is that ability to program some droids to perform actions cooperatively.

That would implicitly limit the audience to persons who would like this kind of thing. It's got nothing very interesting and relaxing.

Anyway the key word there is programming. A language is needed and one of the first things would be to evaluate which one. A new language could be introduced only if it really made a big difference. OTOH it may be just useful to take a conventional language (i.e. something from the already pretty extensive families of languages) and adapt it to the needs, maybe with more of a visual model of interaction than just text based.

By that I mean that the complete IDE and the way the programmer interacts with the language must be a key part of the language itself. Think Self or Squeak for example and live interaction with running objects. Seems very appropriate here.

So if a dev plan was to be made, maybe one of the first items would be to define the language and check how much it is adapted to the task. A minimal graphical representation such as a simplified 2d top view could be used to make the objective more clear and more attractive but it should only be seen as auxiliary, not the main goal itself.

OTOH it is clear that part of the motivation here is a lot broader than just this language theory part. As explained in the very first note, if one think of the project as a whole then other parts are as important as this one. For example, peer-to-peer network interactions and a good 3d engine can be seen as as much crucial as a good game engine.

My point is that each sub part make for a fun project just by itself.

Ideally one could view this as a bunch of not-so-mini projects that can be independent but should be ultimately combined together to form a whole:

• Language
• Game engine
• Network stack
• UI toolkit
• 3D Engine
• Persistence
• Online world
• Characters
• Gameplay
• Etc.

The list can go on and on.

Each project needs some of the others to be useful.

Each project can be a useful learning tool by itself, that is as a home project it is interesting to work on, say an efficient peer-to-peer network stack that would enable characters to move in an online world. A persistence framework is always something challenging to write. Etc.

Yet on the other hand, many of these projects can be though as existing open source libraries. The obvious example is Crystal Space for the 3D Engine. There are two obvious ways to look at this:

• If what I wanted was to produce something fast, i.e. get a real product out of door after tomorrow, the best choice would be to invest time in looking at an existing library. There's a learning curve associated, but the design time and debug time are out of the equation.
• If what I want is to learn, it is more useful to do it myself from scratch. That's when I'll hit the problem hard and get confronted with the real design and implementation issues.

My goal here is to have fun while learning and thus the second point above is the one that really matters to me.

Now of course if this was a serious project in a business context, the picture would be very different. But then that's why people get hired on their actual experience or potential.

So to come back to the subject at hand, what makes sense to start with? In my mind, I see:

• A minimal graphic framework that can represent a world and entities moving in it. Implementation wise, could be something with a 2d top view, an entity can be as simple as a dot, a world can be as simple as boundaries delimited by segments. Implementation can be done in a variety of DirectX, OpenGL or simply GDI+, etc.
• A minimal engine that can represent these entities and this world.
• Collisions, movement, interactive setup.
• Some kind of minimal UI is needed to setup that and see it run.
• A basic language can then be designed to make these entities work together.
• Basic programming tools can be introduced (editing, debugging, etc.)
• Persistence and network need to be introduced at that point in their most basic form.
• Once something very basic is setup for each, the complexity can be enhanced to level up the whole foundation at the same time.

So the plan is obviously to work on an horizontal level, i.e. develop several modules that are independent yet rely on each other to achieve something interesting and level them up more or less at the same time. A lot of refactoring and iterative development would be involved.

The alternative development model, a vertical one, would be to fully complete one module before working on the next one. This one is the less rewarding as it means spending time working on the fine details of something that will need to cooperate with other modules which are not designed yet... The probability to get it right from the very beginning is very low and there's no intermediary result to keep the motivation alive.

Although the iterative horizontal model is clearly the way to go, it should not start without a prospective idea of the final goal and how to get there. That is before any implementation can take place, the following is needed:

• A design document clearly explaining the end goal. It doesn't have to be say much on the implementation, if any.
• A more precise design document on the first milestone with the desired implementation goal. The actual implementation will vary at some point to match reality, yet it's good to be able to compare the end implementation with the predicted one.