Our goals are of two kinds: the first group describes the target audience and environment.
- Discrete Event Simulations.
- Model fish in an aquarium, as they swim around and eat things. Or multiprocessor computer systems, as they execute parallel programs in a highly abstracted form. Or factory production environments. Continuous physical models are for someone else.
- We can't assume the users have big machines, and we can't assume the users have patience for long build times. Of course, small is a relative term...
- For developers, research, teaching, experimentation
- These groups need an easy interface to write their own applications. They also know how to write software, if not necessarily of production quality.
- Open Source.
- Well, we are on SourceForge. But seriously, by making this open source with the requisite licenses, we are not just giving it to the public, we are also giving it to ourselves, should we need this sort of thing in future commercial endeavours.
- Be realistic.
- Set achievable objectives, in order to actually reach some of them.
Following from these, we can derive some more immediate, more tactical objectives.
- Start with well established tools.
- Use C++, STL. Maybe Python later.
- Separate functionality.
- Keep things modular, e.g. keep graphics separate from simulation timing.
- Start small.
- We should fit right in with release early, release often. Also, the size of the team is, at this time, definitely not too large. We have to be able to build a complete simulation in a text based (console) environment, with useful output.
- Stay simple.
- Don't use esoteric constructs or languages when straightforward solutions will work just as well. Or there will be no audience.
- Stay scalable
- Saying to start small and stay simple does not mean limit the system to toy examples by designing in limitations.
- This is not a religious undertaking. Should circumstances change, these goals can be changed - after some thoughtful consideration.