Screenshot:
Download:
Follow the instructions in the zip to install it. You'll need Steam and Source SDK base 2007:
I consider Chexmod a failure, due to the long development time, the small amount of content in the released version, and the limited response.
Here are some things I learned about game design over the course of this project:
Even the smallest team must use SVN.
SVN (SubVersioN) lets you turn your game directory into a fancy shared folder that works over the Internet. It lets you incorporate new files from other team members into the game, while keeping everyone up to date with the game's source code.
Even if you don't need to share source code, SVN is absolutely necessary. Let's say a recent code change breaks multiplayer in your game, and you don't realize that until you go to do a beta test with the rest of the team. If you can identify the problem and quickly fix the code, SVN will let you push a small patch to everyone else in a matter of minutes, turning the code problem into a small hiccup.
In comparison, if you try to use Dropbox or Skype or something, you'll need to zip up a rather large DLL or EXE, wait for it to upload, then wait for everybody on the team to download it before continuing.
Here's all you need:
Open source SVN client: http://tortoisesvn.net/downloads.html
Free SVN hosting: https://www.assembla.com/home
Know the programing language and development environment you'll be using before you start making the game. Games are complex beasts, don't expect to learn how to write code “as you go”. For instance, Chexmod is built on the Source Engine, which uses C++ that compiles through the MSVC++ IDE. I spent many hours trying to figure out problems that would have had obvious solutions if I had learned C++ prior to working on the game. I also was not aware that the debugger could be tied into the game while running until recently. This would have vastly simplified development earlier in the project. Since I jumped into the game as a coding novice, I made many mistakes early on that took (literally) years to undo.
If you are building on an existing code base (IE: a mod), keep track of your changes in the code. It is easy to discount the importance of doing this if you are the only coder on the project. However, some bugs don't show themselves immediately, making it vitally important that you tag ANY major change that you make. Use something unique that it not written elsewhere, that you can search for later on. For instance, write “CHANGECHANGE” rather than “CHANGE”. If you know something is broken, but don't know why, mark it with “BUGBUG” or “FIXFIX”. If you fix something but had to write some really bad code to do it, mark it with “HACKHACK”.
These simple identifiers will help you go back to sections later and roll back changes in your code.
Have a release schedule. Even if it just seems like you're working on a silly game for your friends, you may want to release it online at some point in the future. Give yourself a time limit. Six months, a year, it doesn't matter. This will vastly improve the amount you get done between playtests.
Chexmod had this problem, I never really thought about putting it up online until a few months ago. It took 3 years for me to release an unfinished beta, don't do what I did.
In a previous blog post, I mentioned a strategy of making game assets as quickly as possible, with no regard for quality, in order to flesh out the game and have something to playtest. This does not work. Well, it works for a week or two; then you realize everything looks terrible, and it doesn't matter how great your code it. Perhaps this would work for a larger team, if one person did the temporary art, and somebody else did better versions of everything later. However, when it's just you going back and doing multiple passes on your own work, it ends up being frustrating and demotivating.
Once you know what art assets you need to make, take your time and make them look nice to being with.
Finally, perhaps the most obvious lesson:
Make a design document. This can be as simple as a prioritized list of ideas. It's easy when starting out to ignore this step and rush to the part where you start actually doing things. The problem is, if you approach it like this, you'll end up spending a lot of time on code/content that will not be used. If a gameplay element is going to take a lot of effort to code, you should build a prototype of it and playtest it extensively, rather than spending the time to make it prefect first. The biggest waste of time in the Chexmod project was on stuff was not used in the game. This is because there was never any sense of what systems/ideas were the most important to the project.
Avoid doing this. Make a document outlining what you want the game to be, and build it.
