Martin Doege wrote:
Hi Steve!Hi Martin. I'm not sure the tides issue is likely to be a "big technical challenge" actually. In the space of about 4 postings here, a workable scheme was proposed of colouring certain triangles "sea" or "mud" according to their datum heights as compared with a local simplified tideheight generator. I can provide the maths for a tideheight generator, the only "problem" is providing a suitable set of triangles (tagged with datum heights) in a known tidal area. Also, on a tile-by-tile basis, a set of (probably four) tidal vectors has to be given. The graphics engine needs to know how to do the colouring on-the-fly, but compared with the magic that the 3D experts on this project have already acheived, that'll be done in an evening as soon as someone sets out to do it! But in general naval simulations don't always need flashy graphics to be fun, so finding a good graphics engine is probably not so important at this point.I ws intimating that I don't have to find one - I've found it! Right here. :-) As with all simulations, what really makes them absorbing is the feeling of "being there", and while good graphics don't hurt, good gameplay matters more. For example, the submarine sim Red Storm Rising mostly had only tactical displays to look at that look about as boring as it gets, and yet it was an engaging game and the suspension of disbelief worked well.That's about what the current "surprise" program (windoze or linux) has. It's really just a wrapper around the "FDM" to let the "FDM" be used for something. So instead of hoping for great seascapes from FG/SimGear in the near (or not so near) future, I would first improve your existing "FDM", add the ocean, include navigation aids, etc.Stars, sun and a stopwatch. That's all you get! Ok. Ok, I'm joking of course. That's all you get in the 18th century, but if sailing ships worm their way into the FG world, they'll be usable in any timeframe. After all, tall ships are still with us in the 21st century. Cannons and a damage model should also be added since you are mentioning Hornblower. As in Sid Meier's Pirates!, the crew should also be simulated, [giant snip]Funny, you've just written almost exactly what I wrote to "The Admiral" (Peter Davis) last year. His comments were that he never planned to make a game of the sim - his sentiments in fact matched closely to those we hear all the time here on the FlightGear discussions group. It's to be an accurate sim first and foremost, but if people want to add guns/missiles etc then that's up to them. I talked about crew, crew morale etc. (I've been a pen&paper RPG-er for a long time.) Same sort of response - basically, he (Davis) is only really interested in getting the sim to work well and would be disappointed to see the project "degenerate" into "just a game". Of course, done well then there's no reason why any of the additions you mention would degenerate the project - they should be seen as enhancements. Graphics could initially be fairly minimal, perhaps isometric view or 2D.Dovetailing into FG would allow 3D models from the start. I really don't want to have to build a custom isometric or 2D graphics engine just for "surprise". This would also give you time to develop a good interface.All your points are very valid - especially this one. Unlike aircraft, saling ships don't have a single "point of control". The nearest (in 18th century parlance) is "the quarterdeck" where the master or captain issues the orders, which then have to be relayed through several layers of middlemen to the grunts who pull the ropes. There is of course a "ship's wheel" but it's not a single point of control to compare with (say) an aircraft control column. Try it with "suprise". The ship's wheel does precious little unless the ship is moving at quite a lick. It's the set of the sails (especially the spanker) that really steers the thing. I would also use a higher-level language for faster development and improved flexibility. Python comes to mind and has the advantage that the existing BASIC code should be easily converted to it and that there is Libglade and pyGlade. It is also nicely modular and its sane implementation of object orientation as well as its use of generators are definite boons for simulations. At a later point, 3D graphics could be added if desired, e.g. via PyOpenGL or using code in C/C++.The existing code isn't BASIC, it's 'C' that looks like BASIC :-) As I stated before - Davis wrote the original in BASIC and ported it to 'C' many years later. I'm looking for volunteers, me hearties! First jobs involve completing the linux version to have all the features of the windoze original. Then there's the work involved in completing the segregation of GUI code from the "FDM". Then there's work in making the new sources compile on windoze to provide the same functionality it has now, but cleanly this time. Then there's the possibility of heaving the ship FDM into FlightGear, probably mis-using a "3D cockpit" idea to provide all the controls of rudder, yard-arms and sail-setting. Following that, a 3D model of the ship to make the "view out of the cockpit" look roughly like what you'd see over the rail of the quarterdeck. If this all gets left to me, it'll be 2018 at least before I'm anywhere near it! But with interested vounteers aboard, anything is possible. Tomorrow even. PS. You might want to consider registering your Linux port of Surprise at Freshmeat.Currently, I consider it too incomplete. Also, the source code is an embarrassment! Source code is only available to people who sign a "non embarrassing disclosure" agreement :-) (Nahhh, not really. Anyway, it's GPL as you all well know. It's just *embarrassing* GPL, that's all.) Steve. |
_______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
