Tag[][]: unity

Threw out the old +/- crewmember transfer UI, and am going to go back to my original plan of having actual crewmans (well just cubes because art is hard) walk around an actual sub (well again, cube-like layout because art). New build is up.

"Sub" shape from SketchUp (export with two walls!), crewman square click-to-go script currently disabled for debugging. It worked on-screen but doesn't work anymore now that it's in the reference frame of the sub. That's next.

I have great ideas for the sub interior now that it's 3D. I can do lighting, and light up segments based on status and crewed status. I can have them run forward when crash diving. I can have compartments go dark/dim when damaged, and turn red for nighttime lighting. Maybe add a trail or swaying motion when under weigh. :) Anyway, lots of work to do just to get the little dudes walking around. Next!

Reloading, 4 tubes, all that jazz. I intentionally overcomplicated it so that the compartments are easy to redefine so that if I ever get to the point where you can upgrade (or downgrade) boats, it should be possible to reset torpedo configuration easily.

Not that the rest of the game supports that at the moment since the boat mass and torque are hardcoded ... welp. Perhaps I can start looking into the future now. :)



I need to be sure I'm decreasing reload time more specifically rather than just "first found empty tube", but that's the biggest puzzle at the moment. Then, next thing which I think might be sonar - underwater ship detection, that is.

Things are starting to come together, slowly. I have the basics of crew UI, scaled down from the original over ambitious attempt to emulate FTL or Sub Commander. At some point the abstraction of manned compartments may become something more but right now I don't fully feel that is the core of my game.

I guess the sub is the star of my game, not the crew. FTL it's definitely the crew; Sub Commander straddles the line (well, the sub is more like the antihero in that one!); I want to tilt it more towards the sub, a la the SH games. You have to take care of it by keeping it fed with crew in the right places (be it stations or repairs) with the right actions, and ultimately deliver it to be in the right place to deliver the killing blow. As one does.

Is it just me, or does c# have too many storage datatypes? :P

I have successfully replaced ALL of my initial fumblings with velocity and rotation with their appropriate physical replacements, AddRelativeForce and AddRelativeTorque.

For demonstration purposes I left values intentionally high - you can see how the boat responds to changes of direction, preserving inertia and all that jazz. It's pretty slick! I now make no direct references to direction or speed at all - just tweak the forces applied and report on the results.

Unity also makes it easy to access variables while the game is running, so I'll be messing with the exact values for drag, angular drag and force applied to make the boat feel like an actual boat.

Next, some other random entities on the ocean. After that, torpedoes.

Then I can start brainstorming the boat UI. At some point I'll have to switch the controls so you can't turn or accelerate directly - instead you'll set speeds and headings and your crew will do the rest. IF THEY CAN. :D

The series of tutorials I'm watching sets velocity directly on the object - the script reference on Unity's homepage says to not do that. Hmm... :)

The difference I suspect lies in whether you are making something arcadey or something vaguely based on the physical world - if you want physical interactions you have to obey certain rules so that the physics knows how to react. If you set the velocity on an object directly it's somewhat akin to magic - objects don't just gain speed from nowhere.

I suspect I'm going to have to investigate the AddForce function, which will properly give me acceleration and eventually velocity, if I want to do this right (I do, since feel is a huge part of driving something huge through water). That's how you actually achieve a velocity - by applying a force against countering drag and inertia.

But that's for later. First I must try and figure out how to rotate the ship. I suspect that, again, using "rotation" is a no-no - I have to AddTorque instead and let the physical body of the sub be affected by it.

In conclusion: more tutorials!

Time to start working on something again ...