Civilization VI [Steam] had the massive Fall 2017 patch released for Windows on October 19th, but sadly the patch is taking a while for Linux (and Mac).
For those hoping to dive back into Civilization VI with the refreshed game over the holiday, this is sure to be rather dissapointing news. Especially since it's quite a big patch and it means Linux gamers are currently missing out on the Khmer & Indonesia DLC pack. Here's what Aspyr Media said in their update:
UPDATE 12/20/2017
Due to extensive development and necessary code fixes, this patch has taken significantly longer than previous updates. We will not be able to release the Mac and Linux Khmer and Indonesia update until sometime after the holiday break. We apologize for any inconvenience.
I'm sure they have perfectly valid reasons, I just hope they haven't encountered a really nasty bug that takes a while to work around. Even so, it's hard not to be dissapointed since this patch is now over two months late. You can keep an eye on this page for updates.
Full details on what the patch does is available here.
As any developer can tell you, making code changes can be a pain even if it is your own code. (Good developers do what they can through documentation and coding standards to minimize future pain.) When it is someone else's code, it is harder because you have to think like the other developer sometimes to understand how and why they wrote the code as it is. The fact that it is a different company with different coding standards makes it even harder.
In addition, this is a port... which means that functions and libraries used on the original may not be available on the other platform and need to be replaced or in a worse case scenario, written new from scratch. (Engines like Unity and/or Unreal minimize this by having the same functions and libraries available on all platforms, but 1) you have to use the middleware, 2) you would need to limit yourself to only use functions within that middleware, and 3) any bug in that middleware between platforms is a pain to fix.) Porting can be a pain, especially if the original developers don't make any attempt to keep the code friendly to porting.
TL;DR... Rewriting someone else's code can really be a pain in the ***.
They were busy releasing Civ6 for Ipad's.
but damn, I'm actually seriously considering buying an ipad just for that game lol...
They were busy releasing Civ6 for Ipad's.
but damn, I'm actually seriously considering buying an ipad just for that game lol...
Price seemed a bit high to me. For a mobile device game of course.
You can play 60 turns for free then you have to pay.
https://itunes.apple.com/us/app/civilization-vi/id1123795278?mt=12
2.6 point
Last edited by Leopard on 22 December 2017 at 7:02 pm UTC
Copy pasta from my previous comment on an other Aspyr News: Aspyr has to step it up, there's a quite noticeable gap in both quality and quantity between Feral and Aspyr, and it just seems to get bigger and bigger. They haven't even released a Vulkan title (or even some experimental build, like Mad Max) yet, Feral is miles ahead.Plenty of room for both, and both have some really popular titles under their belt. I don't see why you'd want to make it into a competition. Ideally I'd like the original developers to handle their own cross platfrom releases and support, but as long as we have to rely on third party porters, I don't even care who actually does it. As long as we get quality ports.
Its development... it happens.
As any developer can tell you, making code changes can be a pain even if it is your own code. (Good developers do what they can through documentation and coding standards to minimize future pain.) When it is someone else's code, it is harder because you have to think like the other developer sometimes to understand how and why they wrote the code as it is. The fact that it is a different company with different coding standards makes it even harder.
In addition, this is a port... which means that functions and libraries used on the original may not be available on the other platform and need to be replaced or in a worse case scenario, written new from scratch. (Engines like Unity and/or Unreal minimize this by having the same functions and libraries available on all platforms, but 1) you have to use the middleware, 2) you would need to limit yourself to only use functions within that middleware, and 3) any bug in that middleware between platforms is a pain to fix.) Porting can be a pain, especially if the original developers don't make any attempt to keep the code friendly to porting.
TL;DR... Rewriting someone else's code can really be a pain in the ***.
I will preface this by saying that I'm not a full-time coder, or even that good by any stretch of the imagination, but I can usually look at and understand what code is supposed to do after a time, and must say that comments that say something as simple as 'this function does blah' is nice.
That said, at my previous job, the developers there were always told that if their code was too complex that people couldn't just look at it and it needed a comment to say what the code did, then they were doing it wrong, and they were chastised for using comments at all.
I think that's idiotic, because some complex functions need to be... well complex enough that a comment should be used. What are your thoughts on that?
What are your thoughts on that?Whether your code is readable or not, comments are a must. What you consider readable might be total gibberish to someone else. Readability of a function or other code structure is also often dependent on context.
I'm sure anyone who's ever had to work on someone else's code would agree.
That said, at my previous job, the developers there were always told that if their code was too complex that people couldn't just look at it and it needed a comment to say what the code did, then they were doing it wrong, and they were chastised for using comments at all.
I think that's idiotic, because some complex functions need to be... well complex enough that a comment should be used. What are your thoughts on that?
Complex code is sometimes necessary. I agree that when code is complex, it should be commented. Even when code is pretty easy, a comment can help.
When you write code, the idea of exactly what it does and how it does it is fresh in your mind immediately after you write it. However, go back to that same code after 6 months of working on a different project and sometimes even the simple things are not as simple as you remember. I try to write my code with the idea that in 6 months, I will be back to change something and need to re-learn what I did. I write comments to remind me of certain details of why I wrote it that way initially.
One pet-peeve of me in that respect is variable naming. Far too often I see people use two letter variable names. Many languages do not limit the size, use it. For example, when everything is fresh in your mind, "nlg" may obviously mean "number of linux games", but 6 months later it won't be so obvious. Just write "NumLinuxGames" as a variable name instead. It will help you remember 6 months later, and help you self-document the code due to increased readability. (some complain about the increased code length or characters to type, but that argument falls on deaf ears when you consider the amount of code that gets cut/pasted and the ability to search and replace.)
Sadly there are too many coders that do not value comments at all. They obviously have never tried to read their own crap code after the 6 month mark. My favorite editor is Sublime Text, which allows for color themes. The number of themes available that make comments nearly invisible (e.g. light grey text on slightly lighter grey background) is astonishingly high.
This is why I feel sympathy for porters... when re-writing code, you have know idea what you are getting yourself into, until after you start. You may get lucky and find well structured and documented code... or you may find spaghetti code implementing obscure function calls that is lucky that it works at all. Most cases will likely be somewhere in the middle, but no one can tell until after they start to dig into it.
What are your thoughts on that?Whether your code is readable or not, comments are a must. What you consider readable might be total gibberish to someone else. Readability of a function or other code structure is also often dependent on context.
I'm sure anyone who's ever had to work on someone else's code would agree.
Ha, thank you, because that's exactly what I've said as well as all other programmers I've talked to. The manager of that team was... well special. One of the many things he'd done was modify the xml for a tomcat machine on a production server to create a new instance, and he copied one part, and left the port number the same as the default instance, so it took down the production system.
Also didn't understand how patch files work and just copy/pasted the patch file directly into the code, + / - and all!
I can vouch for the necessity of code comments. Why things are done this way, or not that way, and what certain black magic code actually does. The latter almost always have more comments than code, just to explain it.I have worked on large teams, small teams, and now I am working independently. Useful comments are helpful regardless of team size.
Doesn't mean code is unreadable of course. Proper interfaces hide a lot of the more intricate incantations, keeping overall design from plunging into insanity.
Especially with larger teams, good comments and documentation (and they can often be one & the same thanks to tools like doxygen) are an absolute must.
Also, yes proper interfaces (and functions) can also be useful in reducing overall code complexity. When you put the most complex code behind this, you make it so that the complex code only needs to be modified when absolutely necessary; which in turn helps avoid creating bugs.
And a lot of people adopted this approach.
It just... there is this book called Clean Code. It became influential because it had good advices. And guy there says if the code is good, it doesn't need comments and that comments are sign of bad code that isn't readable.
And a lot of people adopted this approach.
Colombo, you already rebuked this approach with your earlier comment:
Often, what is important is not comment what function does. You can see it if the code is well written. More important is to know why the code does a certain thing.
With clean code, yes, it should be easy to know what something does... but reading code alone does not and can not tell you why it was done a particular way.
Personally, I also like to add tidbits of other areas of the codebase that should be looked at if something changes because it may be affected or tightly integrated with the logic in the area I am currently changing.
I also use comments to keep track of changes to the code. While I do use source control, when I am digging through code I don't always check the date of every file to see when it was last changed. Those quick comments at the top save me a lot of time.
While good naming conventions can tell you the source of where variables are coming from, I will use comments if I need to go a little further.
An extra 5 or 10 minutes of creating comments when I write some code can save me hours later, in 6 months from now when I need to modify code or when I am hunting for bugs.
For the record, some comments are useless:
print(variable_name); // writes the variable to the screen
that is pretty obvious and useless.
However...
safe_print(variable_name); // variable_name contains special characters and needs to have the output sanitized
That can be quite useful and save time and heartaches later.
I can not agree with this philosophy of code not needing comments. IMHO, that is horrible advice. I doubt anyone who believes in it has ever written code with any real complexity. They surely have not gone back to old code six months later, (or someone else's code) and tried to figure out why something is happening.
I suspect that many like the advice of not creating comments because they are too lazy to do it in the first place and are not advanced enough to recognize the significance.
I am a damn good developer. With that knowledge, I realize that I still make mistakes. I want to ensure that when I go back and look for those mistakes that I have every tool available to me to help find them in the quickest way. Comments help... a lot.
Colombo, you already rebuked this approach with your earlier comment:
I was merely stating how this trend began.
For an example, see here:
http://apdevblog.com/comments-in-code/
That said, at my previous job, the developers there were always told that if their code was too complex that people couldn't just look at it and it needed a comment to say what the code did, then they were doing it wrong, and they were chastised for using comments at all.
I think that's idiotic, because some complex functions need to be... well complex enough that a comment should be used. What are your thoughts on that?
I can bet any money that policy was made by some fucking moronic manager, who has never written a line of code in his life, but has read all the books on Scrum and Agile, and all these other bullshit methodologies.
If he'd said that to me, I'd have punched him in the face, and then promptly handed in my notice.
Ha! Even as someone not on his team and having to deal with him, I wanted to punch him in the face and hand in my notice.
True Story: Same guy, always complained there was an echo and the sound cutting out on his VOIP phone. I told him to turn down the volume on his speaker phone a couple of notches, because the placement of the speaker and the microphone would cause the sound to reverb off the desk and with SIP being the way it is, it would try to auto-correct the noise, causing drops in audio and an echo. Finally Aastra released a firmware update that literally maxed out the volume at a firmware level. Every time I'd lower the volume, he'd raise it back up, causing the problem.
His comment when Aastra released the firmware, "About time you fixed it." I about stabbed him. Here's the fun part. Who in their right mind talks to clients on a speaker phone!? All the managers did that, they'd leave their office door open and talk to clients on speaker phones... drove me nuts.
I should write a blog for how much crazy shit went on there...
I can not agree with this philosophy of code not needing comments. IMHO, that is horrible advice. I doubt anyone who believes in it has ever written code with any real complexity. They surely have not gone back to old code six months later, (or someone else's code) and tried to figure out why something is happening.
I suspect that many like the advice of not creating comments because they are too lazy to do it in the first place and are not advanced enough to recognize the significance.
I am a damn good developer. With that knowledge, I realize that I still make mistakes. I want to ensure that when I go back and look for those mistakes that I have every tool available to me to help find them in the quickest way. Comments help... a lot.
Well, I have seen the opposite too: a developer write the initial code and uses a fair among of rather simple comments. A second developer touches the code (years) later, does some refactoring but leaves the (no longer matching) comments as is, cause it seems nice to have comments and because comments aren't touched if you use some tooling for refactoring (Jetbrains and friends). A third developer has to work on the code later again and gets utterly confused cause the comments are sending him into a completely false direction. All sort of comments are fine if you are the only developer of a piece of code, even over time. Though comments can have side effects if the team changes over time.
In my opinion comments should be used to explain assumptions, algorithm or describe a public api. Most basic comments though should rather move into variable name, method extraction and methods names etc. One of the important rules in software engineering imho: You never write code for yourself, but for your team members.
A second developer touches the code (years) later, does some refactoring but leaves the (no longer matching) comments as is, cause it seems nice to have comments and because comments aren't touched if you use some tooling for refactoring (Jetbrains and friends).And here you see a developer who doesn't do his/her job. If comments are no longer relevant after you've changed the code, it's your job to update or remove them accordingly. Tooling is a bad excuse.
Welcome to the real world ;). Of course this was a bad job, but these things do happen, though usually much more gradually over time thus a lot less obvious.A second developer touches the code (years) later, does some refactoring but leaves the (no longer matching) comments as is, cause it seems nice to have comments and because comments aren't touched if you use some tooling for refactoring (Jetbrains and friends).And here you see a developer who doesn't do his/her job. If comments are no longer relevant after you've changed the code, it's your job to update or remove them accordingly. Tooling is a bad excuse.
Ignoring the condescending tone of your reply, is that supposed to be an argument against code comments? If a team member messes things up, you might need tighter project control and/or coding guidelines. Otherwise that particular developer's sloppiness is bound to cause problems for the rest of the team. A bit of misinformation in comments might soon be the least of your worries.Welcome to the real world ;). Of course this was a bad job, but these things do happen, though usually much more gradually over time thus a lot less obvious.A second developer touches the code (years) later, does some refactoring but leaves the (no longer matching) comments as is, cause it seems nice to have comments and because comments aren't touched if you use some tooling for refactoring (Jetbrains and friends).And here you see a developer who doesn't do his/her job. If comments are no longer relevant after you've changed the code, it's your job to update or remove them accordingly. Tooling is a bad excuse.
Sorry if I fail to find the humour in this, but I have enough experience of running team projects for this to strike a nerve.
See more from me