Long Term Planning (0.12.0 and beyond)

A generic talk on the OpenMW project.
Locked
User avatar
lgromanowski
Site Admin
Posts: 1193
Joined: 05 Aug 2011, 22:21
Location: Wroclaw, Poland
Contact:

Long Term Planning (0.12.0 and beyond)

Post by lgromanowski »

Zini wrote: With 0.11.0 almost done I would like to present my ideas for the future development. I will make a separate thread for 0.12.0 once we are ready. This one is about the general direction for the next few releases.

It seems that we won't get terrain for 0.11.0. But we should focus on it for 0.12.0.
The mwrender-subsystem needs a complete makeover, which I don't want to do at the same time as the terrain, which makes 0.13.0 the most likely candidate for it. Afterwards we can have a go at a proper character control including all camera modes.

For 0.12.0 I will also do some preparations for multiple esms and esps. There is still a bit groundwork to be done, before we can get to this feature (most likely in 0.13.0).

A few versions ago we tried to make the character creation work. That kinda failed, because some features were still missing/not working properly (mostly the object activation). If we can get enough man-power for GUI-work, I would like to take up this approach again, but on a larger scale. We should be able to get the whole tutorial sequence working, maybe even all the rest of Seyda Neen too.
The only exception here are combat and NPC movement. These features are both far away.
Star-Demon wrote: What is the timeframe on all that?
I think that it's a bit much if you still want to keep an update schedule of 1 minor revision every couple of months.

So - I guess it will look like this:

For 0.12.0 (November or December):
- Get mwrender fixed forever and ready to do terrain
- Conclude forever our problems with files
- Work on on the data management system - we should able to easily get and assign or overwrite as many files, items or references we want and see that in game. I'm not sure what it is, but looking around, we don't seem to have a full grasp on the data, yet. You know more about it than me, but it doesn't look like we have all of it, yet. (At least with resources...)
-Little extra gui tasks to make us feel productive

For 0.13.0 (April or May):
- Terrain - We're doing this.
- Work on game systems, including giving the player stats and spells effects. People really want to work on this, and I'd say anything that gets us here is one of the big obstacles to popularity.
- Begin CharGen.
- Little extra gui tasks to make us feel productive (chargen)

For 0.14.0 (September or October):
- CharGen finished - even works with nords!
- Work on NPC Movement
- Little extra gui tasks to make us feel productive
- If we're ahead of ourselves, try the whole starting scene from boat to leaving the office. This is the big one, but we need to improve the project before this becomes a realistic goal.

This is generally what you were hoping for, right?

It looks unglamorous until next year around this time, but we definitely are not far along enough with the lower level stuff like the renderer and using anything in data files to start inviting folks to work on things that can't be finished until those other things are done.

Other than that one concern, I think what you said is fine. for 0.12.0, the renderer and the data files are definitely the top priorities.
Zini wrote: Not really. We are currently doing a release every 2-3 months. That should result in a somewhat different time scale.

- you mixed up the order of terrain and mwrender-refactoring
-Little extra gui tasks to make us feel productive
These are not little extra tasks. These are big roadblocks, that we need to get out of the way to progress further.
- Work on game systems, including giving the player stats and spells effects. People really want to work on this, and I'd say anything that gets us here is one of the big obstacles to popularity.
Most stats are already there. As for spell effects, I haven't looked into them closely yet, but I think a lot more groundwork is needed, before we can tackle them. Actually, I think it would best to first implement spell casting and management, before we have a go at the effects (will make testing a lot easier).
- Begin CharGen.
The actual CharGen is finished (or nearly; some Windows still miss some of the eye candy and some minor functionality). What is not fully working yet, is the scripted stuff surrounding it.
- Work on NPC Movement
No way we can get that into 0.14.0. There must be at least a dozen others tasks we need to finish first.

Sorry, but I just don't understand what you mean with the following:
- Conclude forever our problems with files
- Work on on the data management system - we should able to easily get and assign or overwrite as many files, items or references we want and see that in game. I'm not sure what it is, but looking around, we don't seem to have a full grasp on the data, yet. You know more about it than me, but it doesn't look like we have all of it, yet. (At least with resources...)
Hircine wrote: With the Gui system, I recall someone mentioning it being crap. but tied so heavily into current things that it would be difficult to change.

why is it crap? (or another is better).
how difficult is it to redo with a better one?
and would a person who is reasonably good at programming, but hasn't delved into C++ be able to achieve this. (i know c#/java).

i could work with someone else maybe Star Demon(as i know he is in a similar situation to me)
we could learn C++ and help out tonnes more :D and get stuff done.
Zini wrote: I don't know MyGUI well enough to say it is crap, but I don't see much evidence that supports this statement. However MyGUI doesn't seem to be widely used, which makes it hard to find coders with experience with it. From what I heard the documentation isn't that great either, but that can be said about most open source GUI systems.

Going from C++ to Java is ... difficult. The two languages look similar and people coming from Java tend to use C++ like Java, which will inevitably fail. It is possible to go from Java to C++ in a limited amount of time, but be prepared to bump your head a couple of times against a wall.
Hircine wrote: how much better would things be if we went to CEGUI?

and is it something that is wanted?

I am happy to learn C++ and the CEGUI library and help out with UI related tasks.

btw.
I have 4-5 weeks free time :)
Zini wrote: Unless we get at least 2-3 coders with prior experience with another GUI library there is little point in swapping MyGUI out for it. As for CEGUI, I recently had to investigate it for another project and I am not impressed that much. The documentation has serious problems too and the library has some annoying quirks (no show-stoppers, but enough to make me wish to hit the screen with my fist a couple of times).

I suggest you take a look at the MyGUI documentation and see if you can make any sense from it.
Hircine wrote: I will have a look at the road map and also look at the specific GUI code.

and i will look at the MyGui Documentation.
Zini wrote: It seems with Atrill we have the optimal candidate for GUI work. But don't let that stop you from having a go at it too. Even right now there is enough GUI work for at least three developers and we can easily make more available for the next release.
Zini wrote: With one or maybe even two new GUI developers and some returning developers we are in a pretty good position now. Experience tells us, that some will drop out before they contribute anything useful. But let's be optimistic about it and assume all will stick with us.
I will start now cleaning out the roadmap for 0.11.0 and building the roadmap for 0.12.0 based on this assumption.
Zini wrote: Why does the server decide to go down exactly when I am about to do some work on the issue tracker? *sigh*
safferli wrote: Might I add my own personal opinion? If we (well, you, the coders) can get the character generation "tutorial" fully functional with GUIs and everything, that would be a major visible thing that can lead to lots of players trying out openMW -- just to make lots of characters. At least I would think so.

It seems that most of the stuff is already done if I read the comments correctly, and some scripting and GUI stuff is left. Even though that is a lot of work, of course.

Having the character generation functional would be a great milestone, as people can actually do something with the game then, even though terrain, quests, etc are still not playable.

Just my opinion, of course.
Zini wrote: Yeah, that's exactly my line of thinking.
Star-Demon wrote: I definitely would like to get the Beginning of the game working. (although if we get that working we're kinda done) If we're doing it to draw coders, we've put the cart before the horse. I also think it's a very, very large job .

Zini - About release schedule: My bad, I had the impression you were making posts about releases on that interval.
Hircine wrote:With the Gui system, I recall someone mentioning it being crap. but tied so heavily into current things that it would be difficult to change.

why is it crap? (or another is better).
how difficult is it to redo with a better one?
and would a person who is reasonably good at programming, but hasn't delved into C++ be able to achieve this. (i know c#/java).

i could work with someone else maybe Star Demon(as i know he is in a similar situation to me)
we could learn C++ and help out tonnes more :D and get stuff done.
I find it hard to keep track of who says what about what around here, too. Zini sometimes comment about work needed here or there in various threads he checks up on. Zini could use "Blue posts", but I'd prefer someone just taking a few minutes to explain how something should work.

Far as I know, The GUI and chargen are incomplete, and if stats worked, that means we made lots of progress since 0.9.0 on it, since it didn't work then. If he had stats we'd have runspeed when I worked on auto-move for 0.10.0, and we didn't have that, either. So, after all that Path Dependency, I'm pretty sure it was safe to conclude Chargen was and is incomplete.

The GUI stuff isn't *hard* - I'd say a few hours doing MyGUI homework and then an hour looking at the code should be enough to work on it. But since it's not clear or documented how we take information from proper places and give it to the gui, It's going to take much longer.

I agree with Zini - changing to CEGUI from MYGUIwould be a lot of work. I want to work with CEGUI, being more widely used and being the most powerful, but the complaint is about documentation (Which I find a bit ironic, but hey, it IS a problem.), but anyone can take a week off and write it - no one with the knowledge wants to put the effort into it.

I think it'd be a good idea to work with you, Hircine; we should see what we can do after the picture becomes clear. If we had an IRC channel, that'd make it really easy to do stuff as a team.
Experience tells us, that some will drop out before they contribute anything useful
My experience tells me lots of things. I still say that it definitely does not have to be that way. There are experienced and talented people we are just throwing away.

C++ to Java isn't hard, nor is Java to C++. It isn't hard for me to understand at all. What you seem to be getting at is program design, but to be honest I'm only just beginning to see how you can make a big program in C++ compared to how you make a big program in java. That is very different, and I'd say that is the big part in order to make that jump from pro java to pro C++.

Java also doesn't require the amount of technical skills to compile, build, and run. The downside is the JVM.

Even though I'd rather be learning and working in C++, as much hate as Java gets, one of the best grossing indie games right now is written in Java** (and it had null pointer exceptions for while!), all the jobs around me are for senior Java developers, and if you have good guidance (not something people in Computer science are very good at giving), you learn the foundations well enough to understand why each language does what it does and you get where you need to be.

TL;DR: Any reason it's difficult is because we make it that way.

** The other one is written in C# using XNA - another "easymode LOL noobs" language and API. Enjoy being poor?
Zini wrote:
Far as I know, The GUI and chargen are incomplete, and if stats worked, that means we made lots of progress since 0.9.0 on it, since it didn't work then. If he had stats we'd have runspeed when I worked on auto-move for 0.10.0, and we didn't have that, either. So, after all that Path Dependency, I'm pretty sure it was safe to conclude Chargen was and is incomplete.
That is not correct. The actual chargen GUI works and is functional complete, for sufficient small values of functional complete. Most stats were already there in 0.9.0. Runspeed is not a stat. It is derived from stats via formulas we haven't completely figured out yet and IIRC it was the physics implementation that got in the way, because a completely different implementation path was chosen than Nico had planned.

Its more about the scripted events around chargen and the tutorial. A few examples:

- The guy who lets you select your class currently doesn't work, because his script is using the one last syntactical feature of the scripting language that is not implemented yet.

- When you try to enter the second building, you are ordered to pick up some stuff from a barrel near the door. But we don't have an UI for interacting for containers yet.
Star-Demon wrote:
Zini wrote:That is not correct. The actual chargen GUI works and is functional complete, for sufficient small values of functional complete.
Shinanigans!
Most stats were already there in 0.9.0. Runspeed is not a stat. It is derived from stats via formulas we haven't completely figured out yet and IIRC it was the physics implementation that got in the way, because a completely different implementation path was chosen than Nico had planned.
Ah. Okay.
Its more about the scripted events around chargen and the tutorial. A few examples:

- The guy who lets you select your class currently doesn't work, because his script is using the one last syntactical feature of the scripting language that is not implemented yet.

- When you try to enter the second building, you are ordered to pick up some stuff from a barrel near the door. But we don't have an UI for interacting for containers yet.
You also don't have terrain to stand on to look in the barrel. :P
Zini wrote: Well, we can still float around with disabled gravity. That doesn't make the tutorial less playable. The missing container UI on the other hand does, because the door won't open before you have taken the stuff from the barrel.
Star-Demon wrote: Speaking of doors, how about the door that unlocks that you open to go get the knife? Do our doors work, yet?
Zini wrote: Somewhat. IIRC the door is unlocked from the script of the NPC that I mentioned (the one that doesn't work yet). I think I implemented the unlock instruction. But opening non-load doors doesn't work yet (this is a different issue than locking/unlocking).
pvdk wrote: On CEGUI: Like I said before: I managed to get the original Morrowind font working in CEGUI as a pixmap font. This was something I was messing around for a long time with MyGUI but I couldn't get it to work properly, even after contacting a MyGUI dev. Turns out it just isn't possible with the current MyGUI code.

A working Morrowind font made me like CEGUI a lot.
However, when I tried to create a simple Ogre+CEGUI app, I stumbled upon a lot of problems. I don't know if it's me or maybe my library versions but long story short: I quit trying.

Another problem with CEGUI is the fact that it uses imagesets instead of single images. An imageset is a single image cut up in smaller portions, somewhat like texture atlases.
Morrowind uses separate texture files. This means we have to combine the separate textures into a single image at runtime, or create separate imagesets for each texture file. For the next CEGUI release there are some changes planned in the way imagesets are created, but I don't know if it will solve this problem.

In the long run I suggest we look into switching to CEGUI, but only when we have developers with experience with it and the imageset problem is solved. The Morrowind font working with CEGUI is not enough to justify the amount of trouble involved.
Star-Demon wrote: Really? That's such a pain. I make my own gui elements, and I use a lot of images and then blit stuff over them to fill them (hp bars dialogue boxes, etc) - this means I make all those images separate for easy modding and reuse.

Putting them on a single image and make someone reskin them that way is a real pain.
pvdk wrote:
Star-Demon wrote:Putting them on a single image and make someone reskin them that way is a real pain.
Yeah but our intention is to support and use the original Morrowind textures. That means we would have to combine the separate textures at runtime (if we want to combine them at all). Thus allowing modifications to the textures to work, like this mod I made back in 2004: Pyro's Morrowind Black II
Star-Demon wrote:
pvdk wrote:
Star-Demon wrote:Putting them on a single image and make someone reskin them that way is a real pain.
Yeah but our intention is to support and use the original Morrowind textures. That means we would have to combine the separate textures at runtime (if we want to combine them at all). Thus allowing modifications to the textures to work, like this mod I made back in 2004: Pyro's Morrowind Black II
I wasn't really talking about OpenMW per se...I can see why we'd want it that way.

I guess it's better to load one image both in code and memory from disk than to load many smaller images, store them, and then blit all of them.
pvdk wrote: Yeah, CEGUI does it that way for exactly that reason.
gus wrote:
IIRC it was the physics implementation that got in the way, because a completely different implementation path was chosen than Nico had planned.
Wrong mouahahah :mrgreen:
In fact, after looking at the old D code,IIRC his implementation of physic character was almost the same than the one provided by bullet. And the current implementation is a modification of what is provided by bullet.
Zini wrote: Okay, I correct myself. The original C++ implementation was completely different from what we have now and what was apparently the D implementation. It is possible the Nico intended the original implementation as a placeholder that was to be replaced by something similar to what we have now. But he never let me in on his plans.
Greendogo wrote:
Star-Demon wrote:Really? That's such a pain. I make my own gui elements, and I use a lot of images and then blit stuff over them to fill them (hp bars dialogue boxes, etc) - this means I make all those images separate for easy modding and reuse.

Putting them on a single image and make someone reskin them that way is a real pain.
You could always make a small external program that knits smaller images together into the single image. But that too would be a pain, but at least it would be a pain only initially for the programmer who makes it and not for the GUI modders later.
Star-Demon wrote:
Greendogo wrote:
Star-Demon wrote:Really? That's such a pain. I make my own gui elements, and I use a lot of images and then blit stuff over them to fill them (hp bars dialogue boxes, etc) - this means I make all those images separate for easy modding and reuse.

Putting them on a single image and make someone reskin them that way is a real pain.
You could always make a small external program that knits smaller images together into the single image. But that too would be a pain, but at least it would be a pain only initially for the programmer who makes it and not for the GUI modders later.
I'm both those people! That's like...double work! :P
sir_herrbatka wrote: pain? We could use imagemagic and write simple bash script
pvdk wrote:
sir_herrbatka wrote:pain? We could use imagemagic and write simple bash script
Yeah, great for portability :) IF we decide to choose this method, why not let OpenMW do the work with a command-line option, using libpng. OpenMW would also have to do this the first time it runs, could be combined with script compilation.

Here's what the CEGUI wiki says regarding imagesets:
(Note: CEGUI 0.8 will completely change the way imagesets work. We will have images, these will simply have a reference to texture file and UV coords of the rectangle we should use in the texture file, .imageset files will still load though, so all of this still applies, furthermore the new CEED editor will support automatic imageset/atlas creation from multiple files to lessen the imageset maintenance pain)
This info can be found here
Can't find any information on this in CEGUI's roadmap though.
Star-Demon wrote: Sounds promising.
sir_herrbatka wrote:
Yeah, great for portability
Portability?

This is SPA... uhm.

:lol:
Zini wrote: Looks like we are almost short on tasks for 0.12.0. The volume if interest came a bit as a surprise to me. I have added three more tasks. That should be enough to keep us going for a while.

http://bugs.openmw.org/issues/121
http://bugs.openmw.org/issues/112
http://bugs.openmw.org/issues/90
Locked