I think that nukes in this game should act like they do in CoN. Not only are the current bombs unrealistic when used, they don't carry the meaning of what a nuclear weapon is. Many new players will think that the nuclear weapon is the strongest and most key unit to research to based off of their meaning in our real world, but in-game it's just an oversized conventional bomb. Even if we're forgetting realism or historical accuracy, the nukes we have aren't even nukes. Spending all the resources and time for a rocket or bomb that isn't even real, let alone useful in most games. If they're gonna have nuclear rockets in a WWII game then at least make them the right way.
Please log in to post a reply.
Only do maor ones, not the dozens of tiny streams. Like the dnieper, volgaa, amazon, nile, etc
Problem is that currently sea in Call of War does not have different terrain types. We only have Sea points = coordinates where you can move along. So for this to work we'd have to remove all sea points from all CoW maps and add sea provinces into all of them, like we did in Iron Order. The feature exists, its just alot of manual work to overhaul all maps and define all the sea province shapes and recreate all sea connections etc.. Just so you understand, it means that all oceans have to be created again, it is not just about the rivers. Once that is done, we can assign specific terrains to sea regions, like river, high sea, shallow sea, and ships could also have different terrain bonuses or speeds depending on the sea terrain they are in.K.Rokossovski wrote:
Well, I DID imply that they should have shorter (dis)embarkment times... having them at 3h/4.5h would make them like full seas while we're not talking full-scale amphibious invasions here. But I was assuming that since the amphibious tank HAS different embarkment times, it would be possible to play with these not just by unit type, but also by "terrain" type. I'd recommend 30m/45m, but if we're really gonna be stuck with 3h/4.5h like normal seas, yeah, this is not a very good suggestion.
But then we are also missing a feature that allows us to tweak embarking times based on the sea terrain the unit embarks on to. Sadly the amphibious tank feature does not allow us to define it per terrain type. So at least that part would be a code change, and ideally it should be configurable and not hardcoded, which increases the effort some more.
Overall this version is still not a small change, mainly due to reworking all the maps. Once sea provinces are activated in the game as a feature it is also not possible to partially do it only for some popular maps as the game would throw errors when it encounters a map that still uses the old sea points instead of sea provinces. So it is either all maps or none.
I guess one could still have the land provinces marked as 'river' provinces, giving shorter disembarkement times. That would avoid the majority of the overhaul proccess although many provinces still would have to be changed. Another way one could do it is have the rivers running through the provinces, and just making it take longer for units to pass through the province and more of a defencive bonus. That would be less favourable but even easier to implement.freezy wrote:
Problem is that currently sea in Call of War does not have different terrain types. We only have Sea points = coordinates where you can move along. So for this to work we'd have to remove all sea points from all CoW maps and add sea provinces into all of them, like we did in Iron Order. The feature exists, its just alot of manual work to overhaul all maps and recreate define all the sea province shapes and recreate all sea connections etc.. Just so you understand, it means that all oceans have to be created again, it is not just about the rivers. Once that is done, we can assign specific terrains to sea regions, like river, high sea, shallow sea, and ships could also have different terrain bonuses or speeds depending on the sea terrain they are in.But then we are also missing a feature that allows us to tweak embarking times based on the sea terrain the unit embarks on to. Sadly the amphibious tank feature does not allow us to define it per terrain type. So at least that part would be a code change, and ideally it should be configurable and not hardcoded, which increases the effort some more.K.Rokossovski wrote:
Well, I DID imply that they should have shorter (dis)embarkment times... having them at 3h/4.5h would make them like full seas while we're not talking full-scale amphibious invasions here. But I was assuming that since the amphibious tank HAS different embarkment times, it would be possible to play with these not just by unit type, but also by "terrain" type. I'd recommend 30m/45m, but if we're really gonna be stuck with 3h/4.5h like normal seas, yeah, this is not a very good suggestion.Overall this version is still not a small change, mainly due to reworking all the maps. Once sea provinces are activated in the game as a feature it is also not possible to partially do it only for some popular maps as the game would throw errors when it encounters a map that still uses the old sea points instead of sea provinces. So it is either all maps or none.
Good idea, maybe a certain part of those provinces can be labeled as rivers and simply make your soldiers go MUCH slower?
The problem with that is, one would have to write more code to subdivide the provinces. One thing one could do, is have rivers as provinces, with slow movement speeds, but completely seperate to seas.Carking the 6th wrote:
Good idea, maybe a certain part of those provinces can be labeled as rivers and simply make your soldiers go MUCH slower?
C
And what if you left the seas as they are, but added coding like:freezy wrote:
Problem is that currently sea in Call of War does not have different terrain types. We only have Sea points = coordinates where you can move along. So for this to work we'd have to remove all sea points from all CoW maps and add sea provinces into all of them, like we did in Iron Order. The feature exists, its just alot of manual work to overhaul all maps and recreate define all the sea province shapes and recreate all sea connections etc.. Just so you understand, it means that all oceans have to be created again, it is not just about the rivers. Once that is done, we can assign specific terrains to sea regions, like river, high sea, shallow sea, and ships could also have different terrain bonuses or speeds depending on the sea terrain they are in.
IF (the sea dot you're embarking to doesn't have connections to any other sea dots) THEN
embarkingTime := 30m
ELSE
embarkingTime := 180m
Yes.K.Rokossovski wrote:
CAnd what if you left the seas as they are, but added coding like:freezy wrote:
Problem is that currently sea in Call of War does not have different terrain types. We only have Sea points = coordinates where you can move along. So for this to work we'd have to remove all sea points from all CoW maps and add sea provinces into all of them, like we did in Iron Order. The feature exists, its just alot of manual work to overhaul all maps and recreate define all the sea province shapes and recreate all sea connections etc.. Just so you understand, it means that all oceans have to be created again, it is not just about the rivers. Once that is done, we can assign specific terrains to sea regions, like river, high sea, shallow sea, and ships could also have different terrain bonuses or speeds depending on the sea terrain they are in.IF (the sea dot you're embarking to doesn't have connections to any other sea dots) THEN
embarkingTime := 30m
ELSE
embarkingTime := 180m
The shorter embarkment times for different terrains would definitely be a new feature, that part would not change in your proposal. The approach to base it on the land province would also mean that we could not make coastal provinces have rivers since otherwise both embarking to sea or river would use the same embarking times in these provinces. So maybe also not ideal.noblebright wrote:
I guess one could still have the land provinces marked as 'river' provinces, giving shorter disembarkement times. That would avoid the majority of the overhaul proccess although many provinces still would have to be changed. Another way one could do it is have the rivers running through the provinces, and just making it take longer for units to pass through the province and more of a defencive bonus. That would be less favourable but even easier to implement.
I understood your other proposal that we introduce a new terrain type, essentially "province with rivers" and assign that to provinces where a major river is running through, and just give units a speed debuff in such provinces similar to mountains, to emulate the river crossing? That indeed seems like less effort than the other solutions, but it also appears a bit half-hearted to me 
As you would not see a real river running through the map and you would not have this river crossing component where your unit is vulnerable.
Also please leave it to the devs to decide what is easy or hard to implement as you don't know the codebase Often times players underestimate the time it takes to implement something. Usually because of all the interdependencies and edge cases.
Yeah that is definitely the type of code that would have been written for our games a decade ago, and is the reason why our codebase is so hard to change nowadaysK.Rokossovski wrote:
And what if you left the seas as they are, but added coding like:IF (the sea dot you're embarking to doesn't have connections to any other sea dots) THEN
embarkingTime := 30m
ELSE
embarkingTime := 180m
So while this quick and dirty way would certainly be much easier to implement I think it is not very sustainable. We rather would do it in a proper way that is consistent with all other features and parts of the code, and that is also easily configurable.btw guys just as disclaimer I am just giving feedback to ideas here to educate more people about the process and challenges. And since I enjoy the discussion. But please don't read this as if we are seriously looking into implementing this right now. I still see the chance for this coming rather low in the near future.
The fact you even entertain it is better than like 90% of other devs anyway. Interesting that the issue is how the code is like a web that unravels at the seems of pulled at, though. I suppose that’s is one of the reasons why new things have been taking time to add, among other things. Could this be fixed over time?
Heh, that's exactly what the programmers in my day job are also telling me (my job as functional designer is about steering them from the business/user point of view). Yet I think it is so strange. You're basically telling me that there's a practical and easy solution, but you can't implement it because it doesn't comply to your current code standards; and if you do it by those sophisticated standards you have now, it will take ages and you won't bother doing it at all. Isn't that the wrong way around; your job as a developer is to build products and features your users/customers/bosses want, and not to maintain some big vault with perfect code. Sure I appreciate how code can get messy over time, and I also realize that this can become really ugly over time. Still in my book, a good programmer knows his way in that jungle, even if it is a little bit harder now to navigate when imperfect code ages. We, as users/customers/bosses, have to pay the price for your vault though... that all the new stuff we want is hard/expensive and we have to be VERY careful about formulating our wishes. Don't you think the "old" coding, where things could be solved more pragmatic and goal-oriented rather than lifetime-oriented, deserves more merit than just being "old school" and messing up your perfect vault of code?freezy wrote:
Yeah that is definitely the type of code that would have been written for our games a decade ago, and is the reason why our codebase is so hard to change nowadays So while this quick and dirty way would certainly be much easier to implement I think it is not very sustainable. We rather would do it in a proper way that is consistent with all other features and parts of the code, and that is also easily configurable.
Yes, but if the code gets messy, there will be more bugs and it will be even more difficult to implement more things, in a neat way or not. All of the bugs would also upset the users more than they would be pleased by the new things.K.Rokossovski wrote:
Heh, that's exactly what the programmers in my day job are also telling me (my job as functional designer is about steering them from the business/user point of view). Yet I think it is so strange. You're basically telling me that there's a practical and easy solution, but you can't implement it because it doesn't comply to your current code standards; and if you do it by those sophisticated standards you have now, it will take ages and you won't bother doing it at all. Isn't that the wrong way around; your job as a developer is to build products and features your users/customers/bosses want, and not to maintain some big vault with perfect code. Sure I appreciate how code can get messy over time, and I also realize that this can become really ugly over time. Still in my book, a good programmer knows his way in that jungle, even if it is a little bit harder now to navigate when imperfect code ages. We, as users/customers/bosses, have to pay the price for your vault though... that all the new stuff we want is hard/expensive and we have to be VERY careful about formulating our wishes. Don't you think the "old" coding, where things could be solved more pragmatic and goal-oriented rather than lifetime-oriented, deserves more merit than just being "old school" and messing up your perfect vault of code?freezy wrote:
Yeah that is definitely the type of code that would have been written for our games a decade ago, and is the reason why our codebase is so hard to change nowadays So while this quick and dirty way would certainly be much easier to implement I think it is not very sustainable. We rather would do it in a proper way that is consistent with all other features and parts of the code, and that is also easily configurable.
Yeah, I’m sure they thought the same thing as you 10 years ago when they wrote the “goal oriented code,” but that caused this current situation… updating fast now will hurt you in the long term future. Slow and steady.
It also brought us this game with all its variety and depth. Maybe we would have just started developing planes now if all the code had been developed under current standards. There's always a balance.Carking the 6th wrote:
Yeah, I’m sure they thought the same thing as you 10 years ago when they wrote the “goal oriented code,” but that caused this current situation… updating fast now will hurt you in the long term future. Slow and steady.
Planes were here when the game started back in 2015/16 lol. Sarcastic joke? Nah definitely serious.
Thing is, I don’t think they are stupid. They very likely understand their own games code better than we ever could. I’m sure they’d really want to add new things. But because of all the cool stuff that game early on without carefulness, it screwed things over now. If they had not slowed down by now perhaps they wouldn’t have been able to add half the things we know now at all. I don’t believe it is easy to tell how much they can add to the game without having worked on it and learned it back and forth for 10 years straight. Notice how he also stated “easier” to implement. Doesn’t necessarily mean it won’t take ages and effort either, all for something that might add one more web to the cob, and may not be as enjoyable anyway.
You can’t tell a builder to build say, a city faster, even though you may be an engineer, because you can’t tell what tools he’s working with, what materials he has and time needed for each building. You don’t want your houses collapsing a few years later…
I guess one could use normal sea for large enough rivers.
Planes might not have been possible to release in version 1 under current superior coding standards... only the bad/old coding made it possible at all...Carking the 6th wrote:
Planes were here when the game started back in 2015/16 lol. Sarcastic joke? Nah definitely serious.
True... but now they have it they can start to tidy it up and remove bugs.K.Rokossovski wrote:
Planes might not have been possible to release in version 1 under current superior coding standards... only the bad/old coding made it possible at all...Carking the 6th wrote:
Planes were here when the game started back in 2015/16 lol. Sarcastic joke? Nah definitely serious.
Who knows? Perhaps they were. You’d have to understand the code to really get a deep feel of how things work. How do you know that bad/old coding was the only option as we know it?K.Rokossovski wrote:
Planes might not have been possible to release in version 1 under current superior coding standards... only the bad/old coding made it possible at all...Carking the 6th wrote:
Planes were here when the game started back in 2015/16 lol. Sarcastic joke? Nah definitely serious.
It is what Freezy said in this thread.Carking the 6th wrote:
Who knows? Perhaps they were. You’d have to understand the code to really get a deep feel of how things work. How do you know that bad/old coding was the only option as we know it?K.Rokossovski wrote:
Planes might not have been possible to release in version 1 under current superior coding standards... only the bad/old coding made it possible at all...Carking the 6th wrote:
Planes were here when the game started back in 2015/16 lol. Sarcastic joke? Nah definitely serious.
And just to be clear, I ADMIRE the coding of this game! The immediacy of feedback to events, the responsiveness between players, within seconds, in a web environment, that's just... wow. Setting that in an interesting strategic game with depth... amazing.
Yet most of that was in place years ago. The basic engine of this game was indeed built a decade ago, and by Freezy's words, under the "old" (inferior) coding standards.
So if these new coding standards are so superior, why don't we get an enormous influx of new mechanisms, ideas, rivers, supply systems, command centers? Why is the game standing still? Could it be because modern coding is SO far superior that it doesn't get anything done anymore?
Hmm… that’s an interesting idea. To be honest I don’t understand coding well enough to be a credible source here. Do games that use modern coding standards fail to get things done in order to preserve code integrity over adding features to the game?
Please log in to post a reply.
