FC Forums

Right, hammer is descending. If you wish to continue your arguments, please do so via PM.

Anyone else? Did we already give up?

I need a list of voice lines to make those. Idk what Tiel is doing. Just keep bumping it if need be, make sure people are constantly annoyed by the yellow wording in this area.

Going to make a short song thing over the weekend, I got this.

Will do, ACH.

@Fen: Good, I think right now design should take priority so ACH and everyone else has some direction. This weekend might be the best time to get a group together and actually discuss. It shouldnt take too long, so you'll have time to do whatever else. I'll ask around to see when everyone's available.

I'm free this Friday through next Wednesday, but my father seems set on deconstructing my car so that might change.

One of the caveats of the engine is the ability to apply techniques such as normal mapping and specular to a mesh - this allows more versatility in the creation of models and textures. Specular in itself could be summarized as the ability to specify how a material will react to lights when rendered. Both it and normal mapping are pretty neat since they allow stuff like this

Adding details without having to modify the mesh itself allows a more conservative mindset during initial modelling. It's a simple matter to make lo-poly, efficient topology and add in finer details (ie greebling) later on with normal mapping. Conversely, it's also entirely feasible to create a higher-poly model and, in a process known as baking, simplify a model's mesh while rendering such aesthetics to a normal map image. Either way you go, the way this works is that the image essentially tricks the renderer into believing there is geometry where there isn't; the distortions in a polygon's normals (basically lighting & facing information) creating the illusion that maybe there is something hidden down there when combined with a complementary diffuse.



This isn't really anything revolutionary, but it's something possible in the project that wasn't before so figured it worth sharing. My time as of late has been split figuring out this engine's implementation of the aforementioned techniques and drawing up this design doc as a means of collating the various features I want to make some progress towards before a public release. So far I've coded a means to select a unit and 'order' it to navigate to a point in the scene using an AI class; when I find the time to delve a bit deeper and get more done I'll make a video.

For the timebeing all I can suggest is arguing about what's in the doc and what could be added; unless you have a set of current skills such as drawing or modeling that may prove more immediately relevant, in which case, do share.

Doc seems pretty solid. if factions ever come up in relation to all of that, I vote Fenway decides.

My only issue is that you don't seem to have any sort of plan for fuel storage. Did I just miss it, or is there going to be a hard cap? I'd suggest tanker vessels which come are warped in dry, or perhaps depot stations which can increase cap. If it's possible, an interesting mechanic would be to make fuel realistic in dispersal; a ship would have to be near the mining outpost or other fuel source to receive fuel, rather than just your fuel income being autodispersed

ACH0225 wrote:If it's possible, an interesting mechanic would be to make fuel realistic in dispersal; a ship would have to be near the mining outpost or other fuel source to receive fuel, rather than just your fuel income being autodispersed

Good in theory, but increases micromanagement too much in execution. The way I'm picturing the algorithm is more like

on tick
if ship1.shipmoving true
decrement fuel pool (shipmoving_cost)

rather than attempting to create a fuel variable for every consuming object present. It wouldn't be terribly difficult codewise, and perhaps 'hardcore mode' could be a thing later on, but for now I'd just like to keep it simple stupid.

Fuel storage; I wasn't really thinking a hard cap would be entirely necessary given the nature as a consumable. In all honesty I found the silo mechanic annoying in C&C, but I can see the viability of such a mechanic here. An artificial limit on how much stuff one can viably field, seeing as everything constantly draws from the pool. Food for thought.

Looks good so far.

On the note of units, I'd suggest adding the following:

Destroyer (anti-frigate)
Cruiser (general purpose)
Missile Cruiser (anti-everything-larger-than-a-frigate)
Battlecruiser (anti-capital ship/anti-flagship)
Battleship (or similar term; heavy direct-combat vessel)
Carrier (produces fighters and corvettes, can ferry them around to reduce their fuel use)

Shipyard (builds or FTL's in all vessels except Flagship - probably immobile)
Defensive Satellite (immobile after deployment. Essentially, a stationary BFG)
Sensor Array (long-range sensor array, immobile)

Beyond that, not sure.

@ACH while refuelling and per-ship fuel stores would be interesting (á la strike craft/corvettes in Homeworld), it probably would stretch us a bit for a first release.

Well, the mechanic introduced by having to refuel from a depot or supply ship would make it so supply lines are a thing; you couldn't just launch a fuckhueg fleet straight into the enemy, you would have to make sure you have enough freighter ships and such to keep them supplied, and if they get cut off, you're screwed. No idea about the difficulty of this, but it could be an interesting option for future releases, if they happen.

I did a thing, I don't know if it's useful though.

But Who's Counting? wrote:Looks good so far.

On the note of units, I'd suggest adding the following:

Destroyer (anti-frigate)
Cruiser (general purpose)
Missile Cruiser (anti-everything-larger-than-a-frigate)
Battlecruiser (anti-capital ship/anti-flagship)
Battleship (or similar term; heavy direct-combat vessel)
Carrier (produces fighters and corvettes, can ferry them around to reduce their fuel use)

Shipyard (builds or FTL's in all vessels except Flagship - probably immobile)
Defensive Satellite (immobile after deployment. Essentially, a stationary BFG)
Sensor Array (long-range sensor array, immobile)

..?
There are no unis in the design doc. If you're referring to Ship Types that's what it says on the tin - they're more for my reference than anything on what to classes to handle in the code. Units are more or less what's there with different names; ie, a Damocles destroyer would be a member of the light capital ships class and inherit general traits thereof, with parameters being specified in its definition to differentiate it from other children.

ACH0225 wrote:Well, the mechanic introduced by having to refuel from a depot or supply ship would make it so supply lines are a thing; you couldn't just launch a fuckhueg fleet straight into the enemy, you would have to make sure you have enough freighter ships and such to keep them supplied, and if they get cut off, you're screwed. No idea about the difficulty of this, but it could be an interesting option for future releases, if they happen.

I haven't the time to point out the flaws in this at present, but supply lines aren't a thing in RTS for a reason.

@Prototype

The texture is inconsistent with the artstyle and if it's made out of boxes I'd have to convert it. If you could rectify one or the other it'd be a lot more useful.

It appears to be made out of boxes, but they are all contained within the same mesh, not sure if workable in it's current state, but I might be able to merge them. Though I might be better off just making it again from scratch, the only real advantage to this one is I know how to texture it.

Doing something slightly more useful:

?