ogre branch ? new attempt from scratch

The point of no return for both Ogre ports. Permanent links will be stickied on top with current information of each port (Lua and Python)

Moderators: ghoulsblade2, strook

Post Reply
ghoulsblade2
Bounty Hunter
Bounty Hunter
Posts: 136
Joined: Tue Jul 27, 2010 7:41 pm
Location: germany
Contact:

ogre branch ? new attempt from scratch

Post by ghoulsblade2 »

hi, anyone still working on the ogre branch ?
if it's this one . http://vegastrike.wcjunction.com/trac/b ... gre_branch
the last commit seems to be roughly 3 years ago, so i guess it was abandoned.
Any postmortem/reasons why it failed and what should be done entirely different ?

i got a rough overview of the devteam and code situation from reading this thread :
http://vegastrike.sourceforge.net/forum ... 27&t=15352
any major situation changes in the meantime ?

i'm currently very tempted to start creating a new ogre branch, using data (models, base images, ship values, etc, whatever i can get my hands on and understand, verrry nice stuff there =D), but starting code from scratch.

From my gamedev experience i feel confident that i can at least put a simple spacegame with vegastrike models and some gui for equipping&trading together, i'll have to massively strip down physics and some other things at first however. I prefer a minimal c++ framework and most of the logic written in lua scripts, with only the performance critical bits moved to c++, using a lib/framework for lua+ogre assembled over a few other hobby gamedev projects. That heavy-scripting approach should prove beneficial for missions and avoiding recompiles since it makes c++ changes rare.
Since it's easy to add modules written in c++ it should still be interesting for people who don't like lua.

It'd be cool if some of the effort would be beneficial for vegastrike as a whole independent of the ogre-branch, any ideas on how to optimize that ? (if you like to chat in realtime, i'll be idling in #vegastrike on irc.freenode.net most of the day)

I'm thinking of things like gui, possibly dokumenting & organizing the data formats, converting old models to more edit-friendly formats etc. Maybe adjusting internal api's to make systems at least partly compatible if there's interest for that.. Of course open for suggestions =)

EDIT (15.08.2010) :
the sourcecode of current state is always available for via readonly git access :
git clone git://zwischenwelt.org/vegaogre.git
update : see https://github.com/ghoulsblade/vegaogre

(includes binaries for win and linux: ubuntu 10.04 as well, win is untested, the ubuntu is only tested on my local machine, no idea if it'll work for others, you probably need at least ./installdeps.ubuntu.sh
just post in this thread if you have problems)

----------------------------

EDIT (18.01.2011) :
to distinguish, this thread now covers two projects,
1) my experiment with vegastrike data in ogre3d engine with heavy lua scripting, not using the original codebase at all
screenshots and vids :
http://www.youtube.com/watch?v=nKH-Y6-xLSs (early fly around test, outdated)
http://vegastrike.sourceforge.net/forum ... &mode=view
http://vegastrike.sourceforge.net/forum ... &mode=view
http://vegastrike.sourceforge.net/forum ... &mode=view
http://img34.imageshack.us/i/space10.png/
http://www.youtube.com/watch?v=Em7A3RJ7J6I&hd=1 (ship models imported)
not playable, just an experiment and currently on halt/ discontinued.
code is on github : https://github.com/ghoulsblade/vegaogre

2) strook's efforts to get the ogre-branch in the original vegastrike codebase up to date (see around page10 or so for details and patches there, version management is still being discussed but probably svn branch on the vegastrike sourceforge page)
https://sourceforge.net/projects/vegaogre/
http://vegastrike.sourceforge.net/wiki/Development:Ogre
http://vegastrike.sourceforge.net/wiki/ ... VN#Modules
http://vegastrike.sourceforge.net/wiki/ ... For_Coders
Last edited by ghoulsblade2 on Wed Feb 02, 2011 9:07 pm, edited 11 times in total.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: ogre branch ? new attempt from scratch

Post by klauss »

ghoulsblade2 wrote:hi, anyone still working on the ogre branch ?
if it's this one . http://vegastrike.wcjunction.com/trac/b ... gre_branch
the last commit seems to be roughly 3 years ago, so i guess it was abandoned.
Any postmortem/reasons why it failed and what should be done entirely different ?
Short answer: I overdesigned.

In depth: I wanted to add lots of cool features with the Ogre branch. Ogre allowed us many useful nifty features, so I tried to fit them all. I still want them, but I realize trying to do it all for the first release was wrong.

There are a few key points that brought some odd troubles:

First, the Ogre version at the time had many limitations. One of which was inherent to the material system: material files specified their textures. Material files are complex, required a lot of understanding of shading techniques, yet they specified specific textures and had to be tied to specific models. That was bad in many levels for VS, so I implemented a material templating system that would let artists edit only the texture references and leave all the complex shading specification to a shading expert.

That turned out great, but was a ton of work. And a similar system is now part of Ogre's core, so if you were to write an engine from scratch, you would probably not need that.

Second, a key design point was the changing of GUI systems, and the requirement for the new Ogre-based GUI to be renderable to texture at any time. The requirement was there to support in-cockpit scriptable interfaces, and it's still a core requirement for an Ogre port. It's the feature Ogre enables us to implement, because render-to-texture is a tricky issue with many compatibility problems we don't want to tackle ourselves. We're understaffed for doing so. We need Ogre, which has already coped with those issues.

The GUI system gave me many headaches, as I didn't really know how to design it. Plus, I wanted to adopt CEGUI. Another mistake - I should have just reimplemented the current base interface using Ogre as rendering backend and be done with it, CEGUI could come in a later phase.

Finally, there's another key requirement that really cannot be ignored, not even in the first release of an Ogre port: dataset compatibility. I made, perhaps a mistake, the decision to move to Ogre's native formats for graphical assets (material descriptions, mesh models, everything). That required me to try to implement dataset migration tools. Believe me, an Ogre port that isn't compatible at the dataset level isn't a port, it's a brand-new engine. We want a port. We're understaffed everywhere, and that includes content creation - we just can't afford making the engine incompatible with the current dataset and force content creations to start over.

Now... if I were to continue the effort, something I wanted to do eventually, I would not start from scratch. There are key features in the ogre_branch that would be required anyhow: the material templating system is a good thing IMHO, the layered rendering scheme, the Model abstraction (we want Model, which are composed of many meshes, some probably animated). In short, there's a lot of value there, but I'd sure ditch a lot too. Like all GUI stuff (Layer, Element, etc) which desperately needs a simplified, minimized redesign.

ghoulsblade2 wrote:From my gamedev experience i feel confident that i can at least put a simple spacegame with vegastrike models and some gui for equipping&trading together, i'll have to massively strip down physics and some other things at first however. I prefer a minimal c++ framework and most of the logic written in lua scripts, with only the performance critical bits moved to c++, using a lib/framework for lua+ogre assembled over a few other hobby gamedev projects. That heavy-scripting approach should prove beneficial for missions and avoiding recompiles since it makes c++ changes rare.
Since it's easy to add modules written in c++ it should still be interesting for people who don't like lua.
That's a whole new game - you'd only be reusing VS art. AFAIK, VS art is in a permissive license (not sure which) that would allow you to do that, as long as you give proper attribution (probably something akin to CC-BY-SA). I'm not 100% sure of anything about licenses, though... don't take my word for more than it's worth.
ghoulsblade2 wrote:It'd be cool if some of the effort would be beneficial for vegastrike as a whole independent of the ogre-branch, any ideas on how to optimize that ? (if you like to chat in realtime, i'll be idling in #vegastrike on irc.freenode.net most of the day)
Well... Ogre doesn't provide you with an audio system, and although there are Ogre-ified audio systems out there, I found them rather lacking (ie: basic).
I'm designing my own with some advanced features in mind for its future. You can reuse that.

In a similar way, you can make whatever you do in your "port" modular and reusable. Say you make a scene manager that does something needed and useful, it could be reused here when the time comes, if it's modular and usable enough separate from your engine.
ghoulsblade2 wrote:I'm thinking of things like gui, possibly dokumenting & organizing the data formats, converting old models to more edit-friendly formats etc.
And there's also any conversion tool you may use or make, of course that would be useful here. Even the converted models would be useful.
ghoulsblade2 wrote:Maybe adjusting internal api's to make systems at least partly compatible if there's interest for that.. Of course open for suggestions =)
I'm not sure that would be possible at a scripting level. If you browse VS scripts (made in python), even forgetting about the difference in language (VS uses python, you'd use LUA), VS scripting system is way too tied into the engine in a way that would hinder any attempt from your part to make the interface APIs compatible.

Of course I could be proven wrong, and I wouldn't mind that.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
ghoulsblade2
Bounty Hunter
Bounty Hunter
Posts: 136
Joined: Tue Jul 27, 2010 7:41 pm
Location: germany
Contact:

Re: ogre branch ? new attempt from scratch

Post by ghoulsblade2 »

klauss wrote:That's a whole new game - you'd only be reusing VS art. AFAIK, VS art is in a permissive license (not sure which) that would allow you to do that, as long as you give proper attribution (probably something akin to CC-BY-SA). I'm not 100% sure of anything about licenses, though... don't take my word for more than it's worth.
should be GPL or something else usable since it's in the ubuntu and maybe even debain repos. need to check in detail, but i want opensource anyway =) which would you prefer, v2 or v3 or "v3 or later" ?

whole new game : not really what i had in mind, but i don't think i'd have much fun working on the current codebase from what i've read, especially since i'm not used to it. What design things would you consider essential for defining vegastrike as a game and not to be changed ?

dataset : yeah, i'll try to go for compatibility if possible. maybe by heavy use of ogre resource-groups and adding them during runtime, i don't understand the vegastrike dataset well enough so far. Any particular stumbleblocks that i should watch out for ?
ghoulsblade2
Bounty Hunter
Bounty Hunter
Posts: 136
Joined: Tue Jul 27, 2010 7:41 pm
Location: germany
Contact:

Re: ogre branch ? new attempt from scratch

Post by ghoulsblade2 »

thanks for the report about the previous branch =)

soundsystem :

Code: Select all

I'm designing my own with some advanced features in mind for its future. You can reuse that.
sure, i'd love to, read about it in the devblog, where can i find it ? If not done already, i'd appreciate putting it in a separate folder for easier inclusion and updating.

gui system : yeah, cegui is ugly, and the render-to-texture thing in cegui and ogre default gui is nasty, luckily i've got a gui system that doesn't need render-to-texture implemented already from another project, should get the job done after a few modifications.

material texture : can probably be solved by using the texture_alias directive , probably wasn't available back then.

please describe what you mean by "in-cockpit scriptable interfaces", do you mean stuff like custom radar / meters that can be scripted rather than compiled in c source ? (due to heavy scripting in my approach that'll be the natural way to do it for me, i'd appreciate if we could exchange ideas on that one, could even be a candidate for "common/similar api" as well.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: ogre branch ? new attempt from scratch

Post by klauss »

ghoulsblade2 wrote:sure, i'd love to, read about it in the devblog, where can i find it ? If not done already, i'd appreciate putting it in a separate folder for easier inclusion and updating.
/trunk/vegastrike/audio
ghoulsblade2 wrote: material texture : can probably be solved by using the texture_alias directive , probably wasn't available back then.
Yep. It was introduced, I think, a few days after I finished the TemplateManager. Talk about bad timing ;)
ghoulsblade2 wrote:please describe what you mean by "in-cockpit scriptable interfaces", do you mean stuff like custom radar / meters that can be scripted rather than compiled in c source ? (due to heavy scripting in my approach that'll be the natural way to do it for me, i'd appreciate if we could exchange ideas on that one, could even be a candidate for "common/similar api" as well.
Well, imagine an interface as the base interface or the main menu (they're all driven by python scripts). That, on a VDU. And you could press a key to select the VDU, and a mouse cursor would appear. (or simply a full-screen cursor, I'm not sure what would be best).

It's needed not only for interactive VDUs, but also to be able to map radar and VDU displays onto 3D virtual cockpits, which as of now is impossible (we have to overlay the 2D HUD on top of the 3D virtual cockpit and that just sucks).
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
ghoulsblade2
Bounty Hunter
Bounty Hunter
Posts: 136
Joined: Tue Jul 27, 2010 7:41 pm
Location: germany
Contact:

Re: ogre branch ? new attempt from scratch

Post by ghoulsblade2 »

hmm, so you mean render-to-texture gui windows/VDUs with mouse support, that can display different stats about the ship or similar (base menu -> you mean buy/sell inside a base/planet?)

i'm still not sure what you mean by the emphasis on "scriptable" then, what would you like to script, the things being displayed inside them and the placement inside a 3d cockpit, or something else ?

the gui i'm thinking about would only have some lowlevel drawing function and mouse-over detection (rect+bitmasks) for speed in c++, base widget classes are realized as lua classes, allowing very good access via script and extensions with new widget classes (e.g custom meters)

when i read vdu i can't help but think about a rectangular area, that seems to me like an unneccessary limit. I'm rather thinking about things like set-speed & hull/shield possibly integrated into the crosshair as half-round meters so it stays in view easier during fighting.
Fully scripted of course to allow for customization should the player prefer something different.

I'm also a big fan of using the mouse for more than just steering the ship, since there are so many things to be done that its a pain to remember all the hotkeys, especially for newcomers.
Probably a key to toggle between mouse-steering mode (dogfights etc where you directly control the ship and weapons, and all neccessary combats utils via hotkey), and a more comfortable "menu" mode (fullscreen) where you can interact with the gui elements :
* tooltips with explanations on mouse-over
* list-window(s) showing in system-navigation points (and ships in range) with different sorting options, filtering
* right-click menus with options (hud-things like crosshair customization as well as options navpoint/ship list things)
* "tracking" info displays following the 3d position of the active target (their hull state etc)
* possibly a 3d radar orb indicating distance&velocity a bit (using lines and size)
* a easier to use & prettier map than the current one
ghoulsblade2
Bounty Hunter
Bounty Hunter
Posts: 136
Joined: Tue Jul 27, 2010 7:41 pm
Location: germany
Contact:

Re: ogre branch ? new attempt from scratch

Post by ghoulsblade2 »

so no interest in collaboration there, or just no time ? Ah pity, i'd love to chat about that stuff a bit 'cause i think gui is very important for a space-game. Oh well, we'll see how it goes =)
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: ogre branch ? new attempt from scratch

Post by klauss »

ghoulsblade2 wrote:i'm still not sure what you mean by the emphasis on "scriptable" then, what would you like to script, the things being displayed inside them and the placement inside a 3d cockpit, or something else ?
You know VS's main menu, so take a look at how it works, by peeking into data/bases/main_menu.py
ghoulsblade2 wrote:the gui i'm thinking about would only have some lowlevel drawing function and mouse-over detection (rect+bitmasks) for speed in c++, base widget classes are realized as lua classes, allowing very good access via script and extensions with new widget classes (e.g custom meters)
Kind of what the Base Interface in VS does. Only it's only applicable to bases (hence the name). I'd like to extend it to cockpits and VDUs as well.
ghoulsblade2 wrote:when i read vdu i can't help but think about a rectangular area, that seems to me like an unneccessary limit.
Well... don't then. VS has tons of non-square interfaces already, it's just art.
ghoulsblade2 wrote:I'm also a big fan of using the mouse for more than just steering the ship, since there are so many things to be done that its a pain to remember all the hotkeys, especially for newcomers.
We agree there.
ghoulsblade2 wrote:* a easier to use & prettier map than the current one
I think to be more usable it just needs to be prettier. All the important elements are there already, its ugliness isn't just aesthetic, it's so blatant that it goes all the way to unusability and beyond. I believe the exact same map, but with prettier (and more proportioned) icons would already be a lot more understandable and usable.

But yes... improvements there are highly desired by all.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
ghoulsblade2
Bounty Hunter
Bounty Hunter
Posts: 136
Joined: Tue Jul 27, 2010 7:41 pm
Location: germany
Contact:

Re: ogre branch ? new attempt from scratch

Post by ghoulsblade2 »

how about a gui to equip stuff into ship slots ? any graphical layout ideas there ? a nice drag&drop with tooltips would be cool, no ?
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: ogre branch ? new attempt from scratch

Post by klauss »

That would be super-cool.

It would be a tad bit hard to accomplish with the current Base Interface framework, but if all the necessary widgets were coded into GUI.py, the abstraction could do wonders for any future work.

I'd be glad to help out there as much as I can (ie: adding missing engine-side features, like arbitrary mesh displays and camera/light management on base interfaces).
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
ghoulsblade2
Bounty Hunter
Bounty Hunter
Posts: 136
Joined: Tue Jul 27, 2010 7:41 pm
Location: germany
Contact:

Re: ogre branch ? new attempt from scratch

Post by ghoulsblade2 »

sorry, i don't plan on using the python gui in vega, i think the lua-based gui system i have in the framework is better suited, and more flexible.

What i'd first want to discuss is : how would you like the vega gui to look and behave, not considering any current technical limitations or existing content.
How would you want it to be, from a player point of view ? =)
Chances are good i'll implement a large part of the resulting ideas in the lua gui.
So suggest away, now's the chance to influence me, i'm even begging for it, if you don't i'll just roll my own ideas and move on.

You might be thinking this stuff in lua is of no use to vegastrike.
Possibly true for the current gui system, but i suppose it's going to be rewritten at some point anyway (ogre, render-to-texture for 3d-cockpit, mouse-over/mousemode, some decent custom widget stuff)
and the lua syntax isn't that spaced out that it'd be too difficult to port some interesting bits of it to python. Who knows maybe you might even want to use the lua directly (for gui, it's not impossible to mix lua gui and python gamecode), it's rather common in gamedev, just the opensource community seems to be tardy picking it up. Even if the code is of no use at all, a chance to see and test such ideas live without having to implement them yourself should be worth a bit of time to talk about it, don't you think ? =)
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: ogre branch ? new attempt from scratch

Post by klauss »

ghoulsblade2 wrote:sorry, i don't plan on using the python gui in vega, i think the lua-based gui system i have in the framework is better suited, and more flexible.

What i'd first want to discuss is : how would you like the vega gui to look and behave, not considering any current technical limitations or existing content.
I'm not a content guy. There are lots of things about the VS universe I don't know.

I've asked that same question repeated and got few answers. It's hard getting people committed to producing a full specification and design, and then the art for it.
ghoulsblade2 wrote:Chances are good i'll implement a large part of the resulting ideas in the lua gui.
So suggest away, now's the chance to influence me, i'm even begging for it, if you don't i'll just roll my own ideas and move on.
I'll say again, anything done in LUA is unlikely to be usable on this side. We've chosen python, we won't add LUA (no point in having two scripting languages), we won't switch to LUA (too much work porting all the scripts and for what gain?).
So if you're going that route there's no need to worry about compatibility with VS codebase or even scripting techniques. Just, perhaps, if you want a remake of VS, its canon. And - remember that - current VS art/behavior is not necessarily canon. I've seen a lot of cool ideas in VS canon that haven't been properly implemented (like shield/weapon mechanics, detailled quite nicely in the docs but not really implemented in full).
ghoulsblade2 wrote:You might be thinking this stuff in lua is of no use to vegastrike.
Yap
ghoulsblade2 wrote:Possibly true for the current gui system, but i suppose it's going to be rewritten at some point anyway (ogre, render-to-texture for 3d-cockpit, mouse-over/mousemode, some decent custom widget stuff)
Doubtful. Too many scripts to rewrite.
Rather, I think its API will be made compatible with Ogre, render-to-texture, etc.

Take GUI.py - it's new, and aided a lot in producing the main meny and other complex interfaces a lot easier than with the base API. In fact, there's an XGUI coming, that will take XML layout descriptions (which artists can meddle with), much like a game-level MVC.

But even though it's useful and can ease design decisions, nothing has been rewritten to use it, rather, new stuff is written to make use of it. Eventually, the old system will be deprecated, and that will be because an acceptable low number of modules are left to be ported to the new GUI API. But it's a slow process, and LUA doesn't take that approach - it's a radical change that has to be done all at once, like a bandaid. We don't have the resources for that, and I question whatever gain you think you'll receive of that costly procedure.
ghoulsblade2 wrote:Who knows maybe you might even want to use the lua directly, it's rather common in gamedev, just the opensource community seems to be tardy picking it up.
I'm not saying LUA is bad, I don't know LUA (I've only seen examples - far too little to judge it), so I couldn't say it's good or bad. It very well could be the best scripting language ever. What I'm saying is that I don't see any gain from switching to LUA, over Python. Python's enough for our needs - heck, Python's enough to serve YouTube. And switching would involve a lot of resources, I don't think you can contend with that.

But you don't face that problem. An engine written from scratch can use LUA if you feel it's better to your needs.

ghoulsblade2 wrote:Even if the code is of no use at all, a chance to see and test such ideas live without having to implement them yourself should be worth a bit of time to talk about it, don't you think ? =)
Certainly.

The "rewrite from scratch" tactic to make radical and experimental improvements is a proven one. I'm only skeptical about the idea of applying that tactic to an entire game at once, with only one dev in the team: I can help, but certainly my time is stretched thin enough as it is so I can't help with actual coding. I can brainstorm with you.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: ogre branch ? new attempt from scratch

Post by klauss »

klauss wrote:
ghoulsblade2 wrote:Even if the code is of no use at all, a chance to see and test such ideas live without having to implement them yourself should be worth a bit of time to talk about it, don't you think ? =)
Certainly.

The "rewrite from scratch" tactic to make radical and experimental improvements is a proven one. I'm only skeptical about the idea of applying that tactic to an entire game at once, with only one dev in the team: I can help, but certainly my time is stretched thin enough as it is so I can't help with actual coding. I can brainstorm with you.
So... in that line of thought...

What do you have in mind for the DragNDrop interface you mentioned?

If you can prototype it in your engine (or skeleton of engine, or whatever prototype), I could find the time to implement it with our Python base scripting. So it would be beneficial for both (you get feedback, I get what I always wanted: an interface mockup. And a functional one at that! :D )
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
ghoulsblade2
Bounty Hunter
Bounty Hunter
Posts: 136
Joined: Tue Jul 27, 2010 7:41 pm
Location: germany
Contact:

Re: ogre branch ? new attempt from scratch

Post by ghoulsblade2 »

> currently no resources and sense in vs to lua
Yes i agree, and i'm not saying you should.
What i'm saying is i'm making a radical experiment with the lua+ogre rewrite, and it's even likely it'll fail and and the experiment will die somewhere along the line.
But i'll put in some time and will be able to try things out (maybe a friend of me as well), and i want to make it so that vegastrike has the chance to get some benefit out of those experiments. Any ideas on how to optimize that welcome=)
Be it just seeing how ideas for gui stuff in praxis, or, ideally a few ideas for how to design a more flexible scripting gui api. (seeing a similar gui element scripted in different apis might be interesting and lead to improvement in both )
I'm not a content guy. It's hard getting people committed to producing a full specification and design, and then the art for it.
What i'm trying to get from you is some ideas of stuff you'd like me to try out.
I don't know the vs canon or all the plans discussed in this forum, you probably do know a large part of it =)
Doesn't need to be full spec or complete design, just brainstorm or try to remember all those
"A: x would be cool, B: too hard to implement right now..." threads,
and throw those (ideas or threads*g*) at me =)
I'm only skeptical about the idea of applying that tactic to an entire game at once
I've got some code i can use/reuse, and some time i want to spend on space-game-dev, i just think it'll be more fun trying from scratch than trying to get a grip on the vegastrike codebase and cope with python (which i rather dislike).

Don't worry about helping me code, i think i'll do well alone using a framework i know well, and a friend of me might also help, so chances are good we'll at least get to play around with a few things. It'll be fun for me regardless of the result, and i'm writing here in the hopes of maybe making it useful for vegastrike, if only as an experiment to see how it goes and where the problems are.

I'd really appreciate some brainstorming about about optimizing the benefit for vs as a whole and for gui ideas =)
Last edited by ghoulsblade2 on Thu Aug 05, 2010 10:26 pm, edited 1 time in total.
ghoulsblade2
Bounty Hunter
Bounty Hunter
Posts: 136
Joined: Tue Jul 27, 2010 7:41 pm
Location: germany
Contact:

Re: ogre branch ? new attempt from scratch

Post by ghoulsblade2 »

drag&drop interface : okies, i'll focus on that first then, probably can show something this weekend =)
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: ogre branch ? new attempt from scratch

Post by klauss »

ghoulsblade2 wrote:> currently no resources and sense in vs to lua
Yes i agree, and i'm not saying you should.
What i'm saying is i'm making a radical experiment with the lua+ogre rewrite, and it's even likely it'll fail and and the experiment will die somewhere along the line.
But i'll put in some time and will be able to try things out (maybe a friend of me as well), and i want to make it so that vegastrike has the chance to get some benefit out of those experiments. Any ideas on how to optimize that welcome=)
Be it just seeing how ideas for gui stuff in praxis, or, ideally a few ideas for how to design a more flexible scripting gui api. (seeing a similar gui element scripted in different apis might be interesting and lead to improvement in both )
(emphasis added)

Yep yep yep... I need that, I've ran aground designing interface scripting APIs before, so I will most certainly draw inspiration from your design. After all, the ogre_branch needs a redesigned GUI API, and though I intend to (whenever I retake that branch) write a simplistic one that is barely enough to support current base interfaces, I very much so would like to be able to do more complex stuff more easily.

And even if not there, I could apply some ideas to GUI.py which is a nice abstraction of the low-level Base Interface already.
ghoulsblade2 wrote:
I'm not a content guy. It's hard getting people committed to producing a full specification and design, and then the art for it.
What i'm trying to get from you is some ideas of stuff you'd like me to try out.
I don't know the vs canon or all the plans discussed in this forum, you probably do know a large part of it =)
Doesn't need to be full spec or complete design, just brainstorm or try to remember all those
"A: x would be cool, B: too hard to implement right now..." threads,
and throw those (ideas or threads*g*) at me =)
Well, if you're in the game dev industry already you may help out a lot with scripting. In essence, content people really can't cope with how scripting is handled in VS, which is rather programmer-oriented (not even programmer-friendly). To get some missions scripted you basically are required to program a "Director" that monitors the universe and acts on trigger events. Trigger events aren't laid out in front of you in an easily understandable way, they're buried in code. That's bad for many reasons.

If you implement a form of scripting (even in LUA) that is more friendly to content creators, we could probably adopt the front-end (the part that is friendly towards content creators) and adapt the back-end for VS.

In that area, you may know it already, but I'll enumerate regardless, people is very fond of:
  • Flightgroup waypoints
  • Flightgroup personalities (or stances, targets, orders, whatever)
  • Trigger lists, of the "enter this area" / "kill this guy" then "do some" kind
  • Easily parameterized "actions" (which sometimes amount, on the engine level, to a "sub-script"): example, call for reinforcements. This implies searching the dynamic universe for such reinforcements (VS simulates a dynamic universe in the background, so ships that reinforce must exist rather than be created for consistency), the instructing each to go help guy X.
  • Orderly savegame persistence stuff. ATM, VS has a very unorderly savegame that brings some trouble.
I don't know what else... there's probably a lot left to consider.

Another thing that people always wanted but is hard to implement in a universe like VS: seamless planetary flight.

There are tons of issues to consider, from grossly different rendering engine requirements at the surface/air vs in space, to aerodynamics, to numerical precision issues (we're handling distances of light-hours), to required game-mechanical changes that go with it (suddenly, you have to land to dock with a planet, something you don't have to do now - you have to find a landing pad on the planet too, so you have to add hud indicators and helpers for that task - and a lot of other nuisances people forget when they ask for "seamless planetary flight").

You'll have the benefit of designing your engine from scratch with those in mind, so you may be able to play with those requirements a lot more than us. After you've experimented, I bet the pros/cons/issues involved will be a lot clearer and we'll have a refined implementation plan that might help us implement planetary flight in VS. Or at least know what to expect.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
ghoulsblade2
Bounty Hunter
Bounty Hunter
Posts: 136
Joined: Tue Jul 27, 2010 7:41 pm
Location: germany
Contact:

Re: ogre branch ? new attempt from scratch

Post by ghoulsblade2 »

seamless planetary flight :
i've seen a few ogre addons related to that, but i'd focus on stuff that has bigger effect on gameplay feeling first, time is on our side regarding such fancy eyecandy, the longer we wait, the better the addons may get =)

gameplay wise :
planet landing : think dropships. might be more efficient to leave a big ship in orbit and send a smaller craft down. launching yourself in a smaller craft during a fight and keeping a big ship on autopilot might be interesting as well (e.g. a single small fighter docked to a big slow cargo hauler, might make sense+fun to pilot the small one and leave the big slow one on auto pilot with turrets and pray that the shields hold..) . Not sure how well that goes with vs canon.

mission script :
yep, also very interesting for scripting api :
a capsuled, minimalistic, humanreadable subset , possibly taking care of state serialization automatically.
Extensible via more lowlevel plugins providing additional commands like the reinforcements call you noted, those could be made and published by more experienced scripters.
maybe for gui as well, think mission editor mode for map, e.g. patrol routes, in system and paths betweens systems, stray radius, alternates, timing... with easy load/save to xml file.
Possibly even graphical programming, with some sort of timeline (adobe flash editor) or an editable diagram/flowchart form for multiple paths/branches (story branches, if you kill or save a npc...).
Or those "dropdown/multiple choice" based scripting like in warcraft3, also seems quite user-friendly considering the mass of complex maps out there.

how about disabling + boarding ships ?
unthinkable in vs canon or possible ?
i loved doing that in escape velocity, you could robb fuel, cargo cargo and equip, and even add a few smaller ones as escorts (up to 4 vessels total or so, possibly with size limits). might also be interesting for "take x prisoner" or "retrieve stolen item" type missions. (you blow up the thieves -> item destroyed -> fail)
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: ogre branch ? new attempt from scratch

Post by klauss »

ghoulsblade2 wrote: how about disabling + boarding ships ?
unthinkable in vs canon or possible ?
I think it's pretty ok canon-wise, but the engine's damage model can't take it.
Your remake probably could be designed with that in mind.

However, gameplay-wise, I'm not sure how you see the "boarding" part flowing.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
ghoulsblade2
Bounty Hunter
Bounty Hunter
Posts: 136
Joined: Tue Jul 27, 2010 7:41 pm
Location: germany
Contact:

Re: ogre branch ? new attempt from scratch

Post by ghoulsblade2 »

boarding damage model :

is there any docs on the damage model ? didn't really do fighting in vs, only saw that shields and hull have 4 sides each. would a ship be destroyed once the hull is completely breached on one of the sides ?
(if not please explain or point me to some docs =)

in escape velocity a ship would become "disabled" when reaching around 10% hull state : cannot move or shoot but boarding can be attempted once you move close and match the speed : can still fail and result in various outcome, most likely explosion of the boarded ship leading to some damage of your own vessel. i think crew size played a role there too. you could even increase chances by hiring mercs and transporting them in cargo/passenger slots.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: ogre branch ? new attempt from scratch

Post by klauss »

The only doc about the damage model is the source itself.

And I couldn't go into too much detail on how it works, because it's a mess and hard to follow.

That's why a "rewrite" is on the To-Do, and here we don't have too many buts: the damage/stats/upgrades model does none of what it's supposed to do very well. So it's free for all, anyone rewriting it, given that he caters to the needs of the various mods, can do pretty much whatever he wants.

Short answer, I think there are two protection levels: armor, and shields. Shields regenerate, armor does not (unless replaced). Both are directional, although shields aren't limited to four sides: two and eight are possibilities too. And beyond armor there's the hull, which can only be fixed with a "basic repair", it's not directional, and once it reaches 0 you blow up.

There's a mod that implemented boarding, as follows: instead of blowing up, ships get disabled (I'm not sure if you can destroy them fully by firing on disabled ships - that would be similar to EV and its 10% hull rule). When they're disabled, you can approach them and dock, even if they're hostile (normally, you can't dock with hostile ships). There you get access to their "base interface" (as regular capships), but everything's for "0 credits" - ie: up for grabs. It's like plundering the ship.

That mod makes it so that time does still run while docked, so it's... weird. But nicely done, I mean, it's interesting from a gameplay standpoint, if not limited to just plundering ships.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
ghoulsblade2
Bounty Hunter
Bounty Hunter
Posts: 136
Joined: Tue Jul 27, 2010 7:41 pm
Location: germany
Contact:

Re: ogre branch ? new attempt from scratch

Post by ghoulsblade2 »

initial project setup working, not much so far, only a spinning llama (with only base texture, no bump etc) and a skybox.
possibly interesting : i rendered stars as (slightly colored) dots onto it, i think it looks far crisper than embedding them into the skybox image, which usually results in annoying artefacts even at high resolutions.
You do not have the required permissions to view the files attached to this post.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: ogre branch ? new attempt from scratch

Post by klauss »

ghoulsblade2 wrote:initial project setup working, not much so far, only a spinning llama (with only base texture, no bump etc) and a skybox.
You did notice the llama has all flat faces... right?
ghoulsblade2 wrote:possibly interesting : i rendered stars as (slightly colored) dots onto it, i think it looks far crisper than embedding them into the skybox image, which usually results in annoying artefacts even at high resolutions.
Ya, VS does this too. Only they're small speckles and people found it too un-busy, so they added them on the skybox (I'm guessing, it so appears). I find it distasteful, but what can one do? Producing skyboxes is out of my skill set.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
ghoulsblade2
Bounty Hunter
Bounty Hunter
Posts: 136
Joined: Tue Jul 27, 2010 7:41 pm
Location: germany
Contact:

Re: ogre branch ? new attempt from scratch

Post by ghoulsblade2 »

klauss wrote:You did notice the llama has all flat faces... right?
yep, so much for easy exporting from bfxm to something useful *sigh* i DID check the "smooth group" on the importer in blender, but no idea if that data was even in the .obj file.
are you sure the original llama has smoothing ?
any other ideas how to get the models into a better format without loosing smoothing groups / normals ?

simply autosmoothing the whole model looks like this:
You do not have the required permissions to view the files attached to this post.
ghoulsblade2
Bounty Hunter
Bounty Hunter
Posts: 136
Joined: Tue Jul 27, 2010 7:41 pm
Location: germany
Contact:

Re: ogre branch ? new attempt from scratch

Post by ghoulsblade2 »

first programmer-art icon thingies, not draggable yet, but you can see a bit what i have in mind i hope =)
how many and what kind of slots does the llama have ? where can i find such info in data?
You do not have the required permissions to view the files attached to this post.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: ogre branch ? new attempt from scratch

Post by klauss »

units.csv

It's hard to read, but it's where you have to look.

That, or fire up VS and look in the upgrade interface ;)
(but you'll miss hardpoint locations and such)
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
Post Reply