So the first requirement I had is I want an interface similar to Visual Studio or Unity3D, with the detachable windows \ panes, the reason for this is because that kind of program works well with multiple monitors and doing different tasks along with the ability to make the experience your own, positioning windows where and how you want saving different layouts for different games which is something I find very handy myself in Unity3D.
The second requirement is because of the modularity of the engine the editor needs to be just as modular, therefore it needs to be plugin oriented.
The third requirement is the need for multi-user editing, which the Toasty Editor will be based on. This means that at any time you can host a project and see real-time edits of other users. This will require the locking of entities and components so only you can work on it, but this also means there needs to be admins or project managers with permissions to unlock anything. The direct idea behind this is that you could monitor and manage the project from within Toasty itself. I'll talk about this later on.
So to begin with the choice of wxWidgets as my GUI of choice. The reasons follow as:
- Cleanliness, don't have to use macros and the ability to customize for smallest library size.
- Unicode
- wxAUI - The only issue with this is it doesn't have all the features I want however it's...
- Open source with a good licence so i'm working on those features at the moment!
- Excellent community support, both from the developers on the google groups wx-users and wx-dev and from the users at the wxForums. Ask a question on google groups and you'll at least have a response the next day.
- Ultra active development, there are many commits per day, just checkout the puchcard.
- Keeps backwards compatibility for a decent time
- Works on Linux, Mac and Windows.
This solves requirement number one and two. I have done a bit of research in plugin architectures and the way I have found is to have a common library (wxWidgets and the plugin interface library I write) which the main application and any plugins will link to this way the common library is the plugin interface and because the main application uses it, it should be powerful enough to make any kind of plugin required. The only thing is making it secure!
The third requirement however is a bit harder but I think I have it solved with the MVC pattern. So the Model is the project in the filesystem so scenes are scenename.scene folders that contain entity files. Views can then listen for modification of files or folders they are interested in and display data as required. Controllers can be anything that edits the files and folders that represent the project but for the networking I intend to have NetworkedCommands which one will have to inherit from which will allow others to undo \ redo external changes and on top of that can have the ability to log all changes in large projects!
Lets see how it goes!
