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.
Sat, 17 May 2014 18:08:54 GMTPHYSICS
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!
Thu, 08 May 2014 06:44:40 GMTBEGIN
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. :)
I realized I haven't put up ... well, anything lately so here's a small dev update and a couple of screens.
First, my ghetto starting screen. It works - and yes, the player class loads from XML with its own stats and graphic - but that's about all I can say for it. :)
Second, range-finding. The goblin started out far to the left, and the bat started out below. The goblin searches for things nearby to hurl things at, and then doesn't because there are walls in the way. :)
I also revamped skills to allow them to be more atomic. A skill can now modify the amount of times skills are processed without breaking itself, for example. This is useful for creatures with special abilities such as double move, double throw, double spell, or potions of speed that allow any move or skill to be performed an additional time. So yes, stacking items of speed is now effectively in the game ... for NPCs at least. Player skills are another story.
Kinda fell by the wayside. I'll attempt to remedy the remaining 23 days (HAHA) into some sort of cohesive entry here. Of most interest to me are Trades (Day 11), for the simplified dungeonkeepering that you'll eventually do, Weapons (14) because well, you know, Politics/Officials (16) to shed a bit of light on why you'll find certain features in the world, Legends (26) for some sort of persistence layer, and that's probably it. I am torn between wanting to spend more time on the creative aspect of the thing and time constraints that say I better focus on the immediately game-affecting components first.
This world is relatively high in magic and low in mechanical invention. As such, you are far more likely to encounter alchemists' workshops and supplies, rune tables and crystal cutters, imbued scrolls and dimensional portals than hacksaws, chisels and anvils. It is rumoured some far off cultures have mastered metals to rival the best enchanted steel, but since the latter is far easier to get a hold of, these weapons are mostly curios. You will find basic weapons and armor - hardly more than slabs of raw metal or strips of leather - easy to come by; from there, you'll apply magical and alchemical processes to them to make them into something more to your liking. Everyone (dungeon inhabitants and questers alike) picks up a bit of this, and you'll be able to improve your skills along the way.
Because of this magic-inclined world, weapons don't really tend to have a lot of variety. Everyone starts off with a set of simple items and then uses this common, easily findable (well, relatively speaking) magic to make something they like. The downside is that you won't be able to use too many more fancy items that you'll find, as they will be tailored to the user and thus unsuitable for you. Again, there will be exceptions to this rule but they will be more curious and oddities - you'll also find lots more raw blanks/crude forms in various shapes and sizes early on that you'll be able to use and commit to for evolution throughout the game.
I wrote a bit about this in the overview, but the world's high magic field means that exerting control over any larger area is nearly impossible. Large amounts of warlords of various alignments and agendas eke out carefully balanced existences in areas close to their powerbases; the wilderness teems with powerful monsters of all sorts that only grudgingly give way to mighty heroes; the balance of power is maintained by the need to defend from all sides and threats. This is also why your adventure changes halfway through, as nature abhors a vacuum and once you get rid of your boss you need to assume new management immediately or face your own crushing. :) Organized warfare as such is nonexistent, as every warlord spends a significant portion of their day just dealing with whatever crisis is on their doorstep and has barely enough left for their own agenda.
Some heroes or warlords (or their minions, natch) grow in stature with time. Their deeds are recorded where they fell (tombstones), where they rose to power (items in their keeps/lairs), or verbally (still working on this one. Random barks here and there? I'm not sure yet). I will definitely try to incorporate larger victories or simply longer-than-standard lives of players into the game in some way. I should create a legends.xml right away, now that I think about it. TODO!