Tag[][]: gamedev

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

Removed NPC game object from game. Added NPC prefab into the game and instantiated it twice, each time with random starting location, speed and direction, so that's progress. Next, infinite spawns! And convoy code brainstorming. :)

I'm also still tossing around ideas for movement and changing perspective and such. On one hand I want to provide a large playing area, large enough to set up real-feeling torpedo runs (say 5km or less) and ambushes, but on the other hand I don't want the player to be moving a dot in order to fire a dot at a dot. While it would certainly work it lacks that certain something ... Of course if I can figure out how to zoom and move the camera that problem is pretty well solved. Hmm. Now there's a thought.

Next up is figuring out how to instantiate them beyond the boundary of the game, but still have them coming into the frame of the game. I already know what I need to do (pick random angle of approach that's defined by the lines going from NPC ship to the two farthest camera frame corners) but translating that into Unity-ese will take some research.

The above all assumes scenario-based gameplay. The larger meta game where things like plotting the intercept course and receiving messages about possible contacts will happen much, much later. I need to get this close-ranged (well, relatively, we're still talking a maximum of 40km X 40km) combat done first.

Also brainstormed a bunch of stats on the various entities (ships) in the game. Looks like there'll be about 10 different ones, broadly broken up into small merchants, large merchants, small combat ships and large combat ships, each set having 1-2 ships with slightly different starting stats to keep things interesting.

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!

I am 3D modeling MASTER. Next challenge!

.

Time to start working on something again ...