Code [][] XMLhttp://www.codesquares.comCode[][]en-us UI do-over
"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!]]>
Marcin MThu, 05 Feb 2015 05:56:15 GMT compartment now functional.
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.]]>
Marcin MThu, 21 Aug 2014 06:48:44 GMT log and crew UI
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]]>
Marcin MFri, 20 Jun 2014 04:06:18 GMT!
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.]]>
Marcin MThu, 05 Jun 2014 22:30:28 GMT
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]]>
Marcin MSat, 17 May 2014 18:08:54 GMT with real movement
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!]]>
Marcin MFri, 16 May 2014 16:51:40 GMT's start with this.
Marcin MThu, 08 May 2014 18:23:37 GMT MThu, 08 May 2014 06:44:40 GMT! I fix it!
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. :)]]>
Marcin MTue, 21 Aug 2012 04:51:40 GMT combat, specials and info
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. :)]]>
Marcin MSun, 08 Apr 2012 23:54:27 GMT