Sim:Main Page

From The Dreadnought Project
Revision as of 14:08, 2 August 2016 by Tone (Talk | contribs)

Jump to: navigation, search
SimBattleshipUnderFire 512.jpg
SimFireControlMechanism 512.jpg

In 2002-2006, I created a simulation I called Fleet Action Imminent. I hoped to then create a massively multiplayer game called With the Fleet, but except for a few prototypes, WTF never got very far before I set it aside for other pursuits — notably, this wiki. But that doesn't mean the end.

Fleet Action Imminent

FAI was written in Java, and delivered a Spartan 3D interactive environment using an extinct, Windows-only 3D plug-in. It delivered low frame-rates and a dated appearance, but these were not a barrier to what I wanted to focus on: creating a realistic simulation of the ships, duties and mechanisms of fire control.

FAI embodied realistic ballistics and implementations of 20+ distinct AI behaviours for sailors with different shipboard duties, manning a virtual Dreyer table, wireless transmitter, many data transmitters and receivers, Vickers director, coincidence rangefinders, dumaresqs, etc, etc. It was fairly glorious.

I toyed with the idea of tearing out Wildtangent in favour of jMonkeyEngine, but didn't proceed with it, as the FAI architecture was unlikely to ever deliver me the massively multiplayer experience I felt was necessary to achieve my broadest vision. This does not mean that I would not permit a talented and motivated hacker from trying to achieve this.

One limited fruit of the switch to using jMonkeyEngine was that I took out the ballistics code into an application called Blammo that creates very accurate HTML range tables for simulated weapons based on very little input data. I may eventually release Blammo.

With the Fleet

When I was setting aside FAI's Java code, I made a few prototypes of the proper game I wanted to create. The first was based in Torque Game Engine, and the second built atop Ogre3D. The prototypes had some innovative features I won't divulge, but never got very naval. I sorely needed a better coder than myself to get where I was going.

I since have looked at Unity3D, which tries to be easy to use but is harder to understand than a C++ game engine... how did they do that?

Developer Blog


Converted the sim to run on JME3. Portions are working, especially the destroyers.

4-in gun fire


The battlecruiser up and running. The wireless systems work, the Dreyer tables and rangefinders. A good many bugs, but some shooting is possible.

Some parts I am leaving for later:

  • the ShipsLogPlayback app is in real disrepair. If it comes back, it will be in Java2D
  • particle effects of gunfire and shell splashes leaves much to be desired
  • flags don't work very well (native physic libraries would help)
  • some of my secret features are shelved for now
  • multiplayer
  • PC compatibility was demonstrated briefly and lost. I hate Windows like mad.

Right now, the following stuff works:

Fore Top accessible by magic portal on gundeck
  • Range Officer (w/ telaupad to Top network)
  • Spotter (w/ telaupad to Top network)
  • Voicepipe to Conn
Director Platform accessible by magic portal on gundeck
  • Vickers Light Aloft director manned by
  • Phone Man (w/ telaupad to Top network)
  • Sightsetter
  • Director Layer
  • Director Trainer
Transmitting Station accessible by magic portal on gundeck
  • TS Officer
  • Top Talker (w/ telaupad to Top network)
  • Main Talker (w/ telaupad to Main network)
  • Dreyer Table Mark III (c1918 sans Wind Dumaresq), manned by
  • Range Plotter (w/ six overhead single range receivers, two functioning)
  • Bearing Plotter
  • Range Tuner
  • Spotting Corrector
  • Dumaresq Operator
  • Totaliser Operator
  • Range Master Transmitter w/operator
  • Deflection Master Transmitter w/operator
  • Bearing Transmitter w/operator
  • Gun Ready Board with Fire push
Conning Tower accessible by hatch to signal deck
  • Captain
  • Helmsman
  • Voicepipe to Fore Top
  • Captain's Cease Fire push
Gun Control Tower accessible by hatch on its top
  • Rangetaker (w/telaupad to Main network and nine-foot coincidence rangefinder)
  • Gunnery Officer (with bearing and rate transmitters)
  • placeholder sailor
  • placeholder sailor
Torpedo Control Tower accessible by hatch if you trek back there!
Signal Deck
  • Semaphore Signaller (partly functional)
  • Flag Signaller (broken)
Four Twin 13.5-in Turrets, each with
  • Officer of Quarters
  • Turret Talker (w/ telaupad to Main network)
  • Two loaders (abstractly representing the entire loading process)
  • Two gun layers with elevation receivers, controls for elevating gun, sighting scopes and triggers
  • Turret trainer with 2 telescopes and trainer's switch, controls for training the turret
  • Turret Director Trainer with training receiver
  • Four sightsetters
  • a few miscellaneous receivers

Marsden Samuel helped me with some art. I set him up with what I hope is a runnable WIndows version of my sim so he can walk around the Queen Mary and see whether textures are right or wrong, and check on geometry, etc. It's encouraging to consider someone other than me running my sim!


I worked some with Marsden and with Arjen on various aspects of the sim, but work abated.

New hydrodynamics

June, 2014

I spent some time looking at licensed libraries to improve the hydrodynamic and environmental appeal of the work, but the JME3 developers say that they really cannot support middleware of this type. I'm thoroughly sick of JME3 now. The developers seem content to have cameras that are handled differently than any other Spatial object in their system, and their lack of understanding that this would be the simplest way to treat them is reflected in the fact that the object they provide to tie them to a spatial within their system presumes, oddly, that the camera will control the spatial rather than the other way around (which would HALVE the complexity of this part of the code), and the camera faces BACKWARD when it is set up. This is the sort of usability that gives me hives.

July, 2014

Looking again at Unity, still hating it. They have some nice videos to show you the ropes now, but they persist in some bad usability stuff. An example: there is a "play mode/edit mode" dichotomy that can cause your work to be silently discarded if it is done in the play mode, and the graphical control buttons for this ignore standards of usability that have existed since VCRs and tape recorders. When in PLAY mode, there is a lit PLAY delta pointing to the right. Why is this not an unlit STOP icon (the block known around the world)?

There is no way to see, when a geometry in the scene is selected, its extents on the current scaling.

The free boat model in their asset store has a keel, beam, and draft unaligned with X,Y,Z. It is a fairly model, but they should not accept such submissions.

August, 2015

Back working at Unity. I've licensed some very commendable components to work with:

I may also license

  • Triton for ocean modeling, but that will also require that I spring for Unity Pro

September, 2015

Unity3D continues to be a difficult tool for me.

November 28, 2015

I have posted a tech demo that runs on OS X and on WIndows to show to the development team. The content is essentially a stripped-down H.M.S. Acheron model -- a good place to start.

Its best features are a very realistic ocean asset, a very nice weather/sky system, and some rudimentary deck walking behavior.

December 17, 2015

I have started to bring some networking into play. There are deck walking bugs that cause outrageous capsizing of the ship you are on, and the halyards also go unstable at times. However, the weather system is synchronized and two sailors can walk the deck of the same ship, poorly. Main deck, foredeck and bridge are walkable. Much fixing to do.

The main components are now:

Components I found to be near-misses were:

  • ActionController/MotionController - very well done and superbly documented, but seemingly not up to deck-walking
  • Unistorm - nice precipitation effects, but atrocious API and most clouds inferior to Silverlining's. May go back and bring in the precipitation stuff later.

January 12, 2016

I posted a single-player build that has addressed deck-walking issues in which the sailor could cause his own ship to capsize.

I've done some testing of networking with Forge and with the Lidgren Library. In the first case, I got a client to join the server, producing two "sailors" who could roam the deck (very poorly). The sea and weather were also synchronized.

I consider UFPS and Forge to now be in the "iffy" category. I find both to be complex, and Forge has mission drift and "small game" fixation.

January 28, 2016

I posted another demo with limited multiplayer function... embarrassing, really, but...

You can launch as server if you simply want single player mode. If you wish, however, a second user can join the first player if he wishes as a client.

You cannot do anything more than observe woeful implementation of networking I tested to evaluate Forge (ships, sailors, sea, weather, time of day) and Lidgren (chat).

User interface cheat sheet:

  • left Apple/Windows key == show mouse
  • right click to squint
  • WASD to move (shift == go faster)
  • space jumps
  • \ cycles chat window size (small, large, none)
  • / opens the chat composer -- escape to cancel or enter to send

You can jump overboard if you wish... you will randomly be respawned on one of the three destroyers.

There is no means of controlling the destroyers.

August 2, 2016

I've been working on the sim. It is now a multiplayer-only sim and has just a little stuff to demonstrate.

The main components are now:

  • UFPS for First-person camera and control. I hope to toss this, as it is too complex.
  • Lidgren for networking. I tossed out Forge, which was poorly documented and not designed for flexible use
  • Tenkoku for sky, sun and weather
  • Ceto (Scrawk's) Ocean -- a phenomenal and cheap ocean.
  • a very nice 2D world map asset

I hope to soon show it to people who might be able to help me take it to the next level, such as a 3D modeler, etc.

The WorldServer has a GUI for setting the locale and weather conditions, and these data propagate to the ShipNodes and PlayerClients.

You can control the destroyers by a simple placeholder GUI on their ShipNode. Multiple sailors can spawn aboard the ships or an island and chat and walk about.

It has some novel features I want to keep secret for now.

My next step is to get an AI sailor working a helm and engine telegraph, and to allow the players to also use these items. This will replace, of course, the GUI for these items on the ShipNode.

See Also