Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 15 Jun 2006
Offline Last Active Oct 26 2016 03:14 PM

Posts I've Made

In Topic: the very best resources I found for game programming

29 September 2016 - 09:18 AM

Oh yes. You wander into any large IT org. There they are. Zombies. Speaking something that was fashionable twenty years ago like... Uniface or something. Employed on contracts to maintain something crumbling that the government department concerned can't afford to have re-written but can sink tons of money into having badly maintained.


There are loads of devs who haven't moved on. I was once hired to teach UNIX development to a bunch of them. They had to leave their discontinued, unsupported, hugely expensive-to-sustain mainframe/JCL/Cobol world behind and move at least to IBM machines with UNIX on which was running a port of JCL and the same Cobol heap they were used to tinkering around the edges of. They were all "but how do you get register dumps?"[1] and "why isn't there a proper offline editor" when presented with arrays of AIX systems to play with. Perl looked like, and was treated as, witchcraft and shell was glaced at and dismissed with distain but no effort. Even Emacs and VI weren't sufficiently arcane to be untoylike to their minds...


I got bored of the task and quit.


The one thing I couldn't tell them was that they were getting fired if they didn't change role... and lo. They were fired.






[1] The machines concerned have about 200 registers...

In Topic: the very best resources I found for game programming

28 September 2016 - 04:34 PM

"Speaking of "Pro", one can't call himself professional if he only knows one language, try and know at least 3"


I was asked how many languages I've used at one point[1] so I compiled a list because I lost track after the first dozen. Terrifyingly, I found I've delivered software for money[2] written in at least 29 different languages (including 4 assembler languages) on 6 types of UNIX, half a dozen version of Windows, three major versions of Mac, several embedded environments and Android together with JavaScript running on various browsers.


That's a bit more than 1 language per year of my career. My main suggestion for career maintenance for younger developers is "get good at getting good at things".



[1] By someone who only wrote in one and was surprised that I could switch between several at a time.


[2] I've hobby-coded in at least a dozen more.

In Topic: the very best resources I found for game programming

28 September 2016 - 03:56 PM

"What about the Indie developers who dream of making there own games, yet they hate programming and can't afford to hire a programmer, should they give up?"


Partner up with a programmer, do the art for them for their game. After that first game, if you haven't done the normal artist thing[1], they're likely to listen to your pitch for your game...


No. I don't know what to do if you can't do art either.



[1] Done the first 1/4 of the things needed, had a change of heart about the style, redone the first 1/4, had a personal crisis and then apparently fallen off the planet for anything between a year and forever. And these were artists I was **PAYING** to do the work.

In Topic: Coding-Style Poll

28 September 2016 - 03:41 PM

Don't write a coding standard. Ever. People who write coding standards should be lined up against a wall and SHOT. Over and over and over and over again until everyone, everywhere forever stops writing them.




Because once you've put cursor to Word document[1], for the rest of time you have to boringly enforce it and have it boringly enforced on you.



Companies are very keen on coding standards and it wastes MASSIVE amounts of time. You spend ages messing about in code reviews with people going "oh, this needs a space here and two there and this line is one character too long (and fixing it will involve you hand re-formatting two subsequent lines..)" and everyone's smug about this because it feels like work and it's BLOODY WELL NOT WORK and then later on the review someone says "Oh hey, why don't you just use this API over here" and you throw away all that code and all the effort in fiddling the spaces into place.


Code layout standards are the sort of thing you need if you have either a lot of spare software engineer time you need soaking up or the kind of engineers better deployed on the task of counting spaces in code than in actually writing it. The first option is unlikely and the second is an environment to leave soon anyway.


Go and write an automated nitpicker / code autoformatter / automated nitfixer instead. Preferably by using an existing one wrapped up with some flags describing the selection of options made in the tedious meetings. And very preferably the latter two[2].


Now you a) don't have to enforce it and b) people don't spend their lives having to try and conform to it. A quick command and now you get nicely formatted code and you're having the machines doing the boring scut work. Which is supposed to be the business we're in but everyone seems to lose sight of that when it comes down to space-counting, bracket-lining-up OCD.



[1] Usually, ironically, a very poorly laid out one which sets off my typographical sensibilities but which for some reason can never, ever, ever be changed[3].


[2] An ex-colleague was horrified when my approach to getting frankly stupid quantities of silly, niggly complaints out of an automated Java style-checker was to write a python script which ingested its complaints, parsed them and ran regexes over the source to fix them. I considered this a set of problems which were hence solved for all time. He seemed to consider it cheating. I wasn't doing the penance properly and never would learn how to write compliant code. So I named it after him...

[3] I recall one such document for C++ which required that any condition must be compared to a boolean. So you had to write "if ((x == y) == true)". This was because once someone had had some code written without it which "didn't work". Given the skill background of some of the other "engineers", I suspect they were just a muppet. But despite no record of the incident, no repro, no witnesses or no sense for the rule I still could not get the committee to remove it. On the basis that "you just never know, do you?". Once you start down these routes, you're in a world of giving the Bs a mechanism to treat the As like Cs and soon you don't have any As.
Here endeth the lesson.

In Topic: Serious Question needs serious logical feedback

24 September 2016 - 03:32 PM

The "Tell me how to make my game with no money and when the idea is so secret I can't tell you because you'll steal it" type questions.


If you keep answering these things, people are going to keep punking you with them.