Im going to be very negative here so dont take any of it personally.
No problem. Let's see what I can answer:
maxim wrote:
- instant usage of plugins: embedding sound, speech, video or flash animations is just one line of code away.
Difficult to add positional information and doppler effects to audio. No need for flash, we have openGl.
We are talking about the gui. Sound for non gui effects should be handled elsewhere of course. Flash is also meant for gui effects as animated buttons, transparency, morphing of gui elements, etc. - all those eyecandy things that are usefull in game design - will be hard work to implement this in native OpenGL.
Quote:
- instant usage of scripting capabilities for complicated gui task - with javascript.
Better to have a widget set that has enough features so we don't need to prop it up with a scripting language. Besides we have a great scripting language. Lua.
Don't mix up the scripting language for automating Celestia, and a script language for gui tasks. They're completely independent from each other. And I don't think that any widget set contains things as event handlers for mouse and keyboard events - that would be far above their use intentations. Using Javascript you can create, rearange, fill, hide, change, popup, etc. gui elements. you can handle freeform buttons and even imaged areas. You can combine a button with a sound and a lot of other things. Of course there are other ways to do those things - but with far more effort.
Of course, if you keep things simple, you won't need this interactivity, but that would make usage a little more dull.
Quote:
- fully independed gui developement:
--> work intensive gui design can be easily spreaded between several developers.
The gui design is not work intensive, and should be done on paper. Implementing it can be done using gui designer tools. (plib only has a very simple one) It is the plumbing behind it that is the hard bit.
A good gui design is almost as work intensive as creating the applications core. There is not only the basic design done on paper, but also the testing, and the merging. From the first paper design until an intuitive, fast and secure usable gui it's a long way. Splitting it up could be usefull. You may have set of gui panes for traveling, another one for trading, fighting, ship upgrade, ...
Quote:
--> failures in newly developed gui pages don't interfere with other code.
And nothing fails at compile time, meaning more bugs get through to releases, and it is difficult to debug.
Again, don't mix up two different task blocks. If your underlying gui handler (here the browser core) is stable, you won't have to deal with compile time errors here. As I said above, gui testing is cruical, and errors usually arise from bad design rather than failureous coding. They are logical errors, not syntactical ones. The debugging of core code and gui design/implementation are intependend from each other and can easily be handled from different persons. If your gui implementation is good, you won't have to touch it any more, even when updating your core code several times.
Quote:
--> easy design and replacement of multiple skins.
both plib and Qt have customizable styles that can easily be applied to all components.
I've thought of other people that like to modify your gui skin, because they have some design ideas, they are talented in that way or something else. They would just have to replace it, with no need for recompiling the whole code.
Quote:
- instant network capabilities:
I am using an embedded mysql server, If i ever get to the stage of trying networking capabilities all I need to do is to move the relavent tables from the embedded server to a remote mysql server. The api for embedded and remote is the same. Actually doing something with the networking is something else all together.
Of course accessing the sql server from local or remote doesn't mean the game itself is network capable.
Quote:
--> setting up a webserver on any machine could immediately create a common playground.
--> HTTP protocol is quite firewall resistant.
HTTP is designed for sending webpages, not for networking games. (then again neither is mySQL)
HTTP is used for many task, not only for web pages - as a tunneling protocol for VPNs for example, or for other tunneling tasks. If you need fast action respond for ego shooter games or similar, it is surely too slow. But for less time critical things as trading or general positioning of atavars it should be sufficient.
Quote:
--> instant cross platform capable.
I'm guessing, just add Mozilla Firefox.
It should work with any browsers core. HTML and Javascript are platform independend.
To my opinion the Gecko enginge (Mozilla rendering engine) is too huge with about 8MB. I was searching for some other canditates on the net, and found some quite lean an fast ones. But all lacked of some capabilities (no javascript, only HTML subset, ...), so actually I haven't found a real good usable core yet.
Quote:
- rapid developement.
Be careful of this buzzword, can also mean inflexible development..
I should have said 'rapid prototyping'. Quickly setting up a test situation, and then going throught possible paths, looking for straighforward usage and design holes.
maxim
