Weekly Update #69

Battlescape
1

Update69_Header.jpg2524×1464 1.87 MB

Hey everyone it’s time for your weekly update. This week has been more or less a continuation of the previous week. Flavien spent some time polishing up various game systems changed by the new networking code. He also put more work into our new control scheme which will be unveiled in the next patch. On my end I spent half of the week polishing up GPU memory management with the UI and some new code for benchmarking GPU rendering performance. The second half of the week I had to take care of several administrative tasks along with the fact that this weekend was the big July 4th holiday weekend here in the U.S.

service-tower.jpg1915×1920 956 KB

Pre-rendered image of the land base service tower

On the art side Kristian has completed the land base service tower, pictured above, and continues his work on the remaining sections of the land base. Jan has textured some more pieces of station, many of them are support structures that aren’t particularly exciting, while Dan continues his effort on the destroyer.

Pylons1.jpg1918×1080 342 KB

Editor shot of more WIP station materials

That’s all for this week’s update. It’s a bit of a short one due to the holiday on my end but we should have more to talk about next week.

19 Likes
2

Nice work there :slight_smile:

Any news on the estimate date of the first gameplay iterations?

5 Likes
3

Did you and @InovaeFlavien have a chat about all the control mechanics discussion that went on in Weekly Update #67?

2 Likes
4

Are you referring to the next patch?

I spoke with Flavien about keeping the current control scheme as an option as well as having a 2nd control scheme. I also mentioned we needed to apply limits to rate of rotation etc to the current control scheme depending on the ship being piloted. Aside from that he’s implementing his own ideas for controls so you’d have to ask him however I know he’s very much aware of that thread.

3 Likes
5

If I understand correctly, you’ll be releasing an Alpha version with a first playable state of gameplay. But I guess that before you release the Alpha, you may deliver some versions with “partial” gameplay (meaning with PvP and, for instance… i don’t know, with deactivated capital ships, or with only orbital stations, or…).

So my question was about an estimate of the first implementations of gameplay. It might be next patch, truth be told I’m a bit lost lately on the schedule :slight_smile:

6

Our internal schedule is currently to release the next patch sometime in August and ship the Alpha 1-2 months after that. We’ll resume gameplay iteration upon the release of the next patch.

6 Likes
7

Ok, that clarifies it, thank you for your reply :slight_smile:

1 Like
8

Have you considered making the limit max angular acceleration per ship but no limit to actual angular velocity other than death? Where if you exceed the “structural limits” of the material of the ship it breaks apart and you die.

1 Like
9

I’m implementing an interface for various input control schemes, which you’ll be able to switch in real-time during gameplay. That way we can iterate and experiment various control schemes. At the moment two are planned: the old direct control, and the new cursor-target based scheme. But more can be added easily during alpha.

21 Likes
10

Excellent! That is a great way to test what works and what doesn’t! I look forward to comparing them :smile:

4 Likes
11

AWESOMESAUCE! :smiley: :thumbsup:

4 Likes
12

Old as in ICP direct FPS? or old as in what’s currently in the pre-alpha?

13

Technically, neither. It’s based of the current pre-alpha control scheme, but with limitations on thrust. The current one in the pre-alpha is unlimited, so if you perform an ample movement with your mouse, it’ll generate a huge force for a short time, exceeding with the ship’s thruster capabilities would be able to output. It also allows users that reconfigurate their mouse sensitivity to have an advantage over people who keep the default’s.

The downside is that if you now perform an ample mouse movement, it’ll “delay” the force’s application so that each frame it does not exceed the ship’s capabilities, but over time the entire movement gets “absorbed”. Not sure if I explain myself very well :slight_smile:

Ex. Let’s assume that every single pixel moved by the mouse generates a force of 0.01g and that the ship’s max capabilities is 1g per frame.

In the old direct scheme, you would have:

  • Frame 0: 350 pixels moved -> 3.5g applied
  • Frame 1: 0 pixels moved
  • Frame 2: 50 pixels moved -> 0.5g applied
  • Frame 3: 0 pixels moved

In the new direct scheme you’d have:

  • Frame 0: 350 pixels moved -> 3.5g to apply, 1g applied, 2.5g remaining
  • Frame 1: 0 pixels moved -> 2.5g to apply, 1g applied, 1.5g remaining
  • Frame 2: 50 pixels moved -> 2g to apply, 1g applied, 1g remaining
  • Frame 3: 0 pixels moved -> 1g to apply, 1g applied, 0g remaining

In both cases the same amount of mouse pixels movement was applied every frame, and the total force over the 4 frames was the same, but in the new control scheme it was distributed over multiple frames instead of being instantly applied and exceeding the ship’s physical capabilities.

4 Likes
14

The old ICP/early prototype scheme was vastly superior. Could we have it back please? :pray:

15

In which ways do you think it was superior ? Please elaborate.

2 Likes
16

It allows for more precise and less messy movement and targeting, and feels better and more natural, while taking nothing of value from the gameplay.

Decision-wise, it is the same: the goal is almost always to point toward a specific direction (which may not be fixed, for example when leading a target).
In the old scheme, I point at a direction and the ship does its best to turn as fast as possible with the right rotation speed (or stopped rotation) when aiming there.
In the new scheme, I have to manually make it accelerate and decelerate, and it is nearly impossible to get this perfect immobile alignment, which is rather important for precise flight and targeting. The impossibility to fly perfectly straight on a specific vector is particularly infuriating.

As far as the “twitch-gameplay” challenge goes, having to manually perform rotation and compensation feels messy to me, and most of all artificial. It is not unlike having bad latency in a FPS, or the old random movement added by some games when using scope sight.
I:B should not need this extra, artificial difficulty when positioning, prediction and flight are already requiring skill to perform well. Basically, it feels like I am turning the craft instead of actually flying the craft.

I personally also find it much more natural, as it is like that that several space/air sim games I played work, in addition to being close to the ever-popular FPS scheme (which from time to time also adds inertia in aiming).
With the new system, I just feel crippled, as if I had to manually pull flap cables instead of relying on a fly-by-wire control stick on a plane. Or if I was suddenly playing QWOP instead of actually running.

There may be edge cases where some forms of direct control over directional aim is superior, though I doubt they would appear in any but the most extreme super-agility dogfights.

Some may also find direct control more natural, particularly as it is how actual vehicles (particularly aircrafts) generally work in the first place, and it may be more suited for control sticks, so it would be best to have the choice. But if it does require only small amount of work to add the old scheme back, please consider it - even though calculating the optimal solution for a moving reticule may not be trivial.

1 Like
17

I see. Thanks for the explanation!

So two systems: One where the user controls the desired thrust as you describe, and one where the user controls the desired heading.

Regarding the desired heading ‘cursor-target’ system, will the cursor be constrained to the view window? My preference would be not constrained, and I believe this is what @ThornEel has just described:

I believe in the ICP rotational acceleration was instantaneous like in an FPS, though I may be wrong. - This doesn’t seem to be what @ThornEel described. “ship does its best to turn as fast as possible” implies non-instant rotational acceleration.

1 Like
18

To be honnest, my memory from ICP is a bit fuzzy ( and finding back the code, hidden somewhere on a 10 years old backup hard drive, almost impossible ) but I do not recall it being that different from the “current” (latest public build) control scheme, besides balancing (ships having different physical parameters/thrust abilities).

2 Likes
19

‘Direct FPS’ thing and the ICP system everyone is talking about is what you find in games like Counter Strike or Battlefield, as you turn the mouse the reticle and the ship immediately points where you moved your mouse.

20

I’ve just reviewed a few videos of the ICP and it’s clearly very different. As @cybercritic says, it was FPS controls - your mouse directly controlled your orientation with instantaneous rotational acceleration.

While there is a valid argument in favour of instantaneous rotational acceleration, I believe the most important thing is having a mode in which the mouse is used to set the desired orientation rather than the quantity of thrust.

It sounds like the ‘cursor-target’ mode will be this mode and I’m looking forward to trying it out in the next build.
My question remains however, will the ‘cursor’ be able to be anywhere, eg 180° behind you, or will it be constrained by the edge of the view?

1 Like