Code [][]

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 ...

It's been a few months, but I finally figured out how I've been misusing node and the mongodb JS plugin.

Essentially it's my PHP background to blame, where every new request to the server is exactly that - a new request - and everything has to be reinitialized anew.

Instead, node is a true server - it runs, maintains state, and waits for new input, be it a page request or ... something else. As such, it is not necessary to reinitialize the database, the connections, and most importantly the data collection that mongo maintains. Instead you run new finds/saves against a collection that's already loaded - much faster, seems to me.

Initially the mongo allowed these repeated loads and I'm sure the performance suffered; but at some point, the plugin author decided to stop the madness and simply started throwing errors when repeated (and redundant) connections to an already open DB were requested. I didn't really have the headspace to grok this until now, and I freely admit it's much more elegant to well, behave as node expects. Hopefully that means more updates, on the bloggy at least. DCSB will still have to wait. :)

A bit of utility work this weekend.

First, made sure ranged combat no longer ignored walls. In addition, I started a bit of work to eliminate the test code that simply threw new weapons all the time - I might reuse this as a spell at some point "Throw Illusionary Weapon", ha! but for now I want to stay firmly within the physical. So, creatures will only throw something if they actually have it in the inventory. AMAZING!

Next, I noticed I wasn't getting the info on mouse click anymore. I fairly quickly realized that the scrolling camera was at fault - I was getting absolute screen X,Y position, not world X,Y position. I added the current camera offset - seems to be working. I also added creature behavioral info to status clicks for debug purposes.

Finally, I started working on implementing some skills now that the skill overhaul is complete. Something is certainly happening, but ... I don't think it's what I want. For example, I have yet to see the goblin throw anything (maybe he's not picking it up fast enough and other critters beat him to it?), and the bat rather than move twice as fast moves ... HALF as fast. It will be interesting to discover why that is, but at least the skills seem to be processing properly using the new action counter (game doesn't hang like it did prior).

So, some progress. A bit of it backwards, but the problems are actually quite revelatory to me, so I'm pretty happy. I think I need more vacations. :)