Posted on November 22nd, 2007 by Chris.
Categories: Chris, Games, Programming.
I wrote this a while ago, posted without revision. I think I would change it now, so you’re still a programmer, but you have a sword and stuff.
For fun, I’m creating a role playing game. But in this game, you won’t be a sword fighter. You’ll be a programmer.
Working for a company making a role playing game.
Basically you’ll get to play a number of classes: sales, marketing, product management, engineer. With each, you’ll be able to upgrade the same skills, but some of them will go up quicker than others. (Though it’s true that in Morrowind, this sort of excessive flexibility was criticized for not giving a player a good focus, I’ll make sure that your role is more dictated by your job than your skills).
The first criticism you might have–this is total garbage. Why would you play a game that doesn’t involve killing anyone? I think I can provide an appropriate response in the form of this. Everquest also has crafting, where you put together items to produce a greater whole. We’ll expand on this concept.
The difficulty will be how to make this a challenge like in real life. I think this is a matter of pitting people against each other or together with each other, so we can leverage human AI instead of coding our own, first of all. Then we have to make the RPG a useful creative experience. One thing that we might do is have competing organizations, and a customer base. Basically, you’ll have customers if you have good sales, but you’ll have to work together with good engineers, because engineers can produce useful gadgets. Oh, and you won’t be able to do it all; upgrading some skills will push the others down automatically.
Anyways, the prototype will be based on the following:
- Sales: You need to be able to sell things well, which may not involve being realistic. It also involves being a good communicator, and finding contacts.
- Product Management: You need to be able to manage timelines and put things together. This involves being organized, and being able to empathize with two groups. The more you empathize with engineering the faster and better things may get produced, but the more you empathize with the customer the more likely they’ll be to approve of the product.
- Engineering: Basically, the better you are the better you are. I think Gas will know more about this.
- Testing
OK, so my new game is gonna be about music.
Posted on November 19th, 2007 by Chris.
Categories: Chris, General/Misc., Minesweeper, Programming.
Based on How to feel useful, here is a guide to the five steps for making a programming language actually feel useful, for C++ in particular:
Usually operating systems will offer some sort of programming library so you don’t have to reinvent the window. This varies from Windows to Mac to Linux. Additionally, there are windowing toolkits - downloadable libraries that let you make windows that work anywhere.
GTK, the GIMP toolkit, is best known for being used in many open source programs, like the GIMP (of course), GAIM, and DIA are built in. There is a tutorial, though it’s not entirely transparent.
Possibly preferable are Qt, a partially-open-source toolkit [tutorial], and wxWidgets [tutorial].
One of the simpler ways of pulling web pages is through the use of http-fetcher, a portable library for making HTTP requests.
If you’re willing to stick to Windows-only (and .NET only in particular), this shows how. .NET has a fat library though, so if you’re using it you won’t need the rest of this.
C++ has built in file handling (and more importantly, a good C++ tutorial will typically document this). Reading a file line by line is pretty straightforward [tutorial].
Use system() to make calls to other command line programs. [reference]
Fortunately, native compilability is C++’s h2 suit. In general, using a standard C++ compiler (the Microsoft compiler or G++, for instance), you get a binary file that can be run on any other computer (using the same operating system, of course).
—-
The Boost library is one of the most important C++ library collections, as well as one that will have a major impact on the next version of C++ (as Bjarne Sjourstrup, the creator of C++, said at a recent talk). It’s available at http://www.boost.org/. Most of it is lower level than what we’re talking about here, though.
—-
The updating version is available at http://canadia.strafenet.com/index.php?title=Programmer%27s_Thesaurus
Posted on September 8th, 2007 by Chris.
Categories: Business/The Software Industry, Chris, Programming.
First of all: Some people probably know all about agile. If I asked them what Agile Development was, they’d be all over me about “people over practices” [1], scrum, Extreme Programming, the Agile Manifesto and a “mechanism for social change” [2] in a heartbeat, until I asked them to stop.
This is not for them.
In my case, however, I found an interesting and infuriating conundrum. When I Googled agile development, I found all sorts of articles about agile, but nothing that explained what it was. And even more frustrating, there were plenty of links that said “Click here to learn what agile is!” that would inevitably explain that Agile is a new method of development, Agile is about working together as a team, Agile is happiness and friendship.
If you have somehow read through billions of blog articles and well-written essays only to miss the point again and again, this is for you.
Posted on June 11th, 2007 by Tim.
Categories: Programming.
I saw a link to this page from Digg, listing 10 pieces of programming advice that should not be followed. One of them regards commenting (emphasis mine):
6) “Write lots of comments”
Make sure you comment your code. Otherwise, it will be impossible for anyone to understand - including yourself in a year or so. I have heard that many many times and thought that it was probably right. It makes sense after all, and I have often found use of comments when trying to find meaning in somebody elses code. Particularly, I have struggled with comment-less code and sworn that I would never make that mistake. However, this is mostly the case when the code is not self explanatory. Which it should be. If you feel the need to write comments in your code, I suggest you try to refactor instead, so comments won’t be needed. Renaming some variables or introducing a function call will probably do the trick. Context is better documented using assertions. In fact, a context that cannot be described using assertions is probably a bad sign!
There are times when comments serve a pupose though. Algorithmics can be hard to grasp and yet impossible to simplify through further abstractions. In such cases, you can explain yourself with comments. I think my colleague Lars Thorup pointed out a very good test for comments: they should contain the word “because”. This way, you know that you are answering a why rather than a what.
Oh, and my favourite specialization of the comments advice: keep a history of changes and author info etc. in the top of each file.
I’ve never actually heard anyone say that you should do this but I have seen it so many times that there must be people out there recommending it. Why on earth you would clutter the code with information that so obviously belongs in the version control system is just beyond me.
I think the key point here is that comments should explain “why” and not “what”. I don’t think I ever quantified what good comments were until now, but this makes lots of sense. Some “what” comments are good at the functional level for instance, because they summarize blocks of code, but most line-level comments should be explaining the “why.” If you have to explain to me what you’re doing in a line of code, then something tells me your code is pretty bad.
This is bad:
// Clears the frizzle of the froider
froider.ClearFrizzle();
This is good (sort of):
// Ensure ISO-900000 compliance by keeping our froiders clear
froider.ClearFrizzle();