suggestion list. dumb or brilliant?

[harrymcb]

here are a list of suggestions i have. i fully acknowledge that some may be stupid or not worth the effort. just throwing them against the wall and seeing what sticks.

0) balancing. the game seems very unbalanced at this point. i made this 0 because i am quite certain it is already planned.

1) cannon having ability to shoot up as long as in line of sight.
basically give cannons/sprayers the same line of sight calculation as towers. cannons already can't shoot at the closest part of an edge down because of this, extend the same logic and let it shoot up. imagine a max height wave coming at you now cannons can shoot at it. still make going up a uphill struggle for cannons(pun intended). but make it a little more logical.

2)deeper creeper breeds faster.
this has a few reasons. first putting one drop of creep/AC on a mountain shouldn't be able to loose/win a game for you. this would make pools breed faster and mountains slower. it also makes the back sustained areas very tough and the front lines easier as it should be(in my mind). also by default breeding at very very low creep should be slower than evaporation. this way un-sustained mountains don't work, but sustained ones still work well. as it is evaporation with breeding is nonexistent. if you made breed speed a factor of a log of creeper depth it should work and not runaway too quickly. this was discussed at length on discord(too shame my math skills look it up).

3)single build reactors
basically so you can spam reactors without over building. when at a deficit only route packets to one reactor. simple QoL addition

4)planned builds
another QoL addition that i know has been talked about before. just drag a line of towers across the map and those that are placed in creeper stay blueprints until they are uncovered. same method can be used for any building.

5) smooth out delta graph
currently the creeper delta can be so chaotic that it ends up telling you very little. i have no idea how to do this. but seeing it jump from the bottom to the top and back is very confusing.

6) AC in/out graph(stats)
just like CW3 i assume it is planned just want to say it out loud :)

7) more visible health/ammo bars
i can't see them at all on current videos.

8) ??? i may have more later if so i'll just post a reply to this post.

[Karsten75]

here are a list of suggestions i have. i fully acknowledge that some may be stupid or not worth the effort. just throwing them against the wall and seeing what sticks.

0) balancing. the game seems very unbalanced at this point. i made this 0 because i am quite certain it is already planned.

I'd be really interested to heat your (and others') opinion on game balance and why you perceive this game as unbalanced at the moment? Not that it isn't, just looking for additional perspective.

1) cannon having ability to shoot up as long as in line of sight.
basically give cannons/sprayers the same line of sight calculation as towers. cannons already can't shoot at the closest part of an edge down because of this, extend the same logic and let it shoot up. imagine a max height wave coming at you now cannons can shoot at it. still make going up a uphill struggle for cannons(pun intended). but make it a little more logical.

I believe that all aiming at the moment aims at terrain. This is a by-product of how the game works - the vertical cliffs don't exist in the game logic - they're merely rendered. I think that may make it hard in a straight line-of sight calculation to locate the top of terrain - not saying it can't be done, but that there are hurdles to doing this.

2)higher creeper breeds faster.
this has a few reasons. first putting one drop of creep/AC on a mountain shouldn't be able to loose/win a game for you. this would make pools breed faster and mountains slower. it also makes the back sustained areas very tough and the front lines easier as it should be(in my mind). also by default breeding at very very low creep should be slower than evaporation. this way un-sustained mountains don't work, but sustained ones still work well. as it is evaporation with breeding is nonexistent. if you made breed speed a factor of a log of creeper depth it should work and not runaway too quickly. this was discussed at length on discord(too shame my math skills look it up).

I'm wondering if you're conflating "deeper" and "higher" in your first sentence?

For the rest, I'm going to not comment, each person has his own ideas on how things should work.

3)single build reactors
basically so you can spam reactors without over building. when at a deficit only route packets to one reactor. simple QoL addition

We actually tried this in an early build - it's complex, error prone and hard to program a proper dispatch mechanism that works under even the few situations we tested. If you are aware of an algorithm or model that achieves this, I'm sure we can look at it again.

4)planned builds
another QoL addition that i know has been talked about before. just drag a line of towers across the map and those that are placed in creeper stay blueprints until they are uncovered. same method can be used for any building.

You're right - this comes up often - last time we  tried it out was in a CW3 beta build. It's a disaster. One frame the terrain is clear, and packets get dispatched. Next frame, the wave lapped over it and the unit is destroyed again, with loss of packets - not great for an energy model, also very noisy in unit explosions. :)

5) smooth out delta graph
currently the creeper delta can be so chaotic that it ends up telling you very little. i have no idea how to do this. but seeing it jump from the bottom to the top and back is very confusing.

Yep, we have no idea how to do it either. :)

6) AC in/out graph
just like CW3 i assume it is planned just want to say it out loud :)

There weren't any graphs in CW3. ...  Production statistics for wares (AC being one of those) is part of the Fabricator UI.

7) more visible health/ammo bars
i can't see them at all on current videos.

Visibility of lots of things are issues - any suggestions as to how to make them more visible is probably welcome.

8) ??? i may have more later if so i'll just post a reply to this post.

!!!

[Builder17]

6) AC in/out graph
just like CW3 i assume it is planned just want to say it out loud :)

Not sure if he means like it's in PF, one bar shows how much AC you produce and another one shows how much you use, to show how much you can increase AC usage without going deficit? Is example image needed?

[harrymcb]

0) cannons seem supremely under powered at this stage, and AC far TOO powerful also bombers though each shot is same basic damage as mortar they seem to shoot like 2-4 times faster.

1, 3, 4, 5) this is what i expected. nice idea but giant pain to do. have to admit it would be nice :)

2) yes i meant deeper not higher. sorry about that.

6) the problem is having to go to a separate screen to see AC store. i'm thinking of CW3 where it shows store/in/out in the bar at the top. again wrong word i didn't mean graph.

7)this may be over simplifying the problem but just make it bigger with a higher contrast. i think it is green now, the same color of the ubiquitous soylent. maybe a thick black border around it. and possibly make it scale less to zoom level so it is nearly as big on the screen at max zoom out as max zoom in.

as for the emojis at the end i actually tried to make it #8 unfortunately it turned emoji

[Grabz]

7) I gave it a bit of a shot, you can let me know what you think, or how to change:


I also notice that, on full zoom, the ammo bars can become nearly fully obstructed by the unit's model because of the camera angle. The below image is zoomed in further than the above image, this is not a comparison.


(Images taken from the Turtle dev video)

[harrymcb]

i love it grabz! i can see it

[bluebolt]

5)
It might be helpful to have an average creeper delta line on the graph... just to show if you really are lowering the creeper amount or not over a minute.

7)
In addition to what Grabz has, would it be economical to make the bars follow the camera? So they would always be facing/oriented the camera. Facing might prove disastrous on camera angles closer to the horizon, so oriented may be better. Having the bars above the unit rather than below as an option to set it can help with visibility too. Orientation could be in 90° increments, or just oriented towards the camera at all times; I'm not really sure which would be better.

[planetfall]

Here's my case for changing LOS calculations (please excuse toddler-tier scribbles):

For cannons: Even keeping "can't aim up" (like their design physically prohibits pivoting up) there are cases where creeper will be in range, but land will be out of range. However, targeting only the top of creeper means they won't be able to fire at creeper on their own level, since the top of it will be above whatever their elevation is even though a projectile fired horizontally could obviously hit a wavefront. So cannons should try to target the top of creeper, the ground, and their own elevation if target cell elevation + target cell creeper >= cannon elevation.

For mortars: IMO, for the best visuals and believability mortar shells should explode on contact with creeper, not on contact with the ground. It looks a bit silly to see an explosion happen underneath the creeper but see creeper removed at the surface. And due to the whole "mortars have longer range when high above their target" mechanic, assuming it's still in the game, it could be possible that a mortar examines a cell where it could target the ground, but not the creeper at its current height. However a mortar shouldn't just not fire at a towering wave because it can't hit the very top. So it should still search for where the ground is targetable, but only if it searches for places where the top of the creeper is targetable and comes up empty. This does seem like it would be a lot of extra calculations though, not to mention making the mortar shells check for colliding with creeper every tick. So that method may be prohibitively CPU-hungry.

[Hurk]

Planetfall, i believe the solution to that is for guns to use the shields logic and have a max range away, but not in declination. so in your screenshot, instead of it being a sphere, it would be able to shoot the ground straight down from its furthest aim point.

[Grabz]

I believe that all aiming at the moment aims at terrain. This is a by-product of how the game works - the vertical cliffs don't exist in the game logic - they're merely rendered. I think that may make it hard in a straight line-of sight calculation to locate the top of terrain - not saying it can't be done, but that there are hurdles to doing this.

I re-read Karsten75's original response and I have a question that also relates to the current discussion.

Skimmers (or Striders) movement appears to be based around the visual height of creeper, because they need some way to decide where the creeper floor is in order to bounce. In that case, one assumes there is a specific function to figure out the visual creeper ceiling Y coordinate. In that case, why is it difficult for Cannons to look at the same value when deciding where to shoot? Is it a performance problem. i.e. Strider only has to check the cell under him, but Cannons would have to calculate the visual Y coordinate of creeper of all the cells in range, all the time?

[knucracker]

There's a function to turn the raw creeper height into the 'actual' height and it isn't expensive.

For the cannon, it has to look at all of the cells in range per frame to see if there is any creeper.  If some is found it then checks for LOS.  The LOS calculation is 'simplified' so that it isn't doing exact line-on-triangle checks for all of the geometry between the cannon barrel and the target.  The target is currently the terrain, as has been observed. 

The simplified algorithm, which you can think of as similar to a bresenham line algorithm (which is an integer line algorithm that visits each 'voxel' between the source and target), is there to improve the efficiency of the LOS calculation.  That's the idea anyway.  Since I wrote it, I ended up creating a pretty efficient terrain LOS algorithm that the sniper uses (the bomber also uses it when doing a flight path collision detection).  It works by using a 2d bresenham line algorithm to pick terrain 'cells', then pulling the two triangles from them and doing a line/triangle intersect check.

So, whether I switch the cannons to an 'exact' LOS or keep the approximation, the question still remains where they can target.  Targeting at the ground works a whole lot of the time.  Before I started the game I worried a lot about it and thought it would be a big problem.  Then I started playing and quickly concluded my fears were mostly unfounded.  It could just be me, but in the many hours I've played with cannons I've never been particularly irritated with their firing limitations.  One reason for that might be that they show their exact LOS via their range indicator.  So when I move a cannon somewhere I know exactly what terrain (usually lower than it over the edge of a cliff) it will target.

That said, if a wave a creeper came up to a cannon and found itself over a cell that the cannon didn't indicate was a target-able cell, and the cannon shot at it.... I doubt most players would complain.  But, there are two things of note if this were to happen.

1: The target LOS indicator for the cannon wouldn't be able to indicate this since whether it could shoot creeper would depend on the variable height of the creeper.  So the LOS range indicator would still work as it does now.  It would only show if a cannon can target the ground at a given location.

2: If a cannon takes a shot at the surface of the creeper, then some percentage of time the creeper won't be there when the shot reaches its target.  Mortar fire, other cannons, bombers, natural flow... all of these can make the creeper surface be lower when the cannon shot reaches where it thinks it should hit.  This means some percentage of time the shots will miss.  Now if the cannon targets a bit below the surface of the creeper then the problem mitigates, but doesn't go away.  Targeting all the way back down to the terrain still means there can be a miss... just as there is now.  But when the target is the terrain the shot doesn't have to keep going (it hits the terrain).  All of this to say, the shot itself has a greater computational burden since it has to do collision checks, etc.

So those are my thoughts.  No conclusion, and I might change or try other targeting algorithms.  I just wanted to throw some more info out there.

[harrymcb]

i had never thought of those things! that definitely makes it seem not worth the effort.

[Grabz]

Thanks Virgil, that perfectly answers my question and more. Looks like you have a pretty robust engine going on and the biggest problems have to do with UI and balance/quality of life, things I haven't even thought of in this scenario.

Given all of these points, it also makes me shake my head a little bit thinking about what sort of RPL we will have to do to create custom targeting :)