Sim:WTF/Blog

When I was setting aside my Java code for the single-player Fleet Action Imminent, 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 were the first to feature my use of voice-over-IP, but never got very naval. I did not enjoy working in these environments. I got much more working in JME3, but this did not seem like the place to be, either, as I would have to create my own ocean and sky environment.

I changed to working in Unity3D, and things have been much better. With demonstrable networking in place, I consider the present work to be a prototype of With the Fleet. This blog covers progress from FAI on JME3 (2011-2014) through WTF on Unity (2014-to date).

Developer Blog

19 November, 2020

Searchlight in action, November 2020

Wireless Telegraphy works, but is not complete, really. Message forms look great, but need to be properly networked.

Searchlight works nicely in AI or player use. Added navigation lights and lights in the deckhouse and galley, worked by toggle switches.

Kronnect's Volumetric Lights asset looks nice.

9 September, 2020

Am working on getting the Wireless Telegraphy working again. I think I have just gotten it so that players can communicate with players. I need to get AI sailors working, as well, and also tie it in to the use of message blanks, as I think it will be unreliable to have players dictate messages to be sent by wireless. I'd rather have them fill out a blank and hand it to the signals person.

As a gratuitous "call out", I will note that Scrawk's Ocean, which he has essentially open-sourced as he found supporting his users overwhelming, is the only asset I am still using that I was using five years ago. It's a great resource. I wish he'd come back and offer it a little time. Still, though -- it is an amazing value.

6 September, 2020

Recent fixes:

• Refined UI for items such as sightsetting and torpedo director. Of course, more work is needed
• Audio propagation is limited to about 10-12m range.
• Adjustable control "runaway" should be fixed, except in some cases where a down/up (or up/down) may occur in the same frame
• AI gun layers now level the gun when far off in training
• Searchlights work, and their on/off is networked

Bugs:

• islands don't appear until someone has set foot upon them

TODO:

• allow doors (and later, hatches) to open/close
• add diagnostic code to study occasionally terrible speech recognition results
• add Revolution Telegraphs and improve propulsion system simulation
• improve asset appearance and performance, from most crucial to least:
  • compass
  • engine telegraph
  • 4-in gun
  • cursor
• make 12-pdr guns workable

27 August, 2020

Recent fixes:

• Addressed input issues
• Weather looks better now – further improvement can be largely deferred
• Arjen is slowly improving the Torpedo Director asset

Bugs:

• islands don't appear until someone has set foot upon them
• some adjustable items (e.g., gun elevation) might "run away" when under user control
• AI gunlayers choose odd elevations when gun not "on" in training

TODO:

• allow doors (and later, hatches) to open/close
• limit AI sailors hearing ability – everyone on the ship hears your commands
• add diagnostic code to study occasionally terrible speech recognition results
• add Revolution Telegraphs and improve propulsion system simulation
• improve asset appearance and performance, from most crucial to least:
  • compass
  • engine telegraph
  • 4-in gun
  • cursor
• make 12-pdr guns workable

24 August, 2020

Recent fixes:

• my old deck walking system replaced by simpler logic that permits guns and other shipboard objects to block the player from walking through them
• created a simple ship test bed from Arjen's WalkingDeckTest
• when the player is performing a duty, he maintains the proper position and rotation, but can crane his neck to look around somewhat
• join Player/AI control of a gun is certainly achievable now
• FIXED "Player-sailors who take on a shipboard role (e.g., gun layer) appear in a wrong position on other playerclients, rather than stepping into the suitable spot"
• FIXED Networked data such as a gun's training angle, when received the first time at a playerclient, cause an animated transition to that angle on player client, rather than an immediate positioning of the gun
• FIXED precipitation effect was broke
• made ship's wheel look more wood-like

Bugs:

• islands don't appear until someone has set foot upon them.

Niceties TODO:

• improve 3D asset appearance and performance
• tune the weather system effects -- it looks pretty bad

14 August, 2020

Working on it again with Arjen "Husky" as a volunteer tester/modeler/second brain.

Recent fixes:

• speech recognition of full command set works on Windows
• a different key is used to speak a command, helping keep player chit chat from causing AI sailors to interpret it as commands
• using Unity Collaborate to ease builds for the team
• compatible with Unity 2020.1.f1 and latest Ceto ocean
• telescope mask was not scaling
• window sizes, server address, username are persistently saved

Priorities: increase stability of the code, and allow a human/AI crew to jointly work a 4-in gun in action against another destroyer.

Niceties: improve 3D asset appearance, improve tuning of the weather system

Bugs:

• Player-sailors who take on a shipboard role (e.g., gun layer) appear in a wrong position on other playerclients, rather than stepping into the suitable spot
• islands don't appear until someone has set foot upon them. This has to do with scoping and their data (which is essentially none, anyway)
• Networked data such as a gun's training angle, when received the first time at a playerclient, cause an animated transition to that angle on player client, rather than an immediate positioning of the gun

17 March, 2019

Basic gunnery is now working in networked fashion in faithful simulation of the Range Tables of 1910 for the 4-in Mark VIII gun firing a 3 CRH shell. I got away without building the "proving ground" scene. Instead, the range tables are actually compiled as the sim starts up, with a simulated series of shots being taken in about 0.1 second so that a drag coefficient can be calculated such that the researched performance data will be replicated in the game. It is perhaps the best part of my coding so far.

I can fire a shell on one ship on one computer, and watch the shell fly out and splash near the target ship. A second playerclient for a sailor on THAT ship's deck sees and hears the shell splash down in just the right fashion. TADA!

My next priority is fixing bugs and smoothing out the networking code so the ships move fluidly.

3 March, 2019

I have recoil, gun blast and shell splashes functioning for the 4-in gun. The shell splash is a bit diaphanous and perhaps texture-heavy. Good enough as a start? I sort of preferred my old "upward spout of white cubes" modeling of old revisions.

The gunsight works nicely now. I have modeled, to some degree, charges, shells and breech operation. I am trying to avoid networking them, but think it will make sense in the long term, to ensure everyone sees gun drill performed in a consistent manner.

I am working toward having the 4-in gun fire in a networked fashion. When you pull the trigger, the gun recoils and puffs smoke on both your player client and the ship node. Likewise, I think all players will see the same training and elevation of guns on their own ship and others neaby. I have some degree of regret at my complex architecture (PlayerClient/ShipeNode/WorldServer), but know much of my code can help speed any future refactoring.

I noticed that my PID control loops for the AI layers and trainers was not working. I have other, less general logic working fine for now, but I'd like to get that up and going.

Greatest point of dissatisfaction? Smoothness of animation across the network. I am not sure how much is a consequence of my typical run-time test of everything running on one computer, and how much is attributable to my inexperience in networked game design.

Next up: a separate "proving ground" scene in which guns will fire shells experimentally to calculate drag coefficients that match researched real-world weapon system performance and then to create virtual range table data by which accurate simulated gunsights can be "built".

19 February, 2019

• I have the Layer and Trainer AI working with PID loops guiding their efforts to place crosshairs on the target.
• I have the sight fully working with a solid bug in how deflection is tied in and it still lacks Rangetable data
• the telescopes now work with proper magnification
• I did some reading up on 4-in gun drill, but there is just too much to do. I did, however, add some logic for loading shells and charges. I keep some of the loading aspects of the gun work abstract

11 February, 2019

• I have the AI Helmsman working well enough for now.
• You can click on another ship to declare it as the target for the AI crew
• I have started work on the 4-in gun
  • it can elevate and traverse
  • the gunsight works in Deflection; range will have to wait for the Rangetable data to be made ready.
  • UI for Layer, Trainer and Sightsetter is demonstrable, but lacks mouse support for Layer and Trainer.
  • The telescopes work with some bugs
  • The AI Trainer can turn the gun around and track a target or honour a command such as "train green 60"
  • The AI Layer can take his position, but doesn't do anything yet
  • The AI Sightsetter can set his sight for deflection and range upon verbal or typed commands

In approximate order, I intend next to:

• fix the bugs mentioned above
• get the AI Layer working
• get the sight working with range-to-elevation data and proper scope angles
• make an AI Loader

Further off:

• network gunmount training and gun elevation angles between ships, so you see accurately what other ships are doing
• simulate and network shellfire -- this encompasses a lot, and will take considerable time

22 January, 2019

Wonders never cease: I discover that speech recognition indeed works on Windows. I had mis-remembered that, apparently.

Here is a recent video.

<video id="yMzODW5GCHU" height="450" width="800" desc="Gameplay vision and destroyer model critique" frame="true" position="center"/>

January, 2019

I have dusted off the demo and polished it up a bit and re-invigorated the "Naval Simulation on Unity" Slack. The app is still comprised of a couple of destroyers steaming about a world with a few islands. Its primary subcomponents include:

• Opus codec for VOIP. I can't imagine changing from this. It is solid and sufficient
• Enviro for sky and weather -- much better looking than Tenkoku
• World Political Map 2D - a 2D world map
• Ceto (Scrawk's) Ocean -- now deprecated. Possible replacement: Community Ocean "Next Gen"?
• SREC for speech recognition. This is a placeholder; it is poor at rejecting noise and supports only US English. Replacing it would cost "multiple dollars".
• Networking is hand-rolled atop Pnet2/Lidgren. Perhaps I should look at Blackwake or similar.

I still lack talented artists and a coder. Contact me if you like the vision and feel you can help.

September 20, 2016

I tossed out UFPS. I hated that code.

An AI helmsman can steer the destroyer when given commands. It looks pretty stable and demonstrable now, for what it is. I notice that the ShipNode locks up if the destroyer attempts to move in reverse. Puzzling!

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 incredibly 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.
• World Political Map 2D - 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.

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.

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.

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:

• UFPS for First-person camera and control.
• Forge Networking for multiplayer
• Silverlining for a good sky/weather system
• Ceto (Scrawk's) Ocean -- a phenomenal and cheap ocean.
• WorldComposer and TerrainComposer (a love-hate thing here)

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.

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.

September, 2015

Unity3D continues to be a difficult tool for me.

August, 2015

Back working on Unity. I've licensed some third-party components to work with:

• UFPS for First-person camera and control
• Forge Networking for multiplayer
• Silverlining for a good sky/weather system

I may also license

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

July, 2014

Looking again at Unity3D, not sure I like 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)? A nit, I know, but ... ayiyi.

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.

2013

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

<video id="UknqrX89T_w" height="450" width="800" desc="New hydrodynamics" frame="true" position="center"/>

2012

The battlecruiser is up and running on JME3. 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!

• Rangetaker (w/telaupad to Main network and nine-foot coincidence rangefinder)
• Two Torpedo Director Pattern 2006s

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!

2011

I have converted FAI to run on JME3 (Java Monkey Engine). Portions are working, especially the destroyers.

<video id="mUofK0auqGI" height="300" width="400" desc="4-in gun fire" frame="true" position="center"/>

Outstanding Issues Oct 2022

• message pad in the Wireless office is not properly networked. Characters received before you board are not depicted.
• No damage model in place for shells – just hitbox detection; first step is simple hit reporting and scoring
• torpedoes, on the other hand, will cause the target to rapidly flood and sink
• speech recognition is prone to false positives; may have to have a less graceful means of indicating a command will be spoken vs simple idle chat