Involved development of the OpenMW construction set.
- Site Admin
- Posts: 1193
- Joined: 05 Aug 2011, 22:21
- Location: Wroclaw, Poland
For the design stage of the editor I will make a series of postings, that we can discuss before we move on to the next.
0. Organisation (this one)
How to organise the design stage and general organisational issues for the implementation (repository, versions, tracker and such).
What direction the editor should take. Target audience. General design principles.
2. Flaws in the TES-CS
A listing of most obvious design flaws in the CS. Shall serve as a warning not to make the same mistakes again.
3. GUI Design Considerations
Some general insights into GUI design. Not directly CS-related. Probably a bit controversial.
How to design the editor framework. Editor-wide functions and how to integrate individual editing components into the framework.
At this point we probably should start with the coding (well you should; until 1.0 is reached, I will keep what little time I have for coding focussed on OpenMW).
Once the framework is complete, we can do a design-implementation-cycle on a per-component basis. No need to design all components in advance.
0a. Versions and Releases
At a later stage we will want to keep editor and openmw in sync. Since enhancing openmw (post 1.0) usually will mean modifying the esm format, we need to modify the editor too and release at the same time.
I see three phases:
Phase I: Up to OpenMW 1.0.0
Editor and OpenMW share version numbers and we release them at the same time. The first version of the editor probably would have the version number 0.11.0 or 0.12.0.
Phase II: OpenMW at 1.0.0, but Editor not finished yet
At this point the OpenMW development needs to be put on hold until the editor has caught up (except for bug.-fixes). Lets say we have OpenMW 0.30.0 and after that OpenMW 1.0.0. The next version of the editor would still be called 0.31.0. At this time we would only release the editor.
Phase III: Both OpenMW and Editor have reached 1.0.0
From this point on we will develop and release them in sync again.
I think from 1.0.0 on we should put OpenMW and the Editor into two separate packages. Someone who only wants to play doesn't need the editor and we should not burden such a user with it.
Prior to 1.0.0 its really up to the package maintainers, but if it is not too much work, I would suggest haven two packages too.
0c. Github repository
Since the development of Editor and OpenMW is so interwoven we will develop them in the same repository. Both applications will use in parts the same code (especially in the components directory) and the only way to do that reasonably with two separate repositories would be using more submodule-foo. This is a headache I can do without.
The editor goes into the directory: apps/opencs/
I will create a separate Editor branch, that will serve as a new master branch for editor development.
0d. Issue tracker
Same arguments as with github. We track both Editor and OpenMW in the same Mantis project. I will create a couple of additional categories once we have reached the later design phase.
As it is rather a separate team. we should have a lead, to do all the organizing, so its not all on Zini.
Design of the framework and how everything goes together should be discussed in length before any code is put down.
so it was
so who is going to volunteer?
Thanks, but I can handle it just fine. Since we have the entire infrastructure in place already, the organisational part isn't too much work.
Don't know if this is the right topic but:
I'm currently doing some testing with Ogre integration into Qt. Looks promising. We probably can re-use alot of the OpenMW engine, but first I want to get plain old Ogre working as a MDI (Multiple Document Interface) window.
That would be kinda stepping ahead. We need to talk about reusing OpenMW code for rendering (except for the low level component stuff).
MDI is another topic that needs to be discussed (later).
Edit: Also, can we keep the focus on the launcher for now? There are a lot of qt volunteers now. Maybe you want to hand over a subtask to one of them so we get the launcher finished earlier?
Yeah I wasn't intending to spend a lot of time on it, I was curious if it was possible.
Do we have Qt volunteers! Awesome. Anyone interested in a subtask can contact me, I'm all for it.
I am going to swap #2 with #3. makes more sense that way.