next »

[Update]

So, there are some general concepts we could use:

- make the engine a stand-alone exe, and allow everything to be modified with XML and other data files
- make the engine a class library, which programmers can build their game on
- make a the engine and the game with some data files and some hardcoded stuff, and only allow changes by editing of the source

what do you think? i honestly have no idea

Update

The people have spoken! We will create a standalone exe for the engine, and all game data will be held in external files. Classes in the exe will be made public, so they can be inherited from when desired, and of course the open source allows programmers to change stuff if they can't do what they want with external data files (but we will need to prevent that from happening as much as possible  )

I think we'll need two things.  XML is only half the story - only so much can be done there.  We'll also need some form of scripting so that designers can do things not necessarily in the engine to begin with.  An example is the custom spells of warcraft III.  There's no built-in abilities that can be modified to do some of the things players want, so instead they run custom scripts to fill in these effects.  We'll need to approach from both ends to give users the power to do everything they want, so hopefully changing the engine won't be necessary.

As an upside, we can then upgrade the engine at any time, and anyone using it can simply accept our upgrade without any modifications.

well xml may also contain scripts, mixed with preset behaviours

The critical thing is that no one should need to modify the engine to do what they want to do.  That way, if we make an update to the engine at a later date (backwards compatability must be assumed), everyone can accept this update without modification.

I'm not sure what the limits are on XML, but I do agree that all of any game's content be defined in external files.

xml contains nodes, which have properties and a content. this content can be other nodes, but also regular text, which could be used for scripts and other things. in short, it has a lot of possibilities

Like Darvin, I choose option 1.

For me, the term 'open' is closely bound to this project, not only because it's open source, but also because it should be open to modders as much as possible.

I could repeat all what Darvin said, but that would be pretty pointless...

Solinx

option 1 it is then