NaNoWriMo time is upon us!

Of course this is only tangentially related to game development, but one thing you'll find as my blog matures is that I love a game with a good story. However, good storytelling in games is a different beast than good storytelling in books. For one thing, only perfectly linear games have stories that translate reasonable well to books. For another, you don't get to simply act out the battle scenes in books.

Anyway, to get to the point, November is National Novel Writing Month, or NaNoWriMo for short. You might think to yourself, why would anyone want to write a novel in a month? Well, ask the more than 100,000 people that participate every year. I suspect that a large number of game developers -- especially those interested in story-heavy genres -- have thought about it at one point in their lives. Just like the time-limited game development competitions, NaNoWriMo challenges you to get those creative juices flowing. Put your fingers to the keyboard and don't lift them up until you've reached your goal.

That goal is 50,000 words. In 30 days. That's 1,667 words per day every day of the month. A daunting goal to be sure, but over 20,000 people manage it. Sometimes they are established authors, but mostly they are just normal people like yourselves. Whether you start with a detailed outline or a blank file, there is fun to be had.

The perpetrator of this month of debauchery, Chris Baty, provides this guide to success:
No Plot? No Problem!: A Low-Stress, High-Velocity Guide to Writing a Novel in 30 Days

Vimrc Time!

Uh oh, only four posts in and my allegiances come out!

Since Vim 7.3 came out a couple weeks ago, it's about time for a celebration in the form of a vim post! Over the past couple years I have become a vim user. Although I had wanted to use either vim or emacs for some time, I had a lot of trouble getting into it. Where I work, we had Red Hat Enterprise Linux 3 machines when I first started. A lot of people used NEdit, a few (including my boss) used gvim, and a few used emacs. NEdit was intuitive and had syntax highlighting, so it was good enough for me at first.

Then we upgraded to RHEL5.

Oh NEdit was still there, but it had the really odd but entirely repeatable bug that caused the text on the screen to "get stuck" when scrolling. It was annoying enough that I wanted to switch editors immediately. Many NEdit users switched to Kate, which by all accounts is a fine upgrade from NEdit. But if I was going to make the switch, there was hardly a better time. I grabbed my boss' vimrc and jumped in head first.

It was slow going at first -- I still wanted to use the arrow keys for a while, and even now, two years later, I still find myself using the mouse and the Escape button on occasion when I don't need to do so. But even two years later I'm still learning things that boost my productivity. For example, only last week I started making use of macros, which I knew about for a while but never saw reason to use them.

Anyway, there's an important rite of passage for the vim user: putting together his very own .vimrc. It wasn't long before I had become curious about the options available, and browsing examples around the internet. Unfortunately I couldn't tell you the source of many of these settings, and a quick search shows many of them appear in many different examples. But whether you're already a vim user or you're just looking to get started, hopefully my short but sweet .vimrc shows you something useful.

Bonus: gvim can convert code into HTML, so I don't need to mess with raw HTML or tools like syntaxhighlighter to get (I hope) pretty code samples! This also has the benefit of showing off the awesome color scheme I use: wombat!

 1 " set color scheme
 2 colors wombat
 3
 4 " always have syntax highlighting
 5 syntax on
 6
 7 " always number lines
 8 set number
 9
10 " don't wrap long lines
11 set nowrap
12
13 " change tabs into 4 spaces
14 set shiftwidth=4
15 set expandtab
16 set shiftround
17
18 " autoindent new lines
19 set smartindent
20
21 " be quiet
22 set noerrorbells
23
24 " show matching braces
25 set showmatch
26
27 " highlight located search terms
28 set hlsearch
29
30 " normally don't automatically format 'text' (code) as it is
31 " typed, IE only do this with comments, at 79 characters:
32 set formatoptions-=t
33 set textwidth=79
34
35 " get rid of the default style of C comments, and define a
36 " style with two stars at the start of `middle' rows which
37 " (looks nicer and) avoids asterisks used for bullet lists
38 " being treated like C comments; then define a bullet list
39 " style for single stars (like already is for hyphens):
40 set comments-=s1:/*,mb:*,ex:*/
41 set comments+=s:/*,mb:**,ex:*/
42 set comments+=fb:*
43
44 " enable filetype detection:
45 filetype on
46
47 " let gvim know all of those *.cc* files are C++ files
48 au BufNewFile,BufRead *.cc* :set ft=cpp
49
50 " let gvim know all of those *.m* files are Matlab files
51 au BufNewFile,BufRead *.m* :set ft=matlab
52
53 " for C-like programming, have better automatic indentation
54 " and if starting a newline in the middle of a comment
55 " automatically insert the comment leader characters:
56 autocmd FileType c,cpp set cindent formatoptions+=ro
57
58 " in makefiles, don't expand tabs to spaces, since actual
59 " tab characters are needed, and have indentation at 8
60 " chars to be sure that all indents are tabs:
61 autocmd FileType make set noexpandtab shiftwidth=8

I believe it's well commented so nothing should need explanation. But if you do, or if you're proud of yours, feel free to comment. For more info, here is a highly rated book about vim:

Learning the vi and Vim Editors