The upcoming Cap of 15 bricktrons is a really bad idea

Part of the fun is building large armies , and it's been that way since the beginning. There has to be another way to fix the performance issues. Making a change like this after the game was released ,would be a huge disappointment to the loyal C.S player base. And that's putting it nicely
Please don't do it

Comments

  • Well, I wonder how this will work. In the stream, it was mentioned that you could change it pretty easily. Also mentioned that corruptron numbers would be looked at too.

    What I found best, was just to leave the majority of my (25 or so) bricktrons in kits, and just let a few go back to work, between invasion rounds. So, only really 6 or so were moving at any one time, the rest remained in place for the next slaughter. But even then, I was getting lag. Probably this was coming from the hordes of corruptrons that were sent against me. Lots and lots and lots of corruptrons.

    I think probably the lag comes from pathfinding. The more units you have that need to go from A to B, the more the engine needs to work. I think the game could be smarter about how it works though. Maybe it should split invasion hordes into parties, and instead of moving them all, in at the same time, they just focus on this and that group. I'm sure that would cut down on calculations.

    Eh, but probably they'll adjust things as people complain about it. Until there's some balanced play again.
  • ShatojonShatojon Administrator Developer Backer Wiki Editor
    edited February 2018
    Hey guys, I'm going to post the response I gave on Discord, here too. It answers your concerns.

    When it comes to the upcoming changes to the Bricktron cap, let me start by saying that I fully understand your frustration and I did expect a certain resistance to the idea from the community when we discussed it in the studio. It's a pretty major change to suddenly drop on you guys and we fully understand your reaction to it. It’s no fun getting used to the unlimited population then having an update cap it, but it’s a necessary change we should have done much earlier in the development cycle to allow players to get used to it and avoid creating strategies around an unlimited number of Bricktrons. That’s on us and we’re sorry it took so long to incorporate that limit into the game. For those who aren't aware, though, keep in mind that modding the population cap, if you desire, will be as trivial as modifying a number in a text file. It won't be supported though and may cause performance drops.

    It’s actually not a fundamental issue with the engine nor the AI, but rather with the genre of game that Castle Story is. It isn’t fair to compare it with other, more “classic” RTS. Castle Story is a 3D game that includes vertical movement and building, the world is in voxels and the entire terrain is modifiable. The issues the AI in Castle Story has to resolve are considerably more complex and require considerably more calculations than other games with no building, no active pathfinding, no construction and destruction on the map, etc. In games where the map is pre-baked, the user manually controls almost every one of every unit’s movements, where the terrain doesn’t change and pathfinding doesn’t need to be recalculated constantly, it’s significantly easier to optimize elements surrounding your AI. These things considered, 30 bricktrons is a very large number of units in Castle Story, keeping in mind there are likely other units with similar processes: Corruptrons, other teams’ Bricktrons, etc. Setting a population cap is something we should have done a while ago and while we expected some players to be understandably unhappy, we had to rip the bandage eventually and with our focus on polishing and improving performance, right now seems like the second best time to do it (the first being right at the beginning of development). By setting a limit now, we can actually start optimizing in terms of X being the amount of supported Bricktrons. Leaving that to infinity would make that task impossible. And yes, there are other aspects of the game that are problematic when it comes to performance - we’re working on those too.

    You’re worried about balance and that’s perfectly understandable. We want the game to be fun and the population cap comes into this equation. Actually, the version of CS you’ve been playing since 1.0 has actively been balanced for around 15 Bricktrons - that’s around where people tend to win games and/or get tired of Invasion and start a new round. Of course there are exceptions and that’s why we’re making sure all and any of the changes we make are in Lua so they’re very easily moddable to adapt to the way you want to play. Keep in mind though, as of right now, the game already gets significantly easier the farther you get from 15ish Bricktrons. Things aren’t going to change that much by the cap, or if you mod it. Also! It’s trivial to create your own preset/difficulty to play with, there’s a huge amount of variables available for you to change, increasing the difficulty, and I’ll be happy to help if you decide to make a player-made preset; Bricktrons cap will be one, of course, but also Corruptrons cap, unit damage, health, projectile precision, range, bricks health, wave times, Corruptrons per wave, Corruptrons level up speed, etc. etc. - and like I said, we’ll be more than happy to help you out if you’re going to dive into that. It’s as easy as changing a number in a text file. Despite all that, it’s very likely you play the game more than most of us and your thoughts on the change are critically important to us, so do let me know what you think after

    When it comes to multiplayer, if the host modifies the cap, it’s going to apply to the client too, without needing to transfer any files or teach your friends how to modify it. :) It’s the host that dictates the cap for all existing players.
  • What the developers seem to not understand is that why people stop playing after reaching 15 workers is because ussually by that time the lag becomes unberable to play anymore.

    Its better off to focus on simplyfing the pathfinding, even if it means creating possible exploits by the player, it is far better to focus on smooth and lagless experience rather than anything else.
    Lowering the amount of enemytrons to reduce pathfinding, but pushing their stats up to compensate.Also make them move slower but have higher resistance.
    Lowering the attack rate but increasing damage of various units and towers, so they caluclate LOS less often. Calculate LOS on static units in advance instead of recalculating every shot. Remove homing effect, make just simple fast animation, to remove useless caluclations for missiles.
    Remove the healing aura visual effect, the visual effect may look nice, but imo its just a sore eye that doesnt help any clarity, and big overuse of effects.
    Make maps way smaller, the maps are to big, to make more performance.

    Get realistic, the moment i saw this game i though to myself this is either very decent programming or as a lot of todays developers, overshooting what is capable at the moment, just having whatever idea for a game, doesnt mean its possible from a technical standpoint, and this is another great example of that.

    Thats my 2cents on it.
  • Option to simplify/remove animations/dynamic lights could be nice If it affect performance comparable to pathfinding. sentinel homing/ healing aura. every wisp/magic bolt/ward/bricktron proving some light especially at night. also lowering texture's quality probably affect the amount of calculations made to render dynamic lights. I was seeing that when lowering level of detail below lowest, when e.g 16 stone textures become 4 and then 1 at the furthest camera distance, the fps jumps up like crazy
Sign In or Register to comment.